Subject: [EAI] The scenario favoring "uMailbox"?

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 26 Apr 2011 07:00:41 +0800

Dear all,

    Another thought on uMailbox and Mailbox ABNF syntax. Let us consider the following scenario:

Step 1: Alice with an ASCII@ASCII address from rfc5321 system send the message to BOB with an ASCII@A-lable or ASCII@ASCII address from the EAI-aware XX system.  
Setp 2: BOB with an ASCII@A-lable or ASCII@ASCII address from the EAI-aware XX system replys the message to Alice with an ASCII@ASCII address.

If we allow the step 2 happen, the EAI-aware XX system  should recognize both uMailbox and Mailbox or make a difference between Mailbox and uMailbox.
but if we refuse step 2 to be happened, it looks like a little strange.

Any thought?

Jiankang Yao

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Apr 2011 17:33:19 -0700

On 4/25/2011 4:00 PM, Jiankang Yao wrote:
> Step 1: Alice with an ASCII@ASCII <mailto:ASCII@ASCII> address from rfc5321
> system send the message to BOB with an ASCII@A-lable <mailto:ASCII@A-lable> or
> ASCII@ASCII <mailto:ASCII@ASCII> address from the EAI-aware XX system.
> Setp 2: BOB with an ASCII@A-lable <mailto:ASCII@A-lable> or ASCII@ASCII
> <mailto:ASCII@ASCII> address from the EAI-aware XX system replys the message to
> Alice with an ASCII@ASCII <mailto:ASCII@ASCII> address.
> If we allow the step 2 happen, the EAI-aware XX system should recognize both
> uMailbox and Mailbox or make a difference between Mailbox and uMailbox.

The basic problem with your approach is that you are still trying to define a 
hybrid ASCII + UTF-8 system.  However that is no longer the model, for the 
current, core specifications.

The current model is for sending UTF-8 addresses to systems that support UTF-8 
addresses.  Note that an ASCII@ASCII address is /also/ a UTF-8@UTF-8 address.

So there is not need to have the syntax support both ASCII and UTF-8 addresses. 
  They only need to support UTF-8 addresses.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 26 Apr 2011 09:48:22 +0800

----- Original Message ----- 
From: "Dave CROCKER" <[email-masked]>
To: "Jiankang Yao" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 26, 2011 8:33 AM
Subject: Re: [EAI] The scenario favoring "uMailbox"?

> current, core specifications.

I am not trying to define a hybrid ASCII + UTF-8 system. 
but I think that the implementor will be likely to choose to recognize both rfc5321 address and UTF-8 address.
If they choose to recognize both addresses, we should give them more convenient way to do it.

> addresses.  Note that an ASCII@ASCII address is /also/ a UTF-8@UTF-8 address.

yes,  an ASCII@ASCII address is /also/ a UTF-8@UTF-8 address. 

It means that EAI system supports ASCII@ASCII address too because rfc5336/5bis define  UTF-8@UTF-8 address.

the problem is that:

the rfc5336bis said

 "

If the UTF8SMTPbis SMTP extension is not offered by the SMTP server,
   the EAI-aware SMTP client MUST NOT transmit an internationalized
   email address and MUST NOT transmit a mail message containing
   internationalized mail headers as described in [RFC5335bis]
"

now the message from BOB to Alice containing the BOB's ASCII@A-label or ASCII@ASCII address and Alice's ASCII@ASCII address is internationalized message or not?

if we regard it as the  internationalized message, we can not send it according to the rule above defined in rfc5336bis because Alice's email server does not support  UTF8SMTPbis SMTP extension . 

if we regard it as non-internationalized message, the EAI-aware XX system should know it or at least know that it is not internationalized message. Furthermore, if   the EAI-aweare XX system happens to know that it is rfc5322/21 message and should follow the rfc5321/22 rule, the XX system and send this message; if   the EAI-aware XX system recognize that it is non-internationalized message but does not know it is rfc5322/21 message or not, the XX systme may refuse to send this message from BOB to Alice containing the BOB's ASCII@A-label or ASCII@ASCII address and Alice's ASCII@ASCII address .

