Subject: [EAI] Specify a "use only one of these" address list

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Mar 2006 18:25:56 -0600

Per the comment I made at the microphone, the feature I was referring to was in 
RFC 733, but was deprecated by the time of RFC 822:

> address     =  host-phrase                  ; Machine mailbox
>             / ( [phrase] "<" #address ">")  ; Individual / List
>             / ( [phrase] ":" #address ";")  ; Group
>             /  quoted-string                ; Arbitrary text
>             / (":" ( "Include"              ; File, w/ addr list
>                    / "Postal"               ; (U.S.) Postal addr
>                    /  atom )                ; Extended data type
>                ":" address)
> 

The second line is what I was referring to.

The text describing defining the semantics of this is:

>     An individual may have  several  mailboxes  and  a  group  of
>     individuals  may wish to receive mail as a single unit (i.e.,
>     a distribution list).  The second and third  alternatives  of
>     an  address  list  (#address)  allow  naming  a collection of
>     subordinate  addresses  list(s).   Recipient  mailboxes   are
>     specified  within the bracketed part ("<" - ">" or ":" - ";")
>     of such named lists.  The use of angle-brackets ("<", ">") is
>     intended for the cases of individuals with multiple mailboxes
>     and of special mailbox lists; it is not expected to be nested
>     more  than  one level, although the specification allows such
>     nesting.  The use of colon/semi-colon (":", ";") is  intended
>     for  the  case  of  groups.   Groups  can be expected to nest
>     (i.e., to  contain  subgroups).   For  both  individuals  and
>     groups,  a  copy  of the transmitted message is to be sent to
>     EACH mailbox  listed.   For  the  case  of  a  special  list,
>     treatment of addresses is defined in the relevant subsections
>     of this section.

Note that the semantics, here, say to send to ALL of the addresses in the list.

I believe that the goal for the current should be to direct the use of only ONE 
OF the addresseses.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

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

---

From: Chris Newman <[email-masked]>
Date: Tue, 21 Mar 2006 00:38:41 -0600

If we're using:

  phrase <utf8@utf8-domain, ascii@domain>

in RFC 2822 + UTF 8 headers, why don't we use:

MAIL FROM:<utf8@utf8-domain, ascii@domain>

in SMTP instead of the ALT-ADDRESS parameter?

The similar looking protocol is an obvious, but minor advantage of this 
approach.

However, the major advantage of this stems from a limitation of ESMTP 
parameters.  RFC 2821 forbids the use of "=" in an ESMTP parameter value and 
"=" is a common character in ASCII email addresses.  Furthermore, it forbids 
use of space which is legal (albeit never used).  We could work around this 
using xtext encoding (as ORCPT does), by ignoring the rules or by forbidding 
those characters.  But I don't find any of those as satisfactory as simply 
putting both addresses in the angle-brackets.

So I propose we remove ALT-ADDRESS and replace it with optional dual-address in 
the angle-brackets so we can sidestep the parameter encoding/illegal-character 
issue.

                - Chris

---

From: Tony Hansen <[email-masked]>
Date: Tue, 21 Mar 2006 08:40:36 -0500

This sounds reasonable.

	Tony Hansen
	[email-masked]

Chris Newman wrote:
> parameters.  RFC 2821 forbids the use of "=" in an ESMTP parameter value
> and "=" is a common character in ASCII email addresses.  Furthermore, it
> forbids use of space which is legal (albeit never used).  We could work
> around this using xtext encoding (as ORCPT does), by ignoring the rules
> or by forbidding those characters.  But I don't find any of those as
> satisfactory as simply putting both addresses in the angle-brackets.
> 
> So I propose we remove ALT-ADDRESS and replace it with optional
> dual-address in the angle-brackets so we can sidestep the parameter
> encoding/illegal-character issue.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 08:04:17 -0600

> encoding/illegal-character issue.

So:

If there is one address
    and the ATOMIC parameter is present
    and the UTF-8 address must be converted
    then the converted address is added to the rcpt-to list.

If there are two addresses
    then the conversion has already been performed.

It is tempting to suggest that a posting agent simply include both addresses all 
the time.  Therefore it would not be necessary to do the conversion later.  It 
would merely be a case of choosing one.

I do not recall whether ALT-ADDRESS is restricted to be a conversion of the 
UTF-8 address, but it might be useful to allow it to be any legacy-encoded 
address.  Having the posting agent specify the rcpt-to address as a list 
obviously permits this freedom; addresses may be entirely independent of each other.

d/

-- 

Dave Crocker

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 21 Mar 2006 09:27:53 -0500

A small suggestion...
We talked about using a separator for the UTF8 and ASCII addresses within the angle brackets and started using the comma.  This seems to be a bit confusing especially considering what Dave pointed out in RFC733, since commas are usually used for lists, i.e. "ALL" rather than "OR".
Would suggest using a different separator, e.g. a slash "/" or a vertical bar "|":
<utf8@utf8 / ascii@ascii>
<utf8@utf8 | ascii@ascii>

Edmon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 09:47:14 -0600

Edmon,

What is being proposed *is* a list.  That the list is a USE-ONE-OF, rather than 
a USE-ALL, form of list. However this strikes me as a minor point of distinction.

I suspect the only important issue about making the syntactic choice is that the 
delimiter be taken from the existing set of special characters.  Slash and 
vertical bar are not members of that set.

d/

-- 

Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Mar 2006 11:00:00 -0500

--On Tuesday, March 21, 2006 09:47 -0600 Dave Crocker 
<[email-masked]> wrote:

> Edmon,
>
> What is being proposed *is* a list.  That the list is a
> USE-ONE-OF, rather than a USE-ALL, form of list. However this
> strikes me as a minor point of distinction.
>
> I suspect the only important issue about making the syntactic
> choice is that the delimiter be taken from the existing set of
> special characters.  Slash and vertical bar are not members of
> that set.

Worse yet, slash is a key syntax character in a local-form 
address from a particular class of gateway that, while better 
best forgotten, can't be.
    john

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 21 Mar 2006 11:21:59 -0500

I guess the point is, there should probably be some differentiation than using a comma.
Edmon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 10:34:05 -0600

> Worse yet, slash is a key syntax character in a local-form address from 
> a particular class of gateway that, while better best forgotten, can't be.
>    john

oh.  right.  how interesting i forgot that...

to that end, i should note that two other characters that are <special>, but are
not defined as such in the 2822 or 2821 list of specials are plus (+) and equal (=).

My suggestion is that the delimiter for the representation of this address set
a) be the same for rfc2822 header fields and rfc2821 the rcptto command, and

b) be taken from the common set of lexical specials in rfc2821 and rfc2822. I
think that comma falls in that category.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 10:34:20 -0600

> I guess the point is, there should probably be some differentiation than using a comma.

That is a concise statement.  Thanks.

What I am not understanding is why a syntactic distinction is needed, here.  How
will it improve usability, reliability, or the like?

d/
-- 

Dave Crocker

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 21 Mar 2006 11:36:40 -0500

Well, if there are certain ways that application treats comma separated lists of email addresses in the given context currently, then a different notation would more clearly signal a need for handling them differently.
Edmon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 10:07:53 -0600

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 10:28:44 -0600

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 10:31:36 -0600

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 10:50:43 -0600

> Well, if there are certain ways that application treats comma separated lists of email addresses in the given context currently, then a different notation would more clearly signal a need for handl…

OK.  Fair concern.

I believe the answer is:

      Nothing currently handles commas inside angle-brackets.

      So we are talking about brand new code and a brand new capability.

(I feel safe is asserting that there is no deployed code that supports the 
original RFC733 construct...)

d/

-- 

Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Mar 2006 12:01:25 -0500

--On Tuesday, March 21, 2006 08:04 -0600 Dave Crocker 
<[email-masked]> wrote:

>> So I propose we remove ALT-ADDRESS and replace it with
>> optional  dual-address in the angle-brackets so we can
>> sidestep the parameter  encoding/illegal-character issue.
>
> So:
>
> If there is one address
> It is tempting to suggest that a posting agent simply include
> both addresses all the time.  Therefore it would not be
> necessary to do the conversion later.  It would merely be a
> case of choosing one.

Both addresses may not exist.  We've been told by system 
administrators and users all over the world (but some parts of 
the world in particular -- this is layer 9 stuff and I'm happy 
to discuss specifics privately)  that a requirement that they 
have and manage ASCII addresses when they are communicating only 
locally is unacceptable and insulting.   As we all know, 
protocol requirements that are considered unreasonable are 
generally ignored.   I think that, in practical terms, we need 
to allow for the case that neither ATOMIC nor an alternate 
address will be present and that probably ought to specify what 
should be done in that case.

My personal view is that, if one is reduced to guessing about 
the address to which a message should be delivered, it is better 
to bounce it, but others may disagree.

> I do not recall whether ALT-ADDRESS is restricted to be a
> conversion of the UTF-8 address, but it might be useful to
> allow it to be any legacy-encoded address.  Having the posting
> agent specify the rcpt-to address as a list obviously permits
> this freedom; addresses may be entirely independent of each
> other.

It is not restricted to such a conversion.  It is not even 
restricted to be in the same domain.  I think that Yangwoo and I 
explained why in the framework document but, if not, or if it 
isn't clear there, we will be happy to do so at length.  But the 
short answer is that, in many countries, some people use 
transliterations of their actual names while others use 
translations (sometimes fanciful ones).   There are no standard 
rules.  The reason for the different domain?  There are several 
but consider

    [email-masked]
and
 
[email-masked]

Two other observations about the comma story.  These aren't 
showstoppers, just things to think about before we decide.   As 
many of us are unlucky enough to know, we've got a legacy piece 
of SMTP syntax that looks like

   <@a,@b,@c:d@e>

Quite independent of the more substantive reasons for abandoning 
and it and deprecating its use, many implementations of it were 
astonishingly bad, resulting in other implementations that 
perhaps got unreasonably permissive.    I vaguely remember at 
least one that would accept
   <a,b,c:d@e>
as a form of the above.   If such code is around, it could get 
really confused.

As we discussed yesterday, this may be the point at which we 
invoke the "if you implement this extension, you need to clean 
up your act" rule.  But that rule has costs and should be 
applied carefully.  The reason I initially chose a parameter was 
just to dodge any possible concerns about strange legacy code in 
this area.  I'm not particularly committed to it, but that is 
why it started the way it did.

Dave wrote a bit later...

> My suggestion is that the delimiter for the representation of
> this address set a) be the same for rfc2822 header fields and
> rfc2821 the rcptto command, and
>
> b) be taken from the common set of lexical specials in rfc2821
> and rfc2822. I think that comma falls in that category.

