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

[Frank Ellermann <nobody at xyzzy.claranet.de>]

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

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

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

>> 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 ?!?

 [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/ (?)
 
> 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):

| 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