Re: [Rswg] Updating RFC 7997 (The Use of Non-ASCII Characters in RFCs)

[Martin Thomson <[e-mail]>]

John,

The depth of analysis that you might like to see applied might differ substantially from mine.  I would rather have an OK solution soon, than a perfect solution that takes a lot of energy to produce.  If there is a bit of wiggle room and we have to rely on authors, RPC, and (in the event of failure) stream managers to exercise good judgment, then I don't see that as a failure.

1.  Availability.  We've got Cherokee script in this draft and that's fine.

2. Searching.  The mess of normalization forms and whatnot is far less of a problem here than in something like the DNS.  Where it really matters, like in protocol elements, we can trust protocol authors and their reviewers to use or require appropriate levels of precision.  Otherwise, the documents will still be in English, so while searching might fail due to a poor choice, that only happens for the sorts of things that Unicode is used for (names, examples, etc...).  Again, I don't think that we need to make this hard.

3. RTL.  HTML has a solution here.  We should carefully reuse their design (we might choose not to take vertical writing systems) than try to invent our own thing.  Our needs are extremely modest here as we are not producing entire texts in languages other than English.  Supporting names and small examples appear to work without a lot of fancy machinery and we can likely choose not to use text that causes spectacular failures.  Spot fixing as the need arises might be better.

On Thu, Mar 2, 2023, at 15:40, John C Klensin wrote:
> Paul,
>
> Replying to the first message in the thread, but I've read all
> the others.  In addition to the more procedural, document
> relationship, and general content  issues those comments have
> mostly been about, I think the draft is going to need some more
> substantive work.  A few rather high level points by means of
> example(these are not the only ones):
>
> (1) While I agree with John Levine [1] that almost all systems
> these have Unicode support these days, that support gets
> seriously non-uniform when one starts looking at little-used and
> archaic scripts, some symbol sets, etc.   John's "for some
> version of reasonable" comment hints at the problem.    While it
> might be reasonable to put the specific instructions about what
> is considered reasonable to the Style Guide, it seems to me that
> this document should at least work out the theory or, at least,
> that it should not be completely and published until the Style
> Guide has addressed those issues in depth.
>
> (2) For most writing systems, at least most contemporary ones,
> Unicode has the unfortunate property that there can be several
> different ways to express the same conceptual character or
> string and the nice property that they usually display that same
> way (i.e., for display purposes, those different forms make no
> difference).  However, as soon as one imposes a requirement for
> searching, things get more complicated and one has to specify
> rules about how characters and strings are represented or about
> properties of the search procedure that go beyond matching that
> the octet level and into areas that require an understanding of
> the possible variations and that are, in turn, often
> language-dependent at the level of BCP 47 language codings and
> not just, e.g., "French".  At one point, we believed that
> normalization would solve those problems and it does... except
> where it doesn't.
>
> (3) There are many circumstances in which there is a need to
> embed left-to-right text in right-to-left strings and vice
> versa.  Simple application of Unicode's "Bidi" procedure can
> produce unintended (sometimes astonishing) results.  The
> problems are best dealt with by careful markup, but it is not
> clear that the markup mechanisms we have are sufficient.
>
> In addition to the issues with addressing those questions at
> all, different possible answers may imply very different
> requirements for expertise and expected times for document
> processing within the RPC.
>
> I don't think the document should move forward without issues of
> those types being addressed.  And it is not clear to me that
> trying to dig into them on this list would be the optimal way
> forward.
>
>     john
>
>
>
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/rswg/WW-b0P5aNtJFDw2OZbsIsfF0AYM
>
> --On Tuesday, February 28, 2023 20:08 +0000 Paul Hoffman
> <[e-mail]> wrote:
>
>> Greetings again. The message from the RSAB last week
>> <https://mailarchive.ietf.org/arch/msg/rswg/BgB7Ue-vNLCa3GTUTX
>> ZVsx6_VcA> showed that the RPC is having problems with RFC
>> 7997. RFC 7997 has a number of internal inconsistencies that
>> will make publication of RFCs more work for the RPC and the
>> stream managers. Although it was part of the series of RFCs
>> related to the new grammar and output formats, it dealt with a
>> different topic that had long interested the IETF: the use of
>> non-ASCII characters in names and technical text.
>> 
>> Given that, I have prepared
>> <https://datatracker.ietf.org/doc/draft-hoffman-rfc7997bis/>
>> to clean up RFC 7997, to make it internally consistent, and to
>> deal with situations like the one from the RSAB of documents
>> that have good uses for non-ASCII characters. These changes
>> will likely spark concern for some people about not being able
>> to read some RFCs, but the world of terminal software,
>> browsers, and PDF viewers has moved far forwards in the past
>> six years. Also,  the publication of RFC 9280 makes it clear
>> that the RFC streams themselves should be determining the
>> contents of the RFCs in their stream, with coordination among
>> the streams.
>> 
>> If working on this is of interest to the WG (even if there is
>> differences of opinion of what the rules should be), it could
>> be adopted as a WG document.
>
>
> -- 
> rswg mailing list
> [e-mail]
> https://mailman.rfc-editor.org/mailman/listinfo/rswg