If we allow BOB with an ASCII@A-lable or ASCII@ASCII address from the EAI-aware XX system to reply the message to Alice with an ASCII@ASCII address from rfc5321 system, making a difference in uMailbox and Mailbox is imporant althogh we do not try to define a hybrid ASCII + UTF-8 system.

Jiankang Yao

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Apr 2011 19:38:01 -0700

On 4/25/2011 6:48 PM, Jiankang YAO wrote:
> I am not trying to define a hybrid ASCII + UTF-8 system. but I think that the
> implementor will be likely to choose to recognize both rfc5321 address and
> UTF-8 address. If they choose to recognize both addresses, we should give
> them more convenient way to do it.

It is natural to want to be friendly to the implementer.

However no, a specification usually must not try to anticipate implementation 
work that goes beyond the primary goal of the specification.  The job of the 
specification is to define only what it is supposed to cover.  In this case, the 
current goal of the specification is to support UTF-8.

The fact that someone might make implementation decisions that go beyond what is
covered does not mean that the scope of the specification should be changed.
This is an example of the very basic difference between a protocol specification
and an implementation specification.

>> The current model is for sending UTF-8 addresses to systems that support
>> UTF-8 addresses.  Note that an ASCII@ASCII address is /also/ a UTF-8@UTF-8
>> address.
>

You have been using ASCII@ASCII to refer to addresses that are not 8-bit.

Hence, no, the current specification does not have the goal of supporting 
ASCII@ASCII.  It's goal is to transmit data that are full 8-bits.  The fact that 
some of that data might also qualify as ASCII is proving to be a distraction. 
That's why it is especially important to have everything put only in terms of UTF-8.

> the problem is that:
> the rfc5336bis said
>
> " If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, the
> EAI-aware SMTP client MUST NOT transmit an internationalized email address
> and MUST NOT transmit a mail message containing internationalized mail
> headers as described in [RFC5335bis] "

Yes, but the specification does not provide for downgrade.  That's the job of 
separate specifications that cover such gateway translation behavior, but it is 
not the job of these core specifications.

> now the message from BOB to Alice containing the BOB's ASCII@A-label or
> ASCII@ASCII address and Alice's ASCII@ASCII address is internationalized
> message or not?

For the purposes of this specification, there are no ASCII@ASCII addresses.  All 
addresses are UTF-8@UTF-8.

> if we regard it as the  internationalized message, we can not send it
> according to the rule above defined in rfc5336bis because Alice's email
> server does not support  UTF8SMTPbis SMTP extension .

The current specification does not define how to handle messages that are not 
UTF-8.  The previous version tried to specify that hybrid but it did not 
succeed.  The current specification is trying to cover only the simpler, cleaner 
case: UTF-8@UTF-8.

> if we regard it as non-internationalized message, the EAI-aware XX system
> should know it or at least know that it is not internationalized message.

If it is not an internationalized message, then it has nothing to do with the 
EAI working group.  Or, at least, it has nothing to do with these two, core 
specifications.

d/
-- 

   Dave Crocker

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 26 Apr 2011 11:37:18 +0800

From your comments, I have a feeling below, but not sure whehter it is righit or not.

For the example
"
Step 1: Alice with an [email-masked]  address from rfc5321 system send the message to BOB with an  [email-masked] or abc@a-label (ASCII@A-lable or ASCII@ASCII) address from the pure EAI-aware syste.  
Setp 2: BOB with an  [email-masked] or abc@a-label (ASCII@A-lable or ASCII@ASCII) address from the pure EAI-aware system try to reply the message to Alice with an ASCII@ASCII address.

"
If  [email-masked] or abc@a-label (ASCII@A-lable or ASCII@ASCII) are in the UTF-8 form,  the current EAI core system allow it to be sent.
If [email-masked] or abc@a-label (ASCII@A-lable or ASCII@ASCII) are in the ASCII  form,  the current EAI core system does not allow it to be sent or do not care for it.

If that is true,
it  means that Alice with an [email-masked] address from rfc5321 system can send the message to BOB with an  [email-masked] or abc@a-labeladdress from the Pure EAI-aware system;
but BOB with the [email-masked] or abc@a-label address in the  Pure EAI-aware system can not reply it to Alice with the [email-masked] since Alice's system does not support UTF8SMTP extension.

