Terminology Used in Internationalization in the IETF
RFC 6365

Note: This ballot was opened for revision 06 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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
(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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Sean Turner) No Objection

Comment (2011-07-12)
No email
send info
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 so.    

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
   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?