> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of S Moonesamy
> Sent: Thursday, January 05, 2012 9:38 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
> 
> Thanks for the feedback.  Can you forward it to those lists?  I asked
> for feedback from a mailman developer and other MLM implementors.

I sent it to the mailman developers list.  I suggest ietf-822 as well.

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

Fair enough, though have URI schemes changed a lot since the RFCs you're updating?

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

Also fair enough.  I got asked the same thing for a recent "bis" draft I did, so I figured you should face this question sooner rather than later.  :-)  But you should probably expect the IESG to double-check.

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

I still think it would be a good idea.  The role an MLM plays in the handling of a message can be complicated, and RFC5598 does a nice job of laying it all out.  I think this is especially important given the fact that we're talking in these RFCs about substantial message alteration that ultimately is meant to change MUA behaviour.

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

I wouldn't have made the suggestion if not for the very size of Appendix A in RFC2369.  There's a lot of good material in there, and someone finding the -bis version for the first time might end up with a lot of questions that are answered there, but not think to follow informative references.  There's a lot to read already.  :-)

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

Much better.

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

That might be an argument for making "http" the URI scheme of choice rather than "mailto".

> >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:list-request@example.com?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.

It could well be that there isn't any demand for being able to do this (or as John mentioned in REPUTE, Apache mod_rewrite makes this kind of thing unnecessary).  It was just a suggestion to make things more flexible.  Part of my motivation was the fact that most "unsubscribe" links have "href" tags that do include the unsubscribing user's address as part of the URI; this provides a means for doing that.

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

My concern is that the advice that's there is dangling.  It gives a default local-part to contact the owner, but no method for selecting a domain.  If we don't like the idea of saying List-Owner needs to be added in all cases, then the default local-part should go as well.

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

You still need to know which domain to contact somehow.

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

I think it's fine to say that the goal of these header fields is to make available specific additional information to users via MUAs, should the MUAs wish to support them, and then let the MUAs decide how to do that.  Any detail beyond that and, as you mention, we're tinkering in space we don't understand well enough to do so.

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

I guess I'm just of the mindset recently that anything using DNS name syntax automatically draws the "What about IDNA?" question, so I thought I'd get us thinking about it sooner rather than later.  If it doesn't apply here, that's fine, as long as we considered it.

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

It definitely is a security consideration, but I would go so far as to say that this should be made normative.  Allowing external instances of these fields to pass through can confound MUAs or even get users to click on things that have nothing to do with list postings.

In RFC5451 this was made a MUST/SHOULD depending on the circumstances.  I think the same applies here.

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

Not a bad idea, actually.

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

I think since we're using DNS syntax here, whatever language RFC1034/1035 use to describe label comparison would suffice here.

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

Ah, that seems reasonable.  I suggest you add such comments to the draft so the reader is not left wondering why this is there.

Thanks,
-MSK