doc: Add RFC documents

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]
+