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

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