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 12:11:37 +0100
Message-ID: <5559e7d7-675d-5f61-d9ad-f0f2ab2b5e14@gmx.de>
To: ietf-http-wg@w3.org
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
Received on Friday, 2 December 2022 11:11:54 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:47 UTC