idnits 2.17.1 draft-schulzrinne-sipping-service-01.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 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 290. ** 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 (October 23, 2005) is 6750 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: '1' is defined on line 216, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '2') ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2915 (ref. '7') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 3406 (ref. '8') (Obsoleted by RFC 8141) == Outdated reference: A later version (-01) exists of draft-schulzrinne-ecrit-lump-00 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: April 26, 2006 October 23, 2005 6 A Uniform Resource Name (URN) for Services 7 draft-schulzrinne-sipping-service-01 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 April 26, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 51 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 53 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 55 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 56 Intellectual Property and Copyright Statements . . . . . . . . 8 58 1. Introduction 60 In existing telecommunications systems, there are many well-known 61 communication and information services that are offered by loosely 62 coordinated entities across a large geographic region, with well- 63 known identifiers. Some of the services are operated by governments 64 or regulated monopolies, others by competing commercial enterprises. 65 Examples include emergency services (reached by 911 in North America, 66 112 in Europe), telephone directory and repair services (411 and 611 67 in the United States and Canada), government information services 68 (311 in some cities in the United States), lawyer referral services 69 (1-800-LAWYER), car roadside assistance (automobile clubs) and pizza 70 delivery services. Unfortunately, almost all of them are limited in 71 scope to a single country or possibly a group of countries, such as 72 those belonging to the North American Numbering Plan or the European 73 Union. The same identifiers are often used for other purposes 74 outside that region, making accessing such services difficult when 75 users travel or use devices produced outside their home country. 77 These services are characterized by long-term stability of user- 78 visible identifiers, decentralized administration of the underlying 79 service and a well-defined resolution mechanism. (For example, there 80 is no national coordination or call center for 911; rather, various 81 local government organizations cooperate to provide this service, 82 based on jurisdictions.) 84 In this document, we propose a URN namespace that, together with 85 resolution protocols beyond the scope of this document, allows to 86 define such global, well-known services, while distributing the 87 actual implementation across a large number of service-providing 88 entities. While there are many ways to divide provision of such 89 services, we focus on geography as a common way to delineate service 90 regions. In addition, users can choose different directory providers 91 that in turn manage how geographic locations are mapped to service 92 providers. 94 Availability of such service identifiers simplifies end system 95 configuration. For example, an IP phone could have a special set of 96 short cuts or buttons that invoke emergency services, as it would not 97 be practical to manually re-configure the device with local emergency 98 contacts for each city or town a user visits with his or her mobile 99 device. Also, such identifiers allow to delegate routing decisions 100 to third parties and mark certain requests as having special 101 characteristics while preventing these characteristics to be 102 accidentally invoked on inappropriate requests. 104 This URN allows to identify services independent of a particular 105 protocol to deliver the services. It may appear in protocols that 106 allow general URIs, such as SIP [4] request URIs, web pages or 107 mapping protocols. 109 Existing technologies address the mapping of service identifiers to a 110 service for a particular DNS domain (DNS SRV [6], DNS NAPTR [7]) or a 111 local area network (SLP [5]). 113 The tel URI [9] allows to express service codes such as 911 by adding 114 a context parameter, but does not address the problem of global 115 validity. 117 LUMP [10] is a prototype resolution system for mapping URNs to URLs 118 based on geographic location. However, it is anticipated that there 119 will be several such systems. 121 2. Registration Template 123 Below, we include the registration template for the URN scheme 124 according to RFC 3406 [8]. 125 Namespace ID: service 126 Registration Information: Registration version: 1; registration date: 127 2005-07-10 128 Declared registrant of the namespace: TBD 129 Declaration of syntactic structure: The URN consists of a 130 hierarchical service identifier, with a sequence of labels 131 separated by periods. The left-most label is the most significant 132 one and is called 'top-level service', while names to the right 133 are called 'sub-services'. The set of allowable characters is the 134 same as that used for domain names. Any string of service labels 135 can be used to request services that are either more generic or 136 more specific. In other words, if a service 'x.y.z' exists, the 137 URNs 'x' and 'x.y' are also valid service URNs. [?] 139 "URN:service:" top-level-service *("." service-identifier) 140 top-level-service = ALPHA / DIGIT / "-" / 141 service-identifier = ALPHA / DIGIT / "-" / 143 Relevant ancillary documentation: None 144 Identifier uniqueness considerations: 'service' URNs identify one 145 logical service, recognized by human users as such. The service 146 does not have to be provided by the same organization or to the 147 same standards over time and space. Unlike for other URNs, the 148 content of the service is by nature dynamic. While undesirable in 149 many cases, two users making the same request for a service from 150 the same place may not necessarily be directed to the same 151 resource. 153 Identifier persistence considerations: The 'service' URN for the same 154 service is expected to be persisent, although there naturally 155 cannot be a guarantee that a particular service will continue to 156 be available globally or at all times. 157 Process of identifier assignment: Details of the service assignment 158 depend on the service and national regulations. In general, it is 159 assumed that providers of services can register through a service 160 mapping mechanism for a particular service in a particular 161 geographic area. The provision of some services may be restricted 162 by local or national regulations. (As a hypothetical example, 163 providing emergency services may be restricted to government- 164 authorized entities, which may limit the region where each entity 165 can advertise its services.) The rules for each service are 166 described in a service-specific document. 167 Process for identifier resolution: 'service' identifiers are resolved 168 by the TBD mapping protocol, an instance of a Resolution Discovery 169 System (RDS) as described in RFC 2276 [2]. (In theory, there 170 could be several such mapping protocols in concurrent use, as long 171 as there are reasonable guarantees that all services are available 172 in all mapping protocols.) 173 Rules for Lexical Equivalence: 'service' identifiers are compared 174 according to domain name comparison rules. The use of homographic 175 identifiers is NOT RECOMMENDED. 176 Conformance with URN Syntax: There are no special considerations. 177 Validation mechanism: The RDS mechanism is also used to validate the 178 existence of a resource. As noted, by its design, the 179 availability of a resource may depend on where service is desired 180 and there may not be service available in all or most locations. 181 (For example, roadside assistance service is unlikely to be 182 available on about 70% of the earth's surface.) 183 Scope: The scope for this URN is public and global. 185 3. Example 187 For discussion and illustration purposes only, we include an example 188 of a particular service. We choose emergency services as an example, 189 with the top-level service identifier 'sos'. A possible list of 190 identifiers might include: 192 urn:service:sos 193 urn:service:sos.fire 194 urn:service:sos.police 195 urn:service:sos.marine 196 urn:service:sos.mountain 197 urn:service:sos.rescue 198 urn:service:sos.poison 199 urn:service:sos.suicide 200 urn:service:sos.mental-health 202 4. IANA Considerations 204 New service-identifying tokens and sub-registrations are to be 205 managed by IANA, according to the processes outlined in [3]. The 206 policy for top-level service names is TBD, but could be 207 'specification required', 'IETF Consensus' or 'Standards Action'. 208 The policy for assigning names to sub-services may differ for each 209 top-level service designation and MUST be defined by the document 210 describing the top-level service. 212 5. References 214 5.1 Normative References 216 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 217 Levels", BCP 14, RFC 2119, March 1997. 219 [2] Sollins, K., "Architectural Principles of Uniform Resource Name 220 Resolution", RFC 2276, January 1998. 222 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 223 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 225 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 226 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 227 Session Initiation Protocol", RFC 3261, June 2002. 229 5.2 Informative References 231 [5] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service 232 Location Protocol, Version 2", RFC 2608, June 1999. 234 [6] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 235 specifying the location of services (DNS SRV)", RFC 2782, 236 February 2000. 238 [7] Mealling, M. and R. Daniel, "The Naming Authority Pointer 239 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 241 [8] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 242 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 243 BCP 66, RFC 3406, October 2002. 245 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 246 December 2004. 248 [10] Schulzrinne, H., "Location-to-URL Mapping Protocol (LUMP)", 249 draft-schulzrinne-ecrit-lump-00 (work in progress), June 2005. 251 Author's Address 253 Henning Schulzrinne 254 Columbia University 255 Department of Computer Science 256 450 Computer Science Building 257 New York, NY 10027 258 US 260 Phone: +1 212 939 7004 261 Email: hgs+simple@cs.columbia.edu 262 URI: http://www.cs.columbia.edu 264 Appendix A. Acknowledgments 266 This document is based on discussions with Jonathan Rosenberg. 268 Intellectual Property Statement 270 The IETF takes no position regarding the validity or scope of any 271 Intellectual Property Rights or other rights that might be claimed to 272 pertain to the implementation or use of the technology described in 273 this document or the extent to which any license under such rights 274 might or might not be available; nor does it represent that it has 275 made any independent effort to identify any such rights. Information 276 on the procedures with respect to rights in RFC documents can be 277 found in BCP 78 and BCP 79. 279 Copies of IPR disclosures made to the IETF Secretariat and any 280 assurances of licenses to be made available, or the result of an 281 attempt made to obtain a general license or permission for the use of 282 such proprietary rights by implementers or users of this 283 specification can be obtained from the IETF on-line IPR repository at 284 http://www.ietf.org/ipr. 286 The IETF invites any interested party to bring to its attention any 287 copyrights, patents or patent applications, or other proprietary 288 rights that may cover technology that may be required to implement 289 this standard. Please address the information to the IETF at 290 ietf-ipr@ietf.org. 292 Disclaimer of Validity 294 This document and the information contained herein are provided on an 295 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 296 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 297 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 298 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 299 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 302 Copyright Statement 304 Copyright (C) The Internet Society (2005). This document is subject 305 to the rights, licenses and restrictions contained in BCP 78, and 306 except as set forth therein, the authors retain all their rights. 308 Acknowledgment 310 Funding for the RFC Editor function is currently provided by the 311 Internet Society.