Subject: [apps-discuss] APPSDIR review of draft-moonesamy-rfc2919bis-04

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 13 Mar 2012 19:38:38 +0900

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-moonesamy-rfc2919bis-04
Title: List-Id: A Structured Field and Namespace for the Identification 
of Mailing Lists
Reviewer: Martin Dürst
Review Date: March 13, 2012

Summary: This draft is close to being ready for publication on Standard 
Tracks, with the exception of Internationalization concerns, which seem 
to have been forgotten completely

General comment: I'm somewhat unsure about the need for this update. But 
if somebody is doing the actual work, I don't mind.
[After completing this review, I realize that I have probably invested 
too much work to let the above comment stay. But I definitely didn't 
want to disappoint our Team Lead.]

Major Issues:

Internationalization of list identifiers seem to have been completely 
ignored. How is a list id from an IDN domain used? One option is 
punycode, but this is really ugly (and would mean MUAs have to translate 
to readable text). Also, it might make conversion to/from EAI messages a 
real pain.

There is a tension between "the owner of a mailing list MUST NOT 
generate List Identifiers in any domain name space for which they do not 
have authority" and "As such the mailing list administrator should avoid 
changing the List Identifier even when the host serving the mailing list 
changes.". The MUST NOT is worded more strongly, but I think we want the 
second part to win in case of conflict.

Minor Issues:

"List manager" is used throughout the document. When reading, I first 
associated a person with this term, which was of course confusing. I 
propose to change to another term or at least to explain the term on its 
first use.

"This document obsoletes RFC 2919 [RFC2919].": I was really wondering 
here what changed. At least provide a pointer to Appendix B here.

"and on other messages where the message clearly applies to this 
particular distinct mailing list.": It would be good to give a few 
examples here. I was thinking that this would mean bounce messages, 
subscription confirmations, and the like, but I wasn't sure I got that 
right.

"This field MUST only be generated by mailing list managers, not MUAs.": 
What about MTAs?

"The contents of the List-Id header field mostly consist of": "mostly 
consists of" is really confusing. It would be better to give the syntax 
first, and then discuss the components one-by-one.

