Note: This ballot was opened for revision 02 and is now closed.
Summary: Has enough positions to pass.
In Section 7.1 the definition ends with "<Stringprep>" but there is no
While I found the indications of source references useful, I did not
find that angle brackets were the best indicators as they are also
used for two other (distinct) purposes in the document.
Replacing <NONE> with <THIS> might send a more positive message.
This is updated to add Catherine's comment:
I'm curious to see how Dan's 1st discuss point shakes out. If it's really
going to be a BCP, then the following should be changed:
definitions in this document are not normative for IETF standards;
however, they are useful and standards may make informative reference
to this document after it becomes an RFC.
If it's a BCP then, as Barry noted in his response to Dan, everybody could
normatively reference this document. I'm not really sure I buy the rationale
of wanting to make this a BCP because everybody wants to normatively reference
it (because DOWNREFs are easy), but if that is the case, then we ought to say
Is there somebody outside the IETF that can't reference an informational RFC
that wants to refer to this draft?
I found the phrase
"Internet users must be
able to be enter text in typical input methods and displayed in any
in the introduction somewhat hard to parse. Does it mean that 1) users should
be able to use any of a set of typical input methods and 2) it should be
possible to display the results in any human language, or that users should be
able to enter text from any human language using typical input methods?
(1) s/provides identifiers/provide identifiers/ in definition
of language (standards is plural)
(2) s/for global from the/for global use from the/ on p8
(3) Is anchor9 in 3.2 supposed to remain or not? I would
have thought the time for comments on that was past?
I don't agree that this document needs BCP status as currently formulated. We
can find a way to address the downref inconvenience if that's a primary
motivation. I don't find a basis in 2026 for "This is informational but we
REALLY mean it". If there are requirements being placed on future IETF work
(even if those requirements apply only to a particular set of groups), I can
see an argument for BCP in the 2026 definitions.
That said, if this is published as a BCP, I don't believe it does any harm to
the work it is attempting to influence, and very little additional harm to how
the world (especially outside the IETF) interprets RFCs with this designation
(beyond continued erosion of the perception of BCPs as "special"), so I am
balloting no objection while stating a preference that the choice be