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 apps-discuss@ietf.org
    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.