- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 2 Dec 2022 10:21:45 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Cc: ietf-http-wg@w3.org
On 02.12.2022 09:48, Poul-Henning Kamp wrote: > -------- > Martin J. Dürst writes: >> 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". > > Non-Ascii is widely used in the /contents/ transported with HTTP. Yes. > It has never, to my knowledge, been used, much less widely used, in > the /envelope/ used to steer that transport (ie: the HTTP-headers). It has, for instance in Content-Disposition (which, FWIW, has an encoding scheme for that that works over ASCII). > The HTTP standards go out of their way to avoid it being necessary > too, for instance, for the response status codes, the numerical > value controls. > > Also: All major HTTP implementations I personally know will fail > your HTTP traffic hard, if you send anything with the high bit set > in the headers. Yes. That's why we regularly see requests for a string format for use in fields that can express non-ASCII characters without having to set that bit. See <https://github.com/httpwg/http-extensions/issues/537>, 4 years ago. See, in particular, <https://github.com/httpwg/http-extensions/issues/537#issuecomment-477534651>. > We included sf-binary specifically to stop the proliferation of > workarounds for that state of affairs, because there are legitimate > needs to move binary information efficiently, for instance X.509 > certificates and other cryptographic information. Yes, sf-binary can be used for non-ASCII strings, but it's really only a workaround. For instance, tooling doesn't know whether the contents is supposed to be a string and thus will not decode it. Be aware that the "tooling" argument is the *only* reason we are adding sf-date; otherwise sf-integer would be just fine. > If some standard draft decide that they, against all the evidence > and common sense, absolutely need to put I18N content in a HTTP > field, they are more than welcome to specify the use of sf-binary > with any encoding, fixed or variable, they prefer. Well. See <https://www.ietf.org/archive/id/draft-ietf-httpapi-rfc7807bis-04.html#section-4>. >> If that's the solution, then please specify it, > > There is no problem to be solved. Yes, there is. Just dismissing it will not stop this discussion. > Poul-Henning > > PS: I call it a sump, because even though I have had email continuously > since 1988, there has never been /a single/ day, where I did not > receive at least one email, with screwed up character-set encoding. How many JSON files do you find regularly with broken strings? (Yes, when transferred over US-ASCII transport) Best regards, Julian
Received on Friday, 2 December 2022 09:22:06 UTC