Subject: Re: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 1 Mar 2007 18:03:11 +0800

Thanks a lot for your good comments.
I just return from our big Chines new year holiday.
some comments below.

YAO Jiankang
----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 19, 2007 12:13 PM
Subject: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt

> [email-masked] wrote:
> 
>> Filename        : draft-ietf-eai-smtpext-03.txt
> 
> 
> Some ABNF nits:
> 
> 1:
> Please replace all <Non-ASCII> by UTF8-2 / UTF8-3 / UTF8-4.
> <Non-ASCII> is an ambiguous term.  RFC 3977 uses the term
> <UTF8-non-ascii> if you insist on some kind of shorthand.

will update it to UTF8-non-ascii

> 
> 2:
> -  ; Let-dig in the right of '=' is defined in RFC 2822
> +  ; Augment Let-dig in RFC 2821, section 4.1.3

will update it 

> 
> 3:
> -  ; Replace Ldh-str in RFC 2821, section 4.1.2
> +  ; Replace Ldh-str in RFC 2821, section 4.1.3
> 

will update it 

> Do we really want an <uAt-domain> for UTF8SMTP source routing ?
> IMO relays should simply use the ASCII version of domain names
> in reverse or forward paths.  It's anyway deprecated.  Without
> <uAt-domain> there's of course also no <uA-d-l>.

here, we define uAt-domain for 

"MAIL FROM:" SP <uReverse-path> [ SP <mail-parameters> ]<CRLF>
                      uReverse-path = uPath
                      uPath = "<" [ uA-d-l ":" ] uMailbox ">"
                      uA-d-l = uAt-domain *( "," uA-d-l )
here uReverse-path should have UTF8 address.

> 
> -  sender, the email must be bounced to the original sender.  If the
> -  email is bounced due to the incapability of supporting UTF8SMTP, the
> +  sender, the email must be rejected.  If the email is rejected due
> +  to the incapability of supporting UTF8SMTP, the

will update it to reject.

> 
> Better don't talk about "bounces to the original sender", that's a
> wild and dangerous battlefield reserved for 2821bis.
> 
> The start of section 2.5 is rather obscure:
> 
>   The "ALT-ADDRESS" requires an all-ASCII address.  There are two
>   alternative ways to set ALT-ADDRESS value: one is set by the sender
>   using the all-ASCII address, the other is set using the transformed
>   email address.
> 
> IMO the other way is that the MSA (knowing the sender) could supply an
> ALT-ADRESSS for the MAIL FROM.  If that's in some way "transformed" or
> not is the local business of the MSA.

IMO, "transformed" address should not be produced by MSA or MTA. The sender should have some other method to produce "transformed" address as  the 
alternate address.

> 
> The following discussion about "transformations" could be deleted, we
> didn't pick that option.  It's also unclear what "the predefined way"
> is, (quote) the sender can specify that these addresses are safe to be
> converted in the predefined way (unquote).  For the RHS there is a
> clear predefined way, but not for the LHS.

this discussion exists because some member is not clear about why we did not prefer "transformed" address.

> 
>   Assuming that the server advertises UTF8SMTP and 8BITMIME, and at
> etc.
> 
> IMO that paragraph should be deleted, it's obscure and unnecessary.
> Of course BODY=8BITMIME and BODY=BINARY mean what they always mean,
> that doesn't depend on UTF8SMTP, as explained in the first paragraph
> in 2.6.

We  has already discussed this issue in the [email-masked]. keep this paragraph may be more clear for readers.

> 
> It's IMO misleading to assume that the presence of non-ASCII addresses
> in the envelope _always_ announces a message/utf-8.  For a RCPT TO it
> could be still a message/rfc822 (depending on the generated timestamp
> lines).  The oppposite also isn't necessarily true, the envelope could
> be ASCII, but the message header can contain UTF-8.
> 
>   This alternate-MX-or-retry-later technique SHOULD NOT be used when
> 
> It SHOULD NOT be discussed at all, it's really odd.  Especially "retry
> later", what's the idea, the receiver just happens to upgrade their MX
> today ?

 don't need upgrade their MX..  because some failure is temp failure, we may try anoher  host based on MX record.

Gellens has some disuccsuion in this issue in  the ima mailing list.

