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

["Murray S. Kucherawy" <[e-mail]>]

[moving to apps-discuss from appsdir]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of John Levine
> Sent: Thursday, January 05, 2012 10:40 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [appsdir] [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
> 
> It's basically fine, but I have a few suggestions.  As an editorial
> matter, the constant harping to use mailto: everywhere gets old.  I'd
> suggest saying it up front and noting that mail users aren't
> necessarily able to use any other kind of URI, then drop it.  The other
> 99.9% of mail users, of course, find a web page a lot easier than
> trying to send mail and hope for a response.

+1 about mailto.  But as the common thing is to have MUAs that are able to deference both kinds of links, maybe that base set should include mailto and http.

> Section 4 seems obsolete.  Does anyone use nested lists any more, at
> least nested lists visible to the users?  The idea used to be to save
> bandwidth by sending one copy of a list message to an exploder closer
> to the users, but I don't know anyone who still does that.  You can get
> pretty much the same effect by sorting the deliveries by target MX, and
> then send one copy per MX with multiple MAIL TO.

I've written software that accommodates such configurations, but I haven't seen it in active use in a long time.  People just subscribe to multiple lists these days.

> Appendix B strikes me as MUA user interface design advice by people who
> know nothing about UI design.  I'd just drop it, or replace it with a
> short note that the plan is for MUAs to recognize and interpret the
> list headers and use them to present a list management interface to the
> user that matches the rest of the MUA's interface.

I agree, simpler is better when it comes to MUA design.

> >>3) The deletion of Appendix A from RFC2369 is conspicuous.  Why remove
> >>all of that supporting discussion?
> 
> Because it's not very interesting any more.  I suppose you could put in
> a sentence saying that the design discussion in RFC 2369 may be useful
> to help understand the design of list headers.

I'd be happy with such a back-reference.

> >>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?
> 
> I agree that's wrong.  Just add the fripping header, please.

Well, either that, or have some simple heuristic for extracting a domain name to append to "postmaster@" when presenting some list management knobs in an MUA.  As written right now, it seems like an incomplete mechanism.

> Comments on 2919bis:
> 
> >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.
> 
> I'd just point out that the subject is associated with the message, not
> the list.  As a concrete example, if I send a personal reply to the
> author of a list message, the subject will still have the list tag, but
> it won't have a list-ID.

I still don't understand why it's there.  I know what it's telling me and I believe it's correct, but I don't understand how someone using this document (to write an MLM or a compliant MUA) would apply this information.  That is: "OK, so subject tags and List-ID have different uniqueness properties.  Now what?"