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 13:29:28 +0100
Message-ID: <7a93fa17-38fe-5fa8-54ed-a726ab9d5a39@gmx.de>
To: ietf-http-wg@w3.org
On 02.12.2022 13:14, Poul-Henning Kamp wrote:
> --------
> Julian Reschke writes:
>>> I have no idea why they did not use your RFC5987.
>> "They" in this case is your co-author on sfbis.
> Why yes, it is indeed!
> But since he has not employed me as his official spokesperson, you
> will have to ask directly, why he did not use your RFC.
> Feel more than free to not Cc me on that discussion.
>> I'd like this WG to consider adding strings with non-ASCII characters as
>> first-class data types.
> If you think there is WG-appetite for RFC5987bis, then I see no reason you
> should not go for it ?

I don't think there's any appetite for that; it's a hack for existing
fields that use the HTTP "parameter" syntax. For that it works, but it's

We can do better.

>>> And if the RFC7807-crew, of all crews, did not adopt RFC5987, why
>>> would should we expect /anybody/ to pick up standard N+1 from sfbis ?
>> Because it would be an integral part of SF, not something added on top.
> ... but if you are trying to co-opt sfbis for your pet issue of putting I18N

So you call support for non-ASCII characters "my pet issue"?

> into HTTP, after you have repeatedly failed in a number of other ways,
> including a Standards Track RFC, that even a prominent member of the HTTP WG
> ignored, I think you should stop wasting our time.

I have no idea what you're talking about, but I agree that this
discussion between you and me is a waste of time.

That said, I'd like Mark to state how he got to the proposed change for
the "Problem" header field, and also other members of this WG to provide
feedback on the problem of sf-string being restricted to ASCII.

> Time to take a walk, (and I suggest you do too).
> Poul-Henning

Best regards, Julian
Received on Friday, 2 December 2022 12:29:42 UTC

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