[art] draft-bray-unichars-09 review

[Orie Steele <[e-mail]>]

Hi,

This is not yet my AD evaluation, if you think I missed something obvious
here, please let me know so I can address it when this document moves to AD
Evaluation.

* line numbers:
  -
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-bray-unichars-09.txt&submitcheck=True

## Comments

### Lack of BCP14 Guidance

This document does not include many BCP14 keywords.
There are a few places where warnings could probably be upgraded to
recommendations.

### Recommendation to allow unassigned code points?

```
125   than 150,000 have been assigned to characters.  It is difficult to
126   specify that unassigned code points should be avoided, because they
127   regularly become assigned when new characters are added to Unicode.
```

This is bordering on a recommendation, should it be strengthened to BCP14
language?

### What about CBOR or protocol buffers?

```
145   a single transformation format.  UTF-8 is widely used for
146   interoperable data formats such as JSON, YAML, and XML.
```

The framing of this sentence implies UTF-8 is only relevant to text based
interoperable data formats.
CBOR is commented on later, but could be introduced in context here.

### Where is UTF-16 used?

```
178   A surrogate which occurs in text encoded in any transformation format
179   other than UTF-16 has no meaning and may cause malfunction in
180   software that encounters it.  In particular, it is impossible to
181   represent a surrogate in well-formed UTF-8.
```

Some guidance here on where to expect UTF-16 could help explain where to
expect surrogates.

### Where are legacy codes still used in IETF protocols?

```
198   Aside from the useful controls, the control codes are mostly obsolete
199   and generally lack interoperable semantics.  This document uses the
```

It would be good to call out any known places where these codes still have
interoperable semantics.

### Citation for this?

```
232   Surrogate code points have been observed to cause software failures.
```

Ideally in an RFC.

### Clearer guidance on handling problematic input

```
260   Reasonable options for dealing with problematic input include, first,
261   rejecting text containing problematic code points, and second,
262   replacing them with placeholders.  (As an exception, [UNICODE] notes
263   that it may in some cases be appropriate, specifically for
264   noncharacters, to treat them as non-problematic unassigned code
265   points.)
```

This could be framed with BCP14 language... The phrasing along with the
parenthetical make this slightly hard to understand.