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

[Julian Reschke <[e-mail]>]

On 02.12.2022 11:32, Julian Reschke wrote:
>  ...

Trying to structure the discussion somehow, I have opened
<https://github.com/httpwg/http-extensions/issues/2343>, currently saying:

> RFC 8941 does not support non-ASCII characters in sf-string (but recommends to use sf-binary when non-ASCII characters are needed).
>
> The solution space is roughly:
>
>     1. No support at all
>     2. No support, but addings hints about workarounds, such as
>     2.1 Using sf-binary (approach in RFC 8941)
>     2.2 Using RFC8187 parameter encoding (works only for parameters at it uses the "*" marker)
>     2.3 Using an escaping mechanism inside sf-string (with out-of-band info to indicate that it is in use) - currently proposed for the "Problem" header field (see ietf-wg-httpapi/rfc7807bis@ebf9465)
>     3. Direct support
>     3.1 By extending sf-string to allow native UTF-8
>     3.2 By extending sf-string to support a new escaping mechanism (for instance, by introducing new backslash escapes)
>     3.3 By adding a new type ("sf-ustring") that somehow supports non-ASCII characters
>
> Note that the question whether non-ASCII octets appear in the field value (obs-text) is somehat orthogonal, expect if 3.1 would be chosen.

The purpose is to get to a common understanding of where we are with RFC
8941, and potential approaches if we wanted to do more.

Feel free to edit the description to add more details, options, but
please put *discussions* into comments.

Best regards, Julian