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

[Alessandro Vesely <[e-mail]>]

On 07/Jan/12 00:55, S Moonesamy wrote:
> At 04:54 06-01-2012, Alessandro Vesely wrote:
> 
>> 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.

Is "that" the new section or the matching?

> Please see the comments from Murray and John about subject tags.

I agree with what John notes, that after putting the tag in the
Subject it is going to stick there independently of List-Id.  I, for
one, wouldn't like a MUA to remove subject tags on replying.

> The problem with using a subject tag which matches list-id is that
> it takes more space.

I never suggested that.  It would match the /list-label/, where
list-id = list-label "." list-id-namespace.  This list complies.

In case the majority of lists comply too, noting such behavior may
explain why it's not off topic.

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

John said "the list ID is typically a hostname in the domain of the
list itself, not of the list owner."  List-Owner, defined in 2369bis,
can indeed refer to any address, independently of the list's domain.

Please let me quote, for informative purposes only, part of the EU
definitions [1] (just mentally s/personal data/a list/):

 (d) 'controller' shall mean the natural or legal person, public
 authority, agency or any other body which alone or jointly with
 others determines the purposes and means of the processing of
 personal data;

 (e) 'processor' shall mean a natural or legal person, public
 authority, agency or any other body which processes personal data on
 behalf of the controller;

I would consider a list administrator a processor, in that sense.
Thus the question is whether the list-id could be used to identify the
controller.  If I `dig apps-discuss.ietf.org`, I get the correct SOA
in the authority section.  That way I'd be able to tell the
list-id-namespace even if the list-label were, say, apps.discuss.

> Although we would say that the string does not convey anything
> meaningful, in practice, it would be something which the average
> subscriber would recognize.

What's the advantage of having it opaque, since it's structured?

>> And also what is a /nested list/, maybe.
> 
> 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.

I'd propose this:

   When one or more addresses in a list are in turn the posting
   address of other mailing lists, the latter are called nested
   lists, a.k.a. umbrella lists.

I, for one, wasn't clear on what that meant before reading your reply.
The fact that nested lists almost disappeared makes a definition even
more needed, for comprehensibility.

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

List-Id seems different from the other List-* fields in this respect,
also because of the fact that it lives in its own RFC.  However, the
abstract and the introduction don't seem to be worded so as to catch
the attention of newsletters developers.

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

In that case, wouldn't it be better to relegate (part of) that
paragraph to a description of the second example in Section 3?

I think it was in Section 5 as a means to stress that a list-id must
univocally identify a list.  That is, to guarantee uniqueness even in
the absence of any list-id-specific DNS record, rather than to prevent
conflicts with other DNS records.  For example, if the IETF had a
mailing list about the world wide web, it could legitimately use
www.ietf.org as the list-id.  Correct?

> There isn't any normative statement.  I removed the text from RFC 2919
> about authority structure.

Yup, there was a MUST NOT in Section 2.  What's the advantage of
relaxing that requirement?

> 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 think I would be abusing someone else's domain name if I did that.
How would people recognize a fake List-Id and block messages?  And why
would they want to do so, given that generating list-ids in different
domains is going to be legitimate?

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

IMHO, technical specifications should provide grips and holds for law
makers and regulators.  The fact that they are usually such assholes
as to be unable to use them is not a justification for omitting them,
lest be accused of being equally foolish.

-- 
[1]
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML