Network Working Group A. Mayrhofer
Request for Comments: 4969 enum.at
Category: Standards Track August 2007
Network Working Group A. Mayrhofer
Request for Comments: 4969 enum.at
Category: Standards Track August 2007
IANA Registration for vCard Enumservice
i安娜注册vCard Enumservice
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number.
此备忘录使用URI方案“http”和“https”注册Enumservice“vCard”。此Enumservice用于从ENUM域名引用到描述相应E.164号用户的vCard实例。
Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call.
从这些vCard收集的信息可以在入站或出站通信发生之前、期间或之后使用。例如，在接听电话之前，可能会向被叫人显示呼叫者的姓名和关联。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Enumservice Registration - vCard . . . . . . . . . . . . . . . 2
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security and Privacy Considerations . . . . . . . . . . . . . . 3
5.1. The ENUM Record Itself . . . . . . . . . . . . . . . . . . 3
5.2. The Resource Identified . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Enumservice Registration - vCard . . . . . . . . . . . . . . . 2
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security and Privacy Considerations . . . . . . . . . . . . . . 3
5.1. The ENUM Record Itself . . . . . . . . . . . . . . . . . . 3
5.2. The Resource Identified . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
E.164 Number Mapping (ENUM) [1] uses the Domain Name System (DNS) [2] to refer from E.164 numbers [3] to Uniform Resource Identifiers (URIs) [6]. The registration process for Enumservices is described in Section 3 of RFC 3761.
E.164编号映射（ENUM）[1]使用域名系统（DNS）[2]将E.164编号[3]引用到统一资源标识符（URI）[6]。RFC 3761第3节描述了Enumservices的注册过程。
"vCard" [4] is a transport-independent data format for the exchange of information about an individual. For the purpose of this document, the term "vCard" refers to a specific instance of this data format -- an "electronic business card". vCards are exchanged via several protocols; most commonly, they are distributed as electronic mail attachments or published on web servers. Most popular personal information manager applications are capable of reading and writing vCards.
“vCard”[4]是一种独立于传输的数据格式，用于交换个人信息。在本文件中，术语“vCard”是指这种数据格式的一个具体实例——“电子名片”。vCard通过多种协议进行交换；最常见的是，它们作为电子邮件附件分发或发布在web服务器上。大多数流行的个人信息管理器应用程序都能够读写vCard。
The Enumservice specified in this document deals with the relation between an E.164 number and vCards. An ENUM record using this Enumservice identifies a resource from where a vCard corresponding to the respective E.164 number could be fetched.
本文档中指定的Enumservice处理E.164号码与vCard之间的关系。使用此Enumservice的ENUM记录标识一个资源，从中可以获取对应于相应E.164编号的vCard。
Clients could use those resources to, e.g., automatically update local address books (a Voice over IP phone could try to fetch vCards for all outbound and inbound calls taking place on that phone and display them together with the call journal). In a more integrated scenario, information gathered from those vCards could even be automatically incorporated into the personal information manager application of the respective user.
客户端可以使用这些资源，例如自动更新本地通讯簿（IP语音电话可以尝试获取该电话上发生的所有出站和入站呼叫的vCard，并将其与呼叫日志一起显示）。在更集成的场景中，从这些vCard收集的信息甚至可以自动合并到相应用户的personal information manager应用程序中。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
Enumservice Name: "vCard"
枚举服务名称：“vCard”
Enumservice Type: "vcard"
枚举服务类型：“vcard”
Enumservice Subtype: n/a
枚举服务子类型：不适用
URI Schemes: "http", "https"
URI方案：“http”、“https”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified is a plain vCard, according to RFC 2426, which may be accessed using HTTP/ HTTPS [7].
根据RFC 2426，此Enumservice表示标识的资源是普通vCard，可以使用HTTP/HTTPS[7]访问该vCard。
Clients fetching the vCard from the resource indicated should expect access to be restricted. Additionally, the comprehension of the data provided may vary depending on the client's identity.
从指定的资源获取vCard的客户端应期望访问受到限制。此外，对所提供数据的理解可能因客户身份而异。
Security Considerations: see Section 5
安全注意事项：见第5节
Intended Usage: COMMON
预期用途：普通
Author: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Author: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
An example ENUM entry referencing to a vCard could look like:
引用vCard的示例枚举条目如下所示：
$ORIGIN 6.4.9.0.6.4.9.7.0.2.4.4.e164.arpa. @ IN NAPTR 100 10 "u" "E2U+vcard" \ "!^.*$!http://example.net/vcard.vcf!" .
$ORIGIN 6.4.9.0.6.4.9.7.0.2.4.4.e164.arpa.@在NAPTR 100中10“u”E2U+vcard“\”！^.*$！http://example.net/vcard.vcf!" .
As with any Enumservice, the security considerations of ENUM itself (Section 6 of RFC 3761) apply.
与任何ENUM服务一样，ENUM本身的安全考虑（RFC 3761第6节）也适用。
Since ENUM uses DNS -- a publicly available database -- any information contained in records provisioned in ENUM domains must be considered public as well. Even after revoking the DNS entry and removing the referred resource, copies of the information could still be available.
由于ENUM使用DNS（一个公开可用的数据库），所以在ENUM域中提供的记录中包含的任何信息也必须被视为公开的。即使在撤销DNS条目并删除引用的资源后，信息的副本仍然可用。
Information published in ENUM records could reveal associations between E.164 numbers and their owners - especially if URIs contain personal identifiers or domain names for which ownership information can be obtained easily. For example, the following URI makes it easy to guess the owner of an E.164 number, as well as his location and association, by just examining the result from the ENUM lookup:
ENUM记录中发布的信息可能会揭示E.164号码与其所有者之间的关联，特别是当URI包含个人标识符或域名时，可以轻松获取其所有权信息。例如，通过检查枚举查找的结果，以下URI可以轻松猜测E.164号码的所有者及其位置和关联：
http://sandiego.company.example.com/joe-william-user.vcf
http://sandiego.company.example.com/joe-william-user.vcf
However, it is important to note that the ENUM record itself does not need to contain any personal information. It just points to a location where access to personal information could be granted. For example, the following URI only reveals the service provider hosting the vCard (who probably even provides anonymous hosting):
但是，需要注意的是，枚举记录本身不需要包含任何个人信息。它只是指向一个可以访问个人信息的位置。例如，以下URI仅显示托管vCard的服务提供商（可能甚至提供匿名托管）：
http://anonhoster.example.org/file_adfa001.vcf
http://anonhoster.example.org/file_adfa001.vcf
ENUM records pointing to third-party resources can easily be provisioned on purpose by the ENUM domain owner - so any assumption about the association between a number and an entity could therefore be completely bogus unless some kind of identity verification is in place. This verification is out of scope for this memo.
指向第三方资源的枚举记录可以很容易地由枚举域所有者故意设置，因此，任何关于数字和实体之间关联的假设都可能是完全虚假的，除非进行某种身份验证。此验证超出此备忘录的范围。
In most cases, vCards provide information about individuals. Linking telephone numbers to such Personally Identifiable Information (PII) is a very sensitive topic, because it provides a "reverse lookup" from the number to its owner. Publication of such PII is covered by data-protection law in many legislations. In most cases, the explicit consent of the affected individual is required.
在大多数情况下，vCard提供个人信息。将电话号码与此类个人识别信息（PII）链接是一个非常敏感的话题，因为它提供了从号码到其所有者的“反向查找”。许多立法中的数据保护法涵盖了此类PII的发布。在大多数情况下，需要受影响个人的明确同意。
Users MUST therefore carefully consider information they provide in the resource identified by the ENUM record as well as in the record itself. Considerations SHOULD include serving information only to entities of the user's choice and/or limiting the comprehension of the information provided based on the identity of the requestor.
因此，用户必须仔细考虑EnUM记录所标识的资源以及记录本身所提供的信息。考虑事项应包括仅向用户选择的实体提供信息和/或根据请求者的身份限制对所提供信息的理解。
The use of HTTP in this Enumservice allows using built-in authentication, authorization, and session control mechanisms to be used to maintain access controls on vCards. Most notable, Digest Authentication [8] could be used to challenge requestors, and even synthesize vCards based on the client's identity (or refuse access entirely). This could especially be useful in private ENUM deployments (like within enterprises), where clients would more likely have a valid credential to access the indicated resource.
此Enumservice中使用HTTP允许使用内置的身份验证、授权和会话控制机制来维护vCard上的访问控制。最值得注意的是，摘要身份验证[8]可用于质询请求者，甚至根据客户的身份合成vCard（或完全拒绝访问）。这在私有ENUM部署（如在企业内部）中尤其有用，在这种情况下，客户端更有可能拥有访问指定资源的有效凭据。
Even public deployments could synthesize vCards based on the identity of the client. Social network sites, for example, could (based on HTTP session data like cookies [9]) provide more comprehensive vCards to their members than to anonymous clients.
甚至公共部署也可以根据客户端的身份合成vCard。例如，社交网站（基于HTTP会话数据，如cookies[9]）可以向其成员提供比匿名客户端更全面的vCard。
If access restrictions on the vCard resource are deployed, standard HTTP authentication, authorization, and state management mechanisms (as described in RFCs 2617 and 2695) MUST be used to enforce those restrictions. HTTPS SHOULD be preferred if the deployed mechanisms are prone to eavesdropping and replay attacks.
如果对vCard资源部署了访问限制，则必须使用标准HTTP身份验证、授权和状态管理机制（如RFCs 2617和2695中所述）来实施这些限制。如果部署的机制容易受到窃听和重放攻击，则应首选HTTPS。
ENUM deployments using this Enumservice together with DNS Security Extensions (DNSSEC) [10] should consider using Minimally Covering NSEC Records [11] to prevent zone walking, as the PII data contained in vCards constitutes a rich target for such attempts.
使用此枚举服务与DNS安全扩展（DNSSEC）[10 ]的枚举部署应该考虑使用最小覆盖的NSEC记录[11 ]来防止区域移动，因为包含在VCARI中的PII数据构成了此类尝试的丰富目标。
This memo requests registration of the "vCard" Enumservice according to the template in Section 3 of this document and the definitions in RFC 3761 [1].
本备忘录要求根据本文件第3节中的模板和RFC 3761[1]中的定义注册“vCard”Enumservice。
The author wishes to thank David Lindner for his contributions during the early stages of this document. In addition, Klaus Nieminen, Jon Peterson, Ondrej Sury, and Ted Hardie provided very helpful suggestions.
作者谨感谢David Lindner在本文件早期阶段所作的贡献。此外，克劳斯·尼米宁、乔恩·彼得森、昂德雷·苏里和特德·哈迪提供了非常有益的建议。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[3] ITU-T, "The international public telecommunication numbering plan", Recommendation E.164 (02/05), Feb 2005.
[3] ITU-T，“国际公共电信编号计划”，建议E.164（02/05），2005年2月。
[4] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[4] Dawson，F.和T.Howes，“vCard MIME目录配置文件”，RFC24261998年9月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[6] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[7] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[8] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[9] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[9] Kristol，D.和L.Montulli，“HTTP状态管理机制”，RFC 29652000年10月。
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[10] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[11] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, April 2006.
[11] Weiler，S.和J.Ihren，“最低限度地覆盖NSEC记录和DNSSEC在线签名”，RFC 44702006年4月。
Author's Address
作者地址
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/2/9维也纳A-1010奥地利
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。