Subject: [EAI] EDITORIAL: smtpext-08 (1 .. 3)

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 24 Sep 2007 14:38:21 +0200

Hi, 

I'd say "An internationalized email address includes" instead
of "Internationalized email address includes without article.
Ditto "the email transport [...] provides" with an article,
maybe there are more missing articles in the document.

Is the reference to RFC 1869 necessary ?  It's obsoleted by
RFC 2821.  Something's odd with RFC 1869, its front page says
that it belongs to STD 10, but RFC 3700 says that STD 10
consists of RFC 821 and RFC 1870 (not 1869).

Maybe replace "the specification in [EAI-ut8header] specifies"
by "[EAI-utf8header] specifies", or s/specifies/explains/

2.1 #9: "The mail datum is extended"... what's a mail datum ?

2.2 s/a "mailbox" MAY appear/a mailbox may appear/, it's not
    about a normative OPTION.  Or s/MAY/can/ to be sure.

"The UTF8SMTP extension is valid on the submission port
[RFC4409]."  Maybe write "... can be also used for message
submission [RCF4409]."

2.3 <Atom>:
| That string MUST NOT contain any of the ASCII characters
| (either graphics or controls) that are not permitted in 
| "atext"; it is otherwise unrestricted.

s/; it is otherwise unrestricted//  At some point in time
(not now) there can be resrictions about say non-characters
or private use characters.

2.5:
| [EAI-utf8header] specifies "UTF8SMTP message" which requires
| UTF8SMTP support. Such a message MUST NOT be sent to an SMTP
[...]

An UTF8SMTP message or message/global or whatever requires
UTF8SMTP support only if transported with ESMTP, other
transport protocols like xmpp, nntp, etc. need to find their
own way to deal with such messages.  Proposal:

| An "UTF8SMTP message" as specified in [EAI-utf8header] MUST
| NOT be sent to an SMTP
[...]

2.6:
|  1.  For No "Body" parameter, headers are in UTF-8, body parts
|      are in ASCII.
|  2.  For BODY=8BITMIME parameter, headers are in UTF-8, some
|      or all body parts contain 8-bit line-oriented data.
|  3.  For BODY=BINARYMIME parameter, headers are in UTF-8, some
|      or all body parts contain binary data without restriction
|      as to line lengths or delimiters.

s/headers are/the header is/ and /body parts are/the body is/.
The internal MIME structure of messages is opaque for relaying
MTAs.

2.7.3:
-| Time stamp appears in the form of "Received: lines".
+| "Received:" header fields are also known as time stamp lines.
And s/("time stamp" or "Received")// before.

s/debugging mail faults/forensics/ (?)
(caveat, my DEnglish is utter dubious)

| The primary purpose of the Return-path is to designate the 
| address to which messages indicating non-delivery or other
| mail system failures are to be sent.

s/mail system failures/auto-replies/   Or maybe delete this
very incomplete explanation of the Return-Path here => KISS.

-| we update the time stamp line and the return path line
+| this memo updates the time stamp line and the return path
+| header field [RFC2821]

Maybe a matter of taste.  The "we update" style is fine, but
I think it should be used consistently or not.

| ; Replaces Return-path-line in the section 4.4 of

I'd replace "in the section ... of" by "in section ... of"
everywhere.  

| where non-ASCII domain name may be used
s/name/names/

-| More information is in the "IANA Considerations" section
-| of this document. 
+| Compare the "IANA Considerations" of this document.

2.7.4:
-| If the client issues the RCPT command which contains 
-| non-ASCII characters, the SMTP server
+| If the client sends a RCPT command containing non-ASCII
+| characters, the SMTP server

| the client can accept UTF-8 on replies of the VRFY and
| EXPN commands
Maybe s/on replies of/in replies to/ (???)

| MUST not use UTF-8 on replies, if the SMTP client does
| not ask UTF-8 replies
Maybe s/on replies/in replies/ and s/ask/ask for/ (???)

s/most of replies/most replies/  

ABNF-nit:
-| "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF;
+| "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF
Ditto for EXPN (= remove the unnecessary semicolon).

-| This parameter "UTF8REPLY" does not have value. If SMTP reply
+| The parameter "UTF8REPLY" has no value. If the SMPT reply
Or better remove this "no value" remark, the syntax is clear.

-| ; User Name allows the non-ASCII character.
+| ; User Name can contain non-ASCII UTF-8 characters.
That's an issue in 2821bis-04, if the User Name syntax is not
yet specified.  E.g. we can't have a "<" here.

-| enhanced mail system status code [RFC3463] is used
+| enhanced mail system status codes [RFC3463] are used

-| If the SMTP Client lack of the UTF8SMTP support receives
-| the UTF-8 message on reply, it may crash.

That's gibberish, just delete it.  Of course the client "may
crash" if the server violates MUSTard, that's more or less 
the definition of MUST in 2119.

I think one of the two last paragraphs in 2.7.4 can be 
deleted, they are variations of the same obvious concept.

Please get rid of chapter 3, these issues are discussed in
other I-Ds.

 Frank

 

  

 

 

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