Document: draft-freed-sieve-in-xml-05
Reviewer: Ben Campbell
Review Date: 2009-08-11
IETF LC End Date: 2009-08-13
IESG Telechat date: 2009-08-13


Note: The LC end and the Telechat are on the same day, so this review serves as both a last call and telechat review.


Summary:  This draft is almost ready for publication as a draft standard. There are some issues and questions that I think should be resolved prior to publication.

Note: I am not an XML expert. I have not attempted any sort of mechanical validation of the schema or style sheet included in this draft. If this has not been done already, it probably should prior to final publication.


Major issues:


-- This draft depends heavily on the premise that SIEVE control structures are rarely extended, and can be known to a conversion process in advance. However, if I understand correctly, there is another draft under review right now that adds new controls (namely draft-ietf-sieve-mime-loop)--so I'm not sure I accept that premise. At the least, the draft should discuss what would happen if a conversion process encounters an unknown control, and how a human user might detect and correct the problem.  In particular, would a round-trip conversion process on a sieve script that contained an unknown control render the equivalent script?


Minor issues:

-- General:

It would be helpful to have up front definitions of the terms "editor"  
and "processor". They are used throughout the document, and have normative requirements placed on them. I gather from context that "editor" is a UI, and "processor" is something that performs the sieve- to-xml round trip transformations?

-- Section 1, paragraph 3:

Is there an expectation that a UI could generate new sieve scripts in XML format from scratch? If so, can it generate illegal sieve scripts from the XML? How can it avoid doing so if it doesn't have a semantic knowledge of sieve?

  -- Section 4.1, paragraph 9 (starts with "Editors MAY use displayblock,..."

I'm not sure I understand what you mean by "preserve this data", in particular with the bit about "..editors may find it inconvenient" If they _don't_ preserve the information, won't it get lost in a round trip conversion?

-- Section 4.1, paragraph 11:  "Implementations MAY use this to represent complex data 
    about that sieve such as a natural language representation of sieve
    or a way to provide the sieve script directly."

I'm not sure I understand the last part  --are you saying this can be used as an alternate encoding of the script?

-- Section 4.2, paragraph 5: " ... SHOULD use the structured comment format shown above."

Why not MUST? Wouldn't violation of this requirement introduce interoperability problems between different implementations?

-- Security Considerations, last paragraph:

You mention that potentially executable content can be introduced via other namespaces, and that "appropriate security precautions" should be taken. I think this needs more discussion, as I am not sure an implementor will understand what the authors considered appropriate.

Nits/editorial comments:

-- Section 3, last paragraph: First sentence is repeated.