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

[S Moonesamy <[e-mail]>]

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 
>first, and then discuss the components one-by-one.

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 
>user if the descriptive name of a mailing list changes."

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 
>names, then we are back to ".invalid". I suggest sorting this out better.

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.
>This will lead to a better balance of sections and subsections.

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.

>"This Internet-Draft can be discussed on the [e-mail]
>    mailing list.  [RFC-Editor: please remove this paragraph]":
>"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 
>"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).

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 
>ignore.": "that" -> "which" ("that" cannot start a nonrestrictive clause)

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"

:-)

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

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