Internet Engineering Task Force (IETF) P. Faltstrom, Ed.
Request for Comments: 6452 Cisco
Category: Standards Track P. Hoffman, Ed.
ISSN: 2070-1721 VPN Consortium
November 2011
Internet Engineering Task Force (IETF) P. Faltstrom, Ed.
Request for Comments: 6452 Cisco
Category: Standards Track P. Hoffman, Ed.
ISSN: 2070-1721 VPN Consortium
November 2011
The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0
Unicode代码点和应用程序国际化域名（IDNA）-Unicode 6.0
Abstract
摘要
This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0.
本备忘录记录了IETF关于应用程序国际化域名（IDNA）派生字符属性的共识，这些属性与Unicode 5.2中存在的三个代码点有关，在版本6.0发布时更改了属性值。大家一致认为，不需要根据Unicode 6.0中所做的更改对RFC 5892进行更新。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6452.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6452.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. U+0CF1 KANNADA SIGN JIHVAMULIYA ............................2
1.2. U+0CF2 KANNADA SIGN UPADHMANIYA ............................2
1.3. U+19DA NEW TAI LUE THAM DIGIT ONE ..........................2
2. IETF Consensus ..................................................2
3. IANA Considerations .............................................3
4. Security Considerations .........................................3
5. Acknowledgements ................................................3
6. Normative References ............................................3
1. Introduction ....................................................2
1.1. U+0CF1 KANNADA SIGN JIHVAMULIYA ............................2
1.2. U+0CF2 KANNADA SIGN UPADHMANIYA ............................2
1.3. U+19DA NEW TAI LUE THAM DIGIT ONE ..........................2
2. IETF Consensus ..................................................2
3. IANA Considerations .............................................3
4. Security Considerations .........................................3
5. Acknowledgements ................................................3
6. Normative References ............................................3
RFC 5892 [RFC5892] specifies an algorithm that was defined when version 5.0 (later updated to version 5.2) [Unicode5.2] was the current version of Unicode, and it also defines a derived property value based on that algorithm. Unicode 6.0 [Unicode6] has changed GeneralCategory of three code points that were allocated in Unicode 5.2 or earlier. This implies that the derived property value differs depending on whether the property definitions used are from Unicode 5.2 or 6.0. These are non-backward-compatible changes as described in Section 5.1 of RFC 5892.
RFC 5892[RFC5892]指定了一个算法，该算法是在版本5.0（后来更新为版本5.2）[Unicode5.2]是Unicode的当前版本时定义的，它还基于该算法定义了一个派生属性值。Unicode 6.0[Unicode6]更改了Unicode 5.2或更早版本中分配的三个代码点的通用类别。这意味着派生属性值的不同取决于所使用的属性定义是来自Unicode 5.2还是6.0。这些是RFC 5892第5.1节所述的不向后兼容变更。
The three code points are:
这三个代码点是：
The GeneralCategory for this character changes from So to Lo. This implies that the derived property value changes from DISALLOWED to PVALID.
此角色的常规类别从So更改为Lo。这意味着派生属性值将从DISALLOWED更改为PVALID。
The GeneralCategory for this character changes from So to Lo. This implies that the derived property value changes from DISALLOWED to PVALID.
此角色的常规类别从So更改为Lo。这意味着派生属性值将从DISALLOWED更改为PVALID。
The GeneralCategory for this character changes from Nd to No. This implies that the derived property value changes from PVALID to DISALLOWED.
此字符的GeneralCategory从Nd更改为No。这意味着派生属性值从PVALID更改为DISALLOWED。
No change to RFC 5892 is needed based on the changes made in Unicode 6.0.
基于Unicode 6.0中所做的更改，无需对RFC 5892进行任何更改。
This consensus does not imply that no changes will be made to RFC 5892 for all future updates of The Unicode Standard.
这一共识并不意味着未来所有Unicode标准更新都不会对RFC 5892进行任何更改。
This RFC has been produced because 6.0 is the first version of Unicode to be released since IDNA2008 was published.
之所以生成此RFC，是因为6.0是自IDNA2008发布以来发布的第一个Unicode版本。
IANA has updated the derived property value registry according to RFC 5892 and the property values defined in The Unicode Standard version 6.0.
IANA已根据RFC 5892和Unicode标准版本6.0中定义的属性值更新了派生属性值注册表。
When the algorithm presented in RFC 5892 is applied using the property definitions of Unicode Standard version 6.0, the result will be different from when it is applied using the property definitions of Unicode 5.2 for the three code points discussed in this document. The three code points are unlikely to occur in internationalized domain names, however, so the security implications of the changes are minor.
当使用Unicode标准版本6.0的属性定义应用RFC 5892中的算法时，结果将不同于使用Unicode 5.2的属性定义应用于本文档中讨论的三个代码点时的结果。然而，这三个代码点不太可能出现在国际化域名中，因此这些更改对安全的影响很小。
The main contributors are (in alphabetical order) Eric Brunner-Williams, Vint Cerf, Tina Dam, Mark Davis, Martin Duerst, John Klensin, Pete Resnick, Markus Scherer, Andrew Sullivan, Kenneth Whistler, and Nicholas Williams.
主要贡献者是（按字母顺序排列）埃里克·布伦纳·威廉姆斯、温特·瑟夫、蒂娜·达姆、马克·戴维斯、马丁·杜尔斯、约翰·克莱辛、皮特·雷斯尼克、马库斯·谢勒、安德鲁·沙利文、肯尼斯·惠斯勒和尼古拉斯·威廉姆斯。
Not all contributors believe that the solution for the issues discussed in this document is optimal.
并非所有贡献者都认为本文档中讨论的问题的解决方案是最佳的。
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892]Faltstrom，P.，Ed.“Unicode代码点和应用程序的国际化域名（IDNA）”，RFC 5892，2010年8月。
[Unicode5.2] The Unicode Consortium, "The Unicode Standard, Version 5.2.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN 0-321-48091-0, as amended by Unicode 5.2.0, October 2009, <http://www.unicode.org/versions/Unicode5.2.0/>.
[Unicode 5.2]Unicode联盟，“Unicode标准，版本5.2.0”，Unicode 5.0.0，马萨诸塞州波士顿市，Addison-Wesley ISBN 0-321-48091-0，经Unicode 5.2.0修订，2009年10月<http://www.unicode.org/versions/Unicode5.2.0/>.
[Unicode6] The Unicode Consortium, "The Unicode Standard, Version 6.0.0", October 2010, <http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode 6]Unicode联盟，“Unicode标准，版本6.0.0”，2010年10月<http://www.unicode.org/versions/Unicode6.0.0/>.
Authors' Addresses
作者地址
Patrik Faltstrom (editor) Cisco
Patrik Faltstrom（编辑）思科
EMail: paf@cisco.com
EMail: paf@cisco.com
Paul Hoffman (editor) VPN Consortium
保罗·霍夫曼（编辑）VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org