Re: support for non-ASCII in strings, was: signatures vs sf-date

["Roy T. Fielding" <[e-mail]>]

FWIW, there is nothing technical preventing a requirement that sf fields
support UTF-8 by default. The charset limitations for HTTP were for the
request-line, response-line, and existing unstructured header fields.

I don't know of parsers that block UTF-8 in header field-line parsing
(before the value is looked at), since that would interfere with non-standard
fields. There are some WAFs that might be weird about that, but we can say
the same about any feature of HTTP.

Interpretation of the field value after it is parsed is expected to be defined
by the field name, which can be defined once for sf-bis and I don't think
anyone (other than the authors) would care whether that is ASCII or UTF-8.

Of course, there's the other can of worms about whether UTF-8 is now
sufficient to satisfy everyone (and I do mean everyone). *shrug*

....Roy