Subject: [EAI] Ticket status, EAI, June 15, 2007

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 15 Jun 2007 00:19:28 +0200

The following tickets are open on the EAI issue tracker:

1483 SMTPEXT 2.7: Non-ASCII in response texts 
Text proposed in -06, no later discussion.

1484 SMTPEXT 2.2: More exact definition of action choices 
Text proposed in -06, no later discussion.

1485 UTF8HDR 4.6/DSN: Choice of body part for transport of UTF8SMTP messages
MIME type message/something is proposed, no clear consensus. Poll will be
sent.

1486 SMTPEXT 2.7.2: Message retry 
Text proposed in -06, no later discussion.

1487 UTF8HDR 4.2: Does this specification update MIME? 
Proposed resolution: Yes. Say so in introduction.

1488 UTF8HDR 4.2: List MIME headers that are modified? 
Proposed resolution: Yes. We need an intro saying how we handle the
difference in grammars.
Propose to merge this with 1487.

1490 UTF8HDR 4.2: Including Content-Description to picture (grammar)
Propose to merge this with 1487.

1491 UTF8HDR 4.2: Extending MIME (ABNF grammar) 
Propose to merge this with 1487.

1492 SMTPEXT 2.7.3: <uFor> syntax 
Text proposed in -06, no later discussion.

1493 SMTPEXT 2.4: Redefining of RCPT TO and MAIL FROM commands (ABNF
grammar)
Text proposed in -06, no later discussion.

1494 UTF8HDR 4.4: <angle-addr> should include <obs-angle-addr> 
Proposed resolution: Yes; UTF-8 format needs to be an additional
alternative (=/) on angle-addr.

1495 SMTPEXT 2.5/2.6: Reply code used on DATA
Text proposed in -06.

1496 DOWNGRADE: Specify a simpler downgrade procedure?
No discussion so far.

For the "text proposed in -06" tickets, we will interpret silence as "this
is good enough", and resolve the tickets in a week or so. For the issues
with no proposed solution, discussion is needed.

            harald, for the chairs

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

---

From: Kari Hurtta <[email-masked]>
Date: 15 Jun 2007 08:02:05 +0300

It is still unclear what was destiny of

         ISSUE: UTF8HDR 4.5: <angle-addr> and <addr-spec> on trace field syntax

Was that editoral issue? Or was it minor, non-important issue?

Basically when utf-8 address is allowed on for clause, rfc 2822
syntax needs extending:

  received        =       "Received:" name-val-list ";" date-time CRLF

  name-val-list   =       [CFWS] [name-val-pair *(CFWS name-val-pair)]

  name-val-pair   =       item-name CFWS item-value

  item-name       =       ALPHA *(["-"] (ALPHA / DIGIT))

  item-value      =       1*angle-addr / addr-spec /
                            atom / domain / msg-id

<addr-spec> does not allow utf-8 addresses. So <item-value>
need include <utf8-addr-spec>.

( Another problem is that syntax is changing. So change need to be tracked :-) )

On ISSUE I suggested

         item-value      =/      utf8-addr-spec

/ Kari Hurtta

Harald Tveit Alvestrand <[email-masked]> writes in gmane.ietf.ima:

> 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no
> later discussion.
> 
> 1484 SMTPEXT 2.2: More exact definition of action choices Text
> proposed in -06, no later discussion.
> 
> 1486 SMTPEXT 2.7.2: Message retry Text proposed in -06, no later
> discussion.
> 
> 1487 UTF8HDR 4.2: Does this specification update MIME? Proposed
> resolution: Yes. Say so in introduction.
> 
> 1488 UTF8HDR 4.2: List MIME headers that are modified? Proposed
> resolution: Yes. We need an intro saying how we handle the
> difference in grammars.
> 1491 UTF8HDR 4.2: Extending MIME (ABNF grammar) Propose to merge this
> with 1487.
> 
> 1492 SMTPEXT 2.7.3: <uFor> syntax Text proposed in -06, no later
> discussion.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 Jun 2007 07:58:18 +0200

> Was that editoral issue? Or was it minor, non-important issue?
I forwarded that to the editors as an editorial issue.

---

From: Kari Hurtta <[email-masked]>
Date: 16 Jun 2007 09:29:03 +0300

> 1483 SMTPEXT 2.7: Non-ASCII in response texts Text proposed in -06, no

I suggest small change to text. Change here is on diff format.
Dicussion follows.

