Thanks for the comments. My responses are interspersed below.
Sharon Chisholm wrote:
Attached is my review of the specified document, submitted as part of
the Gen-ART process. For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Document:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-04.txt
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.
After looking at my draft and 3028bis again, I think the sentence in
question can be removed from the draft, as none of the notation spelled
out in 3028bis section 1.1 is used in the draft.
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?
Members of the WG specifically wanted the draft to allow for flexibility
in how the address is encoded. I'll let the WG chairs decide whether we
should wade back into that pool.
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?
This extension has no bearing on how addresses are formatted, it just
extends the Sieve syntax for parsing addresses, therefore IMO it doesn't
add any additional security issues.
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.
I see your point, but given that RFCs are primarily text-only documents,
the only ways to emphasize a term or phrase is by using quotes or CAPS
(rather than a different font or face). My thought is that readers that
are familiar with 3028bis, RFC 2821 and RFC 2822 will not be confused,
but I could be wrong. Any thoughts from the chairs?
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.
The RFC editor will remove the entire section as has been done with
other drafts.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
