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

[Barry Leiba <[e-mail]>]

>>> -- 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