Martin Duerst wrote: > 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. You could take UTF-8 as "ASCII plus opaque garbage" in various protocols, and then other parts of [Unicode] are not relevant. Nobody's forced to use say Unicode collation or hyphenation only because (s)he uses UTF-8 referencing STD 63, Another example would be 3066bis, it references ISO 3166. Nobody using language tags is now forced to use also 3166-3 codes, they can still make up their own stuff, use CLDR or what else. > 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. The RFC 4408 folks made sure that URIs work, indirectly that arrives as whatever e.g. http offers. A scenario for RFC 4408 is a user trying to send on a route not permitted by the sender policy of his domain. What really happens: User submits mail to the "wrong" MSA, and this MSA doesnt't enforce submission rights (RFC 4409 6.1), it tries to forward the mail towards the recipient. The MX checks the sender policy (RFC 4408) by querying a nameserver of the domain in the Return-Path. That policy says "FAIL" and offers an explanation in the form of an URI (optional of course). The MX "encodes" this as 5.7.1 error response (RFC 2034) - oops, the 2034-reference was still correct in draft 00, odd, maybe the missing 2034 was my bad - while talking with the "wrong" MSA (or its mailout). Of course the MX is not forced to add the explanation of this third party to its 5.7.1, but it can, let's assume that it did. The MSA had accepted the mail for forward or delivery, and that didn't work, therefore it MUST (RFC 821/2821) generate a non- delivery message (aka "bounce", not the definition in 2821). It will probably copy the 5.7.1 error message verbatim into its non-delivery message. It then puts the error message in the mailbox of the user of this domain. Or forwards it if the user arranged it this way. Later the user finds the bounce, that quotes the 5.7.1 (maybe), and the 5.7.1 quotes the FAIL-explanation (maybe), that is an URI, and now the user can contact that URI (maybe), and if it is HTTP depending on the server, the browser, LTRU, matching, and some other details the user can read the explanation of an admin in his domain in their preferred language, why this mail didn't make it on the wrong route. That's in a nutshell the reason why there are no explicit I18N considerations in RFC 4408: It would never do to tunnel some non-ASCII text from DNS through a 5.7.1 and a bounce, besides it would be pointless, the domain can have many users with many different languages. Frank _______________________________________________ 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.