so the conclusion is that EAI system blocks the communication between [email-masked] or abc@a-label  in the pure EAI system  and [email-masked] in rfc2821 system??

Jiankang Yao

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2011 04:19:21 -0000

>so the conclusion is that EAI system blocks the communication between
>[email-masked] or abc@a-label in the pure EAI system and
>[email-masked] in rfc2821 system??

I wouldn't say it blocks it, although I would say that it doesn't
enable it.

This group spent a very long time trying to figure out ways to provide
downgrades for EAI messages, and gave up.  I don't think there is much
support for reopening that discussion.

R's,
John

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 26 Apr 2011 08:35:59 +0200 (CEST)

> specification is to define only what it is supposed to cover.  In this case, 
> the current goal of the specification is to support UTF-8.
>

If we go back the message exchanges we had in January/February, you will 
alo see that we somehow suggested to add an informational "implementers' 
guide" document, where we can both give correct suggestions, and also add 
a number of useful examples to clarify this and other possible different 
interpretations.

I storngly still think this is the way to go, and let the model clean and 
separate between the ascii-only and utf8-only areas, and add in between a 
"gateway" (or call it as you prefer!) specification.

> ASCII@ASCII.  It's goal is to transmit data that are full 8-bits.  The fact 
> that some of that data might also qualify as ASCII is proving to be a 
> distraction. That's why it is especially important to have everything put 
> only in terms of UTF-8.

exactly.

> separate specifications that cover such gateway translation behavior, but it 
> is not the job of these core specifications.

yes... call it "downgrading" :== gateway :-)

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: John C Klensin <[email-masked]>
Date: Tue, 26 Apr 2011 03:02:50 -0400

Dave,

I don't think there is "gateway" behavior involved here.  Let me
try a different version of the problem Jiankang is describing in
the hope of clarifying what he is asking about.   I apologize
for the length of this explanation, but I think we are having
both terminology confusion and substantive confusion (and
possibly disagreement).  I want to be very clear and precise in
the hope of isolating those issues so we can discuss them.

So...

--On Monday, April 25, 2011 19:38 -0700 Dave CROCKER
<[email-masked]> wrote:

>> I am not trying to define a hybrid ASCII + UTF-8 system. but
>> I think that the implementor will be likely to choose to
>> recognize both rfc5321 address and UTF-8 address. If they
>> choose to recognize both addresses, we should give them more
>> convenient way to do it.
> 
> However no, a specification usually must not try to anticipate
> implementation work that goes beyond the primary goal of the
> specification.  The job of the specification is to define only
> what it is supposed to cover.  In this case, the current goal
> of the specification is to support UTF-8.
>...

For clarity, let me avoid terms like ASCII@ASCII, ASCII@A-label,
and ASCII@UTF-8 and say instead "strictly 5321/5322 conforming"
(of which the first two cases are members) and "EAI-requiring"
(of which the third is an example).   Note that "EAI-requiring"
is different from "EAI-conformant".  The latter requires support
for all three of those cases (as well as cases involving
local-parts that are not strictly ASCII-conformant).  If I
correctly understand your notes on the subject, is the only
environment you consider interesting in the context of EAI work.
"EAI-requiring" is a property of particular messages and/or
their transmission.  It is not a property of systems.
EAI-conformant is a property of systems that fully support the
EAI specifications.

It is also worth noting that any EAI-conformant system that is
going to interact with the DNS MUST be IDNA2008-conformant in
its handling of labels (again, that interact with the DNS).

Now, JianKang's Alice, who is using a strictly 5321/5322 system,
sends a message to Bob using strictly 5321/5322 addresses and
message headers.  Those addresses might well include domains
that contain some A-labels.   That case is uninteresting from an
EAI standpoint because there is nothing else that Alice can send
Bob.  Neither 5321/5322 nor IDNA2008 prevent Alice from sending
domains containing A-labels since, as far as 5321/5322 are
concerned, A-labels are conformant to the domain-part
(letter-digit-hyphen) definitions in those specs and a strictly
5321/5322 conformant implementation has no need (or mechanism)
for distinguishing between (in IDNA2008 terminology) A-labels
and LDH-labels.

