--- Begin Message ---
Ken Murchison wrote:
Thanks for the comments. My responses are interspersed below.
Hi,
Just a couple of additional comments.
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.
(Draft is referring to use ot 2119 key words and "Usage:" convention.
But this is not really relevant as per Ken's comment below).
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
I though this was obvious, but if you think it is not, this text can be
added. Can you suggest the place?
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.
Indeed. The original RFC 3598 only documented the most common schema
user+detail, however several WG members wanted more flexibility, as
existing implementations use different separator ("-" or "--"),
different order of user/detail and can even encrypt them.
I'll let the WG chairs decide whether we should wade back into that pool.
No, if I can avoid it ;-).
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.
I agree.
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).
Yes, I agree that emphasizing something in plain text can be a problem.
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?
Looking at the document <"> is used for emphasizing terms and for
quoting string values (a la C). I personally don't find this
particularly confusing and I think the document should use something for
each purpose. Maybe use single quote <'> for terms?
(Apart from that I would rather leave the document as is)
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.
Ken, as you will be updating the draft anyway, can you add "RFC editor's
note:" there?
--- End Message ---
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
