Document:  draft-ietf-sieve-rfc3598bis-04.txt
Reviewer: Sharon Chisholm
Review Date:  Wednesday 5/24/2006 3:00 PM CST
IETF LC Date:  23 May 2006

Summary: This draft is basically ready for publication, but has nits that
	 should be fixed before publication.

Comments:

1. In section 2, it says "Conventions for notations are as in
[I-D.ietf-sieve-3028bis] section
   1.1.", but it isn't clear which notations one would expect to find
there. 2028bis describes itself as "a language for filtering email
messages at time of final delivery". Could we instead then say "This
document uses the language for filtering emails at the time of final
delivery defined in [I-D.ietf-sieve-3028bis]. It therefore uses the
grammar and conventions defined within that specification.". Note that
section 1.1 is not self contained so pointing only to that section
doesn't seem sufficient. Also, the reference in its current form
under-sells the fact that a reasonable understanding of the language
defined in 3028bis is required for this document to make any sense.

2. There appears to be something magical about being able to split the
local address into its two pieces - user and detail. The document does
already have a number of disclaimer around this, but it doesn't quite
seem sufficient. 

2.1 Perhaps if the document contained some elements of procedure that
went something like

- Perform implementation/mail-system specific method of parsing out user
and detail from local address
- Use these two values to evaluate the statements defined in the sieve
language, including this subaddressing extension

2.2 Can we get more prescriptive as to what the encoding would be for
specific mail systems?

3. For the security considerations section, are there not any new ways
to badly format an email address as a result of this extension that
could cause damage to either the mail server or the user?

4. The use of double quotes in this document is quite confusing. Some
instances are to indicate values of fields or of keywords in the sieve
language. Others appear to be random words in sentences. I realize this
is not a change from the previous version of the RFC, but it does make
the document awkward. The editor should determine what double quotes are
being used for in the document, ensure this both adds clarity and makes
grammatical sense and then delete all other occurrences.

5. The section "Meta-information on this document" provides some
information that presumably the RFC editor is to remove. The section is
not very specific on exactly what information needs to get removed and
by whom.