> 
> -   uFor = "FOR" FWS 1*( Path / uMailbox ) CFWS
> +   uFor = "FOR" FWS 1*( uPath / uMailbox ) CFWS
> 
> 

will update it according to your suggestions.

> 2.7.5:  Please delete the complete section, there's no "Header-Type"
> anymore.

will delte it.

>  2.7.6 could be also deleted, POP3 and IMAP are introduced
> in the framework RFC, they will get their own RFCs.  No SMTP business,
> no case for a "SHOULD".  Or is that about the job of MDAs ?  Then it
> doesn't say what special actions an MDA is expected to perform (after
> it got the uReturn-path-line right as specified in 2.7.3).

IMO, this section is kept for information. others' view?

> 
> 3.1:  Please delete this section, mailto URIs are no SMTP business.

will delete it.

> 3.2:  s/2476/4409/ everywhere, 

will use 4409

>and s/EAI protocol/UTF8SMTP/ (?)

I still prefer EAI protocol. EAI protocol includes many rfc.  UTF8SMTP is just one of them.

> The complete chapter 3 should go.  Chapter 4 is also unnecessary.

I still prefer keeps some of them.

> How about some nice example sessions ?
> 

a good suggestion.    will consider to have example sessions.

> Another nit in 2.2:
> 
> -  transmit a mail body which contains internationalized mail headers
> +  transmit a message which contains internationalized mail headers
> 
> Maybe 'mail data', SMTP transports complete messages, header + body.

update it to "message"

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

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

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 04 Mar 2007 19:24:13 +0100

YAO Jiankang wrote:

 
 
> here uReverse-path should have UTF8 address.

Yes, but IMO you can keep <A-d-l> as is, without introducing an
I18N format <uA-d-l> for the obsolete source routing.  RFC 1123
5.2.6 + 5.2.19 and RFC 2821 appendix F.2 explain that and why
that's obsolete.  You also don't need an I18N <uAt-domain> then.

<uPath>, <uMailbox>, and <uReverse-path> are of course needed,
we want the new <uMailbox> for UTF8SMTP.
----------------------------------------------------------------

>>   alternative ways to set ALT-ADDRESS value: one is set by the
>>   sender using the all-ASCII address, the other is set using the
>>   transformed email address.

>> IMO the other way is that the MSA (knowing the sender) could supply
>> an ALT-ADRESSS for the MAIL FROM.  If that's in some way "transformed"
>> or not is the local business of the MSA.
 
> IMO, "transformed" address should not be produced by MSA or MTA.
> The sender should have some other method to produce "transformed"
> address as the alternate address.

Then I miss a clue what "the other is set using the transformed email
address" or "some other method to produce 'transformed' address" is.

