Re: [I18ndir] Working Group Last Call: Structured Headers for HTTP

["Patrik Fältström " <[e-mail]>]

On 5 Feb 2020, at 13:50, John C Klensin wrote:

> Is that about right?

Yes

> If it is, I think it is time for two directorate
> recommendations.  One is that this document, with respect to i18n issues, is not ready for IETF LC.  It may even be that the HTTP WG needs to clean up its act and, for i18n issues, may be in need of adult supervision because they are contradicting
> existing standards track documents within their own scope,
> apparently without noticing.

Yes

> The second is that it may be time to update the recommendations about character sets, Internationalization Considerations, etc.
> I don't know whether the revised recommendation should find
> expression in an IESG statement, a new BCP, or some other form of guidance or direction but it is now clear to me that, without it, the IETF is just going to dig itself in deeper and deeper...
> even more so if there is not a functioning directorate or
> equivalent than if there is.

This is something IESG have to give advice on.

> Those recommendation would be, approximately:
>
> (i) For any document that discusses or allows the use of
> non-ASCII characters, UTF-8 is mandatory to implement.  Other encodings of Unicode or use of other coded character sets may be justified by circumstances but, if they are allowed, the CCS and any additional encoding information required with it must be identified, e.g., by the mechanisms defined in RFCs 2231 and 8187.

Yes

> (ii) For any document that allows or specifies the use of
> non-ASCII characters in a protocol context (even in what is
> nominally free text), neither "use UTF-8" nor "Use UTF-8 and specify a normalization" are sufficient.  The presence of such statements without further explanation is usually an indication that an author or WG has paid insufficient attention to i18n issues but is, instead and intentionally or not, trying to blow them off.  In almost all cases that will be visible to users, character strings will eventually be compared to others, sorted, searched and/or rendered.  For one or more languages or scripts, each of those operations requires treatment that goes beyond simply examining octets.   Documents allowing such strings must either specify how those issues are addressed or must explain why they are not applicable.  For characters or strings than are protocol elements not visible to users, specific justification is required if non-ASCII characters are to be allowed.

There is one sentence that I think could be removed, so the recommendation is (one misspelling of "than" which should be "that" in the last sentence as well I think:

(ii) For any document that allows or specifies the use of non-ASCII characters in a protocol context (even in what is nominally free text), neither "use UTF-8" nor "Use UTF-8 and specify a normalization" are sufficient.  In almost all cases that will be visible to users, character strings will eventually be compared to others, sorted, searched and/or rendered.  For one or more languages or scripts, each of those operations requires treatment that goes beyond simply examining octets.   Documents allowing such strings must either specify how those issues are addressed or must explain why they are not applicable.  For characters or strings that are protocol elements not visible to users, specific justification is required if non-ASCII characters are to be allowed.

   Patrik