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

[Michael Sweet <[e-mail]>]

Not wanting to wade too deep into the waters here, but for IPP we usually reference Network Unicode (RFC 5198) when we want Unicode text without potentially nasty control/special code points. Among other things, it acknowledges that we are not Unicode experts and that somebody else will make sure to update the allowed characters should the Unicode Consortium add more control characters.

WRT the need for localizable error messages, while IPP does support such things we also like to use well-known “reason” strings (normatively plain English strings like “toner-empty”) that can be localized at the client as needed. This solves common UX issues like “my printer doesn’t offer localizations in my language” and “I have multiple users consuming messages in different languages”, avoids the security issues or passing display strings, and avoids putting the burden of localization on a busy server.

(for the record I’m +0 on sf-display-string)

____________________
Michael Sweet

> On May 27, 2023, at 5:56 AM, Julian Reschke <[e-mail]> wrote:
> 
> On 27.05.2023 10:37, Willy Tarreau wrote:
>> ...
> 
> Without having read all details:
> 
> +1 to consider (!) just using raw octets
> 
> +1 not to use sf-binary
> 
> +1 to exclude ASCII controls (but not entirely sure about CR LF HTAB)
> 
> but
> 
> -1 to use anything but UTF-8 (I fail to see any reason for that) - and
> no, use of UTF-8 does require revising things when Unicode code points
> are added
> 
> Best regards, Julian
>