I certainly agree with (b) if we are going down this path.  For 
(a), I suggest it is a desirable target, but that we need to 
examine and balance other considerations.  Those addresses are 
already a bit different (no name phrase in RCPT, I think no 
@a:b@c forms in 2822 addresses).  And I think the case analysis 
of what a downgraded form would look like to a legacy POP or 
IMAP client needs to be done _very_ carefully.

Edmon wrote:

> Well, if there are certain ways that application treats comma
> separated lists of email addresses in the given context
> currently, then a different notation would more clearly signal
> a need for handling them differently.

It feels as if Edmon and Dave aren't communicating, so let me 
try to explain what I think Edmon is saying.

In the most common case,
    ...
   RCPT TO:<[email-masked]>
   RCPT TO:<[email-masked]>
shows up in the headers as
   To: [email-masked], [email-masked]
Now, we can also have
   To: Melvin <[email-masked]>, Dick <[email-masked]>
but the no-phrase forms
   To: <[email-masked]>, <[email-masked]>
are aesthetically unattractive (and were prohibited entirely 
prior to, I think, RFC 1123)

So, if one is going to have
    RCPT TO:<[email-masked], [email-masked]>
    RCPT TO:<[email-masked]>
That "To:" header is going to look like...
    To:  <[email-masked], [email-masked]>, [email-masked]