However, assume that the primary domain name for Bob's address
is an internationalized one, i.e., it contains some of the
special label formats specified in IDNA2008 as either U-labels
or A-labels.  While Bob's system is EAI-conformant, there is
nothing about the message or its transmission that makes it
EAI-requiring.

So the message is delivered.  Bob (or, more precisely, Bob's
MUA) now has it, on his EAI-conformant system.  

Bob might now decide to reply to Alice.  He might instead decide
to generate an entirely new message to her.  Given how little
5322 says about replies, the on-the-wire difference between the
two cases is fairly insignificant.  Since either is a new
message generated at MUA level (the "reply" case just has some
additional decorative header fields or header field content for
MUA-level threading purposes) and nothing is happening in
transit, there are no gateway or downgrade issues involved.

Now Bob's MUA and MSA, which are EAI-conformant, MUST be able to
originate an EAI-requiring message.  They are also required by
the current specs and if possible to recognize A-labels and to
_not_ send them.  Put differently, an EAI-conformant system
sending to an EAI-conformant system is required to send domain
parts in addresses (either forward-pointing or
backward-pointing) consisting entirely of U-labels or
LDH-labels; they are strongly discouraged from passing A-labels
around.

So, ignoring relays for clarity, Bob's MSA opens an ESMTP
session to Alice's delivery MTA.  That delivery MTA does not
advertise the UTF8SMTPbis capability (however the announcement
is spelled), so Bob's systems MUST NOT send an envelope or a
message whose headers contain backward-pointing addresses whose
domain parts contain U-labels (i.e., MUST NOT attempt to send a
message that is EAI-requiring for that reason (or any other
reason, but let's stick to my version of Jiankang's example).

But because, in that example, the only thing that can make a
message from Bob to Alice EAI-requiring is the domain part,
Bob's systems can behave like they are strictly 5321/5322
conforming in dealing with Alice.  5321 requires that, if an
extension capability is not advertised by the SMTP-server, the
SMTP-client MUST NOT use it, i.e., MUST exhibit strict 5321/5322
conforming behavior with regard to that feature.  And IDNA2008
requires that systems that conform to it MUST be able to
recognize A-labels and U-labels and convert between them as
required by context.

Now, if I understand it correctly, Jiankang's problem is that he
would like to make clear that Bob can (is capable of), and MAY,
send Alice a strictly 5321/5322 conformant message, using only
5321/5322 conformant facilities, if Alice's systems cannot
handle EAI-requiring messages.  Because the WG told him to
include a requirement that U-labels be used in internationalized
domain parts when possible, it is perfectly reasonable for him
to say what should occur when it is not possible (indeed, many
people have argued for making a statement of conditions and/or
alternatives a near-requirement when SHOULD is stated in a
conformance requirement).

He would like to use ABNF that facilitates making that
statement.   I am less sure than he seems to be that one ABNF
model blocks him from doing so while the other permits it.  But
it seems to me that taking a position of "if one is
EAI-conformant, it is all UTF-8 and nothing else is an EAI
concern" (whether or not that is, in fact, the position you are
taking) ignores the IDNA2008 requirement that one be able to
convert from U-label to A-label form when communicating with
applications or implementations that are known to be
non-IDNA-aware.

Finally, 

> and an implementation specification.

If he had asked about converting local-parts, I think the above
would be completely appropriate guidance given the WG's choices
about "downgrading".  However, because being EAI-conformant
requires that an implementation be IDNA-aware and
IDNA-conformant, it does not appear to me to be strictly
applicable to cases involving only the domain-part and
statements like "has nothing to do with the EAI Working Group"
are not strictly correct.

Jiankang, if the above is not consistent with your concern, or
misses part of it, please explain.

regards,
    john

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 26 Apr 2011 15:45:34 +0800

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: <[email-masked]>; "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 26, 2011 3:02 PM
Subject: Re: [EAI] The scenario favoring "uMailbox"?

> model blocks him from doing so while the other permits it. 
>

yes, I am concern that one ABNF model might block it and the other might permit it.

> But

It is consistent with my concern.
I agree all the points discussed in this message.
Thanks a lot for your detailed explanation. 
Jiankang Yao

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 26 Apr 2011 10:05:33 -0700

Jiankang,

