Subject: [EAI] Shepherd report review of mailinglist-02

From: Joseph Yee <[email-masked]>
Date: Tue, 10 Jul 2012 12:13:44 -0400

Hi.

We have just completed a draft of the Shepherd's report and
corresponding pass through the document prior to handing
the mailinglist document off to IESG.

The review turned up several editorial and related issues.  If
possible, we would like to see them corrected into a -03 before
the document is handed off for IETF Last Call.   Getting nits
fixed at this point often saves a lot of time quibbling about
them later.

WG participants: some of these issues are substantive, see
notes 8, 9, and 11 below.

Authors of other documents.  This type of review is a painful
and time-consuming process.  I used to defer parts of it until
AUTH48, but have learned my lesson: it needs to be done either
before we request IETF Last Call, during or after that Last
Call when ADs or other members of the community start
nit-picking, or during AUTH48.  It only gets more painful at
later stages.   If possible, review your own documents to see
if you can spot and fix these sorts of things before I/we have
to.

John, if you don't have time to make these changes within the
next few days but can supply document source and any comments,
we will try to get a new version out.  we really, really want
this document in IETF LC before Vancouver if that is at all all
possible and we are running out of time.

(1) Abstract

Please change "does not offer implementation or deployment
advice." to "does not specify a protocol or offer
implementation or deployment advice." or, if you prefer "does
not specify protocol changes or offer implementation or
deployment advice."

    Reason: The Shepherd's Report format contains a lot of
        questions that are really relevant only to protocol specs.
        The writeup becomes much more clear if one can say "not a
        protocol spec" and that is less likely to be nit-picked if
        the abstract says that up front.

(2) Introduction, paragraph 3.

Text reads "...This agent sets the envelope return address..."
Please either insert "normally" or "usually" in front of "sets"
or provide a citation to something that requires this.  If you
want to go down the latter path, the relevant citation is
Section 3.9 of RFC 5321 but note that a narrow reading of those
text essentially prohibits a mail exploder from adding "List-*"
headers.

Nit: s/rathern/rather/

(3) Section 1.1, 1.2, and maybe elsewhere.

Nit: "mailing list agent" is fine, as is "mailing list exploder"
(the term used in RFC 5321) but making mailing lists animate
can only cause confusion.  So "Some mailing lists alter
message header fields..." needs adjustment.

(4) Section 1.2, first sentence

Did you want "...mail transport protocol does not differentiate
between..."

(5) Section 1.2, paragraph 3

Old:
        "first, mailing lists might choose to reject all messages
        from internationalized addresses."
New:
        "first, mailing list agents might choose to reject all messages
        from internationalized addresses perhaps because they have
        not been upgraded to handle such messages."
Reason: A little obscure otherwise.  And see note (3) supra.

Old:
        if the members are UTF-8
New:
        if the members are SMTPUTF8
Reason: That has been the convention in the WG and we really
don't need someone reminding us during IETF LC that a message
that contains nothing but ASCII characters is perfectly valid
UTF-8.  Same comment about "EAI messages", etc.

(6) Section 1.2, paragraph 4.

The antecedents in this paragraph are ambiguous.  Since the
paragraph is important, it should be painfully clear.  Suggest
(without changing more of your text than necessary):

   Conceptually, a mailing list's internationalization can be
divided
   into three capabilities: First, does the list itself have a
   non-ASCII submission address or does the message submitter
   use a non-ASCII return-path address?  Second, does the list
   manager accept subscriptions for addresses containing
   non-ASCII character?  And third, does the agent accept
   messages that require SMTPUTF8 capabilities even if neither
   of the other two conditions apply?

Is that what you meant?  Note that the rewording also got rid
of the idea of a UTF-8 address (see note 5).   FWIW, RFC 5321
thinks that a "return-path" is the name of a header field that
doesn't exist prior to final delivery (and a mailing list
exploder is essentially prohibited from adding one and is
supposed to remove it if it appears).  The term you are looking
for is probably "reverse-path" or "backward-pointing address"
but probably no one will notice this unless he or she spent too
much time buried in 5321 and its predecessors.  The return-path
issue also appears in Section 2.3 and perhaps elsewhere.

Also s/EAI messages/SMTPUTF8 messages/, probably globally.

(7) Section 2, first paragraph.

The paragraph seems to be more confusing than it needs to be.

For example,

Old:
   In both cases,
   the message might have only one recipient, or might have
   multiple recipients.
