Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01

[S Moonesamy <[e-mail]>]

Hi Murray,
At 16:10 05-01-2012, Murray S. Kucherawy wrote:
>First, I suggest this be sent to the "ietf-822" list as well as the 
>lists of MLM package developers, such as Mailman.  I'm on both 
>already and can forward it if you like.

Thanks for the feedback.  Can you forward it to those lists?  I asked 
for feedback from a mailman developer and other MLM implementors.

>A few cursory review points based on a diff of the old ones to the 
>new ones (and apologies for jumping back and forth between documents 
>as I go here):
>
>0) What's the rationale for doing this work now?

RFC 2369 was published over ten years ago.  The major change since 
then is the use of URI schemes.  I was reusing some old code and had 
to figure out which up-to-date RFCs to use.  I added the odds and 
ends I found to the drafts.

>1) Have the original authors of these documents been contacted to 
>see if they want to

I emailed to the original authors.  If anyone has an up to date 
contact for them, please email me.  BTW, I am listed as an editor and 
not the author.  There is a "most of the text in this document" 
sentence in the Acknowledgement section.

>participate in the update?  Has their permission been secured to 
>republish substantial chunks of their original text?  The IPR 
>statement in your draft should reflect this either way.

The "Status of this Memo"  Section mentions that:

   "This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79."

I don't think there is any issue about that.

>2) It seems to me both of these would be helped (in the "can't hurt" 
>sense) by an informative reference to RFC5598 just so there's a 
>handy illustration of how all these components fit together.

I kept the References section lightweight by only adding what is 
necessary for someone to understand what is in the document and to 
implement it.  I prefer not to add more informative references.

>3) The deletion of Appendix A from RFC2369 is conspicuous.  Why 
>remove all of that supporting discussion?  I suppose since this 
>stuff has been out there for a while now it'd be sufficient to 
>mention in later sections that such discussion exists in the original document.

There is an informative reference to RFC 2369 in the draft.  As such, 
people who are interested in why RFC 2369 was written in such a way 
will find the supporting discussion.    I am going to leave this 
comment open (whether it is worth explicitly pointing out).

>4) The language at the top of 3.1 sounds vaguely like a minimum 
>compliance statement.  I suggest it be reworked to something 
>simpler, like striking everything from "is the most" up to and 
>including "by definition it".

The language is similar to what was in RFC 2369.  I'll change it to 
the following:

    The List-Help header field can direct the user to complete
    instructions for all other commands.  Typically, the URI
    specified would request the help file, perhaps incorporating
    an HTML form for list commands, for the list, and alternatively
    provide access to an instructive website.

BTW, most subscribers find web forms more accessible then interacting 
with a MLM by email.

>5) Adding ABNF for each of the header fields would be good.   Right 
>now there's only ABNF for List-Sequence.

Ok.

>6) The various URI constructions might benefit from being enabled by 
>what's specified in draft-gregorio-uritemplate (now in IESG 
>Evaluation, so it might be an RFC soonish), which would allow the 
>defined header fields to contain values expanded by the MUA, something like:
>
>         List-Help: <mailto:[e-mail]?subject=help?user={user}>
>
>...and then just define that when expanding such templates, "user" 
>is the email address the MUA is using.

There is a discussion about variable substitution in Appendix A.5 of 
RFC 2369.  It explains why that was not added.  I'll leave this comment open.

>7) In 3.5 of RFC2369bis (and of its antecedent), the "There is no 
>need" sentence seems odd.  If the MUA is supposed to use 
>"postmaster" to contact the owner in the case of a list that doesn't 
>add this, what domain name should it use?

The List-Owner may not necessarily be the postmaster.  For example, 
in a hosted environment, the administrative role may be delegated to 
the person running the mailing list as it is easier to have them 
answer questions about how to unsubscribe or to act as a first point 
of contact for mailing list issues.

Using this mailing list as an example, there isn't a List-Owner 
header field.  Some of the subscribers know that they can contact 
ietf-action if there is a problem.  As the email has ietf.org in the 
return-path, the contact address would be [e-mail].

"There is no need" could be read as "we know that the postmaster is 
the human contact if there is a mail problem".  If you look at this 
from a different angle, the users contact their postmaster and the 
latter figures out how to reach a human contact at the other end.

