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

From: S Moonesamy <[email-masked]>
Date: Wed, 04 Jan 2012 12:18:06 -0800

Hello,

I would appreciate some feedback on draft-moonesamy-rfc2369bis-01 [1] 
and draft-moonesamy-rfc2919bis-01 [2].  The I-Ds are about the List- 
header fields.

The changes from RFC 2369 are:

   o  URL changed to URI

   o  Replaced MTAs with mailing list managers in the sentence: "MTAs
      generating the header fields SHOULD".

   o   Replaced MTAs with mailing list managers in the sentence: "MTAs
       MUST NOT insert whitespace within the brackets" in Section 2

   o  In Section 2, client application SHOULD ignore whitespace within
       brackets

   o  Updated references

   o  Added informative reference to RFC 5064

   o  Editorial changes

   o  Removed Background Discussion

The changes from  RFC 2919 are:

   o  Removed text about the domain name system and domain ownership in
      Section 2

   o  "localhost" replaced with "invalid"

   o  Replaced MTAs with mailing list managers in the sentence: "MTAs
       MUST NOT insert whitespace within the brackets" in Section 3

   o  Case independence in Section 6 changed to case insensitivity for
      ASCII

   o  Added a paragraph in the appendix about subject tags

   o  Updated references

   o  Editorial changes

Regards,
S. Moonesamy

[1] http://www.ietf.org/internet-drafts/draft-moonesamy-rfc2369bis-01.txt
[2] http://www.ietf.org/internet-drafts/draft-moonesamy-rfc2919bis-01.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Jan 2012 16:10:53 -0800

Hi SM,

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.

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?

1) Have the original authors of these documents been contacted to see if they want to 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.

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.

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.

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

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

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:[email-masked]?subject=help?user={user}>

...and then just define that when expanding such templates, "user" is the email address the MUA is using.

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?

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.

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

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?

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

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.

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.

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

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.

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.

I think that's enough for now.  I'll have more as the work evolves.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Thu, 05 Jan 2012 21:38:12 -0800

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

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.

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

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 [email-masked].

"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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Jan 2012 13:54:21 +0100

Hi SM,
hope you don't mind my taking this occasion to ask some questions.

On 04.01.2012 21:18, S Moonesamy wrote:
> 
> I would appreciate some feedback on draft-moonesamy-rfc2369bis-01

