A few comments follow... John C Klensin wrote:
...The client knows which languages that the server supports (unless the server can't enumerate them),...
Enumerating languages can be difficult. Most locale systems are quite extensive, with hundreds of potential values available. The server would have to attempt to load resources in each and enumerate whether the resources were extant in the locale or not in order to build an accurate list. In practice, few languages are actually available, but the code to figure it out is not available either.
Another issue you didn't mention is that, in an environment in which the language negotiated runs right to left, it not clearwhere all the pieces go.
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/
Even if we can make this model work, I suggest it is the wrong model. I further suggest that the difficulties with the small, inconvenient, cases, such as those above, are symptomatic of whyit is the wrong model.
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.
(1) This draft be dropped in favor of an effort to make SMTP reply text easier to translate to other languages or generate-able from the codes.
Allowing UTF-8 would still seem to be a Good Thing, since even boilerplate messages might need to include runtime data that is non-ASCII. Language negotiation is another issue.
If extended reply codes permit the server to emit its own internal error messages which are not entirely standardized (i.e. boilerplate), then the user-agent may have not choice other than to render the string on to the user. This is unsatisfactory.(3) We should look at the text associated with extended reply codes to be sure that the portions of those lines that are not boilerplate explanations are easily identified and extracted by automatic processes. If we discover cases where that goal is not met, we should fix them.
(i) MUA that receives the reply, or MTA that is about to deliver the reply to such an MUA, extracts the extended reply code and non-boilerplace, message-dependent, material from the "text" and discards the rest.
This works best if the message dependent material were clearly separate and in a machine-friendly format. This:
9106 Invalid user name; user=nobody, domain=example.org Is easier to deal with than: "9106 Invalid user name 'nobody' for domain 'example.org'"
SMTP is already too complicated. Let's avoid adding more complexity unless it is strictly necessary. This is not.
+1 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ 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.