Re: signatures vs sf-date

[Julian Reschke <[e-mail]>]

On 02.12.2022 09:48, Poul-Henning Kamp wrote:
> --------
> Martin J. Dürst writes:
>> On 2022-12-02 17:10, Poul-Henning Kamp wrote:
>>> --------
>>> Julian Reschke writes:
>>>
>>> (Apologies for resending, I think I botched the copy to the list)
>>>
>>>> That said, LC on draft-ietf-httpapi-rfc7807bis surfaced issues with the
>>>> missing support for non-ASCII characters in sf strings, and we really
>>>> shouldn't ignore that issue.
>>>
>>> That was always intentional in sf, and I do not think we should wade into
>>> that sump *ever*.
>>
>> What sump? Non-ASCII is used all over the Web, without there being any
>> "sump".
>
> Non-Ascii is widely used in the /contents/ transported with HTTP.

Yes.

> It has never, to my knowledge, been used, much less widely used, in
> the /envelope/ used to steer that transport (ie: the HTTP-headers).

It has, for instance in Content-Disposition (which, FWIW, has an
encoding scheme for that that works over ASCII).

> The HTTP standards go out of their way to avoid it being necessary
> too, for instance, for the response status codes, the numerical
> value controls.
>
> Also: All major HTTP implementations I personally know will fail
> your HTTP traffic hard, if you send anything with the high bit set
> in the headers.

Yes. That's why we regularly see requests for a string format for use in
fields that can express non-ASCII characters without having to set that bit.

See <https://github.com/httpwg/http-extensions/issues/537>, 4 years ago.
See, in particular,
<https://github.com/httpwg/http-extensions/issues/537#issuecomment-477534651>.

> We included sf-binary specifically to stop the proliferation of
> workarounds for that state of affairs, because there are legitimate
> needs to move binary information efficiently, for instance X.509
> certificates and other cryptographic information.

Yes, sf-binary can be used for non-ASCII strings, but it's really only a
workaround. For instance, tooling doesn't know whether the contents is
supposed to be a string and thus will not decode it.

Be aware that the "tooling" argument is the *only* reason we are adding
sf-date; otherwise sf-integer would be just fine.

> If some standard draft decide that they, against all the evidence
> and common sense, absolutely need to put I18N content in a HTTP
> field, they are more than welcome to specify the use of sf-binary
> with any encoding, fixed or variable, they prefer.

Well. See
<https://www.ietf.org/archive/id/draft-ietf-httpapi-rfc7807bis-04.html#section-4>.

>> If that's the solution, then please specify it,
>
> There is no problem to be solved.

Yes, there is. Just dismissing it will not stop this discussion.

> Poul-Henning
>
> PS: I call it a sump, because even though I have had email continuously
> since 1988, there has never been /a single/ day, where I did not
> receive at least one email, with screwed up character-set encoding.

How many JSON files do you find regularly with broken strings? (Yes,
when transferred over US-ASCII transport)

Best regards, Julian