---------------------------------------------------------------------------
--- draft-ietf-eai-smtpext-06.txt	2007-06-05 06:40:53.000000000 +0300
+++ draft-ietf-eai-smtpext-06.txt--1483	2007-06-16 09:16:28.000000000 +0300
@@ -600,18 +600,26 @@
    MUST be transmitted in the form of ACE labels.  The protocol value of
    the WITH clause is UTF8SMTP when this extension is used.  More
    information is in the "IANA Considerations" section of this document.
 
 2.7.4.  UTF-8 Reply
 
-   If the client issues the "RCPT" command which contains non-ASCII
+   If the client issues the RCPT command which contains non-ASCII
    characters, the SMTP server is permitted to use UTF-8 characters
    within 251 and 551 response codes.  Servers MUST NOT include non-
    ASCII characters except in the limited cases specifically permitted
-   in this section.
+   in this section. The SMTP client following this specification MUST 
+   accept UTF-8 on replies of the RCPT command on that case.
 
+   If SMTP reply requires UTF-8, but SMTP client does not use
+   RCPT command which contains non-ASCII characters, the response
+   code 250 meaning "OK"  or 550 meaning "Requested action not taken:
+   mailbox unavailable" is used.  When response codes 250 and 550 is 
+   used on place of 251 and 551 response codes, response do not include 
+   new mailbox. If enhanced mail system status code [RFC3463]
+   is used,  response codes given on below is used.

 Yao & Mao               Expires December 8, 2007               [Page 11]
 
 Internet-Draft                     EAI                         June 2007
 
@@ -627,28 +635,26 @@
    is included in it and therefore UTF-8 is not needed.  UTF8REPLY
    parameter on the VRFY and EXPN commands tells the SMTP server that
    the client is prepared for UTF-8 on SMTP replies.
 
    VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to:
 
-       "VRFY" SP uAtom [SP "UTF8REPLY"] CRLF;
-              ;uAtom is defined in section 2.3 of this document
+       "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF;
+              ;uLocal-part and uMailbox is defined in section 2.3 of this document
 
-       "EXPN" SP uAtom [SP "UTF8REPLY"] CRLF;
-              ;uAtom is defined in section 2.3 of this document
+       "EXPN" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF;
+              ;uLocal-part and uMailbox is defined in section 2.3 of this document
 
    This parameter "UTF8REPLY" does not have value.  If SMTP reply
    requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in
-   the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "252"
+   the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code 252
    is used, defined in [RFC2821], meaning "Cannot VRFY user, but will
-   accept the message and attempt the delivery".  If enhanced mail
-   system status code [RFC3463] is used, the response code should be
-   "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply
-   required, but the UTF8REPLY parameter not used.". [[anchor13: REMOVE
-   THIS: IANA please assign the proper error codes for "5.6.y" and
-   "2.6.y".]]  "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN)
+   accept the message and attempt the delivery". Also response code 550
+   may be used, meaning "Requested action not taken: mailbox unavailable". 
+   If enhanced mail system status code [RFC3463] is used, response codes 
+   given on below is used. "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN)
    commands enables UTF-8 for that command only.
 
    The uAtom of the VRFY and EXPN commands is a user name or a user name
    and a domain (see below).  If a normal (i.e., 250) response is
    returned, the response MAY include the full name of the user and MUST
    include the mailbox of the user.  It MUST be in either of the
@@ -658,12 +664,20 @@
                 ; uMailbox is defined in section 2.3 of this document
                 ; User Name allows the non-ASCII character.
 
          uMailbox
                 ; uMailbox is defined in section 2.3 of this document
 
+
+   If SMTP reply requires UTF-8, but UTF-8 is not allowed on reply,
+   and enhanced mail system status code [RFC3463] is used,
+   the response code should be  "5.6.y" or "2.6.y" [SMTP-codes],
+   meaning that "The UTF-8 reply required, but not allowed.".
+   [[anchor13: REMOVE THIS: IANA please assign the proper error codes
+   for "5.6.y" and "2.6.y".]]
+
    If the SMTP Client lack of the UTF8SMTP support receives the UTF-8
    message on reply, it may crash.  UTF-8 messages on reply are only
    allowed in the commands under the situations described above.  Under

---------------------------------------------------------------------------

Discussion:

1) 

SMTP client needed to be required to accept UTF-8 also on RCPT response.

2)

251  response with UTF-8 mailbox can be replaced with 250 response. 
250 response does not include new address.

