ietf
[Top] [All Lists]

Re: Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05

2009-08-13 13:45:49
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.

FWIW, it looks like there's a serious problem with the XML Schema that's
going to require some changes to address.

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.

OK, let's look at the facts. Sieve was iniitally standarded in 1991 (RFC 3028),
a document that defined three control elements: if, stop, and require.

There have subsequenty been, by my count, 29 revisions or new documents written
that extent or enhance Sieve in some way, including at least one that applies
Sieve in a very different context than it was designed for. Of those around 16
have been published as RFCs.

In all of those documents there has been exactly one that proposed new
controls: The MIME loops document now under consideration, which defines the
controls foreverypart and break. (I note in passing that the language used in
the draft is incorrect - it calls them actions, not contorls.)

Moreoever, work on Sieve extensions is finally winding down - the rate at which
entirely new proposals are being created right now is for all intents and
purposes zero.

So we started with a list of 3 items, and in almost 9 years it's had one
addition, extending it to 5 items. And that's over a period of active
development, which is now coming to an end.

And when such a change occurs all that needs to be done to satisfy this
language requirement is add the new items to an internal list. Whereas in order
to actually support the procesing of a new control in any nontrivial fashion
that would actually call for distinguising it from an action would almost
certainly require quite a lot more work.

This is an update problem and associated rate of change I for one can live with
very easily.

Nevertheless, it seemed like a good idea to make the current list explicit
in the document, so I've gone ahead and done that:

  The separation of controls from actions in the XML representation
  means that conversion from normal Sieve format to XML has to be able
  to distinguish between controls and actions.  This is easily done by
  maintaining a list of all known controls since experience indicates
  new controls are rarely added.  At the time of this writing the list
  of defined and proposed controls consists of:

  1.  if [RFC5228],

  2.  stop [RFC5228],

  3.  require [RFC5228],

  4.  foreverypart [I-D.ietf-sieve-mime-loop], and

  5.  break [I-D.ietf-sieve-mime-loop].

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?

OK, so how about:

 It should be noted that with this approach unknown controls will simply be
 treated as actions and can be passed back and forthe between the two
 representations. The treatment of a control as an aciton is unlikely to
 cause other issues since knowledge of a control's language semantics is
 almost always required to take of advantage of it.

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?

I don't think this is really necessary, but it seems mostly harmless, so how
about:

 The term "processor" is used throughout this document to refer to agents
 that convert Sieve to and from the XML representation. The term "editor"
 refers to agents that operate on, possibly creating or modifying, Sieves
 in XML format.

-- Section 1, paragraph 3:

Is there an expectation that a UI could generate new sieve scripts in
XML format from scratch?

Sure.

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?

Nowhere does this document say or even imply that no semantic knowledge of
Sieve is required to construct a Sieve from scratch using the XML
representation. Such a claim would be absurd in any case - it is axiomatic that
in order to construct a program you have to know what the elements in the
language do!

What the document does say (section 4.1, fourth paragraph) is that XML can be
used to avoid the need for a client to understand sieve *grammar* or to have a
full understanding of Sieve semantics. Syntax understanding is made unnecesary
by substituting XML syntax, of course. As for semantics, a processor can be
written (and many have been) that only look at the metadata elements
(displayblock and so on) and treat all the Sieve stuff under those elements as
a black box.

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

It's pretty much entire point of this specification is that it won't be lost by
conversion processing. This section is talking about operating on Sieves in
XML, not the conversion process between XML and regular format.
The reality is different editors are going to use the various meta-data
facilities differently. When one editor encounters another editor's stuff, it
has to decide what to do with it. There's no one right answer here: in some
cases it makes sense to try and preserve it, in others the sensible thing to do
is discard it. In fact there are probably legitimate use cases where the only
possible answer is to discard. This section is simply documenting that there's
no one right answer.

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

Of course not. Since when do we have programs capalable of taking completely
arbitrary natural language statements and reliably encoding them into
programming language statements?

I see nothing unclear about this at all.

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

It's a SHOULD because the WG believed that there may be some exception cases
where an alternate format makes more sense.

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

The point of Sieve namespaces is to allow multiple XML vocabularies to be used
in a single document. This is a completely open ended mechanism and it is not
our intent to label any particular use as inappropriate. As such, unless you
have some specific text in mind, I for one fail to see what could be added here
that would be useful.

Nits/editorial comments:

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

Fixed, thanks.

                                Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf