ISSUE-250: Non-ASCII not permitted in extensions
Non-ASCII not permitted in extensions
- State:
- PENDING REVIEW
- Product:
- TPE Last Call
- Raised by:
- Nick Doty
- Opened on:
- 2014-07-13
- Description:
- http://lists.w3.org/Archives/Public/public-tracking-comments/2014Jun/0024.html
I18N-ISSUE-348
Non-ASCII characters are not permitted in extensions. There is a note:
--
The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string without further encoding (section 6.5 Tracking Status Representation). At most one DNT header field can be present in a valid request [HTTP].
--
It's unclear why this restriction exists? Non-ASCII characters are useful in many contexts and they work in a JSON string (they can be encoded further using \u escape, but don't have to be). The limitation to ASCII-only may be helpful for other reasons, of course, but these are no spelled out. Can you clarify why extension names have a limited character set? - Related Actions Items:
- No related actions
- Related emails:
- Resolving Last Call issues to TPE (from jbrookman@cdt.org on 2014-09-08)
- Re: tracking-ISSUE-250: Non-ASCII not permitted in extensions [TPE Last Call] (from fielding@gbiv.com on 2014-08-26)
- tracking-ISSUE-250: Non-ASCII not permitted in extensions [TPE Last Call] (from sysbot+tracker@w3.org on 2014-07-13)
Related notes:
WONTFIX. Non-ASCII characters are not interoperable when parsed within an HTTP header field unless they are first encoded as ASCII. Since there is no current need for extensions and the field is not intended for humans, there is no justification for the complexity of arbitrary unicode.
Roy Fielding, 27 Aug 2014, 01:07:35Display change log