Instead of

        RCPT TO:<[email-masked]>
        251 2.1.5 New address is <käyttäjätuki@@example.com>, will forward

use

        RCPT TO:<[email-masked]>
        250 2.6.y Address is changed, will forward

Of course 251 can not replaced with 550 because that recipient is accepted.
Therefore 250 is correct response code.

3)

--- start quote --
This parameter "UTF8REPLY" does not have value. If SMTP reply
requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in
the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "252"
is used, defined in [RFC2821], meaning "Cannot VRFY user, but will
accept the message and attempt the delivery". If enhanced mail
system status code [RFC3463] is used, the response code should be
"5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply
required, but the UTF8REPLY parameter not used.".
--- end quote ---

Here is problem that that talks only response code "252", but
enchanced response codes talk both "5.6.y" and "2.6.y".

These "5.6.y" and "2.6.y" are fine -- these should NOT removed.

Problem is that these enchanced response codes now apply only
to VERIFY and EXPAND. My original text these apply also to
RCPT command.

On that change effectively
   ``If enhanced mail
     system status code [RFC3463] is used, the response code should be
     "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply
     required, but the UTF8REPLY parameter not used."??
is moved just to new chapter so that it applies to RCPT
-command also. menaing text is also of course change, because 
RCPT command here did not taken UTF8REPLY paramater.

4)

Limiting VRFY and EXPN to uAtom is very restrictive.

RFC 2821 quote: ------------------------------

   "User name" is a fuzzy term and has been used deliberately.  An
   implementation of the VRFY or EXPN commands MUST include at least
   recognition of local mailboxes as "user names".  However, since
   current Internet practice often results in a single host handling
   mail for multiple domains, hosts, especially hosts that provide this
   functionality, SHOULD accept the "local-part@domain" form as a "user
   name"; hosts MAY also choose to recognize other strings as "user
   names".
---- end RFC 2821 quote -------------------------------

uAtom do not accept "@domain" which is "SHOULD" on RFC 2821.

With suggested syntax it roughly matches with RFC 2821 text.

Yes, actual syntax on RFC 2821 is somewhat conflict with
this:
 
RFC 2821 quote: ------------------------------
4.1.1.6 VERIFY (VRFY)

   This command asks the receiver to confirm that the argument
   identifies a user or mailbox.  If it is a user name, information is
   returned as specified in section 3.5.

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer.

   Syntax:
      "VRFY" SP String CRLF

4.1.1.7 EXPAND (EXPN)

   This command asks the receiver to confirm that the argument
   identifies a mailing list, and if so, to return the membership of
   that list.  If the command is successful, a reply is returned
   containing information as described in section 3.5.  This reply will
   have multiple lines except in the trivial case of a one-member list.

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer and may be issued at any time.

   Syntax:
      "EXPN" SP String CRLF

---- end RFC 2821 quote -------------------------------

Where String seems to be

         String = Atom / Quoted-string

( And anyway uAtom do not cover Quoted-string which is allowed on 
  String ).

