Re: [I18ndir] [art] Fwd: New Version Notification for draft-bray-unichars-05.txt

[Rob Sayre <[e-mail]>]

On Tue, Sep 19, 2023 at 4:04 PM Rob Sayre <[e-mail]> wrote:

> On Tue, Sep 19, 2023 at 10:29 AM Tim Bray <[e-mail]> wrote:
>
>> Two big differences here:
>>
>>
>>    1. The %0-10FFFF production, and discussion of All The Code Points as
>>    a subset, is removed. Which ended up re-organizing the draft quite a bit
>>    (diffs vs -04 may not be very helpful) but we think improved the flow quite
>>    a bit; thanks to James and Carsten for arguing this point so fiercely.
>>    2. The discussion around RFC9413 is changed quite a bit based on
>>    Asmus’ input.
>>
>>
>> Unless substantial new issues are raised, we plan to consult our ADs
>> about advancing the document.
>>
>
> There are still some bugs here. Generally, I think "Abstract Character
> Repertoire" as used here is good:
> https://unicode.org/reports/tr17/#Repertoire
>
> Making it clear that the various encoding and escaping routines happen
> before or after this idea. I don't think you need to add "Abstract" as a
> qualifier. Just explain it.
>
> > The Unicode Standard's definition of "Unicode character" is conceptual.
> > However, each Unicode character is assigned a code point, used to
> represent
> > the characters in computer memory and storage systems and, in
> specifications,
> > to specify the allowed repertoires of Unicode characters.
>
> I think you want to add: "Not all code points represent characters."
>
> > In ABNF, the hexadecimal values for characters are preceded by "%x"
> rather than "U+"."
>
> But these are code points in the ABNF, right? For example:
>
> https://www.ietf.org/archive/id/draft-bray-unichars-05.html#section-4.1
>
> "; exclude surrogates"
>
> These are in the problematic code point types. They are not characters.
> So, it's probably best to go through and clean that up.
>
> I think the "Restricting Character Repertoires" section should be run
> through a grammar checker (MS Word or something). It doesn't say anything
> incorrect, but I often thought "hmm, there should be a comma there" and
> little things like that. Thank you for taking the "conforming JSON text"
> suggestion, but the capitalization differs between the two uses: "JSON
> text" vs "JSON Text".
>

Unfortunately, I also have to add that this sentence is wrong:

"Problematic code points are an example of problematic input. [RFC9413],
"Maintaining Robust Protocols", provides a thorough discussion of
error-handling options when choosing a strategy for dealing with
problematic input."

RFC9413 does not discuss "problematic input". It does discuss errors in
implementations and specifications. JSON is intentionally defined as code
points, not scalar values.

I can understand why people don't like this situation, but it is not an
error.

thanks,
Rob

Un