Re: [httpapi] Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard

[Julian Reschke <[e-mail]>]

On 07.11.2022 14:19, Ben Bucksch wrote:
> ...
> 4. Problem: HTTP header field and localization
>
> The spec states: `The title and detail values MUST NOT be serialized in
> the Problem field if they contain characters that are not allowed by
> String; see {{Section 3.3.3 of STRUCTURED-FIELDS}}. Practically, this
> has the effect of limiting them to ASCII strings.`
> I understand that the limitation to ASCII is imposed by prior existing
> specs. However, mandating error strings to be in English (which is what
> ASCII means in practice) is not very helpful for the purposes of this
> specification.
> Importance: Errors strings need to be helpful for the user and allow
> them to correct the problem. If they are in a language that the user
> does not understand, they are unlikely to be helpful. This in turn
> leaves the end user frustrated. Messages that are potentially important
> for the end user MUST be translated into the user's language.

I share that concern. Unfortunately, that is a shortcoming of the SF syntax.

> If it is not reasonably possible to convey in the HTTP header field, I
> would recommend to remove this transmission method entirely.

That. Or...

> Alternatively, you could specify an escaping mechanism which allows for
> escaping of Unicode characters to be expressed with ASCII, e.g. a JSON
> string (RFC 4627 Point 2.5, Paragr. 2, "\u005C").

That would be incompatible with the SF syntax. But we could state that
strings containing non-ASCII characters will need to be sent as UTF-8
byte sequence (sf-binary). Ugly, but would at least allow transmission.

> ...

Best regards, Julian