- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 2 Dec 2022 10:54:25 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Martin J. Dürst <duerst@it.aoyama.ac.jp>, ietf-http-wg@w3.org
On 02.12.2022 10:46, Poul-Henning Kamp wrote: > -------- > Julian Reschke writes: > >>> 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). > > You mean RFC5987 ? Yes. > If I remember right, '*' was allowed in sf's parameter names /precisely/ > to cater for that, and the other side of RFC5987's '=' is a valid sf-token. > > So when there already is a perfectly serviceable RFC you can layer on top > of sf, why would sf need to wade into the sump too ? It's not a sump. This is not helpful. So, as author of SF, can you answer why SF doesn't recommend that encoding (instead of binary)? My theory: 1) It's ugly. 2) It's super-verbose. 3) It causes potential conflicts when "both" variants are present. > If you want us to add "For I18N strings, see RFC5987" we can do that of course... I'm pretty sure there would be an outcry, but go ahead :-). >> How many JSON files do you find regularly with broken strings? (Yes, >> when transferred over US-ASCII transport) > > Not nearly as many, because I dont receive several hundred JSON files each day :-) Is "not nearly as many" maybe "0"? Best regards, Julian
Received on Friday, 2 December 2022 09:54:45 UTC