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

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 1 Oct 2007 20:23:04 +0800

----- Original Message ----- 
 From: "Frank Ellermann" <[email-masked]>
 To: <[email-masked]>
 Sent: Monday, September 24, 2007 8:38 PM
 Subject: [EAI] EDITORIAL: smtpext-08 (1 .. 3)

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

updated to reference to both RFC 1869 and 2821

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

updated.

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

updated to the mail message

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

updated.

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

move it to section 2.1

> 2.3 <Atom>:
º&Šf›¢éÜzÈžµú+€Ê'9Ët×O7×O6ÓNÑzÛ«ž–†)šn‹§që"z×è®^qè¯y×ë¢mvïM5…éh²Øžvšæ™©õ½©ÞºËZÊ&o)ž«k¢xžµú+ƒ…ë&¶‘1Šn8Þ'u!Â«M4ë.ºœÊ'ÓSœ·m4ïO7Ón´ãMyÇ¢½ç_®‰¢™¦ò™è¶º'‰ë_¢¸0ŠØe¡Æ¥¦ãâwR(ø´ÓN¯Ø>Ÿ¢¸¦iÊ'~*æú‰&z®‰âz×è®(ŸMNrÝ´Ó½<ßM|Ó4EçŠ÷~º&×OtßŽ8…éhržvšæj)u‰ë_¢¸Êg jÚèž'~ŠàÂ+azÉ­¤Lb›Ž7‰ÝHp£âÓM:±ÝI~Šâ™¨žµú+€Ê'ÓSœ·m4ïO7Ó_4ãMyÇ¢½ç_®‰¬šÚ\žxœr}y÷mºï^:…éhryâqÉÛÉÈbyÚk™¨¥Ö'~ŠàÂ+a²ki¦ãâwR(öôÓMŠ‹¾ß¢¸¦j'~Šà2‰ôÔç-ÛM;ÓÍô×m8ÓD^qè¯y×²¢ëÚk¢
Ú˜Ê'ÓSœ·m4ïm7ÓM~ÓÍ41ë,jˆuÛ|Ó]wën\žxœruÄ`å‚Ò13ÀQ1òjˆäryâqÉÑyÇ¢½ç_®‰®žIèÂqÄ,ìš¢95Û½4Õ¼µÛ½4×…#<Ê'ÓSœ·m4ïm7ÓM~ÓÍ41ë,jˆO7×M\óN6éÏyçN´Ómú}ý]k&¨ŽAk¢f8˜šžF§ƒ&¨ŽG'ž':©äY^®f§žz¡Ü±Ë<òrV«jwuä^}êÞÇ¬ßÝ:ß¿8Ó_xÛw'ž'ŸuÛ;çÝ¸çÍ\žxœrt®n7œµ„!3‘ ìšÚ^ÆÝ<×pÚµã(ŸSœ·m4ïm6ßN>ÓÍ40ƒUêìŠ‰õÑsëŠŠâ·-×1#ŠSëŠŠâ·#h®f¥\Æ¢•êÌ‰Êè²‡í:ëe¢‰ÆšÞ²Î´ÓotÓ}wñs"™ã‹úèvçtŒ‰Êè²‡í2)ž8±ëM6÷M7×J–¦IÊ+{þûï—IÆ§J('jÛ«{v¸mÎºÛ}:çÝw×N{m¾¼yÞuçßð'"™¨žµú+p^ztáz·¢™¨žµú+sŠYšW«²*'Û^OçuéÜzX¬´¸¬´‡D&j)@uÚÞ²Â'µêçjØ¨©bÍ«b¢x¦j'~Šà.+-R{.nÇ+‰·¡¶Úlÿü0ÃXžµú+ƒùšŠYšŸùb²Ø§~â™©šŠ[hŠf«z«ž²Øžµú+‚Ë›ç-º{.nÇ+‰·‹ŠË@Èb½èm¶ŸÿÃ5‰ë_¢¸?¦*^®f¢—ø¦h¸¬´ú,¶f¢–Ú"™¨žµú+€¸¬´w¥¦f¢–Ú"™ªÞªç¬¶'~Šà²æãyËazZKŠËR¹»®&Þ†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?Šf¦j)m¢)šê®zËbz×è®.n7œ¶Ë›±Êâmà¨ž×§µ<©zk¥¶*Z®ßæ‹n‹§uªò×Îv÷^}ç±+®ŠìNˆ¦iº.Ç¬‰ë_¢¸

 ----- Original Message ----- 
 From: "Frank Ellermann" <[email-masked]>
 To: <[email-masked]>
 Sent: Monday, September 24, 2007 8:38 PM
 Subject: [EAI] EDITORIAL: smtpext-08 (1 .. 3)

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

updated to reference to both RFC 1869 and 2821

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

updated.

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

updated to the mail message

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

updated.

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

move it to section 2.1

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

not very clear of the meaning.

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

updated.

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

updated.

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

updated.

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

updated.

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

updated.

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

updated.

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

updated.

> | the client can accept UTF-8 on replies of the VRFO�]��[��UT����۝Z[�[�HوHT��RH�\�X�\��B��
Z]\�ܘ\X��܈�۝���H]\�H��\�Z]Y[�B���]^��]\��\��\�H[��\��X�Y�B��B�����]\��\��\�H[��\��X�Y��]��YH�[�[�[YCB��
�����H\�H�[��H�\ܚX�[ۜ�X��]�^H�ۋX�\�X�\��B��܈�]�]H\�H�\�X�\�˃B�B����\�H�X\�وHYX[�[�˃B�B��B����N�B���PRK]]�XY\�H�X�Y�Y\��U��UY\��Y�H��X��\]Z\�\�B��U��U�\ܝ��X�HY\��Y�HUT����H�[��[��UB��ˋ��CB��B��[�U��UY\��Y�H܈Y\��Y�K��ؘ[܈�]]�\��\]Z\�\�B��U��U�\ܝۛHY��[��ܝY�]T�U�\�B���[��ܝ������Z�H\��]ˈ�YY��[�Z\�B���ۈ�^H�X[�]�X�Y\��Y�\ˈ����[�B�B��B��[��U��UY\��Y�H�\��X�Y�YY[��PRK]]�XY\�HUT�B�����H�[��[��UB��ˋ��CB�B�B�B�\]Y�B�B�B��B������B��K��܈�����H�\�[Y]\�XY\��\�H[�U�N��H\��B��\�H[�T��RK�B�����܈��ON�URSQH\�[Y]\�XY\��\�H[�U�N��YCB��܈[��H\���۝Z[�X�][�K[ܚY[�Y]K�B��ˈ�܈��OP�S�T�SRSQH\�[Y]\�XY\��\�H[�U�N��YCB��܈[��H\���۝Z[��[�\�H]H�]�]�\��X�[ۃB��\��[�H[���܈[[Z]\�˃B��B����XY\��\�K�HXY\�\��[�؛�H\��\�K�H��H\�˃B�B�B�\]Y�B�B�B��H[�\��[RSQH��X�\�HوY\��Y�\�\��\]YH�܈�[^Z[��B��U\˃B��B����ˌ΃B��_[YH�[\\X\��[�H�ܛHو��X�Z]�Y�[�\ȋ�B��
���X�Z]�Y��XY\��Y[�\�H[��ۛ�ۈ\�[YH�[\[�\˃B��[����[YH�[\�܈��X�Z]�Y�K���Y�ܙK�B�B�B�\]Y�B�B�B��B����X�Y��[��XZ[�][�ٛܙ[��X���
�CB��
�]�X]^H[��\�\�]\�X�[�\�CB��B��H�[X\�H\���HوH�]\��\]\��\�Yۘ]HHB��Y�\����X�Y\��Y�\�[�X�][���ۋY[]�\�H܈�\�B��XZ[�\�[H�Z[\�\�\�H��H�[��B��B����XZ[�\�[H�Z[\�\��]]�\�\Y\��܈X^X�H[]H\�B���\�H[���\]H^[�][ۈوH�]\��T]\�HO��T�˃B��B��_�H\]HH[YH�[\[�H[�H�]\��][�CB��
�\�Y[[�\]\�H[YH�[\[�H[�H�]\��]B��
�XY\��Y[ԑ�̎�WCB�B�B�\]Y�B�B�B��B��X^X�HHX]\�و\�K�H��H\]H��[H\��[�K�]B��H[��]��[�H\�Y�ۜ�\�[�H܈���B��B����\X�\��]\��\][[�H[�H�X�[ۈ
�كB��B��I��\X�H�[�H�X�[ۈ���و��H�[��X�[ۈ���و�B��]�\�]�\�K�B��B�B�B�\]Y�B�B�B���\�H�ۋPT��RH�XZ[��[YHX^H�H\�YB���ۘ[YKۘ[Y\��B��B�B�\]Y�B�B�B��_[ܙH[��ܛX][ۈ\�[�H�PS�H�ۜ�Y\�][ۜȈ�X�[ۃB��_و\���[Y[��B��
���\\�HH�PS�H�ۜ�Y\�][ۜȈو\���[Y[��B��B����ˍ�B��_Y�H�Y[�\��Y\�H����[X[��X��۝Z[��B��_�ۋPT��RH�\�X�\��H�U�\��\�B��
�Y�H�Y[��[��H����[X[��۝Z[�[���ۋPT��RCB��
��\�X�\��H�U�\��\�B��B�B�B�\]Y�B�B�B��H�Y[��[�X��\U�Nۈ�\Y\�وH���H[�B��V���[X[��B��X^X�H��ۈ�\Y\�ً�[��\Y\���
���CB�B�\]Y�B�B�B��B��UT���\�HU�Nۈ�\Y\�Y�H�U�Y[��\�B����\��U�N�\Y\�B��X^X�H��ۈ�\Y\��[��\Y\��[���\���\���܋�
���CB��B����[��و�\Y\��[���\Y\��B�B�\]Y�B�B�B��B��P���[�]�B��_����H��
S��[\\��SXZ[��
H���U��TH�Hԓ��B��
�����H��
S��[\\��SXZ[��
H���U��TH�Hԓ�B��]��܈V�
H�[[ݙHH[��X�\��\�H�[ZX��ۊK�B�B�\]Y�B�B�B��B��_\�\�[Y]\��U��TH��\���]�H�[YK�Y��U�\CB��
�H\�[Y]\��U��TH�\����[YK�Y�H�T�\CB��܈�]\��[[ݙH\�����[YH��[X\��H�[�^\��X\��B�B�\]Y�B�B�B��B��_�\�\��[YH[���H�ۋPT��RH�\�X�\��B��
��\�\��[YH�[��۝Z[��ۋPT��RHU�N�\�X�\�˃B�B�B�\]Y�B�B�B��]	��[�\��YH[���X�\�L
Y�H\�\��[YH�[�^\���B��Y]�X�Y�YY�K�ˈ�H�[��]�HH��\�K�B��B��_[�[��YXZ[�\�[H�]\���Hԑ���
��H\�\�YB��
�[�[��YXZ[�\�[H�]\���\�ԑ���
��H\�H\�YB��B��_Y�H�U�Y[�X��وHU��U�\ܝ�X�Z]�\�B��_HU�NY\��Y�Hۈ�\K]X^Hܘ\��B��B��]	���X��\�\��\�[]H]�و��\��HH�Y[��X^CB��ܘ\��Y�H�\��\��[�]\�UT�\�]	��[ܙH܈\��B��HY�[�][ۈوUT�[��LNK�B��B��H[��ۙHوH��\�\�Yܘ\�[���ˍ�[��HB��[]Y^H\�H�\�X][ۜ�وH�[YH؝�[�\��ۘ�\�B��B���YHY[X�\���Y��\�]�H��[�Y\]��]�H�[�[\\�^�H]�B�B��X\�H�]�Yو�\\��\�H\��Y\�\�H\��\��Y[�B���\�KQ˃B�B��[�ۜ�Y\���[[ݙCB�B�B�B�[���H��܈[�\��[���[Y[�˃B��\��Y�\��B�PS��X[��[��B�B�B��B����[��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B��B�������������������������������������������������B��SPHXZ[[��\�B��SPPY]��ܙ�B��΋�����K�Y]��ܙ��XZ[X[��\�[����[XCB�

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 2 Oct 2007 07:59:40 +0200

> not very clear of the meaning.

At the moment we allow any syntactically valid non-ASCII UTF-8.
At some point in time (after the experiment) this hast to be
restricted:

- We need to get rid of C1 controls like NEL
- We might exclude all or most private use characters 
- Nobody needs non characters or a BOM in e-mail addresses
- ... (e.g. RFC 3987 defines a sound Unicode subset)

 Frank

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 02 Oct 2007 18:45:05 +0900

I agree with the idea that some characters should be banned for many 
good reasons. The real issue is that there is no easy (or even no hard) 
way to realize this goal. Assuming that this hardness is very evident to 
all of us, I am not so sure whether Frank's suggestion worths inviting 
discussions on it.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 2 Oct 2007 12:04:06 +0200

> all of us, I am not so sure whether Frank's suggestion worths inviting 

Just to be clear, my editorial proposal was to remove the note "it is
otherwise unrestricted" in the I-D, nothing more elaborated for now.

 Frank

---

From: "Yangwoo Ko" <[email-masked]>
Date: Wed, 3 Oct 2007 09:47:00 +0900

> s/; it is otherwise unrestricted//

Oops. I should have better eyes. I thought that explanations afterwards was
suggested as a replacement.

---

From: Soobok Lee <[email-masked]>
Date: Wed, 3 Oct 2007 12:10:48 +0900

> >>>or private use characters.

Just for a editorial, please see the following excerpt interleaved opinion of mine:

1. Change the definition of "Atom" to permit either the definition
      above or a UTF-8 string.  

my opinion> "permit a UTF-8 string" is too loose, rather how about using
"a non-ASCII UTF8 string"?

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

my poninion> If we use "non-ASCII" adjective like above, this statement is not
necessary, since RFC821/2811 already prohibit those ASCII puntuations etc
and this draft does not introduce ASCII characters in the grammer. See below.

uLet-dig = Let-dig / UTF8-xtra-char
                   ; Let-dig is defined in RFC 2821, section 4.1.3
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
                   ; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629

my opinion> This grammer *clearly and well* states that only non-ASCII UTF8 string
(of sequence length >= 2) is permitted newly in this specification. 
We don't have to worry about permission of full UTF8 strings which contains full 7-bit ASCII subset.

Soobok

---

From: Soobok Lee <[email-masked]>
Date: Wed, 3 Oct 2007 15:59:57 +0900

>                    ; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629

UTF8-xtra-char (UTF8 EXTRA??? CHARACTER??? ) is not an intuitively good term 
to carry the meaning of UTF8 8th-bit-high *byte sequences* which encode non-ASCII Unicode character
code points.

I suggest:  s/UTF8-xtra-char/non-ASCII-UTF8/;

THis will make the syntax rules look clear.

I googled for "utf8-xtra-char", but I can't find any significant reason to
follow that terminology other than "Usenet Format"-related draft by Charles Lindsey. 
( I'm sorry to Charles ;-)  )

Soobok

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Oct 2007 16:55:26 +0100

> THis will make the syntax rules look clear.

Bear in mind that this is a name ob an object in the ABNF, which needs to  
be chosen to make the ABNF clear.
> ( I'm sorry to Charles ;-)  )

I have no great concern to retain <utf8-xtra-char>, but I am not sure that  
<non-ASCII-UTF8> is the best alternative (though no other suggestion  
springs to mind). But, if it is changed, be sure to change the occurrences  
in all of the drafts, because it has been quite widely used.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Oct 2007 17:01:33 +0100

> all of us, I am not so sure whether Frank's suggestion worths inviting  

Way back, when the USEFOR WG was considering using UTF-8 for  
<newsgroup-name>s, we had some restrictions on the Unicode allowed (e.g.  
no punctuation characters - Unicode has quite an elaborate classification  
system which can be used to describe such restrictions). I suspect that  
any such restriction in this case would be of the form of restricting  
UTF-8-atoms.

I can dig out the resrictions USEFOR proposed if anyone is interested (but  
not just now, as I am away for the next week). Or you can probably find  
them in the earlier drafts on the Usefor web site.

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 8 Oct 2007 12:12:49 +0200

> THis will make the syntax rules look clear.

Let's say UTF8-NON-ASCII as in RFC 3977 (NNTP).

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 11 Oct 2007 19:57:55 +0100

> Let's say UTF8-NON-ASCII as in RFC 3977 (NNTP).

+1

---

From: Soobok Lee <[email-masked]>
Date: Tue, 16 Oct 2007 00:46:07 +0900

> Let's say UTF8-NON-ASCII as in RFC 3977 (NNTP).

+1.

This seems better & clearer than "non-ascii-UTF", 
since "UTF8" comes first.

<quote from RFC3977>
 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
     UTF8-2    = %xC2-DF UTF8-tail
     UTF8-3    = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail /
                 %xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail
     UTF8-4    = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail /
                 %xF4 %x80-8F 2UTF8-tail
     UTF8-tail = %x80-BF
</quote>

Soobok