On 4/25/2011 8:37 PM, Jiankang YAO wrote:
> For the example " Step 1: Alice with an [email-masked]  address from
> rfc5321 system send the message to BOB with an  [email-masked] or
> abc@a-label (ASCII@A-lable or ASCII@ASCII) address from the pure EAI-aware
> syste.

If I understand your example, all of the addresses in them use ASCII.  They are 
not UTF-8.  (A-label is ASCII and I believe it works in the existing email 
environment.)  Therefore your example for Step 1 does not seem to require EAI 
enhancements.

As a consequence, I do not understand the reference to "pure EAI-aware" for Step 
1.  What is the purpose of having that reference in Step 1?

> Setp 2: BOB with an  [email-masked] or abc@a-label (ASCII@A-lable or
> ASCII@ASCII) address from the pure EAI-aware system try to reply the message
> to Alice with an ASCII@ASCII address. " If  [email-masked] or abc@a-label
> (ASCII@A-lable or ASCII@ASCII) are in the UTF-8 form,  the current EAI core
> system allow it to be sent.

The first sentence of Step 2 refers to addresses that only are ASCII.  They do 
not need the EAI enhancement.

The second sentence appears to refer to these same ASCII addresses, but has them 
encoded as UTF-8 rather than pure ASCII.  If BOB has an email-system that is 
based on UTF-8, then yes, it is natural that the ASCII addresses will be encoded 
as UTF-8, rather than marked as ASCII.

However when BOB's system is sending a message has only these types of ASCII 
addresses, BOB's system can choose to use EAI or not use EAI.  That is, BOB's 
system can choose to "downgrade" the message to pure ASCII or to retain it as 
UTF-8 and use the EAI SMTP extension.

> If [email-masked] or abc@a-label (ASCII@A-lable or ASCII@ASCII) are in the
> ASCII  form,  the current EAI core system does not allow it to be sent or do
> not care for it.

Correct!

However I believe that this choice is outside of the scope of the current core 
specifications.  I further believe that that this issue is where the confusion 
in the working group discussion is occurring.

If BOB's system does not record that the message it received from Alice came in 
through legacy RFC5321, then you are correct that BOB's system will not know 
that it can and should use legacy SMTP.

If BOB's system sends all UTF-8 addresses as EAI, then it is likely that many 
transmission will fail.  This is an example of an issue that makes it useful to 
distinguish UTF-8 that is not ASCII.  It suggests that an implementation that 
supports EAI might wish to use legacy SMTP -- rather than EAI-enhanced SMTP -- 
when all of the addresses are pure ASCII.

However, that's implementation guidance, not protocol specification.  These need 
to be kept separate.

> [email-masked] or abc@a-label  in the pure EAI system  and [email-masked]
> in rfc2821 system??

If an EAI-enabled system sends all mail only in UTF-8, it is certain that quite 
a bit of mail will not be delivered.  This is especially true during the early 
stages of EAI adoption.

In January, I circulated an architectural description of the current model being 
pursued by working group:

  EAI Technical Architecture
  ==========================

  +-----------+                                      +-----------+
  | MUA-ASCII |                                      | MUA-ASCII |
  +----+------+                                      +-----------+
       |                                                  ^
       v                                                  |
  +-----------+    +-----------+    +-----------+    +----+------+
  | MSA-ASCII +--->| MTA-ASCII +--->| MTA-ASCII +--->| MDA-ASCII |
  +-----------+ ^  +-----------+ ^  +-----------+ ^  +-----------+
                |                |                |
                |                |                |
                |                |                |
  +-----------+ V  +-----------+ V  +-----------+ V  +-----------+
  | MSA-UTF8  |--->| MTA-UTF8  |--->| MTA-UTF8  |--->| MDA-UTF8
  +-----------+    +-----------+    +-----------+    +----+------+
       ^                                                  |
       |                                                  V
  +-----------+                                      +-----------+
  | MUA-UTF8  |                                      | MUA-UTF8  |
  +-----------+                                      +-----------+

This is a pure and simple model.  However, you are correct that it produces a 
failure for sending from UTF-8 systems to ASCII systems.  That is why the 
architecture does not show any arrows from UTF-8 to ASCII.

Obviously, UTF-8 systems need to be able to send to ASCII systems.  The question 
is how to support that?