New:
   In both cases,
   the message might be addressed only to the list address, or
   might have recipients in addition to the lis6.

Then the next sentence, which mixes what is coming into the
list exploder with what goes out, could be made single-purpose.

FWIW, I've never seen a large list handled by putting hundreds
of messages into a single SMTP envelope and handing off to a
conventional submission server.  Even with pipelining, the
requirement for a response to each RCPT command is excessive.
Unless that has changed since I've been actively involved with
email operations, you might want to tone "Often" down a bit.

(8) Section 2.1 (warning: substantive)

In a world in which we encourage explicit confirmation as part
of an email subscription process for other reasons (ones with
which you are thoroughly familiar), putting something that
requires SMTPUTF8 handling into the automated confirmation
message would not be burdensome.  Things get complicated if the
list management software wants to take some other action if the
message is rejected at SMTP time (SMTPUTF8 is not offered by
the recipient (would-be subscriber's MTA) or the confirmation
does not arrive.  But, if the policy is "no address that is not
SMTPUTF8-capable need apply" as this paragraph suggests, that
seems fairly easy.

Whether that is worth mentioning is up to you, or, if anyone
has a strong opinion, the WG.

(9) Section 2.2.  (Substantive)

We've essentially said that in-transit message downgrading is
impossible unless the message contains no non-ASCII addresses
and has non-ASCII material only in header fields in which
encoded words can be used.  Absent a whole series of provisions
that you haven't discussed, a mailing list exploder is in no
better shape to downgrade messages for ASCII-only recipients
than a relay.  But here the text says:

   ...list
   software might divide the recipients into two sets, EAI and
ASCII
   recipients, and create a downgraded version of EAI list
messages to
   send to ASCII recipients.

Which sounds misleading and/or like handwaving.    It seems to
me that you either need to spell out the cases of interest
(e.g., "no backward-pointing or additional recipient non-ASCII
addresses, no funky headers that cannot be forced into encoded
words, no signatures over anything relevant") or otherwise
respecify this section.

(10) Section 2.3

"EAI name", "EAI bounce address", etc.  See note 5.

The notion of "modifying" an address is confusing here.  What
you are really suggesting is the use of an ASCII address
instead of the SMTPUTF8 forms that would normally result from
applying traditional rules.

The RFC Editor will  require that you spell out VERP,
supply a reference, or both.  "Both" is almost certainly
preferable.

(11) Section 3.1  (possibly substantive in part)

Title should be "Internationalized List Headers", "Non-ASCII
List Headers", or "SMTPUTF8 List Headers", not "EAI list
headers".

In paragraph 3:
   The most commonly-used URI schemes in List-* headers tend to
be HTTP
   and mailto, although they sometimes include HTTPS and FTP,
and in
   principle can contain any valid URI.

Use "MAILTO", not "mailto" unless you want you waste your time
and ours in a silly argument.

Paragraph 4 is problematic because the whole state of IRIs is
up in the air right now.  It might be better to say something
like:

   Even if a scheme permits an internationalized form, it
   should use a pure ASCII form of the URI described in
   [RFC3986].  Future work may extend
   these header fields or define replacements to directly
   support non-encoded UTF-8 outside the ASCII repertoire in these
   and other header fields, but in the absence of such extension
   or replacement, non-ASCII characters can only be included by
   encoding them as ASCII.

That avoids references to anything but 3986, which is very
stable.  Even though this is an Informational document, the
statement as originally written creates normative references
to 3867  and should create one to [I-D.duerst-iri-bis].  We
really don't want to go there if it can be avoided.

Nit: s/abd/and/

(12) While there have been periodic discussions in the
community about whether the "Normative/ Informative" split
really makes sense for Informational documents, the current
rule is that it is required for the IETF Stream.  While we
could, in principle, make an issue of it, it hardly seems worth
it.  So please split the list up.   Note also that
[I-D.duerst-iri-bis] does not appear to be  not cited in the
current draft and the reference is outdated.  Please get rid of
it unless you have reason to retain it _and_ are absolutely
certain that reason doesn't involve a normative reference.

I think that ends up with the following

Normative:  RFC 3986; RFC6409 (marginal, but a full standard
and hence harmless)

Informative: RFC 2369, RFC 2919 (both mentioned only as
examples)

Questionable: RFC 3987 and RFC 6068  (used only as part of
the specification of "the URI-encoded form" in Section 3.1).  I
urge getting rid of them entirely since it is easy to have the
discussion that is relevant to this document without them and
they (especially 3987, which draft-ietf-iri-3987bis (the real
[I-D.duerst-iri-bis] proposes to obsolete incompatibly.

(13) ID nits tool considers the lack of IANA section an issue, even
this document does not specify any protocol.

Best,
John Klensin and Joseph Yee, co-chair of EAI

---

From: "John R Levine" <[email-masked]>
Date: 10 Jul 2012 12:46:39 -0400

Thanks for this, I'll do a new version later this week.  I also have some 
comments from the WG that I was waiting to fold in.

R's,
John

> John Klensin and Joseph Yee, co-chair of EAI

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Jul 2012 12:54:18 -0400

--On Tuesday, July 10, 2012 12:46 -0400 John R Levine
<[email-masked]> wrote:

> Thanks for this, I'll do a new version later this week.  I
> also have some comments from the WG that I was waiting to fold
> in.

Excellent.

Thanks (from both of us)
   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 11 Jul 2012 18:09:32 +0900

Hello Joseph, John, John, and others,

On 2012/07/11 1:13, Joseph Yee wrote:

> (11) Section 3.1

> and ours in a silly argument.

Scheme names are usually written lower-case, so I suggest to streamline 
this as:

The most commonly-used URI schemes in List-* headers tend to be http
and mailto, although they sometimes include https and ftp, and in
principle can contain any valid URI.

>     or replacement, non-ASCII characters can only be included by

This text would work for me.

> really don't want to go there if it can be avoided.

That's fine with me, but I don't really see any problem with referencing 
RFC 3987.

> certain that reason doesn't involve a normative reference.

Yes, please. I think this is just a leftover from a previous version of 
the draft.

> [I-D.duerst-iri-bis] proposes to obsolete incompatibly.

As draft-ietf-iri-3987bis isn't yet done, its difficult to say exactly, 
but while there are many changes and tweaks in the details, the basic 
principles are exactly the same. Saying that you can't cite RFC 3987 
because there's a WG that is working on updating it would be about the 
same as saying you can't cite RFC 2616 (HTTP) because there's a WG 
working on updating it.

Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Jul 2012 08:23:09 -0400

Hi Martin,

Thanks for the comments -- partial responses below.

--On Wednesday, July 11, 2012 18:09 +0900 "\"Martin J. Dürst\""
<[email-masked]> wrote:

>...
>> (11) Section 3.1
> 
>> In paragraph 3:
>>     The most commonly-used URI schemes in List-* headers tend
>>     to be HTTP
> Scheme names are usually written lower-case, so I suggest to
> streamline this as:
> 
> be http
> and mailto, although they sometimes include https and ftp, and
> in principle can contain any valid URI.

wfm.  Our concern was only about having some in upper case and
some in lower.

>...
> As draft-ietf-iri-3987bis isn't yet done, its difficult to say
> exactly, but while there are many changes and tweaks in the
> details, the basic principles are exactly the same. Saying
> that you can't cite RFC 3987 because there's a WG that is
> working on updating it would be about the same as saying you
> can't cite RFC 2616 (HTTP) because there's a WG working on

The difference is that the group revising HTTP seems to be bound
by strict upward compatibility.   The (tentative) decision to
change the role of IRIs from "UI overlay" to "separate protocol
element mostly suitable for new protocols" is a significant
modification that calls 3987 into question.  My own guess is
that, even if IRIs continue down that path, a profile will
evolve that is strictly upward compatible with 3987 and that
would be suitable for discussion in this sort of paragraph.  But
the timing of development of the two specs is exquisitely bad.

     thanks and regards,
      john

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2012 10:17:03 -0400

>> be http and mailto, although they sometimes include https and ftp, and

The editors have a style book, and I presume that they will adjust stuff 
like this to match the style as they do the normal copy edit.  Why argue 
about it here?

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2012 17:45:01 -0400

OK, I've posted an -03 that I think takes into consideration everyone's 
comments.  The comment that lists are inanimate messages while list agents 
are software was a good one, that let me go through and make the document 
(I think) considerably clearer.

Just so you don't think I ignored you:

> conventional submission server.

It's quite common now, e.g., one of Mailman's normal config options.

> message would not be burdensome.

I didn't do that for two reasons.  One is that while requiring signup 
confirmation usually a good idea, there are real situations where it's not 
needed, and this is the wrong place to argue about list policies.  Also, 
this could apply to lists where the manager is upgrading an existing list 
to EAI, and getting all of a list's subscribers to reconfirm is, ah, 
challenging.  So it mentions it as an option, not as advice.

> than a relay.

Already discussed later on, added references.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 Jul 2012 19:08:42 -0400

WG participants,

I've responded to some of John L's points below -- read or not
as you like.  Either way, consider this a heads-up that we will
ask Pete to start the process of initiating an IETF Last Call in
circa 24 hours.  So, if there is anything here you don't like,
this is your last chance to speak up inside the WG.

John,

Inline.

    john

--On Thursday, July 12, 2012 17:45 -0400 John R Levine
<[email-masked]> wrote:

> OK, I've posted an -03 that I think takes into consideration
> everyone's comments.  The comment that lists are inanimate
> messages while list agents are software was a good one, that
> let me go through and make the document (I think) considerably
clearer.
> It's quite common now, e.g., one of Mailman's normal config
options.

Ack.  Thanks for clarifying.

> I didn't do that for two reasons.  One is that while requiring
> signup confirmation usually a good idea, there are real
> situations where it's not needed, and this is the wrong place
> to argue about list policies. 

Absolutely.

> Also, this could apply to lists
> where the manager is upgrading an existing list to EAI, and
> getting all of a list's subscribers to reconfirm is, ah,

Wfm.  I just wanted to be sure that, if anyone asked, Joseph and
I could say "yes, we considered doing that and decided no to".
 
>> encoded words can be used.  Absent a whole series of
>> provisions that you haven't discussed, a mailing list
>> exploder is in no better shape to downgrade messages for
>> ASCII-only recipients than a relay.
> 

Again, thanks.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 13 Jul 2012 20:04:30 +0900

[cc'ed to the mailing list of the IRI WG]

[IRI WG: This came up in the EAI (email address internationalization) WG 
when discussing 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-eai-mailinglistbis-03, but 
it's highly relevant to the work of the IRI WG.]

[Everybody, please remove the EAI mailing list if you continue 
discussing IRIs, and the IRI mailing list if you discuss the 
mailinglistbis draft, thanks!]

Hello John,

> the timing of development of the two specs is exquisitely bad.

While busy with my day job, I have been able to think about the above. I 
think that what you say above is factually mistaken, but I'm starting to 
see where in the IRI discussion you might have picked up some faint 
signals (one of your many strengths) that let to your interpretation.

But let's go back to the facts:

First (I'm probably writing this for the third time), IRIs as defined in 
RFC 3987 are not "UI overlay". They are clearly defined as protocol 
elements. Of course, they can also be used as "UI overlay", http would 
be a good example. IDNs are a parallel.

Second, of course IRIs are suitable for new protocols. But that also has 
been the case in RFC 3987.

Third, as far as I know, there is no need for a "profile" that is 
strictly upward compatible with RFC 3987. Although the 'modus operandi' 
of the IRI WG may be a bit more chaotic than the well-oiled machine of 
the httpbis WG, the goal, at least as far as I am concerned, is exactly 
the same: To update the spec so that it can be clearer and better 
aligned with actual practice.

Fourth, possibly the most serious compatibility issue between RFC 3987 
as written and 3987bis as it is currently written is the change from 
IDNA 2003 to IDNA 2008. There are varying opinions on whether the change 
from IDNA 2003 to 2008 was the right thing to do. But given that you are 
one of the main contributors to IDNA 2008, I wouldn't expect you to 
throw the first stone at 3987bis.

Fifth, while there have been some proposals in the IRI WG (and before in 
chartering it) to be more liberal with backwards compatibility and 
compatibility with URIs, I have tried hard (and I think up to now 
succeeded) to make sure that this is preserved. As an example, the 
charter of the IRI WG contains an explicit provision that a rechartering 
is needed should any updates to RFC 3986 become necessary.

So I think what's unfortunate is not the timing of development of the 
two specs, but the timing of your confusion. I hope this can be cleared 
up very soon.

If you can point out anything in the actual current 3987bis draft 
(rather than the discussion surrounding it) that let to your confusion, 
I'd appreciate it if you could tell the IRI WG, so that we can (if 
necessary after discussion) fix this as soon as possible.

Regards,    Martin.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 12:10:36 +0100

Hi John,

On 12/07/2012 22:45, John R Levine wrote:
> everyone's comments.  The comment that lists are inanimate messages 
> while list agents are software was a good one, that let me go through 
> and make the document (I think) considerably clearer.

I think you need Informative references for mailto:, http: and ftp: URI 
schemes. I am not sure why you removed the mailto: reference from the 
document.

But otherwise this looks good to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 12:16:14 +0100

> [I-D.duerst-iri-bis] proposes to obsolete incompatibly.
Sorry, missed this earlier: all URI mentioned in the document need 
Informative references. I don't think just assuming that readers can 
find relevant documents is Ok.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 13 Jul 2012 20:27:05 +0900

Hello John, others,

> this is your last chance to speak up inside the WG.

I'm sorry, but I feel I have to take this chance.

As you can see in detail in a mail that I sent a few minutes ago 
(Subject: Confusion about backwards-compatibility of 3987bis/IRIs), I 
think that the very recent removal of the reference to RFC 3987 (and 
possibly also RFC 6068, but then other URI schemes are also not 
mentioned with a reference) is based on confusion only and is a 
disservice to the reader.

Also, my proposal of different text for the "%-routing problem", which 
is clearer about the source of the problem, in particular that it's an 
implementation problem (correct escaping/unescaping) and not an a-priori 
problem, hasn't been taken into account, and I don't know why.

For your reference, here is the current draft text:

<<<<
    The encoding technique specified in [RFC3986] is to use a pair of hex
    digits preceded by a percent sign, but percent signs have been used
    informally in mail addresses to do source routing.  Although few mail
    systems still permit source routing, a lot of mail software still
    forbids or escapes characters formerly used for source routing, which
    can lead to unfortunate interactions with percent-encoded URIs or any
    URI that includes one of those characters.
<<<<

and here is (roughly) what I proposed (and still think) it be replaced with:

    The encoding technique specified in [RFC3986] and [RFC3987] is to use
    a pair of hex digits preceded by a percent sign, but percent signs
    have been used informally in mail addresses to do source routing.
    The correct processing steps when interpreting a mailto: URI are to
    unescape %-encoding and then to interpret the resulting mail
    addresses and other information. Unfortunately, not all mail software
    does this correctly. As a result, % characters indicating URI
    encoding can be erroneously included in actual mail addresses.
    Although few mail systems still permit source routing, a lot of mail
    software still forbids or escapes characters formerly used for source
    routing, which will make incorrectly un-decoded mail addresses
    undeliverable, or in very rare, accidental cases, delivered to
    the wrong addressee.
<<<<

There is some more in 
http://www.ietf.org/mail-archive/web/ima/current/msg04924.html, which 
may also benefit from a more careful consideration.

Regards,   Martin.

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2012 09:36:29 -0400

> Also, my proposal of different text for the "%-routing problem", which is 
> clearer about the source of the problem, in particular that it's an 

I looked at your language, and it seemed to me less clear than what's 
there.  The problem is very simple, some MTAs mishandle addresses that 
contain % signs.  All we need to do is note it, not tell people how we 
think they should fix it or work around it.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2012 09:39:20 -0400

> schemes. I am not sure why you removed the mailto: reference from the 

The various URIs only come up in the context of list headers, and there's 
refefrence to RFC 2369 which defines them and does refer to the sources of 
the various schemes.  If you really think we need to tell people where to 
find mailto: and http: I can add refererences, but since the only 
discussion is with respect to % signs in the syntax, not to what they do, 
I don't see the need.

Regards,

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 16:09:30 +0100

On 13/07/2012 14:39, John R Levine wrote:
>> I think you need Informative references for mailto:, http: and ftp: 
>> URI schemes. I am not sure why you removed the mailto: reference from 
>> the document.
>
> The various URIs only come up in the context of list headers, and 
> there's refefrence to RFC 2369 which defines them and does refer to 
> the sources of the various schemes.  If you really think we need to 
> tell people where to find mailto: and http: I can add refererences, 
> but since the only discussion is with respect to % signs in the 
> syntax, not to what they do, I don't see the need.

I believe the rule is that anything mentioned in the document that is 
not defined in it needs to be referenced.

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2012 11:34:49 -0400

> I believe the rule is that anything mentioned in the document that is not 
> defined in it needs to be referenced.

My. there's a can of worms.  We don't reference RFC 6531 for SMTPUTF8, 
6532 for non-ASCII headers, 5322 for the From, Reply-To, and Sender 
headers, 5598 for MTA, MDA, and MUA, or 20 for ASCII.

RFC 3986, which we do reference, describes all of the URI schemes that we 
mention.

It probably would be a good idea to reference 6531 and 6532, though.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Jul 2012 12:03:59 -0400

--On Friday, July 13, 2012 09:36 -0400 John R Levine
<[email-masked]> wrote:

>> Also, my proposal of different text for the "%-routing
>> problem", which is  clearer about the source of the problem,
>> in particular that it's an  implementation problem (correct
>> escaping/unescaping) and not an a-priori  problem, hasn't
>> been taken into account, and I don't know why.
> 
> I looked at your language, and it seemed to me less clear than
> what's there.  The problem is very simple, some MTAs mishandle
> addresses that contain % signs.  All we need to do is note it,
> not tell people how we think they should fix it or work around
> it.

Agreed, but I suggest that there are really two separate
problems.  The first is the one you mention.  The second is that
there is a mismatch between the MAILTO syntax and definition
(necessitated by the URI syntax) and the specification of 5321,
essentially 
"no one gets to interpret the local part string at all".  It is
correct to talk about that as an implementation problem, but it
is an implementation problem that is so widespread as to justify
security warnings, etc. Similar problems --and probably similar
appropriate warnings-- apply to the use of a number of special
characters (notably "+" and "/" in local parts versus the use of
those characters in URIs and HTML.  Not the fault of mailto, but
traps for the unwary.  And we have ample empirical evidence that
there are lots of unwary (or indifferent) implementers and
implementations out there.

These are important issues.  Probably RFC 3696 should be updated
some day to be more careful and explicit about it.  Or perhaps
5321 should be updated to complement the warning that while the
spec says that local-parts are case-sensitive one shouldn't
depend on it working with one that notes that, while the special
characters used in URIs are perfectly valid in local parts
according to the spec, one shouldn't plan on having them work
either.

But I see no advantages, and several disadvantages, of opening
up any of that discussion in this document.

Again, just my opinion and YMMD.

   john

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Jul 2012 12:04:30 -0400

--On Friday, July 13, 2012 16:09 +0100 Alexey Melnikov
<[email-masked]> wrote:

>>> I think you need Informative references for mailto:, http:
>>> and ftp:  URI schemes. I am not sure why you removed the
>>> mailto: reference from  the document.
>> 
>> The various URIs only come up in the context of list headers,
>> and  there's refefrence to RFC 2369 which defines them and
>> does refer to  the sources of the various schemes.  If you
>> really think we need to  tell people where to find mailto:
>> and http: I can add refererences,  but since the only
>> discussion is with respect to % signs in the  syntax, not to
>> what they do, I don't see the need.
> 
> I believe the rule is that anything mentioned in the document
> that is not defined in it needs to be referenced.

Then, partially following John's logic, it would be as
reasonable (or more so) to clarify that the particular URIs and
references to them appear in 2369.

Precisely because this document is an informational one that
identifies issues rather than a standards track protocol spec,
I'd like to minimize the number of reference dependencies to the
degree possible.  That makes saying (whether explicitly or not)
"if you want to understand this part of the discussion, you had
better understand 2369, just as other parts of the discussion
require some understanding of 5321/5322" more reasonable that
trying to review 2369 in line and thereby talking about the
particular URIs that might be relevant.

Just my opinion, YMMD.

    john

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 18:28:05 +0100

On 13/07/2012 16:34, John R Levine wrote:
> My. there's a can of worms.

It can be.

> We don't reference RFC 6531 for SMTPUTF8, 6532 for non-ASCII headers, 
> 5322 for the From, Reply-To, and Sender headers, 5598 for MTA, MDA, 
> and MUA, or 20 for ASCII.
>
> RFC 3986, which we do reference, describes all of the URI schemes that 
> we mention.

Well, no. It describes the generic syntax. But if one wants to study 
mailto: definition in more details, there is no reference.

> It probably would be a good idea to reference 6531 and 6532, though.

Yes. And ASCII, because it is kind of required to understand "non-ASCII" 
;-).

---

From: Joseph Yee <[email-masked]>
Date: Fri, 13 Jul 2012 15:12:03 -0400

On Fri, Jul 13, 2012 at 9:36 AM, John R Levine <[email-masked]> wrote:

> <thought type="personal">

Agreed that describing how to manage % sign is out of scope for this
document, but noting it helps readers.

</>
Joseph

> ______________________________**_________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ima<https://www.ietf.org/mailman/listinfo/ima>
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Jul 2012 15:37:19 -0400

--On Friday, July 13, 2012 15:12 -0400 Joseph Yee
<[email-masked]> wrote:

> Agreed that describing how to manage % sign is out of scope
> for this document, but noting it helps readers.

<personal>

Once we get EAI wound down or suspended, I want to have a
discussion with the ADs (and maybe the IAB, who have expressed
interest in the past) about re-doing RFC 3696 and/or 4084 to
reflect a whole series of things that either weren't handled
well the first time or need updating to reflect i18n (among
other things).  I'd be delighted to retire to junior author if
someone else is interested in what I think is the right place to
discuss advice about funky characters in mail and how careful
one needs to be if one is going to transform things from one set
of syntax conventions to another one.

Consider that both an offer and, for people who like putting
their names on RFCs, a bribe.

   john

---

From: "John Levine" <[email-masked]>
Date: 13 Jul 2012 19:41:42 -0000

I don't have strong religious beliefs about references, if we need
them we can put them in.  When I look at the IESG statement about
references, it says "It is not considered necessary to cite basic
specifications that may be safely assumed to be known to
practitioners" which I think lets us off the hook for RFC 20* for
ASCII, 5321 for bounce addresses, and 5322 for common mail message
headers.

How about if I add normative refs to 6531 for SMTPUTF8 and 6532
for non-ASCII headers, and put back 6068 for mailto:, since that's
the only URI scheme we talk about beyond a simple mention?

R's,
John

http://www.ietf.org/iesg/statement/normative-informative.html

* - for which I just filed an erratum, by the way

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 13 Jul 2012 22:00:24 +0200

> not defined in it needs to be referenced.

Hi Alexey, I noticed that all of your drafts mention the IETF, but you 
neither define it nor reference a definition ;)

Seriously, that rule is generally taken seriously only for terms that 
affect the meaning of the document. "Copyright 2012 trustees of the 
IETF" has no impact on the document's meaning — it could be IBM, the 
document would still say the same thing.

IMO mailto does not need a reference. No matter what mailto actually 
means, the document still says the same thing.

Arnt

---

From: SM <[email-masked]>
Date: Fri, 13 Jul 2012 13:18:59 -0700

At 13:00 13-07-2012, Arnt Gulbrandsen wrote:
>Hi Alexey, I noticed that all of your drafts mention the IETF, but 
>you neither define it nor reference a definition ;)

+1 :-)

>means, the document still says the same thing.

I included a reference to "mailto" in a draft as a pointer for an 
implementer to see what's the relevant specification quickly.  I have 
heard of the thing called a search engine.  The short answer is that 
it is more of a matter of style.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Jul 2012 19:25:35 -0400

--On Friday, July 13, 2012 12:56 -0700 S Moonesamy
<[email-masked]> wrote:

> Hi John,
> At 09:04 13-07-2012, John C Klensin wrote:
>> reasonable (or more so) to clarify that the particular URIs
>> and references to them appear in 2369.
> 
> If I recall correctly we discussed about URIs for
> draft-moonesamy-rfc2369bis-04 [1].  Could you refresh my
> memory about what to clarify to help mailinglist-02?

As far as mailinglist-02 (or -03) is concerned, I think John L
is on the right track, I agree that we don't need references to
"IETF" or "email", that the issue has gotten down to where
"editor's discretion" sets in, and I'm willing to let him apply
that discretion.

   john

---

From: "John Levine" <[email-masked]>
Date: 14 Jul 2012 00:36:06 -0000

I just submitted -04 which differs from -03 only in that there is a
new sentence in the introduction with a normative referenc to RFC
6530, which describes all the EAI stuff including SMTPUTF8 and
non-ASCII addresses in mail headers, and a normative reference to RFC
6068 which describes percent encoded addresses in mailto URIs.

R's,
John

PS: Since the point of a normative reference is that a reader is
expected to be familiar with the reference to understand the document,
I'm asuming that means that readers are familiar with the normative
references in the normative references and so forth.  So now that I've
added a reference to RFC 6530, you might want to reread RFC20, RFC791,
RFC821, RFC822, RFC974, RFC1034, RFC1035, RFC1047, RFC1123, RFC1305,
RFC1652, RFC1869, RFC1870, RFC1894, RFC1970, RFC2026, RFC2028,
RFC2033, RFC2034, RFC2045, RFC2046, RFC2048, RFC2119, RFC2192,
RFC2234, RFC2244, RFC2246, RFC2277, RFC2279, RFC2327, RFC2387,
RFC2396, RFC2434, RFC2460, RFC2554, RFC2743, RFC2782, RFC2821,
RFC2822, RFC2860, RFC2978, RFC3023, RFC3190, RFC3207, RFC3280,
RFC3339, RFC3454, RFC3461, RFC3462, RFC3463, RFC3464, RFC3501,
RFC3550, RFC3551, RFC3555, RFC3629, RFC3798, RFC3848, RFC3864,
RFC3885, RFC3886, RFC3887, RFC3888, RFC3986, RFC4013, RFC4234,
RFC4288, RFC4291, RFC4409, RFC4422, RFC4467, RFC4468, RFC4646,
RFC4647, RFC4648, RFC4954, RFC5198, RFC5226, RFC5234, RFC5248,
RFC5321, RFC5322, RFC5646, RFC5890, RFC6152, RFC6409, RFC6522,
RFC6531, RFC6532, RFC6533, ISO 639, NIST SHA-1, and the Apple AIFF-C
spec.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 14 Jul 2012 11:06:56 +0900

Hello John,

Thanks for your mail. I think we are getting closer to where we have a 
misunderstanding.

On 2012/07/13 22:36, John R Levine wrote:
>> implementation problem (correct escaping/unescaping) and not an
>> a-priori problem, hasn't been taken into account, and I don't know why.
>
> there.

Sorry about that. I don't claim that my text is perfect.

> The problem is very simple, some MTAs mishandle addresses that
> contain % signs.

Here is where we have the misunderstanding/disagreement. The original 
problem is NOT what MTAs do with addresses that contain % signs. If e.g. 
I enter something like [email-masked] into a To field in my 
MUA, then that might work somehow, or not, but that's secondary.

To continue, if there is an URI mailto:[email-masked], and 
it gets correctly converted to [email-masked], then that 
might work somehow, or not, but that's again irrelevant.

The actual problem we want to discuss (on which point I very strongly 
agree with John Klensin) is the case where there is e.g. an URI of the 
form mailto:[email-masked], which should end up in a 
mail to unlikely?[email-masked], but because the unescaping is 
missing, produces a mail to [email-masked].

The address [email-masked] is essentially wrong. What 
some mailers do with such an address, or with addresses containing % in 
general, just affects who wrongly gets (or doesn't get) the mail, and 
how easy it might be to debug the problem. But the problem happened earlier.

> All we need to do is note it, not tell people how we

Just to note it may be okay (a nugde in the right direction for a fix 
can't hurt though), but what's important is that the focus has to be on 
unescaping %-encoding when moving from mailto: to raw email addresses, 
rather than on what mailers do with mail addresses that have a % in them.

BTW, the examples are all taken from RFC 6068, so again it might not be 
such a bad idea to reference it.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 14 Jul 2012 11:14:09 +0900

> RFC 3986, which we do reference, describes all of the URI schemes that

Small detail, maybe relevant, maybe not: RFC 3986 only describes the 
general syntax of URIs. It does not define individual schemes. The last 
time general URI syntax and individual schemes were described in the 
same spec was in RFC 1738, which is two generations ago (with RFC 2396 
in between).

> It probably would be a good idea to reference 6531 and 6532, though.

Yes indeed.

Regards,   Martin.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 13 Jul 2012 12:56:13 -0700

Hi John,

If I recall correctly we discussed about URIs for 
draft-moonesamy-rfc2369bis-04 [1].  Could you refresh my memory about 
what to clarify to help mailinglist-02?

Thanks,
S. Moonesamy

1. http://tools.ietf.org/html/draft-moonesamy-rfc2369bis-04

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 24 Jul 2012 17:30:03 +0900

Hello John,

On 2012/07/14 4:37, John C Klensin wrote:

> other things).

I plan to have a look at RFC 3696. Ideally, the issues described therein 
should be clear from the base specs. If we can do anything in 3987bis or 
in the mailto draft, let's do that.

> I'd be delighted to retire to junior author if

There are most possibly other cases where funky characters in mail are 
relevant, but for the origin of these discussions, I think first and 
foremost, it would be good to make sure that whatever is needed is in 
the mailto draft. My personal guess is that we have enough examples in 
there to make any serious implementer aware of the issues (and 
superficial implementers won't read the document anyway), but if you see 
any way to be clearer, please propose additional text or examples. I'll 
very gladly integrate them into the draft.

Regards,   Martin.