idnits 2.17.1 draft-ietf-ecrit-service-urn-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 15, 2006) is 6645 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) == Unused Reference: '2' is defined on line 251, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 264, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '3') ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '10') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2915 (ref. '11') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 3044 (ref. '13') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3187 (ref. '14') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3406 (ref. '15') (Obsoleted by RFC 8141) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: August 19, 2006 February 15, 2006 6 A Uniform Resource Name (URN) for Services 7 draft-ietf-ecrit-service-urn-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The content of many communication services depend on the context, 41 such as the user's location. We describe a 'service' URN that allows 42 to register such context-dependent services that can be resolved in a 43 distributed manner. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Registration Template . . . . . . . . . . . . . . . . . . . . 4 49 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 51 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 53 5.2 Informative References . . . . . . . . . . . . . . . . . . 7 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 55 A. Alternative Approaches Considered . . . . . . . . . . . . . . 8 56 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 57 Intellectual Property and Copyright Statements . . . . . . . . 10 59 1. Introduction 61 In existing telecommunications systems, there are many well-known 62 communication and information services that are offered by loosely 63 coordinated entities across a large geographic region, with well- 64 known identifiers. Some of the services are operated by governments 65 or regulated monopolies, others by competing commercial enterprises. 66 Examples include emergency services (reached by 911 in North America, 67 112 in Europe), community services and volunteer opportunities (211 68 in some regions of the United States),telephone directory and repair 69 services (411 and 611 in the United States and Canada), government 70 information services (311 in some cities in the United States), 71 lawyer referral services (1-800-LAWYER), car roadside assistance 72 (automobile clubs) and pizza delivery services. Unfortunately, 73 almost all of them are limited in scope to a single country or 74 possibly a group of countries, such as those belonging to the North 75 American Numbering Plan or the European Union. The same identifiers 76 are often used for other purposes outside that region, making 77 accessing such services difficult when users travel or use devices 78 produced outside their home country. 80 These services are characterized by long-term stability of user- 81 visible identifiers, decentralized administration of the underlying 82 service and a well-defined resolution mechanism. (For example, there 83 is no national coordination or call center for 911; rather, various 84 local government organizations cooperate to provide this service, 85 based on jurisdictions.) 87 In this document, we propose a URN namespace that, together with 88 resolution protocols beyond the scope of this document, allows to 89 define such global, well-known services, while distributing the 90 actual implementation across a large number of service-providing 91 entities. While there are many ways to divide provision of such 92 services, we focus on geography as a common way to delineate service 93 regions. In addition, users can choose different directory providers 94 that in turn manage how geographic locations are mapped to service 95 providers. 97 Availability of such service identifiers simplifies end system 98 configuration. For example, an IP phone could have a special set of 99 short cuts or buttons that invoke emergency services, as it would not 100 be practical to manually re-configure the device with local emergency 101 contacts for each city or town a user visits with his or her mobile 102 device. Also, such identifiers allow to delegate routing decisions 103 to third parties and mark certain requests as having special 104 characteristics while preventing these characteristics to be 105 accidentally invoked on inappropriate requests. 107 This URN allows to identify services independent of a particular 108 protocol to deliver the services. It may appear in protocols that 109 allow general URIs, such as SIP [5] request URIs, web pages or 110 mapping protocols. 112 Existing technologies address the mapping of service identifiers to a 113 service for a particular DNS domain (DNS SRV [9], DNS NAPTR [11]) or 114 a local area network (SLP [8]). 116 The tel URI [16] allows to express service codes such as 911 by 117 adding a context parameter, but does not address the problem of 118 global validity. 120 LUMP [20] is a prototype resolution system for mapping URNs to URLs 121 based on geographic location. However, it is anticipated that there 122 will be several such systems. 124 2. Registration Template 126 Below, we include the registration template for the URN scheme 127 according to RFC 3406 [15]. 128 Namespace ID: service 129 Registration Information: Registration version: 1; registration date: 130 2005-07-10 131 Declared registrant of the namespace: TBD 132 Declaration of syntactic structure: The URN consists of a 133 hierarchical service identifier, with a sequence of labels 134 separated by periods. The left-most label is the most significant 135 one and is called 'top-level service', while names to the right 136 are called 'sub-services'. The set of allowable characters is the 137 same as that for IRIs, that used for domain names [1] except that 138 there is no restriction on the first character being a letter; 139 labels are case-insensitive and SHOULD be specified in all lower- 140 case. Any string of service labels can be used to request 141 services that are either more generic or more specific. In other 142 words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are 143 also valid service URNs. 145 "URN:service:" top-level-service *("." service-identifier) 146 top-level-service = ALPHA / DIGIT / "-" / 147 service-identifier = ALPHA / DIGIT / "-" / 149 Relevant ancillary documentation: None 150 Community considerations: The service URN is believe to be relevant 151 to a large cross-section of Internet users, including both 152 technical and non-technical users, on a variety of devices, but 153 particularly for mobile and nomadic users. The service URN will 154 allow Internet users needing services to identify the service by 155 kind, without having to determine manually who provides the 156 particular service in the user's current context, e.g., at his 157 current location. For example, a traveler will be able to use his 158 mobile device to request emergency services without having to know 159 the local emergency number. The assignment of identifiers is 160 described in the IANA Considerations (Section 4). The service URN 161 does not prescribe a particular resolution mechanism, but it is 162 assumed that a number of different entities could operate and 163 offer such mechanisms. The ECRIT working group is currently 164 discussing several approaches, including solutions based on DNS, 165 IRIS and a web-services protocol. Software prototypes for some of 166 these are currently already available and are believed to be 167 readily developed. 168 Namespace considerations: There do not appear to be other URN 169 namespaces that serve the same need of uniquely identifying 170 widely-available communication and information services. Unlike 171 most other currently registered URN namespaces, the service URN 172 does not identify documents and protocol objects (e.g., [13], 173 [14], [18], [19]), types of telecommunications equipment [17], 174 people or organizations [12]. tel URIs [16] identify telephone 175 numbers, but numbers commonly identifying services, such as 911 or 176 112, are specific to a particular region or country. 177 Identifier uniqueness considerations: A service URN identifies a 178 logical service, specified in the service registration (see IANA 179 considerations). Resolution of the URN, if successful, will 180 return a particular instance of the service, and this instance may 181 be different even for two users making the same request in the 182 same place at the same time; the logical service identified by the 183 URN, however, is persistent and unique. 184 Identifier persistence considerations: The 'service' URN for the same 185 service is expected to be persisent, although there naturally 186 cannot be a guarantee that a particular service will continue to 187 be available globally or at all times. 188 Process of identifier assignment: Details of the service assignment 189 depend on the service and national regulations. In general, it is 190 assumed that providers of services can register through a service 191 mapping mechanism for a particular service in a particular 192 geographic area. The provision of some services may be restricted 193 by local or national regulations. (As a hypothetical example, 194 providing emergency services may be restricted to government- 195 authorized entities, which may limit the region where each entity 196 can advertise its services.) The rules for each service are 197 described in a service-specific document. 198 Process for identifier resolution: 'service' identifiers are resolved 199 by the TBD mapping protocol, an instance of a Resolution Discovery 200 System (RDS) as described in RFC 2276 [3]. (In theory, there 201 could be several such mapping protocols in concurrent use, as long 202 as there are reasonable guarantees that all services are available 203 in all mapping protocols.) 204 Rules for Lexical Equivalence: 'service' identifiers are compared 205 according to domain name comparison rules. The use of homographic 206 identifiers is NOT RECOMMENDED. 207 Conformance with URN Syntax: There are no special considerations. 208 Validation mechanism: The RDS mechanism is also used to validate the 209 existence of a resource. As noted, by its design, the 210 availability of a resource may depend on where service is desired 211 and there may not be service available in all or most locations. 212 (For example, roadside assistance service is unlikely to be 213 available on about 70% of the earth's surface.) 214 Scope: The scope for this URN is public and global. 216 3. Example 218 For discussion and illustration purposes only, we include an example 219 of a particular service. We choose emergency services as an example, 220 with the top-level service identifier 'sos'. A possible list of 221 identifiers might include: 223 urn:service:sos 224 urn:service:sos.fire 225 urn:service:sos.police 226 urn:service:sos.marine 227 urn:service:sos.mountain 228 urn:service:sos.rescue 229 urn:service:sos.poison 230 urn:service:sos.suicide 231 urn:service:sos.mental-health 232 urn:service:sos.animal-control 234 4. IANA Considerations 236 New service-identifying tokens and sub-registrations are to be 237 managed by IANA, according to the processes outlined in [4]. The 238 policy for top-level service names is TBD, but could be 239 'specification required', 'IETF Consensus' or 'Standards Action'. 240 The policy for assigning names to sub-services may differ for each 241 top-level service designation and MUST be defined by the document 242 describing the top-level service. 244 5. References 246 5.1 Normative References 248 [1] Mockapetris, P., "Domain names - concepts and facilities", 249 STD 13, RFC 1034, November 1987. 251 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 252 Levels", BCP 14, RFC 2119, March 1997. 254 [3] Sollins, K., "Architectural Principles of Uniform Resource Name 255 Resolution", RFC 2276, January 1998. 257 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 258 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 260 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 261 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 262 Session Initiation Protocol", RFC 3261, June 2002. 264 [6] Duerst, M. and M. Suignard, "Internationalized Resource 265 Identifiers (IRIs)", RFC 3987, January 2005. 267 5.2 Informative References 269 [7] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 270 FUNCTIONS", RFC 2142, May 1997. 272 [8] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service 273 Location Protocol, Version 2", RFC 2608, June 1999. 275 [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 276 specifying the location of services (DNS SRV)", RFC 2782, 277 February 2000. 279 [10] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 281 [11] Mealling, M. and R. Daniel, "The Naming Authority Pointer 282 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 284 [12] Mealling, M., "The Network Solutions Personal Internet Name 285 (PIN): A URN Namespace for People and Organizations", RFC 3043, 286 January 2001. 288 [13] Rozenfeld, S., "Using The ISSN (International Serial Standard 289 Number) as URN (Uniform Resource Names) within an ISSN-URN 290 Namespace", RFC 3044, January 2001. 292 [14] Hakala, J. and H. Walravens, "Using International Standard Book 293 Numbers as Uniform Resource Names", RFC 3187, October 2001. 295 [15] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 296 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 297 BCP 66, RFC 3406, October 2002. 299 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 300 December 2004. 302 [17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace 303 for the Common Language Equipment Identifier (CLEI) Code", 304 RFC 4152, August 2005. 306 [18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform 307 Resource Names (URN)", RFC 4179, October 2005. 309 [19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the 310 TV-Anytime Forum", RFC 4195, October 2005. 312 [20] Schulzrinne, H., "Location-to-URL Mapping Protocol (LUMP)", 313 draft-schulzrinne-ecrit-lump-01 (work in progress), 314 October 2005. 316 Author's Address 318 Henning Schulzrinne 319 Columbia University 320 Department of Computer Science 321 450 Computer Science Building 322 New York, NY 10027 323 US 325 Phone: +1 212 939 7004 326 Email: hgs+ecrit@cs.columbia.edu 327 URI: http://www.cs.columbia.edu 329 Appendix A. Alternative Approaches Considered 331 The "sos" SIP URI reserved user name proposed here follows the 332 convention of RFC 2142 [7] and the "postmaster" convention documented 333 in RFC 2822 [10]. The approach has the advantage that only the home 334 proxy for a user needs to understand the convention and that the 335 mechanism is likely backwards-compatible with most SIP user agents, 336 with the only requirement that they have to be able to generate 337 alphanumeric URLs. One drawback is that it may conflict with locally 338 assigned addresses of the form "sos@domain". Also, if proxies not 339 affiliated with the domain translate the URL, they violate the 340 current SIP protocol conventions. 342 There are a number of possible alternatives, each with their own set 343 of advantages and problems: 345 tel:NNN;context=+C This approach uses tel URIs [16]. Here, NNN is 346 the national emergency number, where the country is identified by 347 the context C. This approach is easy for user agents to implement, 348 but hard for proxies and other SIP elements to recognize, as it 349 would have to know about all number-context combinations in the 350 world and track occasional changes. In addition, many of these 351 numbers are being used for other services. For example, the 352 emergency number in Paraguay (00) is also used to call the 353 international operator in the United States. A number of 354 countries, such as Italy, use 118 as an emergency number, but it 355 also connects to directory assistance in Finland. 356 tel:sos This solution avoids name conflicts, but is not a valid "tel" 357 [16] URI. It also only works if every outbound proxy knows how to 358 route requests to a proxy that can reach emergency services since 359 tel URIs. The SIP URI proposed here only requires a user's home 360 domain to be appropriately configured. 361 sip:sos@domain Earlier work had defined a special user identifier, 362 sos, within the caller's home domain in a SIP URI, for example, 363 sip:sos@example.com. This approach had the advantage that dial 364 plans in existing user agents could probably be converted to 365 generate such a URI and that only the home proxy for the domain 366 has to understand the user naming convention. However, it 367 overloads the user part of the URI with specific semantics rather 368 than being opaque, makes routing by the outbound proxy a special 369 case that does not conform to normal SIP request-URI handling 370 rules and is SIP-specific. The mechanism also does not extend 371 readily to other services. 372 SIP URI user parameter: One could create a special URI, such as "aor- 373 domain;user=sos". This avoids the name conflict problem, but 374 requires mechanism-aware user agents that are capable of emitting 375 this special URI. Also, the 'user' parameter is meant to describe 376 the format of the user part of the SIP URI, which this usage does 377 not do. Adding other parameters still leaves unclear what, if 378 any, conventions should be used for the user and domain part of 379 the URL. Neither solution is likely to be backward-compatible 380 with existing clients. 381 Special domain: A special domain, such as "sip:fire@sos.int" could be 382 used to identify emergency calls. This has similar properties as 383 the "tel:sos" URI, except that it is indeed a valid URI. To make 384 this usable, the special domain would have to be operational and 385 point to an appropriate emergency services proxy. Having a 386 single, if logical, emergency services proxy for the whole world 387 seems to have undesirable scaling and administrative properties. 389 Appendix B. Acknowledgments 391 This document is based on discussions with Jonathan Rosenberg and 392 benefitted from the comments of Benja Fallenstein and Leslie Daigle. 394 Intellectual Property Statement 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at 416 ietf-ipr@ietf.org. 418 Disclaimer of Validity 420 This document and the information contained herein are provided on an 421 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 422 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 423 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 424 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 425 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 428 Copyright Statement 430 Copyright (C) The Internet Society (2006). This document is subject 431 to the rights, licenses and restrictions contained in BCP 78, and 432 except as set forth therein, the authors retain all their rights. 434 Acknowledgment 436 Funding for the RFC Editor function is currently provided by the 437 Internet Society.