Terminology Used in Internationalization in the IETF
draft-ietf-appsawg-rfc3536bis-06

[Ballot comment]
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?

[Ballot discuss]
I think this document should be published as an Informational RFC.
  It seems to play a very similar role to RFC 2828, which is an
  Informational RFC.  Also, this document obsoletes RFC 3536, which
  is an Informational RFC.

[Ballot comment]
In Section 7.1 the definition ends with "" 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  with  might send a more positive message.

[Ballot discuss]
Ron picked up chains of definitions that I also found
confusing.  I had one other specific question and a more abstract
question:

1. I'm not clear about the relationship among the terms "character
encoding form," "coded character set" and "character encoding scheme."
I consulted RFC 2978 for help (would it be appropriate to cite RFC
2978 with the definitions of CCS and CES?), and it seems CCS/CES gives
everything needed to go from characters to an octet sequence.  Where
does the "character encoding form" fit in?

2. I learned from RFC 2978 that a charset is a mapping from an octet
sequence to a character sequence, but the charset may not be a
complete mapping in the other direction.  Based on this little
insight, I wonder about all of the other mappings in the document: are
any of the other mappings only useful in one direction?  Would it be
useful to note the directionality of other mappings?

[Ballot discuss]
I think this document should be published as an Informational RFC.
  It seems to play a very similar role to RFC 2828, which is an
  Informational RFC.  Also, this document obsoletes RFC 3536, which
  is an Informational RFC.

[Ballot comment]
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.

[Ballot comment]
1. section 3.1 - why is W3C called 'This group' rather than 'This organization' or 'This consortium'?

2. Appendix C should mention the change from Informational to BCP. I believe it is significant.

[Ballot discuss]
Updated DISCUSS taking into account changes from 02 to 03:

1. One of the major changes from 3536 is that the future RFC aims to be a BCP, while 3536 was Informational. I expected to find a discussion on this respect including some rationale of the change and including some language that recommends using the terminology defined in this document. However section 1.1. 'Purpose of this Document' keeps using a language that is more appropriate to an Informational document, like: 'This document attempts to define terms in a way that will be most useful to the IETF audience.'

2. The defition of 'glyph' seems circular to me:

      > A glyph is an abstract form that represents one or more glyph
      images.  The term "glyph" is often a synonym for glyph image,
      which is the actual, concrete image of a glyph representation

3. Section 6 - is not the SnmpAdminString TC defined in RFC 3411 an example of usage of an ASCII-compatible encoding (ACE) that has reached standard status?

PROTO writeup for draft-ietf-appsawg-rfc3536bis-02

The Applications Area Working Group requests the publication of draft-ietf-appsawg-rfc3536bis-02 as a BCP, obsoleting RFC 3536, which is Informational.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Barry Leiba is the document shepherd. I have reviewed this version, and am satisfied that it's ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has adequate review, on the IDNAbis and EAI lists and then on the apps-discuss list, and I have no concerns.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I have no concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no concerns. There is no IPR involved.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is consensus of the working group behind it, not just "a few". That said, internationalization is a very specialized topic, and the majority of Applications Area participants are not well versed in it, and have not commented on the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have verified it with idnits version 2.12.12. It is fine.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All references are properly separated and labelled. This document, by its nature, has a number of references to documents from other bodies -- ISO, the Unicode Consortium, W3C, and ANSI. Two of those references are normative. They were normative in the original document as well, and are updated here:

[ISOIEC10646]
ISO/IEC, "ISO/IEC 10646-1:2003. International Standard --
Information technology - Universal Multiple-Octet Coded
Character Set (UCS)", 2003.

[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6.0", Mountain View, CA: The Unicode Consortium,
2011. ISBN 978-1-936213-01-6)., 2011,
.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

There are no IANA issues with this document, and the IANA Considerations section says that.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There is no formal language in this document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.

This document gives an overview of internationalization as it applies to IETF standards work by lightly covering the many aspects of internationalization and the vocabulary associated with those topics. Some of the overview is a somewhat tuturial in nature. It is not meant to be a complete description of internationalization. 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. Some of the definitions in this document come from many earlier IETF documents and books.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Not surprisingly for a document such as this, there were many suggestions of terminology to include, and of alternative definitions to the ones included. The editors have done a good job of striking a necessary balance between an overly bloated document and one that includes the right set of terms, with definitions that reflect reasonable consensus, if not always unanimity. There were a number of such discussions, with none bearing particular mention here.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

This document replaces RFC 3536, cleaning up and updating many of the definitions therein. RFC 3536 has been in use for eight years, and this document reflects that maturity and what we've learned about the gaps in the terminology and definitions over that time. Section 7 is a significant new section that talks about IDNA work done since RFC 3536.

[Ballot discuss]
1) The definitions in this document are not normative, but the document is a BCP. Isn't that a contradiction?

2) You say that a writing system is a set of rules for using a script to express a language. A better example of this might be helpful. You use the example of the American and British writing systems, but I have no idea what those are.

3) You use the term "character set" to describe the terms "coded character set" and "repertoire". But you never define this term. In fact, in the definition of charset you say, "Many protocol definitions use the term "character set" in their descriptions.  The terms "charset" or "character encoding scheme and "coded character set" are strongly preferred over the term "character set" because "character set" has other definitions in other contexts and this can be confusing.

4) The definition of "Glyph" leaves me thoroughly confused. The problem is that glyphs are described in terms of "glyph images". If I don't understand what a glyph is, how am I supposed to understand what a glyph image is?

5) Your definition of Glyph code does more to explain what a glyph is than your definition of glyph. It makes sense that glyphs might have something to do withn fonts, because the Greek word "glyphe" means "carving".

[Ballot comment]
What no proto write-up ;)

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?

[Ballot comment]
(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?

[Ballot discuss]
1. One of the major changes from 3536 is that the future RFC aims to be a BCP, while 3536 was Informational. I expected to find a discussion on this respect including some rationale of the change and including some language that recommends using the terminology defined in this document. However section 1.1. 'Purpose of this Document' keeps using a language that is more appropriate to an Informational document, like: 'This document attempts to define terms in a way that will be most useful to the IETF audience.'

2. The defition of 'glyph' seems circular to me:

      > A glyph is an abstract form that represents one or more glyph
      images.  The term "glyph" is often a synonym for glyph image,
      which is the actual, concrete image of a glyph representation

3. Section 6 - is not the SnmpAdminString TC defined in RFC 3411 an example of usage of an ASCII-compatible encoding (ACE) that has reached standard status?

4. Appendix C.  Changes from RFC 3536

  NOTE: This appendix is still quite sketchy.  It won't be finalized
  until later in the life of the document.

...

  There is still much to do before this document becomes an RFC.
  Intended changes include:
...

It looks like this Appendix was not updated for a while and I expect it to be finalized before the document is approved

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Terminology Used in Internationalization in the IETF) to BCP


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Terminology Used in Internationalization in the IETF'
  as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides a glossary of terms used in the IETF when
  discussing internationalization.  The purpose is to help frame
  discussions of internationalization in the various areas of the IETF
  and to help introduce the main concepts to IETF participants.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/


No IPR declarations have been submitted directly on this I-D.