(I'd only s/e-mail/email/ in Section 3.8, per
http://www.rfc-editor.org/rfc-style-guide/terms-online.txt)

> [...]

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

Defining what is a /list/ that a List-Id identifies would be another
candidate addition.  And also what is a /nested list/, maybe.  The point is
that it is not clear whether this header field should be used also for
commercial newsletters and similar stuff.

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?

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.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 06 Jan 2012 13:41:24 -0800

Hi John,

Thanks for the feedback.  BTW, your message was copied to appsdir ( 
http://www.ietf.org/mail-archive/web/appsdir/current/msg00687.html ).

At 22:39 05-01-2012, John Levine wrote:
>Hi.  I guess I'm a defacto mj2 implementer.

It's very useful to get input from implementers.

>Josh Baer is easy enough to find, once you know he's the one in Austin,
>not the art critic.

Could you send me his email address off-list?

>General comments on 2369bis:
>
>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.

That would be the following from Section 2 (it does not include 
changes made in my internal version):

   "Additionally, the use of URIs provides access to multiple transport
    protocols (such as ftp and http) although it is expected that the
    "mailto" protocol [RFC6068] will be the focus of most use of the list
    header fields.  Use of non-mailto protocols should be considered in
    light of those users who do not have access to the specified
    mechanism (those who only have email - with no web access).

I would like to keep a reference to RFC 6068 as "mailto" is commonly 
used.  I'll make the following change:

    Additionally, the use of URIs provides access to multiple URI schemes.

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

The exploders I know of disappeared a couple of years ago.  Section 4 
discusses about nested list and does not mention a union of lists.  I 
planned to implement that feature.  It's useful for cases such as 
IETF mailing lists as most of us are subscribed to several lists and 
end up with an administrative hassle as we have to go through each of 
them to set our preference.  draft-sparks-genarea-mailarch-03 does 
not discuss about such functionality.  I vaguely recall some comments 
during discussions about datatracker enhancements.  I'll suggest 
leaving this section as it is.

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

As Murray pointed that out too, I'll replace that appendix with a note.

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

Thanks, I'll add that.

>I agree that's wrong.  Just add the fripping header, please.

I'll remove the following sentence:

   "There is no need to specify List-Owner if it is the
    same person as the mail system administrator (postmaster)."

>Comments on 2919bis:
>
>In sec 2, the list ID is typically a hostname in the domain of the
>list itself, not of the list owner.  I run lists with addresses like
>[email-masked], but I as the owner have an address in
>another domain.

Ok.

>In sec 3, most of the places it refers to the MUA are at least as
>applicable to the MDA.  I do all of my list sorting at delivery time,
>not in the MUA, and I suspect a lot of SIEVE users do the same.

SIEVE would be implicit here.  I'll leave the section as it is unless 
there is further feedback.

>Sec 7, I still think nested lists are dead.

If I remove the sections about nested lists in both drafts and leave 
it to the existing RFCs, List-Sequence won't be covered.

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

That's a good point.  I'll leave this comment open.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Fri, 06 Jan 2012 15:55:02 -0800

Hi Alessandro,
>hope you don't mind my taking this occasion to ask some questions.

Ask. :-)

>"Definitions" section?  (I don't dare suggesting that it should match the

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.

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

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

>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

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 07 Jan 2012 20:02:58 +0100

On 07/Jan/12 00:55, S Moonesamy 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.

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

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

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

> technical angle, the List-Id is for software to have a reliable way to
> identify messages from a mailing list.  The specification does not

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

---

From: S Moonesamy <[email-masked]>
Date: Sat, 07 Jan 2012 14:00:36 -0800

Hi Alessandro,
>Is "that" the new section or the matching?

The would be new section.

>explain why it's not off topic.

There were comments to drop the entire paragraph.

>list-id-namespace even if the list-label were, say, apps.discuss.

 From Section 2:

  "Using the domain name space as a basis for the List
   Identifier namespace, it is intended to leverage an
   existing name space structure to generate a unique
   identifier."

It means that it looks like DNS but it is not DNS.  See comments below.

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

This email is addressed to [email-masked].  Only that domain knows 
who or what "vesely" is for.  From my side, it is opaque.  I can 
guess that it is the local-part for me to reach you by email as we 
have exchanged a few emails.

>    lists, a.k.a. umbrella lists.

I thought that you were asking questions and not arguing for a change.

>more needed, for comprehensibility.

Nested lists did not disappear because of a definition.  It is 
because people do not know about it, that they prefer simple things, 
or that the sites that used it no longer have a need for it.  The 
people configuring the mailing list manager read the MLM 
documentation and not the RFC.

>the attention of newsletters developers.

RFC 2369 was published in 1998 and RFC 2919 was published in 
2001.  They were not written by the same people.  That may be why 
List-Id is in its own RFC.

>paragraph to a description of the second example in Section 3?

I don't think so.

>www.ietf.org as the list-id.  Correct?

There isn't any conflict as nothing in draft-moonesamy-rfc2919bis-01 
or RFC 2919 says that List-ID is to be resolved in DNS.

Yes, the IETF could do that.  People can legitimately do anything 
they want.  It is up to them to assess whether there are negative 
consequences or not.

>relaxing that requirement?

It avoids DNS wars.

>How would people recognize a fake List-Id and block messages?  And why

As this is an antispam question, the answer is not free. :-)

>domains is going to be legitimate?

See above.

>IMHO, technical specifications should provide grips and holds for law

I would have to find a lawyer in the E.U. for legal advice about the 
text to add.  As it is going to be expensive, please do not ask me to 
pay for that.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Jan 2012 22:10:18 -0800

[moving to apps-discuss from appsdir]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Thursday, January 05, 2012 10:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [appsdir] [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
> 
> 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.

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

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

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.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Jan 2012 22:16:48 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Saturday, January 07, 2012 11:03 AM
> To: S Moonesamy
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
> 

Any structure in the local-part is known only to the domain that will receive it.  That's what we mean by opaque here.  It's like a pointer into that domain's address space; you don't know how to dereference it from outside that domain, though if you see it twice, it's reasonable to conclude it's the same thing both times.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Jan 2012 23:20:19 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Thursday, January 05, 2012 9:38 PM
> To: [email-masked]

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"

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.

> >sense) by an informative reference to RFC5598 just so there's a handy
> >illustration of how all these components fit together.
> 

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.

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

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

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

Much better.

> BTW, most subscribers find web forms more accessible then interacting

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

> >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:[email-masked]?subject=help?user={user}>
> >

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
> 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 [email-masked].

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.

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

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

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.

> >deleted by the MLM.  I think that should be in a normative part of the
> >document rather than Security Considerations.  Rather, Security

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

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

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

---

From: S Moonesamy <[email-masked]>
Date: Sun, 08 Jan 2012 02:18:57 -0800

Hi Murray,

Thanks.

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

There is such an example at the end of Section 3.2 of 
draft-moonesamy-rfc2369bis-01

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

Agreed.  I'll remove the text.

Ok.

>Fair enough, though have URI schemes changed a lot since the RFCs 

It's less of an effort when moving from URI to IRI.

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

Thanks for the clarification.  Other people may find the information useful.

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

I'll change the text to a pointer to RFC 2369.

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

Let me try and come up with some text to reference 
draft-gregorio-uritemplate-07 informatively.

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

Agreed.

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

I strongly agree.

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

Ok.

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

I might use your last sentence as part of Security Considerations.

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

I generally use MUST and SHOULD where interoperability is 
needed.  I'll discuss about this point off-list.

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

I'll remove that text.

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

Ok.

Thanks for the review.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 09 Jan 2012 11:54:22 +0100

> It means that it looks like DNS but it is not DNS.  See comments below.

If it doesn't have to be a real DNS name, the reason to treat
".invalid" as a special case becomes rather obscure.

> Nested lists did not disappear because of a definition.  It is because
> people do not know about it, that they prefer simple things, or that
> the sites that used it no longer have a need for it.

So there is an implied "if you don't know what a nested list is, you
may safely skip this section."

> RFC 2369 was published in 1998 and RFC 2919 was published in 2001. 
> They were not written by the same people.  That may be why List-Id is
> in its own RFC.

Since you are somewhat diluting the spec, you might as well have
merged it with 2369bis.  Why not?

>> relaxing that requirement?

Whazzat?  I thought DNS was developed for civilian purposes only...

In any case, I'd substitute "recommended" with either "RECOMMENDED" or
a synonym like "suggested", in the third line below:

   While it is perfectly acceptable for a List Identifier to be
   completely independent of the domain name of the host machine
   servicing the mailing list, it is recommended that the owner of a
   mailing list avoids generating List Identifiers in any domain name
   space for which they do not have authority.

> text to add.  As it is going to be expensive, please do not ask me to

Quite the opposite way around:  It is the EU (or Canada) who will pay
you a consultancy when they'll need to legally nail who is in control
of a list's operations :^)

---

From: S Moonesamy <[email-masked]>
Date: Mon, 09 Jan 2012 14:02:04 -0800

>".invalid" as a special case becomes rather obscure.

It's to avoid localhost.com, etc.

>may safely skip this section."

If you are not implementing nested list, you can skip the section.

>merged it with 2369bis.  Why not?

2369bis is more about list commands whereas 2919bis is about list 
identifiers.  Keeping the them as two separate documents makes it 
easier to compare changes.

>Whazzat?  I thought DNS was developed for civilian purposes only...

Some parts of DNS are about policy.

   "Several people expressed considerable scepticism about the
    chances of success in response to domain name registry issues."

Ok.

>of a list's operations :^)

I'll use that as the rationale for the work. :-)

Regards,
S. Moonesamy

P.S. As all messages from this mailing list are DKIM signed, you can 
use some heuristics to detect misuse of the list-id.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Jan 2012 16:29:31 +0100

> It's to avoid localhost.com, etc.

Since you said one doesn't have to be the registrant of localhost.com
in order to use it as a list-id, it's still not clear.  Does the spec
mandate that list-id-namespace MUST be an existing domain name?

> identifiers.

Nevertheless, BCP 167 proposes List-Post as a candidate domain
identifier.  Accordingly, DKIM driven heuristics should use that field
rather than List-Id.

> Keeping the them as two separate documents makes it easier to
> compare changes.

It is better to rely on the purposely provided appendixes.

By keeping them separate, you turn this state of affairs into a
tradition.  I mean that more stiffness will be needed to merge them in
the future, assuming they will happen to be rewritten simultaneously
again.

>    chances of success in response to domain name registry issues."

Yeah, it is curious that we consider number databases more solid in
that respect.  (Is it because we only have five?)  To ease the
transition to IPv6 we should use names instead.  For DNS, one can
certainly blame the ADMD for any bad settings, so DNS might be
considered more consistent than registries.

One side effect of merging 2919 into 2369 is to corroborate the idea
that List-Id is tailored for discussion lists.  You may have
alternative ideas to express the same concept without merging.  In any
case, since the possibility to use it as a policy element of bulk
commercial messaging is not fully supported, it may make sense to tell it.

> use some heuristics to detect misuse of the list-id.

BTW, isn't it worth to reference BCP 167?

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Jan 2012 09:12:30 -0800

>mandate that list-id-namespace MUST be an existing domain name?

No, but it can still discuss about how to avoid namespace collisions.

>identifier.  Accordingly, DKIM driven heuristics should use that field

That BCP is about DKIM.

Ok.

>that respect.  (Is it because we only have five?)  To ease the

Sorry, I cannot comment about this.

>commercial messaging is not fully supported, it may make sense to tell it.

The drafts are about interoperability.  If commercial messaging 
causes interoperability issues, it can be discussed in the draft.

>BTW, isn't it worth to reference BCP 167?

No.

Thanks for the comments.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Wed, 18 Jan 2012 09:16:15 -0800

Hello,

I plan to submit draft-moonesamy-rfc2369bis-02 today.  The list of 
changes from -01 are:

    o  Added ABNF and reference to RFC 5234
    o  Removed text about postmaster in List-Owner Section
    o  Removed User Interface guidelines from Appendix B
    o  Removed SHOULD include a "mailto" based command in Section 3
    o  Modified the text to first paragraph of Section 3.1

Thanks to Mykyta Yevstifeye, Murray S. Kucherawy and John Levine for 
feedback.  I'll summarize the comments.  As usual, if I misunderstood 
anything you said, please email me.

I added "List-Sequence" in the Abstract Section as Mykyta suggested 
[1] and added the IANA registration.  I included the ABNF he 
suggested and some editorial changes (mailto).

Murray suggested [2] including ABNF.  As he commented on the language 
at the top of 3.1 sounding vaguely like a minimum compliance 
statement, I modified the text.  The suggestion to use "postmaster" 
in Section 3.5 of draft-moonesamy-rfc2369bis-01 has been 
removed.  The Client Implementation appendix has been removed as John 
Levine also commented on not providing UI guidance.  I have not added 
a reference to draft-gregorio-uritemplate (values expanded by MUA).

John Levine suggested [3] not providing MUA user interface design 
advice.  Appendix B has been removed.  I removed the text that 
sounded like the "the constant harping to use mailto:".  I kept 
Section 4 about Nested lists.

Murray also mentioned having some text in the Security Considerations 
Section to recommend that MUAs should not generate the header 
fields.  I didn't make that change as there is already a 
recommendation in the second paragraph of Section 3.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04032.html
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04039.html
3. http://www.ietf.org/mail-archive/web/appsdir/current/msg00687.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jan 2012 10:47:30 -0800

Sounds like a good step forward.

One thing I might suggest including, either in the Abstract, Introduction or an Appendix, is an explanation of why this is being reissued.  In particular, you've said your main impetus for doing this is the URL-URI evolution, so I imagine it would be helpful to highlight that in some way.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 18 Jan 2012 11:57:12 -0800

Hi Murray,

Thanks.

>One thing I might suggest including, either in the Abstract, 
>Introduction or an Appendix, is an explanation of why this is being 
>reissued.  In particular, you've said your main impetus for doing 
>this is the URL-URI evolution, so I imagine it would be helpful to 
>highlight that in some way.

I changed the first paragraph of the Introduction Section as follows:

    RFC 2369 [RFC2369] defined additional header fields to be added to
    email messages sent by mailing list managers (MLMs).  The significant
    change in this document is the use of Uniform Resource Identifier (URI)
    [RFC3986], instead of Uniform Resource Locator (URL), allowing an
    implementation to parse the common components of a URI reference without
    knowing the scheme-specific requirements of every possible identifier.
    The content of  each new header field is typically a URI  - usually
    "mailto" [RFC6068] - which identifies the relevant information or
    performs the command directly.

Regards,
S. Moonesamy