ECRIT Working Group D. Mongrain Internet Draft Frequentis Intended status: Standards Track March 25, 2013 Expires: September 2013 Service Coverage Scope for Service URN draft-mongrain-ecrit-service-coverage-scope-urn-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 25, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Mongrain Expires September 25, 2013 [Page 1] Internet-Draft Jurisdictional Scope for Service URN March 2013 Abstract This document specifies a mechanism to specify a Service Coverage Scope in a Service URN [RFC5031] when multiple providers provide the same service for the same location. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................2 3. Service Coverage Scope.........................................3 4. Impact of Service Coverage Scopes on LoST Service Implementations ..................................................................4 5. Security Considerations........................................5 6. IANA Considerations............................................5 7. References.....................................................5 7.1. Normative References......................................5 8. Acknowledgments................................................6 1. Introduction For some given location, there may be multiple providers that supply the same given service. These providers offer their services for different coverage areas. For example, in the United States of America, both the city police and the state police handle emergency calls. If one needs to reach the state police to request emergency assistance, a different Service URN is needed in order to obtain the appropriate contact URI when querying the LoST service [RFC5222]. This is accomplished by appending a Service Coverage Scope at the end of the Service URN. The presence of a Service Coverage Scope in a Service URN indicates that the requester wants the service provider that provides the given service over the given coverage area for the given location. For example "urn:service:sos.police.country" specifies the national/federal police, "urn:service:sos.police.A1" the state/provincial/region/prefecture police, "urn:service:sos.police.A1" the county/parish/gun/district sheriff/police and "urn:service:sos.police.A3" the city/township/shi police. 2. Conventions used in this document 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 [RFC2119]. Expires September 25, 2013 [Page 2] Internet-Draft Jurisdictional Scope for Service URN March 2013 3. Service Coverage Scope A Service Coverage Scope SHALL be one of the following: +------------------------+----------------------+ | Service Coverage Scope | Coverage Area | +------------------------+----------------------+ | country | Entire country | | | | | A1 | national | | | subdivision (state, | | | region, province, | | | prefecture) | | | | | A2 | county, parish, gun | | | (JP), district (IN) | | | | | A3 | city, township, shi | | | (JP) | | | | | A4 | city division, | | | borough, city | | | district, ward, chou | | | (JP) | | | | | A5 | neighborhood, block | +------------------------+----------------------+ The astute reader will immediately notice that the Service Coverage Scope names are identical to elements found in the civic location format [RFC4119]. This is to avoid utilizing political division nomenclature that is not universally applicable. For example "urn:service:sos.police.A1" specifies provincial police in Canada, prefecture police in Japan and state police in the United States of America. A Service Coverage Scope MAY be used with any valid Service URN when a coverage area needs to be specified. A Service Coverage Scope SHALL be the last element of a Service URN. Expires September 25, 2013 [Page 3] Internet-Draft Jurisdictional Scope for Service URN March 2013 There SHALL NOT be more than one Service Coverage Scope specified in a Service URN. When a Service Coverage Scope is specified, the service requested SHALL be provided over the entire coverage area. For example, the fictitious Whoville Fire Department cannot be contacted using "urn:service:sos.fire.A2" as it does not provide fire prevention services over the entire county/parish/gun/district the city of Whoville belongs to. Nothing in this document prevents a service provider from offering their service over multiple coverage areas. For example, three neighbouring counties may decide to utilize the same sheriff department for all three counties. The Service URN "urn:service:sos.police.A2" can be used in all three counties to reach the sheriff department. The sheriff department cannot be reached using "urn:service:sos.police.A1" since it does not cover the entire state/province/region/prefecture. The use of a Service Coverage Scope SHALL NOT change the intent of the Service URN it is appended to. For example, if a police department exists at the country level but it does not accept emergency calls, "urn:service:sos.police.country" cannot not be used to reach it as "urn:service:sos" and its subservices are intended to be used only when requesting immediate assistance [RFC5031]. 4. Impact of Service Coverage Scopes on LoST Service Implementations An implementation of a LoST service does not need to be modified in order to utilize Service Coverage Scopes. Service URNs containing a Service Coverage Scope are provisioned exactly the same way as any other Service URNs. Care must be given to ensure that service providers provisioned using a Service URN that includes a Service Coverage Scope do indeed provide the service over the entire designated coverage area. This document introduces a new element that is appended to a Service URN. In the future, other subservices will be introduced that will also be added to Service URNs. It can be likely that a LoST Service is queried with a Service URN that is not provisioned, especially if the requester is a device which originates from a location where such a service exists. It may be desirable that the LoST Service returns a "next best thing" answer instead of serviceNotImplemented error. As specified in RFC-5222 section 5.4 [RFC5222], a LoST Service implementation can substitute another service in the case Expires September 25, 2013 [Page 4] Internet-Draft Jurisdictional Scope for Service URN March 2013 the given service is not defined. A method to accomplish this is to unroll the given Service URN. When a request to the LoST Service evaluates to what would be a serviceNotImplemented error, the LoST Service SHOULD remove the last element of the provided Service URN and re-evaluate the request. If the re-evaluation still results in what would be serviceNotImplemented, it SHOULD repeat the process again until all elements of the Service URN have been removed, in which case the LoST Service SHALL return a serviceNotImplemented error back to the requester. 5. Security Considerations As an identifier, the Service URN does not appear to raise any particular security issues. The services described by the URN are meant to be well-known, even if the particular service instance is access-controlled, so privacy considerations do not apply to the URN. There are likely no specific privacy issues when including a Service URN on a web page, for example. On the other hand, ferrying the URN in a signaling protocol can give attackers information on the kind of service desired by the caller. For example, this makes it easier for the attacker to automatically find all calls for emergency services or directory assistance. Appropriate, protocol-specific security mechanisms need to be implemented for protocols carrying Service URNs. The mapping protocol needs to address a number of threats, as detailed in [RFC5069]. That document also discusses the security considerations related to the use of the Service URN for emergency services. 6. IANA Considerations 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Expires September 25, 2013 [Page 5] Internet-Draft Jurisdictional Scope for Service URN March 2013 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Daniel Mongrain Frequentis Suite 1002 150 Metcalfe Street Ottawa, Ontario Canada K2P 1P1 Email: daniel.mongrain@frequentis.com Expires September 25, 2013 [Page 6]