????

Well, it is ugly.  Users who have been taught to ignore the 
brackets when name phrases are not present will be confused. 
And my confidence that MUA implementers will get it right is not 
what you'd call high.

And I think that was, more or less, Edmon's point.

    john

         john

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Mar 2006 12:11:27 -0500

Sorry, this note crossed my earlier reply in the aether. 
Comment below.

--On Tuesday, March 21, 2006 10:50 -0600 Dave Crocker 
<[email-masked]> wrote:

>> currently, then a different notation would more clearly
>> signal a need for handling them differently.
>
> OK.  Fair concern.
>
> I believe the answer is:
>

To be strictly correct "nothing currently handles unquoted 
commas inside angle-brackets".   The distinction is important 
because of the issues we had a brief discussion about yesterday: 
the quoting conventions are routinely screwed up as addresses 
are quoted and dequoted as mail passes through various systems.

Ned has more experience in this particular area than I do, but I 
would not be at all surprised if there were systems out there 
that would take
      a,b
as a syntax variation on
      "a\,b"  or "a,b"
and hence
      <a,b>
as a syntax variation on
      <"a\,b">  or <"a,b">

And, at that point, code written under an expansive view of the 
robustness principle to compensate for bad/buggy code could get 
into trouble with this.

See the earlier note about the "clean up your act..." principle, 
but I fear that, with some implementations, this could cause 
something that users have expected to work in a particular way 
to suddenly stop working.  And that makes the subset of users 
who identify themselves as "customers" very unhappy in painful 
ways.

Ned, what do you think?

> (I feel safe is asserting that there is no deployed code that
> supports the original RFC733 construct...)

Yeah.
     john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Mar 2006 11:12:21 -0600

> My personal view is that, if one is reduced to guessing about the 
> address to which a message should be delivered, it is better to bounce 
> it, but others may disagree.

I believe that an agent associated with an author or an agent associated with a 
recipient can reasonably be authorized to make some kinds of guesses.