The working group originally tried to support this with a model that dealt with 
ASCII and UTF-8 simultaneously.  It tried to do specifications that integrated 
support for pure-ASCII with support for UTF-8.  However this was too complicated 
and the effort was changed to the simpler model that is now being specified.

It is reasonable and it probably is necessary to have the working group deal 
with the scenario that you have described.

In terms of the above architecture diagram, it means finding a way to have 
arrows that go from the UTF-8 environment to the ASCII environment.  Certainly 
the current 'downgrade' specifications are part of that.  However that needs to 
be /separate/ specification work.  The attempt to add this to the core 
specifications re-creates the complexity and problems that the working group 
originally experienced.

I believe the correct place to resolve your concern is with a document that 
discusses EAI implementation, not the core EAI protocol specification documents.

d/
-- 

   Dave Crocker

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 27 Apr 2011 09:58:19 +0800

----- Original Message ----- 
From: "Dave CROCKER" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 27, 2011 1:05 AM
Subject: Re: [EAI] The scenario favoring "uMailbox"?

> 1.  What is the purpose of having that reference in Step 1?

As you have pointed it out,  if [email-masked] or abc@a-label is in the utf-8 form, the EAI system will support it;if [email-masked] or abc@a-label is not in the utf-8 form, the EAI system will not support it;

Alice with an [email-masked]  address from rfc5321 system does not know BOB's system with   [email-masked] or abc@a-label  address.

Alice will just send the message to Bob.

The question now becomes:
1. The system with the addresses such as  [email-masked] or abc@a-label is EAI system or rfc5321 system?
2. Does the EAI system support the address such as [email-masked] with utf-8 form?
3. If the  [email-masked] with ASCII form belongs to rfc2821 system and  the  [email-masked] with utf-8 form belongs to EAI system,  will  BOB's EAI system refuse to accept the message from Alice's RFC5321 system with [email-masked] to BOB's system with  [email-masked] or abc@a-label??

Jiankang Yao

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 21:16:30 -0700

Jiankang,

On 4/26/2011 6:58 PM, Jiankang YAO wrote:
> As you have pointed it out,  if [email-masked] or abc@a-label is in the
> utf-8 form, the EAI system will support it;if [email-masked] or abc@a-label
> is not in the utf-8 form, the EAI system will not support it;

I do not understand what this means.

Anything that is in ASCII is also in UTF-8.  If a string is "in UTF-8 form" on a 
system that supports UTF-8, then the string will be supported.

So I think I do not know what you mean by "supported".

> Alice with an [email-masked]  address from rfc5321 system does not know
> BOB's system with   [email-masked] or abc@a-label  address.
>

Again, apologies, but I do not understand why this example will fail.

> EAI system or rfc5321 system?

Both strings appear to be ASCII, so I do not understand why this matters?

> 2. Does the EAI system support the address such as [email-masked] with utf-8

Of course it does, since ASCII is a subset of UTF-8.  (I do understand that I am 
missing your point; I'm trying to make clear what I think I am seeing, in the 
hope thatt you can figure out what part I am missing.  Unfortunately it is clear 
that I am not able to figure that out myself.)

> 3. If the  [email-masked] with ASCII form belongs to rfc2821 system and
> the  [email-masked] with utf-8 form belongs to EAI system,  will  BOB's EAI
> system refuse to accept the message from Alice's RFC5321 system with
> [email-masked] to BOB's system with  [email-masked] or abc@a-label??

I think you are asking:  will a UTF-8 system accept mail from an ASCII system?

      (For reference,  I suggest that the term "EAI" is not helpful here. Its 
precise meaning for this sort of discussion is not clear. On the other hand, 
referring to the encoding of the data is simple, direct and clear.)

The answer is no, without a gateway, if both systems only do one form of data.

In reality, we can expect a UTF-8 system also to support legacy RFC5321, but 
that is a pure "dual stack" model and the legacy behavior is outside the scope 
of the working group, since it is already covered by RFC5321/RFC5322.

Again, the architectural model the working group has chosen to pursue is for 
dual stack:  UTF-8 and ASCII are not handled together.  If the path is UTF-8, it 
is /only/ UTF-8.

d/