"As such the mailing list administrator *should* avoid changing the List 
Identifier even when the host serving the mailing list changes." (and 
some other instances): Please avoid lower-case normative keywords. They 
are confusing. (one other example I found: "the MUA *may* inform the 
user if the descriptive name of a mailing list changes."

"On the other hand, transitioning from an informal 
unmanaged-list-id-namespace to a domain name space is an acceptable 
reason to change the List Identifier.": There seems to be some confusion 
between names and namespaces. In my understanding, there are only two 
namespaces. Did I get something wrong?

Section 5 (Uniqueness): The first two paragraphs are about ".invalid", 
then there is a paragraph about list ids derived from existing domain 
names, then we are back to ".invalid". I suggest sorting this out better.

"A List Identifier using the special "invalid" namespace SHOULD include 
the month and year (in the form MYYYY), i.e. the List Identifier is a 
"subdomain" of the "invalid" namespace.": Why be imprecise first and 
then give the details in the example? What about: ""A List Identifier 
using the special "invalid" namespace SHOULD include a subdomain with 
the month and year (in the form MMYYYY)."

Why is it MMYYYY? This may be legacy, but if not, it definitely should 
be YYYYMM.

"Such a namespace is inherently flat, unmanaged and thus non-unique.": 
The namespace is flat, but *names in it* are non-unique.

Nits:

Structuring of "1. Introduction": Add a subsection heading "Overview" 
close to the start of the section; merge Terminology and Syntax Notation 
into one subsection (e.g. Terminology and Notation).
Also, consider merging some of the very small sections into bigger 
sections with subsections. As an example, the discussion of Persistence 
and Uniqueness should probably be folded into the "List Identifier" Section.
This will lead to a better balance of sections and subsections.

Provide a short overview (by section) of the doc at the end of the 
general part of the Introduction Section.

"This Internet-Draft can be discussed on the [email-masked]
    mailing list.  [RFC-Editor: please remove this paragraph]":
"paragraph" -> "subsection"

Section 2, "Where" part after "Syntax": I'd prefer to see the reference 
to [RFC2606] immediately after the first mention of "invalid". Then that 
item in the "Where" part could be removed. The explanation of 
"dot-atom-text" would best be moved into the syntax, as follows
   dot-atom-text-enc = <as defined in [RFC5322]>
(see also http://tools.ietf.org/html/draft-duerst-eai-mailto-02 for 
similar examples).

"There MUST be not be more than one of List-Id header field in any given 
message." -> "There MUST not be more than one List-Id header field in 
any given message."

"consist of angle-bracket ('<', '>') enclosed identifier": "consist of 
an identifier enclosed by angle-brackets ('<' and '>')"

"Client applications SHOULD treat any such whitespace, that might be 
inserted by poorly behaved mailing list managers, as characters to 
ignore.": "that" -> "which" ("that" cannot start a nonrestrictive clause)

"While it is perfectly acceptable for a List Identifier to be completely 
independent of the domain name of the host machine servicing the mailing 
list, the owner of a mailing list MUST NOT generate List Identifiers in 
any domain name space for which they do not have authority.": A 
normative sentence (MUST NOT and such) should stand on its own wherever 
possible (and the above sentence is longish anyway).

"from an informal unmanaged-list-id-namespace to a domain name space": 
Please check for consistent spelling of name space/namespace. (namespace 
is better, because most people will parse "domain name space" as (domain 
name) space.

"month and year (in the form MYYYY)": "MYYYY" -> "MMYYYY"

"6.  Operations on List Identifier*s*"

"The comparison operation MUST ignore any part of the List-Id header 
field outside of the angle brackets, the MUA may inform the user if the 
descriptive name of a mailing list changes.": This looks like it wants 
to be two sentences to me.

"however, this will only be possible when the nested mailing list is 
aware of the relationship between it and its "parent" mailing lists.":
Please change "it and its" to "itself and its". Also, please change 
"aware" to a less personifying term.

"If a mailing list manager encounters List-Id header fields from any 
unexpected source it SHOULD NOT pass them through to the mailing list.

As mentioned above, mail list managers should not allow any 
user-originated List-Id header fields to pass through to their lists, 
lest they confuse the user and have the potential to create security 
problems.": Please eliminate repetition.

"Removed List-Sequence header field as it does not fit it": What does 
not fit what?

Regards,    Martin.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 13 Mar 2012 15:42:56 -0700

Hi Martin,
At 03:38 13-03-2012, Martin J. Dürst wrote:
>Summary: This draft is close to being ready for 
>publication on Standard Tracks, with the 
>exception of Internationalization concerns, 
>which seem to have been forgotten completely
>
>
>General comment: I'm somewhat unsure about the 
>need for this update. But if somebody is doing the actual work, I don't mind.
>[After completing this review, I realize that I 
>have probably invested too much work to let the 
>above comment stay. But I definitely didn't want to disappoint our Team Lead.]

I don't think that the Team Lead would be 
disappointed as the reviews are exceeding expectations. :-)

I'll label my response as an individual comment 
as I still have to discuss with my co-authors about the review.

The updated started as a clean-up of RFC 2919 
while I was working on an implementation.  It is 
also to facilitate the internationalization 
aspect and IETF work on its mailing lists.

>Major Issues:
>
>Internationalization of list identifiers seem to 
>have been completely ignored. How is a list id 
>from an IDN domain used? One option is punycode, 
>but this is really ugly (and would mean MUAs 
>have to translate to readable text). Also, it 
>might make conversion to/from EAI messages a real pain.

I am glad that you raised this question as it 
should be given some thought.  Although the draft 
does not discuss about internationalization or 
IDNs, I went through the text to see whether 
there were any possible issues which would affect 
future work.  Internationalization would be more 
than referencing the IDNA documents; the header 
field would have to be RFC 6532 compliant instead 
of RFC 5322 compliant.  That opens a new set of 
issues to be considered and it is better to do that through the EAI WG.

The internationalization alternative is to see 
whether the MTA performing final delivery is 
SMTPUTF8-aware.  It might be better to avoid 
getting into MUA "downgrades"; it's less work to 
rely on RFC 5721 or RFC 5738 support.

>There is a tension between "the owner of a 
>mailing list MUST NOT generate List Identifiers 
>in any domain name space for which they do not 
>have authority" and "As such the mailing list 
>administrator should avoid changing the List 
>Identifier even when the host serving the 
>mailing list changes.". The MUST NOT is worded 
>more strongly, but I think we want the second part to win in case of conflict.

Here's the text from Section 2 of -03:

   "While it is perfectly acceptable for a List Identifier to be
    completely independent of the domain name of the host machine
    servicing the mailing list, it is recommended that the owner of a
    mailing list avoids generating List Identifiers in any domain name
    space for which they do not have authority."

I avoided changing the requirements from RFC 2919 
given the intended status of the draft; hence the 
"MUST NOT generate".  The reverted text (see 
Appendix C.1) is based on advice from the Sponsoring AD.

>Minor Issues:
>
>"List manager" is used throughout the document. 
>When reading, I first associated a person with 
>this term, which was of course confusing. I 
>propose to change to another term or at least to 
>explain the term on its first use.

The term "mailing list manager" (MLM) is used 
throughout the draft.  As it's a well-known term 
in email circles, I expect push-back if I try to 
change it.  I could modify the sentence in the Introduction Section as follows:

    draft-moonesamy-rfc2369bis [ID.moonesamy-rfc2369bis] expands the
    functionality that the Mail User Agent (MUA) can provide by providing
    more information in each message sent by a software agent which is
    generally known as the mailing list manager (MLM)

>"This document obsoletes RFC 2919 [RFC2919].": I 
>was really wondering here what changed. At least 
>provide a pointer to Appendix B here.

That sentence is to be in line with RFC Editor 
policy.  I'll add "(see Appendix B).

>"and on other messages where the message clearly 
>applies to this particular distinct mailing 
>list.": It would be good to give a few examples 
>here. I was thinking that this would mean bounce 
>messages, subscription confirmations, and the 
>like, but I wasn't sure I got that right.

List Identifiers can be added for administrative 
messages in respect to a mailing list.  By making 
a distinction, e.g. providing examples, this may 
be interpreted narrowly.  It's better to leave it 
to good judgement, hence the "clearly applies to 
this particular distinct mailing list"

>"This field MUST only be generated by mailing 
>list managers, not MUAs.": What about MTAs?

The mailing list manager performs mailing list 
operations; the MTA doesn't.  A MTA passes
messages without modification to the message data 
other than adding trace information.

>"The contents of the List-Id header field mostly 
>consist of": "mostly consists of" is really 
>confusing. It would be better to give the syntax 

Given that the text was already in RFC 2919, I 
prefer not to change this.  I'll discuss the above with my co-authors.

>"As such the mailing list administrator *should* 
>avoid changing the List Identifier even when the 
>host serving the mailing list changes." (and 
>some other instances): Please avoid lower-case 
>normative keywords. They are confusing. (one 
>other example I found: "the MUA *may* inform the 

I understand your point.  As it may be pointed to 
the authors that such changes are stylistic in 
the context of this draft (see intended status), 
I'll defer to the Sponsoring AD.

>"On the other hand, transitioning from an 
>informal unmanaged-list-id-namespace to a domain 
>name space is an acceptable reason to change the 
>List Identifier.": There seems to be some 
>confusion between names and namespaces. In my 
>understanding, there are only two namespaces. Did I get something wrong?

The domain name space is used as a basis for the 
List Identifier 
namespace.  "unmanaged-list-id-namespace" comes 
from the syntax.  It's not "namespace".

>Section 5 (Uniqueness): The first two paragraphs 
>are about ".invalid", then there is a paragraph 
>about list ids derived from existing domain 

The first two paragraphs of Section 5 are not 
about ".invalid"; they are about 
uniqueness.  ".invalid" is first mentioned in the fourth paragraph.

>"A List Identifier using the special "invalid" 
>namespace SHOULD include the month and year (in 
>the form MYYYY), i.e. the List Identifier is a 
>"subdomain" of the "invalid" namespace.": Why be 
>imprecise first and then give the details in the 
>example? What about: ""A List Identifier using 
>the special "invalid" namespace SHOULD include a 
>subdomain with the month and year (in the form MMYYYY)."

Please see the above comment about the first two 
paragraphs.  Section 5 is about the uniqueness of List Identifiers.

>Why is it MMYYYY? This may be legacy, but if 
>not, it definitely should be YYYYMM.

BTW, there is a typo in -04, it ought to be 
MMYYYY as in RFC 2919.  This is legacy.  As there 
are four digits for the year, the month won't be confused with it.

>"Such a namespace is inherently flat, unmanaged 
>and thus non-unique.": The namespace is flat, but *names in it* are non-unique.

I'll fix that as follows:

   Such a namespace is inherently flat, unmanaged 
and thus names in it are non-unique.

>Nits:
>
>Structuring of "1. Introduction": Add a 
>subsection heading "Overview" close to the start 
>of the section; merge Terminology and Syntax 
>Notation into one subsection (e.g. Terminology and Notation).

I'll take this with you off-list and post a summary to apps-discuss.

>Also, consider merging some of the very small 
>sections into bigger sections with subsections. 
>As an example, the discussion of Persistence and 
>Uniqueness should probably be folded into the "List Identifier" Section.

Yes, but it makes it changes the text ordering 
when we compare the draft with RFC 2919.  Let me ask my co-authors about this.

>Provide a short overview (by section) of the doc 
>at the end of the general part of the Introduction Section.

I'll discuss this with you off-list.

>"paragraph" -> "subsection"

Ok.

>Section 2, "Where" part after "Syntax": I'd 
>prefer to see the reference to [RFC2606] 
>immediately after the first mention of 
>"invalid". Then that item in the "Where" part 
>could be removed. The explanation of 
>(see also 
>http://tools.ietf.org/html/draft-duerst-eai-mailto-02 for similar examples).

I'll get back to you on this.

>"There MUST be not be more than one of List-Id 
>header field in any given message." -> "There 
>MUST not be more than one List-Id header field in any given message."

Ok.

>"consist of angle-bracket ('<', '>') enclosed 
>identifier": "consist of an identifier enclosed 
>by angle-brackets ('<' and '>')"

Ok.

>"Client applications SHOULD treat any such 
>whitespace, that might be inserted by poorly 
>behaved mailing list managers, as characters to 

Ok.

>"While it is perfectly acceptable for a List 
>Identifier to be completely independent of the 
>domain name of the host machine servicing the 
>mailing list, the owner of a mailing list MUST 
>NOT generate List Identifiers in any domain name 
>space for which they do not have authority.": A 
>normative sentence (MUST NOT and such) should 
>stand on its own wherever possible (and the above sentence is longish anyway).

I prefer to leave this one as it is or else I 
would have to argue that it is not a change in the requirement.

>"from an informal unmanaged-list-id-namespace to 
>a domain name space": Please check for 
>consistent spelling of name space/namespace. 
>(namespace is better, because most people will 
>parse "domain name space" as (domain name) space.

Ok.  I'll follow up on this off-list.

>"month and year (in the form MYYYY)": "MYYYY" -> "MMYYYY"

:-)

>"The comparison operation MUST ignore any part 
>of the List-Id header field outside of the angle 
>brackets, the MUA may inform the user if the 
>descriptive name of a mailing list changes.": 
>This looks like it wants to be two sentences to me.

Ok.

>"however, this will only be possible when the 
>nested mailing list is aware of the relationship 
>between it and its "parent" mailing lists.":
>Please change "it and its" to "itself and its". 
>Also, please change "aware" to a less personifying term.

That would be Section 7:

   "A list that is a sublist for another list in a nested mailing list
    hierarchy MUST NOT modify the List-Id header field; however, this
    will only be possible when the nested mailing list can determine
    the relationship between itself and its "parent" mailing lists.

>"If a mailing list manager encounters List-Id 
>header fields from any unexpected source it 
>SHOULD NOT pass them through to the mailing list.
>
>As mentioned above, mail list managers should 
>not allow any user-originated List-Id header 
>fields to pass through to their lists, lest they 
>confuse the user and have the potential to 
>create security problems.": Please eliminate repetition.

I'll give a quick OK while I ask my co-authors about this.

>"Removed List-Sequence header field as it does 
>not fit it": What does not fit what?

That was a comment to track changes in the 
draft.  It was pointed out to me that the 
List-Sequence header field is not related to the topic discussed in the draft.

Thanks for the thorough review.  I appreciate the effort you put in.

Regards,
S. Moonesamy