Subject: Re: [EAI] EDITORIAL: draft-ietf-eai-smtpext-08.txt

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 1 Oct 2007 16:35:41 +0800

----- Original Message ----- 
From: "Alexey Melnikov" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 19, 2007 5:56 PM
Subject: [EAI] EDITORIAL: draft-ietf-eai-smtpext-08.txt

> Hi,
> 
> Most of the issues below are editorial, some of them can be considered 
> nitpicking.
> 
> 1). I am having a deja vue about this: why is the document referencing 
> RFC 1869, which got obsoleted by RFC 2821? The two references to RFC 
> 1869 are talking about ESMTP, I think RFC 2821 is quite appropriate.

updated to reference to both RFC 1869 and RFC 2821

> 
> 2). In Section 2.2:
> 
>   The UTF8SMTP extension is valid on the submission port [RFC4409].
> 
> This sentence is usually a part of the SMTP service registration template,
> should it be moved to section 2.1?

updated.

> 
>   An SMTP Client that receives the UTF8SMTP extension keyword in
>   response to the "EHLO" command MAY transmit a mailbox name as an
>   internationalized string in UTF-8 form and MAY send an UTF-8 header
>   [EAI-utf8header].  It MAY transmit the domain part of that string in
>   either the form of ACE labels specified in [RFC3490] or UTF-8 form.
>   In the domain part of the mailbox string, if any of the labels are
>   intended to be interpreted as non-ASCII (i.e., are IDNs), then the
>   Message Submission Server ("MSA") [RFC4409] MUST take responsibility
>   for ensuring that the labels are valid (whether they appear in native
>   character or ACE form).
> 
> Does "native character" mean UTF-8 here? I hope we are not recommending 
> use of any other charsets here.

updated.

> 
> [...]
> 
>   2.  Reject the message during the SMTP transaction or generate a
>       notification of non-deliverability, as specified in RFC 2821
>       [RFC2821] and RFC 3464 [RFC3464].  If the message content can be
>       returned without alteration, content should be returned as
>       specified in 2821 but, if a server is encountered along the
>       return path that cannot accept UTF8SMTP traffic, the content
>       should simply be abridged or dropped.
> 
> The last sentence is trying to redefine something already specified in 
> [EAI-dsn]. I think it contradicts [EAI-dsn]. Suggestion to replace the 
> last sentence with a pointer to [EAI-dsn]

updated to fllowing the text:

If the message content can be returned
without alteration, content should be returned as specified in
RFC 2821 but, if a server is encountered along the return path that
cannot accept UTF8SMTP traffic, the content should follow the specification
defined in the EAI DSN document [EAI-dsn].

is it ok for you?

> 
> 3). In Section 2.4:
> 
>        "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" /
> 
> Should "domain" be replaced with "uDomain" for consistency?
> (It can be argued that Postmaster@<uDomain> is still allowed by 
> uForward-Path below:)
> 
>                  uForward-Path) [ SP Rcpt-parameters ] CRLF
>               ; Update rcpt command in RFC 2821, section 4.1.1.3.
>               ; A new parameter defined by the ABNF non-terminal
>               ; <ALT-ADDRESS-parameter> is added. It complies
>               ; with the syntax specified by <esmtp-param>.

updated.

> 
> 4). In section 2.6:
> 
>   The UTF8SMTP extension MAY be used with the BODY=8BITMIME
>   parameter if that is appropriate given the body content or, if the
>   server advertises it and it is appropriate, with the BODY=BINARYMIME
> 
> The use of "it" is confusing here.
> 
>   parameter specified in [RFC3030].
> 
> I think the part starting from "if the server advertises" should read:
> 
>   if the server advertises BINARYMIME [RFC3030] and the the BODY=BINARYMIME
>   is appropriate, with the BODY=BINARYMIME parameter.

updated.

> 
> 5). In section 2.7.4:
> 
>   If the VRFY and EXPN commands have the optional parameter
>   "UTF8REPLY", it indicates the client can accept UTF-8 on replies of
> 
> UTF-8 *in* replies *to*
> 
>   the VRFY and EXPN commands.  Specially this allows to use UTF-8 on
> 
> UTF-8 *in* (here and in many cases below)
> 
>   mailboxes and full names which occur on replies.  The SMTP client
>   following this specification MUST accept UTF-8 on replies of the VRFY
>   and EXPN commands.  However the SMTP server MUST not use UTF-8 on
>   replies, if the SMTP client does not ask UTF-8 replies.  Some replies
>   include the mailbox, but usually most of replies do not require that
>   the mailbox is included in it and therefore UTF-8 is not needed.  The
>   UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP
>   server that the client is prepared for UTF-8 on SMTP replies.
> 
> [...]
> 
>   If the SMTP Client lack of the UTF8SMTP support receives the UTF-8
> 
> SMTP client *which lacks UTF8SMTP support* receives a UTF-8
> 
>   message on reply, it may crash.  UTF-8 messages on reply are only
> 
> [*in* reply.]

updated.

> 
> I would change "message" to "text" here to avoid any confusion with RFC 
> 2821 message.
> 
>   allowed in the commands under the situations described above.  Under
>   any other circumstances, UTF-8 messages on the reply MUST NOT be
>   used.

updated.

> 
> 6). In Section 3.2:
> 
>   The existing draft standard Delivery status notifications
>   (DSNs)[RFC3461] is presently limited to US-ASCII text in the machine
>   readable portions of the protocol.  "International Delivery and
>   Disposition Notifications" [EAI-dsn] adds a new address type for
>   international email addresses so an original recipient address with
>   non-US-ASCII characters can be correctly preserved even after
>   downgrading.  If an SMTP server advertises both the UTF8SMTP and the
>   DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including
>   support for the ORCPT parameter.
> 
> This reference to [EAI-dsn] is not informative! I think [EAI-dsn] should 
> be moved from Informative References to Normative References.

updated.

> 
> 7). In Section 10.2:
> 
>   [RFC2554bis]
>              Siemborski, R. and A. Melnikov, "SMTP Service Extension
>              for Authentication", draft-siemborski-rfc2554bis-09 (work
>              in progress), April 2007.
> 
> This is now an RFC 4954.

updated.

> 
>   [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
>       RFC 4409, April 2006.
> 
> As this document puts some requirements on Submission Agents, I don't think this reference is informative.

updated.

Thanks a lot for your kind comments.
Best Regards,
YAO Jiankang

> 
> Regards,
> Alexey
> 
> 
> 
> _______________________________________________
> 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: "YAO Jiankang" <[email-masked]>
Date: Mon, 1 Oct 2007 20:28:56 +0800

> defined in the EAI DSN document [EAI-dsn].

or use John's suggested text:
2.  Reject the message during the SMTP transaction or
generate a notification of non-deliverability, as
specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and
[EAI-dsn]. 

which is better?

YAO Jiankang
CNNIC