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

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 24 May 2006 16:00:24 -0400

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.

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.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

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

---

From: Alexey Melnikov <[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:
>> 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
> 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.
>
I though this was obvious, but if you think it is not, this text can be 
added. Can you suggest the place?

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

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

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 May 2006 16:51:00 +0100

Ken Murchison wrote:

> Alexey Melnikov wrote:
>> Ken, as you will be updating the draft anyway, can you add "RFC 
>> editor's note:" there?
>
> If I'm going to make a -05, why don't I just remove that section 
> entirely?

This is Ok.
I slightly prefer keeping the section, so that you can describe changes 
since -04.
But this is up to you.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 26 May 2006 08:50:18 -0400

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.2 Can we get more prescriptive as to what the encoding would be for

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.

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.

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

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Ken Murchison <[email-masked]>
Date: Fri, 26 May 2006 11:49:22 -0400

> Ken, as you will be updating the draft anyway, can you add "RFC editor's 

If I'm going to make a -05, why don't I just remove that section entirely?