Seems that  RFC 2821 is mess on here also :-(

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 17 Jun 2007 19:27:08 +0300

> 1495 SMTPEXT 2.5/2.6: Reply code used on DATA

Suggestion on diff format.  This is mostly editoral. Discussion follows.

-----------------------------------------------------------------------------
--- draft-ietf-eai-smtpext-06.txt	2007-06-05 06:40:53.000000000 +0300
+++ draft-ietf-eai-smtpext-06.txt-1495	2007-06-17 19:23:49.000000000 +0300
@@ -450,13 +450,18 @@
 
    address before xtext encoding.
 
-2.5.  Using the ALT-ADDRESS parameter
+2.5.  Using the ALT-ADDRESS parameter and message downgrading
 
    A message containing non-ASCII envelope addresses or header fields
    MUST NOT be sent to an SMTP server which does not support UTF8SMTP.
    Such a message MAY be rejected due to lack of the ALT-ADDRESS as
    discussed in section 2.2 of this document.
 
+   [EAI-utf8header] specifies "UTF8SMTP message" which requires
+   UTF8SMTP support.  Such a message MUST NOT be sent to an SMTP server 
+   which does not support UTF8SMTP. Such a message MAY be rejected due 
+   downgrade failure or lack of the downgrade support.
+
    When messages are rejected because they require UTF8SMTP, response
    code "550" is used, defined in [RFC2821], meaning "mailbox
    unavailable".  If enhanced mail system status codes [RFC3463] is
@@ -465,7 +470,7 @@
 
    If the response code is issued after the final "." of the DATA
    command, the response code "554" is used, defined in [RFC2821],
-   meaning "Transaction failed". if enhanced mail system status codes
+   meaning "Transaction failed". If enhanced mail system status codes
    [RFC3463] is used, the response code should be "5.6.z" [SMTP-codes],
    meaning that "UTF8SMTP downgrade failed".
 
-----------------------------------------------------------------------------

Discussion:

------start quote----------
2.5.  Using the ALT-ADDRESS parameter

   A message containing non-ASCII envelope addresses or header fields
   MUST NOT be sent to an SMTP server which does not support UTF8SMTP.
   Such a message MAY be rejected due to lack of the ALT-ADDRESS as
   discussed in section 2.2 of this document.

   When messages are rejected because they require UTF8SMTP, response
   code "550" is used, defined in [RFC2821], meaning "mailbox
   unavailable".  If enhanced mail system status codes [RFC3463] is
   used, the response code should be "5.6.x" [SMTP-codes], meaning that
   "alt-address is required but not specified".

   If the response code is issued after the final "." of the DATA
   command, the response code "554" is used, defined in [RFC2821],
   meaning "Transaction failed". if enhanced mail system status codes
   [RFC3463] is used, the response code should be "5.6.z" [SMTP-codes],
   meaning that "UTF8SMTP downgrade failed".

   [[anchor8: REMOVE THIS: IANA please assign the proper error codes for
   "5.6.x" and "5.6.z".]]
-------end quote----------------

1)

Now, when this section talks also DATA command and downgrade failure,
title "Using the ALT-ADDRESS parameter" does not describe it.

I suggested of alternative. Is someone better suggestion for title?

2)

It is better to give pointer to draft-ietf-eai-utf8headers 
(section 4.6 UTF8SMTP message), where is listed conditions
when message requires UTF8SMTP support. It does not make
sense reproduce them on here.

Another thing is that these conditions may be controversial. 
But it does not have effect to here.

More likely is that message is not rejected, but instead NDN 
is sent.  This text does not prevent that case. Generation of
NDN is mentioned on section 2.2 

/ Kari Hurtta

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Jun 2007 10:55:48 +0100

> MIME type message/something is proposed, no clear consensus. Poll will be

It would be premature to send a poll on this until there exist clear
technical descriptions of the proposed options.

As regards the proposed message/utf8smtp (by whatever nsme it is
eventually called) I have repeatedly asked for answers to the following
three questions:

1. Is a message/utf8smtp supposed to be transportable on the existing
network?

2. If so, what is supposed to happen when it encounters a MTA that does
not support 8BITMIME?

3. Which currently deployed MTAs will actually do whatever is the answer
to Q2 (and which will not do it, for that matter)?

Nobody has yet seen fit to answer these questions.

-- 
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: Chris Newman <[email-masked]>
Date: Mon, 18 Jun 2007 09:49:25 -0700

For SMTP, allowing UTF-8 in error responses opens a can of worms.

SMTP error response text needs to be comprehensible by:
* An arbitrary remote system administrator
* The local system administrator
* The end-user
Probably in that priority order (although that's debatable and may be different 
for SUBMIT).  That means SMTP response text may have to be in more than one 
language and guidance needs to be provided for language selection.

I would not consider a document allowing UTF-8 in response text complete unless 
dodges this issue (e.g., by only allowing UTF-8 in addresses) or confronts this 
issue.

                - Chris

---

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 20 Jun 2007 15:08:01 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Cc: "Kari Hurtta" <[email-masked]>
Sent: Monday, June 18, 2007 12:27 AM
Subject: [EAI] #1495 draft-ietf-eai-smtpext-06.txt 2.5. Using theALT-ADDRESS parameter => new title 

> Suggestion on diff format.  This is mostly editoral. Discussion follows.

Thanks a lot for kind comments.
how about "ALT-ADDRESS parameter usage and response codes"?

YAO Jiankang

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Jun 2007 13:06:51 +0200

Chris Newman wrote:
> Probably in that priority order (although that's debatable and may be 
> different for SUBMIT).  That means SMTP response text may have to be 
> in more than one language and guidance needs to be provided for 
> language selection.
>
> I would not consider a document allowing UTF-8 in response text 
> complete unless dodges this issue (e.g., by only allowing UTF-8 in 
> addresses) or confronts this issue.
I think the text in the draft is a suitable amount of dodgery, but your 
mileage may vary.
We're not addressing the subject of non-English language in response 
codes at all here; this is an existing problem (error codes in Latin, 
anyone?), and so is out of scope for the EAI WG.

