Re: [EAI] #1483 draft-ietf-eai-smtpext-06.txt 2.7.4. UTF-8 Reply

[Harald Alvestrand <harald at alvestrand.no>]

Chris Newman wrote:
> 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.
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).

One thing I forgot to respond to on Kari's proposed text:
>                - Chris
>
> Kari Hurtta wrote on 6/16/07 9:29 +0300:
>
> > Harald Tveit Alvestrand <harald at alvestrand.no> writes in gmane.ietf.ima:
> >
> > > 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.
> >
> > 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. 
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



_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima