Character Encodings in TEXT

[mnot@…]

RFC 2616 prescribes that headers containing non-ASCII have to use either iso-8859-1 or RFC 2047. This is unnecessarily complex and not necessarily followed by implementations or by specifications of new headers.

This issue is limited to:

• determining whether UTF-8 can be allowed in some way (e.g., in current uses of TEXT, and/or new headers), and
• possibly tightening up use of iso-8859-1 in TEXT (in particular, C1 controls).

See also #63, #111.

[mnot@…]

There was discussion of this at the APPS Area Architecture Workshop, with some disagreement as to whether it's possible to encode IRI->URI->IRI. Specific advice to IRIs may be necessary.

[julian.reschke@…]

Replying to mnot@pobox.com:

There was discussion of this at the APPS Area Architecture Workshop, with some disagreement as to whether it's possible to encode IRI->URI->IRI. Specific advice to IRIs may be necessary.

Is this about round-tripping IRIs through URIs? Obviously that's not possible.

For example, consider the two IRIs:

I1: ​http://www.example.org/Dürst

I2: ​http://www.example.org/D%C3%BCrst

Both would be converted to the URI:

U: ​http://www.example.org/D%C3%BCrst

Now whether that disctinction is relevant of course depends on which kind of URI/IRI comparison is needed; but there are cases where it is relevant (for instance, XML namespace names using IRIs (urg!)).

(see also ​http://tools.ietf.org/html/rfc3987#section-3.2.1)

[fielding@…]

From [395]:

Deprecate line folding, addresses #77. Require that invalid whitespace around field-names be rejected, addresses #30. Make non-ASCII content obsolete and opaque in header fields and reason phrase, addresses #63, #74, #94, #111.

[julian.reschke@…]

Fixed in [398]:

Resolve #63, #74, #94, #111: Issues around TEXT rule closed with revision [395] (closes #63, #74, #94, #111)

[julian.reschke@…]

re-open until reviewed

[julian.reschke@…]

Part 6 still allows RFC2047 encoding for the Warn header.