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

["YAO Jiankang" <yaojk at cnnic.cn>]

Thanks a lot.
comments below.

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


> YAO Jiankang wrote:
> 
> Hi, jumping to something where we apparently don't agree yet:
> 
>>> 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.
> 
> 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.

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?





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

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 at IDN
               an ASCII address :   abc at example.com
               an transformed address: bq-abcdef at xn-idn (transformed from non-ASCII at IDN or using some mapping)

now, Tom can set alt-address=abc at example.com or alt-address=bq-abcdef at xn-idn




> 
>>> 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.
> 
> Replacing "predefined way" by "local convention" I still don't see
> what this paragraph is about.


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

> ------------------------------------------------------------------
> 
>>> 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 ima at ietf.org. keep this
>> paragraph may be more clear for readers.
> 
> Didn't work for me.
> 
> -------------------------------------------------------------------
> 
>>>   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.
> 
> 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 ?!?


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.




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

will consider to reduce the text.

> 
>>> s/EAI protocol/UTF8SMTP/ (?)
> 
>> I still prefer EAI protocol. EAI protocol includes many rfc.  
>> 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):


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


 


> 
> | 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
> 
> 
> 
> _______________________________________________
> IMA mailing list
> IMA at ietf.org
> https://www1.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima