ietf-mta-filters
[Top] [All Lists]

Re: [sieve] [Gen-art] Gen-ART Last Call Review of draft-ietf-sieve-include-13

2012-01-13 09:14:03
-- section 3.1, paragraph 4: "Implementations MUST NOT generate errors for
recursive inclusions at upload time, as this would force an upload ordering
requirement upon script authors / generators.  However, if an active script
is replaced with a faulty script and would remain the active script, an
error MUST be generated and the upload MUST fail."

These two statements seem contradictory on a quick reading.  In
particular, how can the latter assertion avoid an upload ordering
requirement? Or do you mean faulty in some way other than being recursive?

If you're replacing an active script, it has to be correct all the time, and
uploads are atomic only on a per-script basis. There's a risk that if you're
uploading a set of scripts that include one another, at some intermediate
stage while some scripts are uploaded but not others, they are in an invalid
state. The managesieve spec says that scripts must be validated at upload
time. The language above is trying to say that you can upload all of the
scripts that may include one another in any order without generating errors
immediately, however, if you're replacing an active script or a script
included by the active script, then you DO have to upload a correct script
right from the get-go.

Is this just a question of whether the script(s) are replacing active
scripts? That is, the license to create a transient invalid state is
suspended if if you are replacing an active script? If so, how would one go
about updating a set of linked scripts when one or more of them replace
active scripts? Should one somehow deactivate the old ones, load all the
scripts, then activate them?

Having written this out, I don't recall how an implementation would
handle this. I haven't had luck tracking down maling list discussion
on the topic. I'll have to chase up on this.

I don't think this is a real problem; the text just needs a little
tweaking.  Errors should still be generated at upload time for any
detectable script errors OTHER THAN recursion.  What this is meant to
deal with is a situation where, say, we have this:

main includes sub-a
   sub-a includes sub-b
      sub-b includes sub-c

...and we want to rewrite things and  change the structure thus:

main includes sub-a
main includes sub-c
   sub-c includes sub-b
     [sub-b no longer includes sub-c]

This would require that we update sub-b *before* we update sub-c, or
else we'd get an error at upload time.  The text is meant to block the
recursion error, so we can update the scripts in any order.  However,
if the script gets run in the middle of the updates and we hit a
recursion situation, we WILL get a runtime error.

That's all that text is meant to do.

That said, it would be wise for implementations to provide a way to do
an atomic update of a set of scripts, because, clearly, multiple
scrips in some indeterminate intermediate upload state could do very
weird (and perhaps bad) things, even if no errors are generated during
their execution.

I think this isn't a protocol requirement, but a
quality-of-implementation issue.  But I do think the document could
have a paragraph discussing this, and warning of the consequences.

Barry, document shepherd
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve

<Prev in Thread] Current Thread [Next in Thread>