I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
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.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf