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

[Julian Reschke <[e-mail]>]

On 02.12.2022 12:02, Poul-Henning Kamp wrote:
> --------
> 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 ?

Well, it was not me who added the new encoding to the Problem field spec.

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

So why are we adding sf-date then? Why do we actually work on a revision
at all?

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

If that leads to multiple, non-interoperable solutions for the same
problem: no.

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

I don't get how that applies here.

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

Thanks. That confirms what I said: no issues due to incorrect "\u" escapes.

Best regards, Julian