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

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

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" <nobody at xyzzy.claranet.de>
To: <ima at ietf.org>
Sent: Monday, February 19, 2007 12:13 PM
Subject: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt


> Internet-Drafts at ietf.org 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 ima at ietf.org. 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
> 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