W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 2 Dec 2022 11:32:22 +0100
Message-ID: <9990b393-93ff-75af-4e14-de4f6ba3366c@gmx.de>
To: ietf-http-wg@w3.org
On 02.12.2022 11:16, Poul-Henning Kamp wrote:
> --------
> Julian Reschke writes:
>
>> So, as author of SF, can you answer why SF doesn't recommend that
>> encoding (instead of binary)?
>
> Because we did not want SF to have /anything/ to do with the sump
> (feel free to substitue "swamp" or "tar-pit" if you prefer) of
> character encodings.
>
> We even changed my original easter-egg example of sf-binary, in
> order to stay totally clear of that subject - even down to that level.
>
> I literally cannot imagine /anything/ we can write in SFbis about
> character encoding, which will make the world a better place.

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:

"The title and detail values MUST NOT be serialized in the Problem field
if they contain characters that are not allowed by String; see Section
3.3.3 of [STRUCTURED-FIELDS]. Practically, this has the effect of
limiting them to ASCII strings."

...and this has already caused pushback during LC (rightfully, I think).

> As you yourself just pointed out:  Even adding a non-normative
> cross-reference to a well-established, on-point, standards track
> RFC, would become controversial.
>
> So no!
>
> SFbis will only be the addition of sf-date and the editorial/structural
> changes already announced, and provided Mark has time, we can have
> it ready for WG-FC very soon.

Well, that's up to the WG to decide.

>>>> How many JSON files do you find regularly with broken strings? (Yes,
>>>> when transferred over US-ASCII transport)
>>>
>>> Not nearly as many, because I dont receive several hundred JSON files each
>>> day :-)
>>
>> Is "not nearly as many" maybe "0"?
>
> No not even close to zero.  I regularly do see broken JSON, but far
> from every day.   But as I said:  It is not valid to compare the
> rates, in particular not when some of the broken JSON arrives via
> email :-)

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

Best regards, Julian
Received on Friday, 2 December 2022 10:32:37 UTC

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