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

[Poul-Henning Kamp <[e-mail]>]

--------
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.

When somebody wants their headers to have encoded strings, they can
decide how to escape them and safely move them about as sf-token,
sf-string or sf-binary.

But just like all other sf-items in their header, they will have
to explain how to interpret, in their header defining document,
what those sf-items mean.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.