Internet DRAFT - draft-mongrain-ecrit-service-coverage-scope-urn
draft-mongrain-ecrit-service-coverage-scope-urn
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].
<Mongrain> 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.
<Mongrain> 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
<Mongrain> 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
<Blatantly copied from RFC-5031> 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
<TBD>
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.
<Mongrain> 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
<Mongrain> Expires September 25, 2013 [Page 6]
