Terminology Used in Internationalization in the IETF
draft-ietf-appsawg-rfc3536bis-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Ralph Droms |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Ronald Bonica |
2011-08-01
|
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Catherine Meadows. |
2011-07-19
|
06 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-07-18
|
06 | (System) | IANA Action state changed to No IC from In Progress |
2011-07-18
|
06 | (System) | IANA Action state changed to In Progress |
2011-07-18
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-07-18
|
06 | Amy Vezza | IESG has approved the document |
2011-07-18
|
06 | Amy Vezza | Closed "Approve" ballot |
2011-07-18
|
06 | Amy Vezza | Approval announcement text regenerated |
2011-07-14
|
06 | Cindy Morgan | Removed from agenda for telechat |
2011-07-14
|
06 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation. |
2011-07-12
|
06 | Sean Turner | [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 … [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? |
2011-07-12
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-09
|
06 | Pete Resnick | State changed to IESG Evaluation from IESG Evaluation::AD Followup. |
2011-07-09
|
06 | (System) | New version available: draft-ietf-appsawg-rfc3536bis-06.txt |
2011-07-09
|
06 | Ralph Droms | [Ballot comment] I've cleared my DISCUSS. |
2011-07-09
|
06 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2011-07-07
|
06 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss |
2011-07-06
|
06 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss |
2011-07-06
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-07-06
|
05 | (System) | New version available: draft-ietf-appsawg-rfc3536bis-05.txt |
2011-07-02
|
06 | Russ Housley | [Ballot discuss] I think this document should be published as an Informational RFC. It seems to play a very similar role to RFC 2828 … |
2011-07-02
|
06 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss |
2011-07-01
|
06 | Pete Resnick | Placed on agenda for telechat - 2011-07-14 |
2011-06-30
|
06 | Cindy Morgan | Removed from agenda for telechat |
2011-06-30
|
06 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-06-30
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-30
|
06 | Amy Vezza | Ballot writeup text changed |
2011-06-30
|
06 | Pete Resnick | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-06-30
|
06 | Adrian Farrel | [Ballot comment] In Section 7.1 the definition ends with "" but there is no such reference. --- While I found the indications of source references … [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. |
2011-06-30
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-30
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-06-29
|
06 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-29
|
04 | (System) | New version available: draft-ietf-appsawg-rfc3536bis-04.txt |
2011-06-29
|
06 | Ralph Droms | [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. … [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? |
2011-06-29
|
06 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded |
2011-06-29
|
06 | Russ Housley | [Ballot discuss] I think this document should be published as an Informational RFC. It seems to play a very similar role to RFC 2828 … |
2011-06-29
|
06 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded |
2011-06-29
|
06 | Robert Sparks | [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 … [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. |
2011-06-29
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-29
|
06 | Dan Romascanu | [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 … [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. |
2011-06-29
|
06 | Dan Romascanu | [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 … [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? |
2011-06-28
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-28
|
06 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2011-06-28
|
06 | Pete Resnick | 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) … 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. |
2011-06-28
|
03 | (System) | New version available: draft-ietf-appsawg-rfc3536bis-03.txt |
2011-06-28
|
06 | Ron Bonica | [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 … [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". |
2011-06-28
|
06 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded |
2011-06-28
|
06 | Barry Leiba | Changed protocol writeup |
2011-06-28
|
06 | Sean Turner | [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 … [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? |
2011-06-28
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-28
|
06 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded |
2011-06-27
|
06 | Peter Saint-Andre | [Ballot Position Update] New position, Yes, has been recorded |
2011-06-27
|
06 | Stephen Farrell | [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) … [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? |
2011-06-27
|
06 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-27
|
06 | Dan Romascanu | [Ballot comment] 1. section 1.1 s/tuturial/tutorial/ 2. section 3.1 - why is W3C called 'This group' rather than 'This organization' or 'This consortium'? |
2011-06-27
|
06 | Dan Romascanu | [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 … [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 |
2011-06-27
|
06 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded |
2011-06-26
|
06 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2011-06-26
|
06 | Pete Resnick | Ballot has been issued |
2011-06-26
|
06 | Pete Resnick | Created "Approve" ballot |
2011-06-17
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2011-06-17
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2011-06-16
|
06 | Amy Vezza | Last call sent |
2011-06-16
|
06 | Amy Vezza | 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: … 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. |
2011-06-16
|
06 | Pete Resnick | Last Call was requested |
2011-06-16
|
06 | Pete Resnick | State changed to Last Call Requested from AD Evaluation. |
2011-06-16
|
06 | (System) | Ballot writeup text was added |
2011-06-16
|
06 | (System) | Last call text was added |
2011-06-16
|
06 | (System) | Ballot approval text was added |
2011-06-12
|
06 | Pete Resnick | Placed on agenda for telechat - 2011-06-30 |
2011-06-12
|
06 | Pete Resnick | Ballot writeup text changed |
2011-06-10
|
06 | Pete Resnick | State changed to AD Evaluation from AD is watching. |
2011-06-09
|
02 | (System) | New version available: draft-ietf-appsawg-rfc3536bis-02.txt |
2011-05-25
|
06 | Barry Leiba | In WG last call |
2011-05-25
|
06 | Barry Leiba | IETF state changed to In WG Last Call from WG Document |
2011-05-20
|
01 | (System) | New version available: draft-ietf-appsawg-rfc3536bis-01.txt |
2011-05-15
|
06 | Pete Resnick | State changed to AD is watching from Publication Requested. |
2011-05-15
|
06 | Pete Resnick | Draft added in state Publication Requested |
2011-05-03
|
00 | (System) | New version available: draft-ietf-appsawg-rfc3536bis-00.txt |