summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4969.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4969.txt')
-rw-r--r--doc/rfc/rfc4969.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4969.txt b/doc/rfc/rfc4969.txt
new file mode 100644
index 0000000..a2a1eff
--- /dev/null
+++ b/doc/rfc/rfc4969.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group A. Mayrhofer
+Request for Comments: 4969 enum.at
+Category: Standards Track August 2007
+
+
+ IANA Registration for 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.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+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
+
+
+
+
+
+
+Mayrhofer Standards Track [Page 1]
+
+RFC 4969 vCard Enumservice August 2007
+
+
+1. Introduction
+
+ 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.
+
+ "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.
+
+ 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.
+
+ 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.
+
+2. Terminology
+
+ 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].
+
+3. Enumservice Registration - vCard
+
+ Enumservice Name: "vCard"
+
+ Enumservice Type: "vcard"
+
+ Enumservice Subtype: n/a
+
+ URI Schemes: "http", "https"
+
+
+
+
+
+
+
+Mayrhofer Standards Track [Page 2]
+
+RFC 4969 vCard Enumservice August 2007
+
+
+ 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].
+
+ 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.
+
+ Security Considerations: see Section 5
+
+ Intended Usage: COMMON
+
+ Author: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
+
+4. Example
+
+ An example ENUM entry referencing to a vCard could look like:
+
+ $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!" .
+
+5. Security and Privacy Considerations
+
+ As with any Enumservice, the security considerations of ENUM itself
+ (Section 6 of RFC 3761) apply.
+
+5.1. The ENUM Record Itself
+
+ 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.
+
+ 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:
+
+ http://sandiego.company.example.com/joe-william-user.vcf
+
+
+
+
+
+
+Mayrhofer Standards Track [Page 3]
+
+RFC 4969 vCard Enumservice August 2007
+
+
+ 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):
+
+ 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.
+
+5.2. The Resource Identified
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+Mayrhofer Standards Track [Page 4]
+
+RFC 4969 vCard Enumservice August 2007
+
+
+ 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.
+
+6. IANA Considerations
+
+ 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].
+
+7. Acknowledgements
+
+ 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.
+
+8. References
+
+8.1. Normative References
+
+ [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.
+
+ [2] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [3] ITU-T, "The international public telecommunication numbering
+ plan", Recommendation E.164 (02/05), Feb 2005.
+
+ [4] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
+ RFC 2426, September 1998.
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+8.2. Informative References
+
+ [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+ January 2005.
+
+ [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.
+
+
+
+
+Mayrhofer Standards Track [Page 5]
+
+RFC 4969 vCard Enumservice August 2007
+
+
+ [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.
+
+ [9] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
+ RFC 2965, October 2000.
+
+ [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [11] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and
+ DNSSEC On-line Signing", RFC 4470, April 2006.
+
+Author's Address
+
+ Alexander Mayrhofer
+ enum.at GmbH
+ Karlsplatz 1/2/9
+ Wien A-1010
+ Austria
+
+ Phone: +43 1 5056416 34
+ EMail: alexander.mayrhofer@enum.at
+ URI: http://www.enum.at/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mayrhofer Standards Track [Page 6]
+
+RFC 4969 vCard Enumservice August 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Mayrhofer Standards Track [Page 7]
+