- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Fri, 2 Dec 2022 17:23:17 +0900
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
On 2022-12-02 17:10, Poul-Henning Kamp wrote: > -------- > Julian Reschke writes: > > (Apologies for resending, I think I botched the copy to the list) > >> That said, LC on draft-ietf-httpapi-rfc7807bis surfaced issues with the >> missing support for non-ASCII characters in sf strings, and we really >> shouldn't ignore that issue. > > That was always intentional in sf, and I do not think we should wade into > that sump *ever*. What sump? Non-ASCII is used all over the Web, without there being any "sump". It's very strange that HTTP cannot handle it at all yet. That doesn't mean that we suddenly have to allow non-ASCII in each and every protocol field. But providing a single way to encode non-ASCII characters would definitely be the first potential "sump" that we could avoid. > If you want to encode non-ASCII, in sf, use a blob and explicit encoding. If that's the solution, then please specify it, so that it can be used without reinventing the wheel. Of course, I personally would prefer a more direct solution (just use UTF-8), but I know there are some people here on this list who don't like that (or at least have said they don't like it when that topic came up the last time, which was quite some years ago). Regards, Martin.
Received on Friday, 2 December 2022 08:23:34 UTC