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

[Tim Bray <[e-mail]>]

On Sep 25, 2023 at 11:06:38 AM, Rob Sayre <[e-mail]> wrote:

> > It cannot be serialized into well-formed UTF-8, but the behavior of
> libraries
> > asked to parse the sample is unpredictable; some will silently parse
> this
> > and generate an ill-formed UTF-8 string.
>
> It might be better to say "Its code points do not represent well-formed
> UTF-8..." (or well-formed Unicode?), because the example does show it
> serialized as well-formed UTF-8 via escape sequences. Not attached to my
> suggestion, but the current text is a little confusing.
>

Well, “It” at the front of the sentence is (from the top of the paragraph)
’the value of the “example” field” so I think it’s OK.  But that’s 2
sentences away at this point so probably would be good to replace “It” with
“That value”.

> Reasonable options for dealing with problematic input include, first,
> rejecting text
> > containing problematic code points, and second, replacing them with
> placeholders.
> > Silently ignoring an ill-formed part of a string is a known security
> risk. Responding
> > to that risk, [UNICODE
> <https://www.ietf.org/archive/id/draft-bray-unichars-06.html#UNICODE>] section
> 3.2 recommends dealing with ill-formed byte
> > sequences by by signaling an error, or replacing problematic code points
> with
> > "�" (U+FFFD, REPLACEMENT CHARACTER).
>
> typo: "by by"
>

Oops. Couple more too, got sloppy this draft.

>
> "There are reasonable options for dealing with problematic input. First,
> an implementation
> can reject text containing problematic input. Secondly, it's possible to
> replace problematic
> code points with placeholders.  Responding to that risk, [UNICODE
> <https://www.ietf.org/archive/id/draft-bray-unichars-06.html#UNICODE>] section
> 3.2 recommends
> dealing with ill-formed byte sequences by signaling an error, or
> replacing problematic code points with '�' (U+FFFD, REPLACEMENT
> CHARACTER). Lastly, it can make sense to accept it, if the entire
> implementation
> is designed to accommodate ill-formed Unicode."
>
> Not attached to my words, just trying to get the point across.
>

Not sure what that point is. The proposed language loses the narrative
about silently ignoring, and then the added “make sense to ignore” flies in
the face of that narrative, which I think is important given the security
considerations.  What do others think?




>>