I'd be happy to add text saying "use UTF-8 in addresses only" (my 
opinion only).

>> I suggest small change to text. Change here is on diff format.
I suggest a shorter version:

   If the client sends a message without UTF-8 characters in the RCPT TO 
command,
   and the server would desire to send back a response with a non-ASCII 
email
   address in it, the server will have to choose another response code, 
for instance
   replacing a 251 response code with a 250 code, or a 551 response with 
a 550.

I don't think we need to repeat text talking about the enhanced mail 
system status codes.

                    Harald

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jun 2007 14:10:29 -0400

--On Monday, 18 June, 2007 09:49 -0700 Chris Newman
<[email-masked]> wrote:

> Probably in that priority order (although that's debatable and
> may be different for SUBMIT).  

And, of course, SUBMIT could be tuned differently if needed.
Since SUBMIT-i18n is not on the WG's agenda and I think we are
obligated to see how this approach works out, I don't want to
start a discussion now but it occurs to me that, if
general-purpose downgrading turns out to be too constrained to
be useful, another option --whether complementary or alternate--
would be to say that most of the responsibility for downgrading,
if needed, lies next to the endpoints and that SUBMIT might be
extended to permit passing some rather specific instructions
between client and submission server.

> That means SMTP response text
> may have to be in more than one language and guidance needs to
> be provided for language selection.

I suppose partially because I'm not enamored of SMTP language
extensions, I would not like to see part of that idea considered
in isolation -- either we look at the whole package (if
necessary, assigning it to this WG, although I'd hope not), or
we don't start tip-toeing backwards down that path.
 
> I would not consider a document allowing UTF-8 in response
> text complete unless dodges this issue (e.g., by only allowing
> UTF-8 in addresses) or confronts this issue.

>From the above, I guess I vote "dodge".

     john

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Jun 2007 18:02:53 +0100

Harald Alvestrand wrote:

> I think the text in the draft is a suitable amount of dodgery, but 
> your mileage may vary.

+1.

>   If the client sends a message without UTF-8 characters in the RCPT 
> TO command,
>   replacing a 251 response code with a 250 code, or a 551 response 
> with a 550.
>
>

I agree and I like your text.

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 26 Jun 2007 15:39:05 +0800

----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: "Kari Hurtta" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 19, 2007 12:49 AM
Subject: Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply

>dodges this issue (e.g., by only allowing UTF-8 in addresses) or confronts this 

Dear Chris,

We would like to add one sentence in this section: 
"UTF-8 is needed to represent email addresses in responses. This extension does
not authorize the use of UTF-8 for any other purpose".

is it ok for you?

YAO Jiankang
CNNIC

Kari Hurtta wrote on 6/16/07 9:29 +0300:

> Harald Tveit Alvestrand <[email-masked]> writes in gmane.ietfima:
>

---

From: Chris Newman <[email-masked]>
Date: Tue, 26 Jun 2007 17:48:51 -0700

YAO Jiankang wrote on 6/26/07 15:39 +0800:
> "UTF-8 is needed to represent email addresses in responses. This extension
> does not authorize the use of UTF-8 for any other purpose".
>
> is it ok for you?

It's good enough for me.  However, the word "authorize" is unusual in this 
context so others might not like that.

                - Chris

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 27 Jun 2007 11:22:16 +0900

How about "allow" instead of "authorize"?

Chris Newman wrote:
> It's good enough for me. However, the word "authorize" is unusual in
> this context so others might not like that.
>
> - Chris
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Jun 2007 09:22:23 -0400

--On Tuesday, 26 June, 2007 17:48 -0700 Chris Newman 
<[email-masked]> wrote:

>> "UTF-8 is needed to represent email addresses in responses.
>> This extension does not authorize the use of UTF-8 for any
>> other purpose".
>>
>> is it ok for you?
>
> It's good enough for me.  However, the word "authorize" is
> unusual in this context so others might not like that.

Yes.

s/authorize/permit/
or
s/authorize/enable/

I prefer the first, but not strongly

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Jun 2007 09:23:02 -0400

> How about "allow" instead of "authorize"?

Another good alternative.   No preference between it and 
"permit".

    john