ISSUE-250: Non-ASCII not permitted in extensions

Non-ASCII not permitted in extensions

TPE Last Call
Raised by:
Nick Doty
Opened on:

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:
  1. Resolving Last Call issues to TPE (from on 2014-09-08)
  2. Re: tracking-ISSUE-250: Non-ASCII not permitted in extensions [TPE Last Call] (from on 2014-08-26)
  3. tracking-ISSUE-250: Non-ASCII not permitted in extensions [TPE Last Call] (from 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:35

Display change log ATOM feed

Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 250.html,v 1.1 2019/02/01 09:32:39 vivien Exp $