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

On 02.12.2022 12:29, Poul-Henning Kamp wrote:
> --------
> Julian Reschke writes:
>> On 02.12.2022 11:32, Julian Reschke wrote:
>>> ...
>>
>> FWIW: please see
>> <https://github.com/ietf-wg-httpapi/rfc7807bis/commit/ebf9465504713876e6cd507629511313bdbce39c>
>> - which adds a new string encoding scheme on top of sf-string, just for
>> the "Problem" header field. So yes, it's pretty clear that this is a
>> problem worth solving.
>
> I have no idea why they did not use your RFC5987.

"They" in this case is your co-author on sfbis.

> I cannot imagine them being unaware of its existence, you have surely
> told them about it, and suggested its application.

I haven't, but Mark clearly is aware as the "Link" field spec uses it as
well.

> And yet, they clearly did not.
>
> So what exactly do you want sfbis to do ?

I'd like this WG to consider adding strings with non-ASCII characters as
first-class data types.

> You already admitted that even a non-normative reference to RFC5987 will not fly.
>
> We also cannot adopt RFC7807bis' W3C-inspired %xx encoding either, that would
> redefine any sf-string which happen to contain a '%' sign.

I would recommend either adding a new type, or making a breaking change
that introduces "\u" escaping in sf-string.

> No matter what you could manage to get sfbis to say about I18N,
> it would invariably become standard N+1.

It would be the one recommended for use in structured fields, so
applications using SF do not need to invent new ones (or pick one of the
alternatives already discussed).

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

> As I said: There is /no way/ sfbis can add value to I18N.

You keep saying that. I keep disagreeing with it.

Best regards, Julian

Received on Friday, 2 December 2022 11:42:29 UTC