Re: Consensus call to include Display Strings in draft-ietf-httpbis-sfbis

+1 to adopt.

Overall, I think the proposal is at a good middle ground.

It is fine to transfer raw UTF8 characters when possible. There is little
reason to encode UTF8 strings using base64 when the attack surface at the
point of using UTF8 (which happens _after_ decoding base64).

I would be against forbidding the transfer of characters like RTL, because
as others have pointed out, they are useful (and should be available for
use) when displaying information in certain languages (and this proposal is
about "printable" strings). And probably that leads to the argument that we
should allow characters like CR, LF, HTAB as well. Let the UI take care of
UTF8 strings, rather than us trying to say what should be part of UTF8
(that can be transferred).

Regarding how we encode the printable string on the wire, I do not care
much, though I think percent encoding as proposed is probably a good middle
ground between interoperability and usability. It is a good old approach
that goes back at least to MIME Q encoding.

2023年5月25日(木) 11:29 Tommy Pauly <tpauly@apple.com>:

> Hello HTTP WG,
>
> As part of the WGLC for draft-ietf-httpbis-sfbis, we’ve been discussing
> the inclusion of "Display Strings” (strings that allow Unicode content).
>
> While not part of the initial scope of this -bis effort, this addition has
> had significant discussion and support expressed for inclusion.
>
> This email starts a formal consensus call to determine if the working
> group would like to expand the scope of draft-ietf-httpbis-sfbis to include
> Display Strings, specifically to merge in the following pull request
> (modulo any editorial changes that are needed):
>
> https://github.com/httpwg/http-extensions/pull/2494
>
> Please reply to this email to express your opinion on this issue by *Wednesday,
> June 7*.
>
> Thanks,
> Tommy
>
>

-- 
Kazuho Oku