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

Re: signatures vs sf-date

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Fri, 2 Dec 2022 17:23:17 +0900
Message-ID: <eee5a787-da37-feb1-098a-7d2d9c0f1d37@it.aoyama.ac.jp>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Julian Reschke <julian.reschke@gmx.de>
Cc: ietf-http-wg@w3.org
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". It's very strange that HTTP cannot handle it at all yet. That 
doesn't mean that we suddenly have to allow non-ASCII in each and every 
protocol field. But providing a single way to encode non-ASCII 
characters would definitely be the first potential "sump" that we could 
avoid.

> If you want to encode non-ASCII, in sf, use a blob and explicit encoding.

If that's the solution, then please specify it, so that it can be used 
without reinventing the wheel. Of course, I personally would prefer a 
more direct solution (just use UTF-8), but I know there are some people 
here on this list who don't like that (or at least have said they don't 
like it when that topic came up the last time, which was quite some 
years ago).

Regards,   Martin.
Received on Friday, 2 December 2022 08:23:34 UTC

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