Re: signatures vs sf-date

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

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

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.

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.

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.

> If that's the solution, then please specify it, 

There is no problem to be solved.


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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 2 December 2022 08:48:31 UTC