idnits 2.17.1 draft-ietf-enum-vcard-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 20, 2007) is 6241 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2426 (ref. '4') (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '7') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '8') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2965 (ref. '9') (Obsoleted by RFC 6265) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM -- Telephone Number Mapping A. Mayrhofer 3 Working Group enum.at 4 Internet-Draft March 20, 2007 5 Expires: September 21, 2007 7 IANA Registration for vCard Enumservice 8 draft-ietf-enum-vcard-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 21, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo registers the Enumservice "vCard" using the URI schemes 42 "http" and "https". This Enumservice is to be used to refer from an 43 ENUM domain name to a vCard instance describing the user of the 44 respective E.164 number. 46 Information gathered from those vCards could be used before, during 47 or after inbound or outbound communication takes place. For example, 48 a callee might be presented with the name and association of the 49 caller before picking up the call. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. ENUM Service Registration - vCard . . . . . . . . . . . . . . . 4 61 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security & Privacy Considerations . . . . . . . . . . . . . . . 5 64 6.1. The ENUM Record Itself . . . . . . . . . . . . . . . . . . 5 65 6.2. The Resource Identified . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 Intellectual Property and Copyright Statements . . . . . . . . . . 9 78 1. Introduction 80 E.164 Number Mapping (ENUM) [1] uses the Domain Name System (DNS) [2] 81 to refer from E.164 numbers [3] to Uniform Resource Identifiers 82 (URIs) [6]. The registration process for Enumservices is described 83 in section 3 of RFC 3761. 85 "vCard" [4] is a transport independent data format for the exchange 86 of information about an individual. For the purpose of this 87 document, the term "vCard" refers to a specific instance of this data 88 format - an "electronic business card". vCards are exchanged via 89 several protocols, most commonly they are distributed as electronic 90 mail attachments or published on web servers. Most popular personal 91 information manager applications are capable of reading and writing 92 vCards. 94 The Enumservice specified in this document deals with the relation 95 between an E.164 number and vCards. An ENUM record using this 96 Enumservice identifies a resource from where a vCard corresponding to 97 the respective E.164 number could be fetched. 99 Clients could use those resources to eg. automatically update local 100 address books (a Voice over IP phone could try to fetch vCards for 101 all outbound and inbound calls taking place on that phone and display 102 them together with the call journal). In a more integrated scenario, 103 information gathered from those vCards could even be automatically 104 incorporated into the personal information manager application of the 105 respective user. 107 2. Change Log 109 [Note to editors: This section is to be removed before publication - 110 XML source available on request] 112 draft-ietf-enum-vcard-06 113 removed subtypes "xml" and "rdf" 114 added more text about limiting access 116 draft-ietf-enum-vcard-05 117 removed reference to RFC 3761 from Abstract 118 moved Changelog section 119 moved RFC 2119 stuff to seperate section 120 changed "plain" subtype to n/a 121 added examples to security consideration, changed text 122 added HTTP authentication reference 123 removed text about phone reverse lookups 124 clarified IANA registration section 126 draft-ietf-enum-vcard-04 127 added email address to IANA template (selfcontained) 128 changed number in example to UK drama number 129 added note about line break in example 131 draft-ietf-enum-vcard-03 132 Fixed typo in abstract 133 Added acks 134 Added text about PII data 136 draft-ietf-enum-vcard-02 137 added Acknowledgement section 138 clarified security considerations 139 extended introduction 140 sanitized references 141 added subtypes and URI schemes to Abstract 143 draft-ietf-enum-vcard-01 144 minor title change 145 removed sink type 147 draft-ietf-enum-vcard-00 148 changed name to reflect WG adoption 149 subtyped Enumservice 150 added "sink" type idea 151 worked on the text 153 draft-mayrhofer-enum-vcard-00 154 initial draft 156 3. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [5]. 162 4. ENUM Service Registration - vCard 164 Enumservice Name: "vCard" 166 Enumservice Type: "vcard" 168 Enumservice Subtype: n/a 169 URI Schemes: "http", "https" 171 Functional Specification: 172 This Enumservice indicates that the resource identified is a plain 173 vCard according to RFC 2426 which may be accessed using HTTP/HTTPS 174 [7]. 175 Clients fetching the vCard from the resource indicated should 176 expect access to be restricted. Additionally, the comprehension 177 of the data provided may vary depending on the client's identity. 179 Security Considerations: see Section 6 181 Intended Usage: COMMON 183 Author: Alexander Mayrhofer 185 5. Example 187 An example ENUM entry referencing to a vCard could look like: 189 $ORIGIN 6.4.9.0.6.4.9.7.0.2.4.4.e164.arpa. 190 @ IN NAPTR 100 10 "u" "E2U+vcard" 191 "!^.*$!http://example.net/vcard.vcf!" . 193 (Note: Due to line length constraints, the example record above is 194 split in two lines) 196 6. Security & Privacy Considerations 198 As with any Enumservice, the security considerations of ENUM itself 199 (Section 6 of RFC 3761) apply. 201 6.1. The ENUM Record Itself 203 Since ENUM uses DNS - a publicly available database - any information 204 contained in records provisioned in ENUM domains must be considered 205 public as well. Even after revoking the DNS entry and removing the 206 refered resource, copies of the information could still be available. 208 Information published in ENUM records could reveal associations 209 between E.164 numbers and their owners - especially if URIs contain 210 personal identifiers or domain names for which ownership information 211 can be obtained easily. For example, the following URI makes it easy 212 to guess the owner of an E.164 number as well as his location and 213 association by just examining the result from the ENUM lookup: 215 http://sandiego.company.example.com/joe-william-user.vcf 217 However, it is important to note that the ENUM record itself does not 218 need to contain any personal information. It just points to a 219 location where access to personal information could be granted. For 220 example, the following URI only reveals the service provider hosting 221 the vCard (who probably even provides anonymous hosting): 223 http://anonhoster.example.org/file_adfa001.vcf 225 ENUM records pointing to third party resources can easily be 226 provisioned on purpose by the ENUM domain owner - so any assumption 227 about the association between a number and an entity could therefore 228 be completely bogus unless some kind of identity verification is in 229 place. This verification is out of scope for this memo. 231 6.2. The Resource Identified 233 In most cases, vCards provide information about individuals. Linking 234 telephone numbers to such Personally Identifyable Information (PII) 235 is a very sensitive topic, because it provides a "reverse lookup" 236 from the number to its owner. Publication of such PII is covered by 237 data protection law in many legislations. In most cases, the 238 explicit consent of the affected individual is required. 240 Users MUST therefore carefully consider information they provide in 241 the resource identified by the ENUM record as well as in the record 242 itself. Considerations SHOULD include serving information only to 243 entities of the user's choice and/or limiting the comprehension of 244 the information provided based on the identity of the requestor. 246 The use of HTTP in this Enumservice allows using builtin 247 authentication, authorization, and session control mechanisms to be 248 used to maintain access controls on vCards. Most notable, Digest 249 Authentication [8] could be used to challenge requestors, and even 250 synthesize vCards based on the client's identity (or refuse access 251 entirely). This could especially be useful in private ENUM 252 deployments (like within enterprises), where clients would more 253 likely have a valid credential to access the indicated resource. 255 Even public deployments could synthesize vCards based on the identity 256 of the client. Social network sites eg. could (based on HTTP session 257 data like cookies [9]) provide more comprehensive vCards to their 258 members than to anonymous clients. 260 If access restrictions on the vCard resource are deployed, standard 261 HTTP authentication, authorization and state management mechanisms as 262 described in RFC 2617 and RFC 2695 MUST be used to enforce those 263 restrictions. HTTPS SHOULD be preferred if the deployed mechanisms 264 are prone to eavesdropping and replay attacks. 266 ENUM deployments using this Enumservice together with DNS Security 267 Extensions (DNSSEC) [10] should consider using Minimally Covering 268 NSEC Records [11] to prevent zone walking, as the PII data contained 269 in vCards constitutes a rich target for such attempts. 271 7. IANA Considerations 273 This memo requests registration of the "vCard" Enumservice according 274 to the template in Section 4 of this document and the definitions in 275 RFC 3761 [1]. 277 8. Acknowledgements 279 The author wishes to thank David Lindner for his contributions during 280 the early stages of this document. In addition, Klaus Nieminen, Jon 281 Peterson, Ondrej Sury and Ted Hardie provided very helpful 282 suggestions. 284 9. References 286 9.1. Normative References 288 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 289 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 290 Application (ENUM)", RFC 3761, April 2004. 292 [2] Mockapetris, P., "Domain names - Implementation and 293 Specification", STD 13, RFC 1035, November 1987. 295 [3] ITU-T, "The international public telecommunication numbering 296 plan", Recommendation E.164 (02/05), Feb 2005. 298 [4] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 299 RFC 2426, September 1998. 301 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 302 Levels", BCP 14, RFC 2119, March 1997. 304 9.2. Informative References 306 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 307 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 308 January 2005. 310 [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 311 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 312 HTTP/1.1", RFC 2616, June 1999. 314 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 315 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 316 Basic and Digest Access Authentication", RFC 2617, June 1999. 318 [9] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", 319 RFC 2965, October 2000. 321 [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 322 "DNS Security Introduction and Requirements", RFC 4033, 323 March 2005. 325 [11] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and 326 DNSSEC On-line Signing", RFC 4470, April 2006. 328 Author's Address 330 Alexander Mayrhofer 331 enum.at GmbH 332 Karlsplatz 1/9 333 Wien A-1010 334 Austria 336 Phone: +43 1 5056416 34 337 Email: alexander.mayrhofer@enum.at 338 URI: http://www.enum.at/ 340 Full Copyright Statement 342 Copyright (C) The IETF Trust (2007). 344 This document is subject to the rights, licenses and restrictions 345 contained in BCP 78, and except as set forth therein, the authors 346 retain all their rights. 348 This document and the information contained herein are provided on an 349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 351 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 352 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 353 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Intellectual Property 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org. 380 Acknowledgment 382 Funding for the RFC Editor function is provided by the IETF 383 Administrative Support Activity (IASA).