IIRC we discussed "standard transformations", and then decided that
it's a bad idea.  But there can be still "local conventions" at the
"mail originating network" (Keith's MON) to derive a working local
all-ASCII address for a given local UTF8SMTP address.

That local convention can be known by the MSA, or for what's it
worth by the MUA, and then MSA or MUA could automatically transform
the local _sender_ address into an all-ASCII ALTADDRESS using this
local convention.

But the sender (MUA or MSA) can't do anything about the address of
the receiver, the receiver has his own local convention (if any).

>> The following discussion about "transformations" could be deleted,
>> we didn't pick that option.  It's also unclear what "the predefined
>> way" is, (quote) the sender can specify that these addresses are
>> safe to be converted in the predefined way (unquote).  For the RHS
>> there is a clear predefined way, but not for the LHS.
 
> we did not prefer "transformed" address.

Replacing "predefined way" by "local convention" I still don't see
what this paragraph is about.
------------------------------------------------------------------

>> Of course BODY=8BITMIME and BODY=BINARY mean what they always
>> mean, that doesn't depend on UTF8SMTP, as explained in the first
>> paragraph in 2.6.
 
> paragraph may be more clear for readers.

Didn't work for me.

-------------------------------------------------------------------

>> It SHOULD NOT be discussed at all, it's really odd.  Especially
>> "retry later", what's the idea, the receiver just happens to upgrade
>> their MX today ?
 
> don't need upgrade their MX..  because some failure is temp failure,
> we may try anoher host based on MX record.
 
> Gellens has some disuccsuion in this issue in  the ima mailing list.

Yes, I've still flagged that article:
<http://permalink.gmane.org/gmane.ietf.ima/1112>

"Try another MX" could make sense, but I don't get "try later", is it
at the same MX ?!?

 [POP3 and IMAP] 
> IMO, this section is kept for information. others' view?

IMO not relevant for the SMTP draft.  Merging your draft with the DSN
draft might be an idea.  For POP3 and IMAP let the framework RFC (if
it's finally approved) offer the links, or maybe reduce your text to
references.

>> s/EAI protocol/UTF8SMTP/ (?)
 
> UTF8SMTP is just one of them.

IIRC we don't use or explain the acronym EAI anywhere, minus the WG
name and draft names of course... ;-)  You'd have to expand the EAI
acronym on first usage.  The framework RFC says in its chapter 1.3
(terminology):

| The umbrella term to describe the email address
| internationalization specified by this document and its companion
| documents is "UTF8SMTP".  For example, an address permitted by
| this specification is referred  to as a "UTF8SMTP (compliant) 
| address".

Oops, the A in EAI is an "address", for some minutes I thought that
it's "architecture".

Frank

---

From: Yangwoo Ko <[email-masked]>
Date: Mon, 05 Mar 2007 11:31:25 +0900

> YAO Jiankang wrote:

The purpose of section 2.5 is very unclear to me.

We accepted neither ACE-like "always working" transformation nor flags 
for "working for this case". This section can serve, with some 
modifications, as a short explanation behind this decision.

Or,

Still there surely will be cases where automatic conversions are useful. 
This section, with some modifications again, can explain what 
considerations are needed for those cases.

I prefer the former one.

Regards

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 5 Mar 2007 16:42:09 +0800

Thanks a lot.
comments below.

YAO Jiankang
CNNIC
----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 05, 2007 2:24 AM
Subject: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt

> we want the new <uMailbox> for UTF8SMTP.

on another thought, yes, you are right.
 I propose to change "uPath = "<" [ uA-d-l ":" ] uMailbox ">"
"  to uPath = "<" [ A-d-l ":" ] uMailbox ">"
where uMailbox is defined in this document, and A-d-l is defined in RFC2821.

is it ok? or any other good suggestions?

IMO, if the alt-address is set using the transformed address,  the receiver will not (or not need ) do anything to this alt-address.  
the initial text may be not very clear. so I propose to change it to
"The alt-adderss value is directly set by users. The user can use the existing ASCII email address or use some transformed email address
 which is gotten from some methods."

The meaning I want to present is that 
for example:
 Tom has a non-ASCII address:  non-ASCII@IDN
               an ASCII address :   [email-masked]
               an transformed address: bq-abcdef@xn-idn (transformed from non-ASCII@IDN or using some mapping)

now, Tom can set alt-address=[email-masked] or alt-address=bq-abcdef@xn-idn

> what this paragraph is about.

I will consider to refine this section to make it more clear.

based on this presumption: at least when the
   recipient address is non-ASCII, that the delivery path servers
   normally support UTF8SMTP (if the sender's client or MSA didn't
   support UTF8SMTP, the message would not have been accepted for
   delivery in the first place).  Thus, a lack of UTF8SMTP support is
   likely to be a temporary situation, such as a normal inbound server
   being down and a cooperating site acting as a backup MX.

from this assumption:
  if the domain part has two MX records, one host of one MX record may not support UTF8SMTP while the other host of the other MX record may support UTF8SMTP.  for this case, try another MX and may have some help.

if  the domain part has only one MX record, the server may temporary down or in other temporary bad situation.  for this case, try it again after a few minutes and may have some help.

> it's finally approved) offer the links, or maybe reduce your text to

will consider to reduce the text.

> acronym on first usage.  The framework RFC says in its chapter 1.3

how about change "EAI protocol" to "internationalized email address protoco" ?

---

From: Yangwoo Ko <[email-masked]>
Date: Mon, 05 Mar 2007 18:00:06 +0900

> how about change "EAI protocol" to "internationalized email address protoco" ?

If you are mentioning a specific proposal considered in this working 
group, UTF8SMTP is proper one as Frank pointed out.

If you want to make sure that you are mentioning email (address) 
internationalization in general, you may use email (address) 
internationalization if needed.

Regards