W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: support for non-ASCII in strings, was: signatures vs sf-date

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 2 Dec 2022 22:41:44 +0100
Message-ID: <65070e79-5429-a4cd-abe2-667b526badf1@gmx.de>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>, "Roy T. Fielding" <fielding@gbiv.com>
Cc: ietf-http-wg@w3.org
On 02.12.2022 20:18, Poul-Henning Kamp wrote:
> --------
> Roy T. Fielding writes:
>
>> FWIW, there is nothing technical preventing a requirement that sf fields
>> support UTF-8 by default.
>
> (... provided they are somehow escaped into USASCII visibility.)
>
> Yes, and I have absolutely no problem with SF being used to transport
> UTF-8, X.509, BJSON or LU6.2 that way, that is literally why I put
> sf-binary in:  To make it easy for people to move /any/ binary data,
> but at the same time trying to stop them from inventing their own
> obscure escaping mechanisms.
>
> But none of the data SF serializes or parses have /semantic/ meaning
> at the layer in the cake where SF lives, and that is not by accident:
>
> For me it was an explicit design goal, that SF would be totally
> unaware of Code-Tables, UniCode, Mime, Country-codes, TLDs, Timezones
> and all other time-variant registries of human policy or fashion.
> ...

So why are revising the spec then to add sf-date???

Best regards, Julian
Received on Friday, 2 December 2022 21:42:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 1 February 2023 02:18:31 UTC