Terminology Used in Internationalization in the IETF
Summary: Needs a YES. Needs 8 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 02 and is now closed.
( Wesley Eddy ) Yes
( Pete Resnick ) Yes
( Peter Saint-Andre ) Yes
Jari Arkko No Objection
( Ron Bonica ) (was Discuss) No Objection
( Stewart Bryant ) No Objection
( Gonzalo Camarillo ) No Objection
( Ralph Droms ) (was Discuss) No Objection
( Adrian Farrel ) No Objection
Comment (2011-06-30 for -)
In Section 7.1 the definition ends with "<Stringprep>" but there is no such reference. --- 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.
Stephen Farrell No Objection
Comment (2011-06-27 for -)
(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?
( David Harrington ) No Objection
( Russ Housley ) (was Discuss) No Objection
( Dan Romascanu ) (was Discuss) No Objection
( Robert Sparks ) No Objection
Comment (2011-06-29 for -)
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 reconsidered.
( spt ) No Objection
Comment (2011-07-12 for -)
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: The 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 so. Is there somebody outside the IETF that can't reference an informational RFC that wants to refer to this draft? Catherine's: I found the phrase "Internet users must be able to be enter text in typical input methods and displayed in any human language." 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?