Subject: Protocol - Support for internationalization?

From: "Chris Haynes" <[email-masked]>
Date: Wed, 21 Jul 2004 11:37:18 +0100

Referencing:  draft-ietf-marid-spf-3-protocol-00.txt

Section 5.2 ext: Explanation

The explanation string is intended to be displayed to legitimate senders in the
form of a short message or URL, via the SMTP receiver.

I.e. it is intended to be read by 'end user', probably non-technical, humans.

I can't see any support for international characters in the draft.

RFC1035 section 3.3.14 (which defines DNS TXT records) appears to delegate the
semantics of the text to the using domain/context, and seems to have nothing to
say about the encoding of a <character-string>.

If international characters are to be supported there would have to be:

(1) Either a specification of the mandatory character set to be used (e.g.
Unicode), and the encoding to be used (e.g. UTF-8) or some means of indicating
that character set/encoding on a message -specific basis,

(1) The details of how code points (characters) in this encoding  are to be
represented in the DNS TXT record (such as %-escaped UTF-8).

The protocol macro language (section 7.1) states that uppercased macros are
URL-encoded and references RFC2396.

This implies that the URL %HH method of inserting non-ASCII and URL-illegal
octet values may (MUST?) be used, but, like RFC2396, says nothing about points
(1) and (2) above.

There has been a lot of W3C work recently on Internationalised Resource
Identifiers (IRI):
 http://www.w3.org/International/iri-edit/draft-duerst-iri-09.txt

Using IRI syntax, if Mike Dürst wanted to put his name into the DNS TXT
explanation  (the ü has an umlaut) he would encode it in UTF-8 using the % URL
escaping as
"Mike D%C3%BCrst".

Explanations are intended to be used in 'bounces'. The explanations are
associated with the domain of the message originator, the bounce message
generation is done by the MTA of the receiving domain, so the receiving MTA MUST
assume that all explanations are UTF-8 encoded.

    Note:  US-ASCII is a sub-set of UTF-8,
    so all 'plain english' messages would be correctly represented.

The bounce message generator will have to tag _all_ messages containing
explanations as using UTF-8 (by using the appropriate message / MIME-part
Header).

Should the protocol use / reference IRIs and require bounces incorporating
originator-supplied explanations to assume the use of UTF-8?

Or is there / should there be some other way of supporting internationalized
messages?

Or is only US-ASCII to be supported?

Chris Haynes

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 23 Jul 2004 21:22:35 -0400

On Wed, Jul 21, 2004 at 11:37:18AM +0100, Chris Haynes wrote:
| 
| The explanation string is intended to be displayed to legitimate senders in the
| form of a short message or URL, via the SMTP receiver.
| 
| I can't see any support for international characters in the draft.

Are you saying that the URL encoding scheme with %HH is not
sufficient to express international characters?  If so, can
you suggest some new language that would satisfy you and
would be reasonably backward compatible with what is in the
draft?  If it is good enough we could paste that in.

Thank you for bringing the IRI documents to our attention.
If we were to use that as a normative reference we would
need to wait for it to become an RFC.

thanks.

| There has been a lot of W3C work recently on Internationalised Resource
| Identifiers (IRI):
|  http://www.w3.org/International/iri-edit/draft-duerst-iri-09.txt
| 
| Using IRI syntax, if Mike Dürst wanted to put his name into the DNS TXT
| explanation  (the ü has an umlaut) he would encode it in UTF-8 using the % URL
| escaping as
| "Mike D%C3%BCrst".