ps.  I provided an architectural diagram because it often is helpful to show 
these types of issues as pictures that label the actors and the data they are 
exchanging.  I do not know whether it will help for you to develop a picture for 
the above, but it might.

-- 

   Dave Crocker

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 29 Apr 2011 11:25:06 +0800

----- Original Message ----- 
From: "Dave CROCKER" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 28, 2011 12:16 PM
Subject: Re: [EAI] The scenario favoring "uMailbox"?

> Jiankang,

<snips>

> I think you are asking:  will a UTF-8 system accept mail from an ASCII system?

my question is similar to "will a UTF-8 system with recipent address (abc@a-lable) accept mail from an ASCII system with the sender address ([email-masked])?
"
the reversed question is  "can a UTF-8 system with recipent address (abc@a-lable) send mail to an ASCII system with the sender address ([email-masked])?
""

For both questions, your answers are No.

Is that my correct understanding.

If that is correct, I think that most of the current implementors will choose to support "dual stack" model  in the email system in order to avoid the serious email island.

If most implementors will choose  "dual stack" model, the implemntors may prefer "uMailbox" syntax instead of "malbox" syntax.
 
Even if we just use "mailbox" syntax in rfc5336bis, the implementors will choose to use the new name for the "mailbox"  of rfc5336bis in the actual implementaions in order to differ it from the rfc5321's "mailbox" name.

the question becomes: we change the name in the rfc5336bis mailbox syntax for implementors or the implementors choose their own version of the name for the rfc5336bis mailbox ?

thanks.

Jiankang Yao

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 Apr 2011 21:02:47 -0700

Jiankang,

On 4/28/2011 8:25 PM, Jiankang YAO wrote:
> my question is similar to "will a UTF-8 system with recipent address
> (abc@a-lable) accept mail from an ASCII system with the sender address
> ([email-masked])?

Let's start with the fact that both addresses are also valid UTF-8 addresses.

The current work only concerns sending UTF-8 addresses through a special, UTF-8 
SMTP extension.

So the answer to your first question must be Yes, when the message is sent using 
the extension.

Since both addresses also are coded as ASCII, a different question is whether 
the recipient could receive the message through legacy SMTP?  The answer to that 
is that it is outside the scope of this working group.  However we can expect 
that most or all systems that support the SMTP extension will also support 
legacy SMTP. (dual stack)

 >      " the reversed question is  "can a UTF-8 system with
> recipent address (abc@a-lable) send mail to an ASCII system with the sender
> address ([email-masked])? ""

Here the answer must be No, because the current scope of the EAI working group 
does not include solving this problem.

However, again, we can expect systems that support UTF-8 for sending also to 
support legacy SMTP for sending. (Again, dual stack.)

There will be a software design question of their deciding which to use, but 
that, again, is outside the current scope of the working group.

> For both questions, your answers are No.

Only for the second question, I believe.

> If that is correct, I think that most of the current implementors will choose
> to support "dual stack" model  in the email system in order to avoid the
> serious email island.

I believe you are correct.

> If most implementors will choose  "dual stack" model, the implemntors may
> prefer "uMailbox" syntax instead of "malbox" syntax.

Here I believe we run into the confusion between the current protocol 
specification work, versus software development work that will include the 
protocol enhancement.  The first has a narrow job.  The second has a broader job.

You are certainly correct that the software development effort must decide how 
to process dual-stack (ASCII and UTF-8) addresses within the same software 
system.  However that is not the job of the EAI working group.

> Even if we just use "mailbox" syntax in rfc5336bis, the implementors will
> choose to use the new name for the "mailbox"  of rfc5336bis in the actual
> implementaions in order to differ it from the rfc5321's "mailbox" name.

That's a software choice, not a protocol specification choice.  Our requirement 
needs to be keeping things as simple as possible while doing (only) the work 
that satisfies the working group requirements.

> the question becomes: we change the name in the rfc5336bis mailbox syntax for
> implementors or the implementors choose their own version of the name for the
> rfc5336bis mailbox ?

The problem with the uMailbox approach is that it does not use names that are 
"instead" of the existing ones; it uses names that are "in addition to" the 
existing ones.  And the result is a much, much more complex set of rules.

Complexity means that it is more likely to have bugs in the specification and/or 
the implementation.

d/
-- 

   Dave Crocker