- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 02 Dec 2022 11:29:34 +0000
- 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