From nobody Tue Nov  8 01:14:32 2022
Return-Path: <julian.reschke@gmx.de>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 51234C1522B7
 for <httpapi@ietfa.amsl.com>; Tue,  8 Nov 2022 01:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level: 
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001,
 RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001,
 URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
 header.d=gmx.de
Received: from mail.ietf.org ([50.223.129.194])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id T9YVcLSd8Vts for <httpapi@ietfa.amsl.com>;
 Tue,  8 Nov 2022 01:14:27 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id EE6C8C1522B4
 for <httpapi@ietf.org>; Tue,  8 Nov 2022 01:14:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417;
 t=1667898865; bh=hupn8gVaO5u8gWXR3iAAkmqQRyLA/syz8FdUBPpgxEY=;
 h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To;
 b=RA4fcILgGx7wUkCieT14RamjDUw3D7tG5ErejE8XKx70ubf+xe7Z/unZwU9vCbbar
 Z1mz9ggC4z/ZIj6ShLkyAR5utfObvu3DSOlXHS9USV1b9hrlQ08YKzdY7nLCQt4YtG
 aPYnn3yPo4fWckaf+zzjg6RQLw3XyGfEuBq4YN5xGwHk5l14jb65EVIK0083khm9FW
 SkGcC38aN1o8uIh2d4NSpSyX5yqP6RIw2qVWOJNybvEeIkQBVMskwnOcGnbeBboguo
 DxBk3GVd48nLviZeLsD0n6S7tZPFMP/yrJG+XiCe0zYOy+7KIBmRaYf+81FYHvDfJa
 +hEF099uWrqTQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.178.20] ([91.61.56.137]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFsZ3-1omYz00F03-00HPJq for
 <httpapi@ietf.org>; Tue, 08 Nov 2022 10:14:25 +0100
Message-ID: <eb4473cd-fb11-37a4-fcdf-7dd3046730b4@gmx.de>
Date: Tue, 8 Nov 2022 10:14:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Content-Language: en-US
To: httpapi@ietf.org
References: <166627224606.10641.5749459667185024591@ietfa.amsl.com>
 <f79bdc4e-437f-5527-71e1-569d78097299@bucksch.org>
From: Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <f79bdc4e-437f-5527-71e1-569d78097299@bucksch.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:aSriNoMPp61UdIuz8RS05GULBtnNQ5pPqP52htgopsVUHywN+kf
 qwrlhXdXVDQk3uoJyL5Pnwe/Z7Ur9fOJphx75E8G27+PYu4Lyx7m3rwWrwlbVjLGShe3Nzx
 y0sIuMIelVdpjUYVEy99mqnGbn4/LLaWEb6uOQy471eJWveseU0rY67+Upvu6ewQpOAfHd9
 crSq70KAR0kZPdWYrC9Mw==
UI-OutboundReport: notjunk:1;M01:P0:KcXtndnbWB0=;CGG7P3DitQY8QD7fz+++BammwrK
 c8bsjNVf7n+mstNojvBICplUC2ZPyKR5gIgTz3NtbPC3UxhThV+FIYeyR9XbAD33gofkZZBQk
 KycZOMecJIfkZOyHC86Or/E3RwbXvLG5+Tgd/QGK5wLKBtis25mnstm9sp0G8DXWiM2QmYOer
 JiK6wbnY5r7edx7lmGgw91IUUT57HVIlUL+b7WygvaHEAX0R+db0rKWTEZkTXQnxItdu0we9z
 yczgPbgvLSw6mn+J8tYFkEuhAbCIdC/pKIqfeoqwbMynIm8LIXc2VhWoYbFRFziBaMNPFKCJ/
 cYKTAWIrfLLXFLGDPB93oTbdgeOW6cFc60XyznGdOWmAWTXYeVw6tu+a6DWj/AeGMGbQj7c7H
 SPdjNA0R/qR6sRPZ/26v/gHta+VsIQP4TqGS5cX1AKGEAeSv9QNmLSCTXqXi+er1YTAzvrGCU
 QHsEsAeuvqWMn8GHhbe962UJRpMUEh3PjdfIOW+jGVHgJWr9qHEASJ00IshQ0A+o83nxgXI/K
 BI486Oz5nb8DBe50dqSa8ZJHWzA33N5ifoy6yiLzqrgb9S7jn0/h//XETVDmdvrpZ8sDlIHwr
 mksLseHQQkvH78KEQxOwqz+PUgQsEvKJvbJOlnXyMtFfROIxVEPa7IjexFc3syvUTLCfDAAfF
 d9hoPZa38ZSXPuwEb6OVj/AUehcKpS/iA9P6Mw8ZYfgUrmBYWdl5q+fRq8TusWqVkxkKIgGbq
 Z1Fm9HNyljZHGNP2uKsSB/nDStWzPJusmUZTt/PY3j1isWv/AnbhNTe5evi5PNqVv/M6Tz7/C
 Qi3SNFFjZF9h4LzRtJzFP288XmQIqlqNOqYluWS4c+rgdA0AKLM4DgERG4ButpwX1xO43tAj9
 nWq/OmwE+C1UvbpkW+CkVg5dxwT2Ce96WL3bCXveL8mnpxfXqSCP7k7wLtaFivxhrETZ+dYS+
 KOxudQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/G6ko8fqVJHfg_yRyVCzvxBSEtpM>
Subject: Re: [httpapi] Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt>
 (Problem Details for HTTP APIs) to Proposed Standard
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>,
 <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>,
 <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2022 09:14:31 -0000

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 synta=
x.

> 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