I believe  it would be disastrous to have a standard that authorizes any sort of 
intermediary between them to make guesses.

d/

> It feels as if Edmon and Dave aren't communicating, so let me try to 
> explain what I think Edmon is saying.
> 
> In the most common case,
>    ...
>   RCPT TO:<[email-masked]>
>   RCPT TO:<[email-masked]>
> are aesthetically unattractive (and were prohibited entirely prior to, I 
> think, RFC 1123)
> 

yes.  i believe the reality is that there is no "pretty" way to provide the 
alterntive addresses for the same recipient.  so we merely get to debate among 
ugly choices.

d/
-- 

Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Mar 2006 12:21:36 -0500

--On Tuesday, March 21, 2006 11:12 -0600 Dave Crocker 
<[email-masked]> wrote:

>> the  address to which a message should be delivered, it is
>> better to bounce  it, but others may disagree.
>
> I believe that an agent associated with an author or an agent
> associated with a recipient can reasonably be authorized to
> make some kinds of guesses.

I certainly agree with that principle.  I get a little more 
anxious about an agent associated with a class of users, but not 
knowing which user is the recipient, making guesses but can 
tolerate it.  In particular, you know the mixed history of 
nearest-match address guessing systems.  The most difficult of 
those problems is having an address that works well and without 
comment for an extended period suddenly stop (or end up 
somewhere unexpected) because a conflicting address or nearer 
match is added to the receiving system.

Of course, if one carries that concern far enough, the logical 
conclusion is that all of this address substitution is a bad 
idea, a bad idea vaguely related to the "your address isn't 
deliverable, the message has been sent to ...." reply status 
from 821.  And that brings us to the conclusion that the right 
way to deal with an i18n address that cannot be transferred and 
delivered without transformation is to bounce it with an 
explanation that ASCII addresses and headers are needed in the 
path to the destination.   I'm not ready to go there, and I 
suspect I'm a lot more ready than many others, but...

> I believe  it would be disastrous to have a standard that
> authorizes any sort of intermediary between them to make
> guesses.

Again agreed.  Beyond that, isolating the cases may require a 
whiteboard.

     john

---

From: "Edmon Chung" <[email-masked]>
Date: Tue, 21 Mar 2006 12:32:52 -0500

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
> alterntive addresses for the same recipient.  so we merely get to debate among 

In that case, I suppose it is still better to avoid the use of the comma as it creates additional "ugliness" or confusion in my perspective.  Even though within the strict context the comma does not already carry meaning, in the context of emails, email addresses, email headers, etc, a comma separated list of addresses does carry certain conventional meaning, that is not entirely congruent with the intended usage here...
Edmon

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Mar 2006 20:52:55 -0500

Just for the record, I think this is a great idea.  Where I'm 
confused about what to do (and worried) is about how to map the 
syntax into the headers (see earlier note).   If we need to do 
<something else> in the headers, then we need to look at the 
tradeoffs and priorities between:

* doing one thing that seems right for envelope and another 
thing that seems right for headers and

* doing something that can be done consistently in both places.

      john

--On Tuesday, March 21, 2006 00:38 -0600 Chris Newman 
<[email-masked]> wrote:

> The similar looking protocol is an obvious, but minor
> advantage of this approach.
>...

---

From: Chris Newman <[email-masked]>
Date: Tue, 21 Mar 2006 23:59:32 -0600

Edmon Chung wrote on 3/21/06 9:27 -0500:
> A small suggestion...
> We talked about using a separator for the UTF8 and ASCII addresses within the
> angle brackets and started using the comma.  This seems to be a bit confusing
> especially considering what Dave pointed out in RFC733, since commas are
> usually used for lists, i.e. "ALL" rather than "OR". Would suggest using a
> different separator, e.g. a slash "/" or a vertical bar "|":

This is a great suggestion from a usability standpoint as it makes the "OR" 
property clearer to end-users in the event the mail client displays the headers 
unprocessed.  Unfortunately, both "/" and "|" are problematic because they are 
not specials and thus cause lexical problems (the serious one is that the space 
after a non-special delimiter would be lexically critical and that's 
non-intuitive so it will cause problems).

If we want a more user-friendly syntax than "," and we're limited to the 
specials, the option that comes to mind is:

<utf8@utf8 [ascii@ascii]>

I really like this syntax as it makes the subordinate nature of the ascii 
address clear.  Unfortunately, the following case:

<utf8@utf8 [ascii@[domain-literal]]>

would force a change to the lexical model for addresses as nested [] are not 
permitted today.  I don't have a good sense of how many implementations have a 
lexical processing step and how disruptive this would be to those 
implementations.  I'm not sure if that disruption would outweigh the usability 
benefit.

Thoughts?

                - Chris