- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 26 Aug 2014 18:05:04 -0700
- To: Tracking Protection Working Group <public-tracking@w3.org>
On Jul 12, 2014, at 6:42 PM, Tracking Protection Working Group Issue Tracker wrote: > tracking-ISSUE-250: Non-ASCII not permitted in extensions [TPE Last Call] > > http://www.w3.org/2011/tracking-protection/track/issues/250 > > Raised by: Nick Doty > On product: TPE Last Call > > 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? 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
Received on Wednesday, 27 August 2014 01:05:24 UTC