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

[S Moonesamy <[e-mail]>]

Hi Alessandro,
At 04:54 06-01-2012, Alessandro Vesely wrote:
>hope you don't mind my taking this occasion to ask some questions.

Ask. :-)

>Nice addition.  Would it make sense to promote that from appendix to a new
>"Definitions" section?  (I don't dare suggesting that it should match the
>list-label...)

No, that would end up being controversial.  Please see the comments 
from Murray and John about subject tags.  The problem with using a 
subject tag which matches list-id is that it takes more space.  The 
List-id for this mailing list is 21 characters.  That's a little more 
than half of the display, assuming a 40 character width.

>Defining what is a /list/ that a List-Id identifies would be another

I don't fully understand this comment.  You could view the List-Id as 
an opaque identifier.  Basically, apps-discuss.ietf.org is a unique 
string attached to messages from this mailing list (John explained 
that better).  It could have been foo.invalid if that can be 
considered as unique.  Although we would say that the string does not 
convey anything meaningful, in practice, it would be something which 
the average subscriber would recognize.

>candidate addition.  And also what is a /nested list/, maybe.  The point is

See John's comment. :-)  A nested list can be viewed as a list which 
has one or more mailing lists as a subset.  Mailman uses the term 
Umbrella list.  It's part of these mail features which are forgotten 
as mail turned into a legacy application.

The use cases might be as follows:

  (i)  You have 1,000 users subscribed to an external mailing list.  To reduce
       mail traffic, you run an internal mailing list with one subscription to
       the external mailing list.

  (ii) In your organization, employees must be subscribed to several mailing
       lists.  You create one mailing list which is subscribed to those
       mailing lists.  When an employee joins, you add them to the
       mailing list.  When they quit, you unsubscribe them.  This approach
       has less administrative overhead and you don't have to worry about
       forgetting to add the person to one of the sublists.


>that it is not clear whether this header field should be used also for
>commercial newsletters and similar stuff.

The drafts do not specify whether the List- header fields should only 
be used for discussion lists.  Commercial newsletters generally 
require functionality where the user can unsubscribe.  If they find 
the List- headers useful, they will support it no matter what the 
drafts say.  It's easier to explain the functionality and avoid 
getting into discussions about content.

>I'm not aware of the deployment of "list-id" as suggested in the paragraph of
>Section 5:
>
>    It is suggested, but not required, that List Identifiers be created
>    under a subdomain of "list-id" within any given domain.  This can
>    help to reduce internal conflicts between the administrators of the
>    subdomains of large organizations.  For example, List Identifiers at
>    "example.com" are generated in the subdomain of "list-
>    id.example.com".
>
>Is it actually used or is it merely an example?

I don't recall seeing "list-id" in use.  It's a suggestion; you can 
pick any other label in your namespace as long as it does not 
conflict with your subdomains.

>Instead, I found no normative statement that matches the authority on a given
>domain that is mentioned in Section 2.  Should there be a SOA under
>list-id-namespace?  I wonder whether there is a claim of responsibility
>implied in adding List-Id to a bulk message.

There isn't any normative statement.  I removed the text from RFC 
2919 about authority structure.  You can put any domain, even 
ietf.org.  However, if you do that, people will figure out how to 
block messages from your mailing list.  I haven't seen any visible 
traffic in DNS for "list-id" (monitoring NXDOMAIN).  I'd say not to 
worry about the SOA while pointing you to RFC 2308 for you to decide 
about the better approach.

Your last question is one which a regulator might ask.  From a 
technical angle, the List-Id is for software to have a reliable way 
to identify messages from a mailing list.  The specification does not 
discuss about responsibility as that might depend on the legal 
jurisdiction.  If you were to point out that it is a dishonest 
argument, I will agree with you.

Regards,
S. Moonesamy