W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

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

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Fri, 02 Dec 2022 11:29:34 +0000
Message-Id: <202212021129.2B2BTY9f005362@critter.freebsd.dk>
To: Julian Reschke <julian.reschke@gmx.de>
cc: ietf-http-wg@w3.org
--------
Julian Reschke writes:
> On 02.12.2022 11:32, Julian Reschke wrote:
> > ...
>
> FWIW: please see
> <https://github.com/ietf-wg-httpapi/rfc7807bis/commit/ebf9465504713876e6cd507629511313bdbce39c>
> - which adds a new string encoding scheme on top of sf-string, just for
> the "Problem" header field. So yes, it's pretty clear that this is a
> problem worth solving.

I have no idea why they did not use your RFC5987.

I cannot imagine them being unaware of its existence, you have surely
told them about it, and suggested its application.

And yet, they clearly did not.

So what exactly do you want sfbis to do ?

You already admitted that even a non-normative reference to RFC5987 will not fly.

We also cannot adopt RFC7807bis' W3C-inspired %xx encoding either, that would
redefine any sf-string which happen to contain a '%' sign.

No matter what you could manage to get sfbis to say about I18N,
it would invariably become standard N+1.

And if the RFC7807-crew, of all crews, did not adopt RFC5987, why
would should we expect /anybody/ to pick up standard N+1 from sfbis ?

As I said: There is /no way/ sfbis can add value to I18N.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 2 December 2022 11:29:47 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:47 UTC