>8) There's normative language in the Client Implementation appendix, 
>carried over from the previous version.  I think this should be 
>softened, or it should become a non-appendix normative section on 
>its own.  You might, however, get some resistance from people about 
>putting normative guidance to MUAs in a document since it's often 
>said that the IETF the-opposite-of-expert at user interface concerns.

Did you mean normative language in Appendix B?

It is often said that the IETF does not have the expertise to make UI 
recommendations.  I usually read that as a code word. :-)  FWIW, as 
the appendix is about guidelines, it should be read as informative.

>9) There's a mix of SHOULD and should in here.  Since you're citing 
>2119 they all mean the same thing, but the mixed case will leave 
>some people wondering.  I suggest using SHOULD everywhere that you 
>mean it, and alternatives elsewhere ("might", "are advised to", etc.).

Ah, I see, you mean the lowercase "should"?  I'll replace the should 
with non-normative words.

>10) List-ID uses the domain name space, even if the domains don't 
>actually exist.  Do we need to talk about IDNA at all here?

If I had to describe 2919bis in a few words, I would use "in most 
cases, appear like a host name in a domain of the list owner" 
(Section 2).  List-ID is borrows the syntax from an established 
namespace to get some form of uniqueness.

I would have to ask the EAI WG if I introduce IDNA in 2919bis as they 
have been doing some work in this area.  It is possible to 
internationalize 2369bis and 2919bis but that won't address the 
issues as they occur at 5335bis and 5336bis "layers".  I restate your 
question as "can we get away with not talking about IDNA" and I think 
that the answer is yes.

FWIW, it would not be that much of an additional effort to use IDNA 
without discussing about the issues.

>11) Kudos for moving a SHOULD out of the Introduction in RFC2369bis.

Thanks.

>12) There's a place in Security Considerations where it makes a 
>normative assertion that user-generated List-* fields need to be 
>deleted by the MLM.  I think that should be in a normative part of 
>the document rather than Security Considerations.  Rather, Security 
>Considerations might talk about the risks created if an MLM doesn't comply.

That would be:

   "Mailing list managers should not allow any user-originated list
    header fields to pass through to the mailing lists, lest they confuse
    the user and have the potential to create security problems."

It looks more like a security consideration.  In Section 3, there is:

   "There MUST be no more than one of each header field present in
    any given message."

and:

   "These header fields MUST only be generated by mailing list managers,
    not by MUAs."

I have not tested whether existing implementations bounce user 
generated messages which contain List- headers.

>13) The change from "localhost" (which might actually resolve, if 
>that matters) to "invalid" makes sense, but I'm somehow worried 
>about backward-compatibility issues.

Me too.  I haven't seen a case where "localhost" is used.  I assume 
that the fallback is "localhost.localdomain" in environments where a 
valid domain name is not available.  That's incorrect though.  One of 
the arguments in RFC 2919 was "users unable to afford domain name 
registration fees".  That is less of a barrier nowadays.

BTW, we could sneak in a new TLD by using 2919bis to reserve it 
(draft-cheshire-dnsext-special-names-02). :-)

>14) Section 6 in RFC2919bis seems needlessly verbose about 
>case-insensitive string comparison.  Simply using that term is quite 
>sufficient.

I can drop that.  RFC 2919 uses "CASE INDEPENDENCE" from RFC 
822.  That text is not in RFC 5322.  I used some (verbose) text as 
there isn't any such text in the mail-related RFCs.  Let's wait for 
more feedback about this.

>15) Appendix A.1 in RFC2919bis seems way off topic.  I suggest 
>striking it, or adding text to explain why it's not off topic.

Subject tags are commonly used as list identifiers (this mailing list 
uses them).  Appendix A.1 explains the difference between a List 
Identifier and a subject tag in terms of uniqueness.  If I have to 
provide an explanation, I would have to get into mail filtering, e.g. 
why use List-ID instead of subject tags to move messages from this 
mailing list into a separate mailbox.

>16) There's stuff in RFC2369bis Appendix A that recommends MUA 
>application of these fields which uses normative language.  This 
>should probably also be adjusted, or it should become a normative 
>section rather than appendix.

Ok but please see my response to point 8.

Regards,
S. Moonesamy