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