At 04:48 06/08/23, John C Klensin wrote:
>
>
>--On Tuesday, 22 August, 2006 11:10 -0700 Addison Phillips
><addison at yahoo-inc.com> wrote:
>> This is a common misperception. The logical order of the text
>> is left-to-right until the [ SP text ] is reached. This text
>> is rendered RTL, if appropriate to do so, up to the CRLF
>> (which ends the RTL "run"). See http://www.w3.org/TR/CharMod
>> and http://www.unicode.org/reports/tr9/
>
>Exactly (!). If I said that badly, I apologize, but I read
>821/ 2821 as requiring a three digit code and the SP (in
>left-to-right order) followed by "text".
The protocol only defines logical order, i.e. on the wire, the
bytes for the three digit code are followed by (a SP and then)
the extended error code and then (a SP and then) the TEXT.
As Doug has said, how to display these is entirely up to the
client. For an Arabic or Hebrew client, something like
[(RTL) TEXT goes here] 5.1.1 550
is okay and may make sense.
>The extended status
>code stuff is specific about the text, but wasn't written
>anticipating internationalization and is not required by the
>proposed specification anyway. And, to the best of my
>knowledge, there is no standard requiring the used of W3C
>CharMod or Unicore TR9 in Internet mail replies.
TR9 is an Unicode Standards Annex (UAX), which means it is
part of the Standard. In many ways, at the very moment you
say UTF-8, you include it. For the IETF,
http://www.rfc-editor.org/rfc/rfc3629.txt normatively references
Unicode 4.0, and this includes TR9 at
http://www.unicode.org/unicode/standard/versions/components-4.0.0.html
(and I'm sure that the actual book says the same).
>> The examples given are not very convincing. However... I tend
>> to agree that this is the wrong model. The design of SMTP and
>> other protocols is such that user-agents can present
>> "friendly" messages (including localized messages) to end
>> users. Almost no one interacts with SMTP servers directly.
>
>Right
I think I agree to quite some extent with John and Addison, but
as most of us know and Harald has shown again, the situation
with SMTP error message consistency is much worse than with any
other, comparable protocol.
Also, while these error messages with their codes may not have
been intended to be show to users, they routinely turn up in
bounce messages, which go directly to the end user. Telling
the end user that s/he may have mistyped an address should be done
in the user's language, should not require support staff invention,
and should not be treated as a protocol debugging problem.
For EAI, I think it would be immensly helpful to have return
messages defined with enough precision so that an MUA
receiving a bounce can tell the user directly, or otherwise
take an appropriate action (e.g. flagging the relevant entry
in the address book as questionable) without necessarily having
to show the actual message to the user. If we don't manage to
get that for EAI, where we have a fresh slate, I don't think we
are in a position to try anything for the vast reminder of
error codes and error messages.
Regards, Martin.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.