Subject: [Gen-art] [Fwd: Re: Gen-art review of http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-04.txt]

From: Alexey Melnikov <[email-masked]>
Date: Tue, 04 Jul 2006 20:02:45 +0100

Subject: Re: Gen-art review of http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-04.txt
From: Alexey Melnikov <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Cc: Ken Murchison <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Fri, 26 May 2006 14:31:23 +0100

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?

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art