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

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

--------
Julian Reschke writes:

> The key question here is: do we need to support strings containing human
> language in HTTP fields?
> <https://www.ietf.org/archive/id/draft-ietf-httpapi-rfc7807bis-04.html#section-4>
> does that, and says:

Didn't we just agree that sf(bis) can already transport I18N strings /at least/ two different ways ?

RFC5987 or sf-binary + implicit or explicit encoding information ?

I cannot see any way we "need to support strings [...]" on top of that,
and I am a big beliver in Gettys rules of design:

	1. Do not add new functionality unless an implementor cannot 
	   complete a real application without it.

	2. It is as important to decide what a system is not as to
	   decide what it is. Do not serve all the world's needs;
	   rather, make the system extensible so that additional
	   needs can be met in an upwardly compatible fashion.

	3. The only thing worse than generalizing from one example is
           generalizing from no examples at all.  (Phil Karlton)

So for all I care:  We're done with that subject in context of sfbis.

> JSON, transferred over 7 bit transports, being broken because people got
> escapes wrong?

This is way of topic by now, but the most recent one had danish
national characters encoding as ISO8859-1 characters, the one
before that had the escapes as '%5c%78[hexchar][hexchar]' and
the hex value was in ISO8859-15.

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