Actually, the error is partly on our part. We want name to be NCName and NCName uses XML's Char production.

Char is defined:

  Char ::= | #x9 \| #xA \| #xD \| [#x20-#xD7FF] \| [#xE000-#xFFFD] \| [#x10000-#x10FFFF] | /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

We would deviate from this by omitting FFFD, which I think is an error on NCName's part.

This may have to go into a separate issue/PR, but it seems related, so I'm posting it here:
The grammar currently has the following:

simple-start-char = %x0-2D
quoted-char = %x0-5B         ; omit \
reserved-char  = %x00-08        ; omit HTAB and LF

This not only allows CR/LF/tab/FF, which may be okay, but also all kinds of other characters with essentially undefined or in one or another way weird (think e.g. about ESC) behavior. I think excluding those would be very prudent. This would avoid security issues and other nastities (e.g. searching for invisible differences if one of these characters is invisible).

This not only allows CR/LF/tab/FF, which may be okay, but also all kinds of other characters with essentially undefined or in one or another way weird (think e.g. about ESC) behavior.

On rereading, I realized I should have been a bit more specific. I'm talking about the C0 area, %x00-19.

This not only allows CR/LF/tab/FF, which may be okay, but also all kinds of other characters with essentially undefined or in one or another way weird (think e.g. about ESC) behavior.

On rereading, I realized I should have been a bit more specific. I'm talking about the C0 area, %x00-19.

Rejecting control characters was explicitly considered, cf. #268 and #282 and #290. I believe the outcome is explained in syntax.md (emphasis mine):

The syntax should define as few special characters and sigils as possible. Note that this necessitates extra care when presenting messages for human consumption, because they may contain invisible characters such as U+200B ZERO WIDTH SPACE, control characters such as U+0000 NULL and U+0009 TAB, permanently reserved noncharacters (U+FDD0 through U+FDEF and U+nFFFE and U+nFFFF where n is 0x0 through 0x10), private-use code points (U+E000 through U+F8FF, U+F0000 through U+FFFFD, and U+100000 through U+10FFFD), unassigned code points, and other potentially confusing content.

Any Unicode code point is allowed [in text], except for surrogate code points U+D800 through U+DFFF inclusive.

A literal MAY include any Unicode code point except for surrogate code points U+D800 through U+DFFF.

@gibson042 Thanks for your explanation. I think this is all okay, except when it comes to security considerations. Somewhere in the spec, the fact that a message can contain arbitrary control characters should be clearly called out as a security issue.

@duerst Thanks for the comment. Of course you're right: there are security risks here. For example, bidi-based spoofing is an issue. I created #579 to track this and other security considerations.

Somewhere in the spec, the fact that a message can contain arbitrary control characters should be clearly called out as a security issue.

Our syntax permits arbitrary control characters to appear inside the pattern portions of a message, but this does not imply anything about environment in which the message is serialized, stored, or processed. We don't provide character escapes, for example, because it is expected that the host format or system will do so. Most users will see the message as it is layered in their source code format and this will often make control characters visible as escaped.

Most string types are defined as a sequence of code points or code units with minimal restriction on the characters used. Our goal is that anything you could write as a string resource can be used in a pattern.

Ship it...

          |\___..--"/
   __..--``        /
  \_______________/   

@stasm

Would it make sense to treat U+FFFD the same way we treat surrogates, and forbid it globally from simple-start-char (which implies text-char), from quoted-char, and from reserved-char?

No, because it is a valid text char (can appear in literals).