- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 02 Dec 2022 09:46:28 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: Martin J. Dürst <duerst@it.aoyama.ac.jp>, ietf-http-wg@w3.org
-------- 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 ? 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 ? If you want us to add "For I18N strings, see RFC5987" we can do that of course... > 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 :-) -- 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 09:46:43 UTC