< draft-polk-ecrit-lost-transformations-urn-00.txt   draft-polk-ecrit-lost-transformations-urn-01.txt >
ECRIT WG James Polk ECRIT WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: April 19, 2010 October 19, 2009 Expires: Sept 8, 2010 March 8, 2010
Intended Status: Standards Track (PS) Intended Status: Standards Track (PS)
Updates: RFC 5222 (if published) Updates: RFC 5222 (if published)
The Transformations Uniform Resource Name (URN) The Transformations Uniform Resource Name (URN)
Using Location-to-Service Translation Using Location-to-Service Translation
draft-polk-ecrit-lost-transformations-urn-00 draft-polk-ecrit-lost-transformations-urn-01
Abstract
This document creates a new top level service URN for
transformations to be used by location-to-service translation
protocol (LoST) to convert similar values into a different format of
choice. Within this 'transformations' URN, there are two
sub-elements specifically created for geocoding and reverse
geocoding location formats by this document.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 54
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your publication of this document. Please review these documents
rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Abstract document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
This document creates a new top level service URN for warranty as described in the BSD License.
transformations to be used by location-to-service translation
protocol (LoST) to convert similar values into a different format of
choice. Within this 'transformations' URN, there are two
sub-elements specifically created for geocoding and reverse
geocoding location formats by this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
1. Introduction 1. Introduction
Many devices are starting to use location in one of many formats, This document creates a URN for transformations to be used by LoST
but not always the same format. The most common of these formats is (Location-to-Service Translation Protocol) [RFC5222]. Today, the
civic location (defined by RFC 4119 & 4776) and geodetic most obvious transformation using LoST is from one location format
(coordinate) location (like GPS). Various arguments have been made to another. Within each LoST request, there is a location provided,
to have all devices choose one format - and move forward with that. along with a service URN the LoST server uses to determine which URI
This is like choosing one signaling protocol for voice or file to give in the LoST response, based on the location of the
transfer. These two will remain to have multiple choices for years requester. Fundamentally, LoST handles most locations - most likely
(decades?) to come. Location formats probably is no different. in both the geodetic and civic formats [RFC4119]. It seems only
logical to ask the LoST server, who likely has both location formats
In the interim, i.e., before one format is chosen to solve loaded, to transform one location format to the other format.
everything, there needs to be translation between the many formats.
End devices should not necessarily be burdened with making this
conversion, but can correctly identify which format they have or
have just received, and request that this format be converted to the
one that end device prefers. This preference can be for many
reasons, but is more likely because an application running on that
end device prefers location in a certain format, for whatever
reason.
This document specifies how LoST (Location-to-Service Translation
Protocol) [RFC5222] can be used to accomplish this conversion. The
service is converting coordinate location to civic addressing,
called geocoding, and converting civic addressing to geodetic
location, called reverse-geocoding.
LoST is primarily used by communicating two specific pieces of
information and having a URI be returned. The two pieces of
information are
#1 - a location (similar to the PIDF-LO format [RFC4119]), and
#2 - what service is to be attained that services that location.
The service is identified by the requester by a URN. The LoST server
then determines which URI is appropriate for that service within
that location. LoST servers need to accept locations in both the
civic and geodetic formats, thus LoST servers are logical to convert
one location format to another.
This document specifies how a location plus a service identifier
wishes to receive back a converted location, and not a URI to be
contacted.
To accomplish this service, a new service URN has to be created for
each type of conversion. The end device performs a LoST request
with its non-preferred location format it possesses, with the URN of
the type of conversion it wants, and the response will contain the
converted location.
2. Transformations URN
This document creates a URN for transformations, as shown here:
urn:service:transformations
This URN is for converting a dissimilar values meaning the same
thing into another format. For example, transforming civic location
format value into a coordinate pair location format value (see
Section 2.1 for more on geocoding).
2.1 Geocoding URNs
This document creates and registers the following sub-element URNs
below the top-level 'transformations' URN for a geocoding service:
urn:service:transformations:geocoding
and
urn:service:transformations:rev-geocoding
This is to be placed in the <> element of a LoST request. Transforming a geodetic coordinate pair to a civic location address
is called geocoding. The reverse, transforming a civic address into
a geodetic coordinate pair is called reverse-geocoding. If a LoST
server does not have both formats present for this transformation,
but knows of a remote server to contact for such an operation, the
LoST server returns the URI of that remote server in the LoST
response, leaving it to the host to request this conversion of
formats. This latter operation will likely not be done using LoST,
but rather a protocol such as HTTP(S). This document does not
specify how this latter transaction occurs.
3. One Transaction Verses Two 2. One Transaction Verses Two
Strictly speaking, LoST is about including a URN of a service, and Strictly speaking, LoST is about including a URN of a service, and
the location of the requester in a request message, and getting a the location of the requester in a request message, and getting a
response message that includes the URI of who the original requester response message that includes the URI of who the original requester
needs to contact for that service. In some cases, for needs to contact for that service. In some cases, for
transformations, a LoST server can possess both versions of the same transformations, a LoST server can possess multiple formats of the
information. This is most true for location information in two same information. This is most true for location information in two
different formats. If a user wants to convert, or transform one different formats. If a user wants to convert, or transform one
location format to another, it can ask a LoST server if it can location format to another, it can ask a LoST server for who to
convert one location format to another. If the LoST server cannot, contact to make this conversion or transformation. On the other
or is unwilling to, the LoST reply will include only the URI of the hand, and within the same LoST request (implicit or explicit), if
server to be connected for this conversion. the LoST server has both formats of the same location - it should be
able to respond with the transformation. This increases the
user/device experience and makes everything more efficient by
reducing the number of transactions to get the information to the
asking party.
If the LoST server cannot perform this transformation, or is
unwilling to, the LoST response should include only the URI of the
server to be connected for this transformation.
With this as a background, here are two possibilities for a LoST With this as a background, here are two possibilities for a LoST
query for location transformation: query for location transformation:
Option #1 - For LoST servers that have the transformation Option #1 - For LoST servers that have the transformation
information local to it, or otherwise chooses to have a information local to it, or otherwise chooses to have a
single LoST transaction fulfill the transformation single LoST transaction fulfill the transformation
request, the response can have the transformation in the request, the response can have the transformation in the
response. response.
Option #2 - For time in which a LoST server does not have the Option #2 - For time in which a LoST server does not have the
transformation information local (or decides it does not transformation information local (or decides it does not
want to go fetch the information requested for a single want to go fetch the information requested for a single
LoST transaction with the requester), or otherwise does LoST transaction with the requester), or otherwise does
not want to provide this transformation information in a not want to provide this transformation information in a
single transaction - the LoST server can merely provide single transaction - the LoST server can merely provide
a URI of the server that can answer this transformation a URI of the server that can answer this transformation
query in the LoST response. query in the LoST response.
4. Registration of Template This document leaves it up to the implementation to decide which way
it wants to go - of the 2 choices above.
TBD (and will follow the rules according to RFC 3406 [RFC3406]) If a transformation cannot be performed by the LoST server, the
response SHOULD contain the URI of where to contact that can do this
service, or provide an error indicating it cannot.
5. Examples of LoST Request and Response 3. Transformations URN
TBD This document creates the service URN for transformations to be used
by the LoST protocol, as shown here:
(will show a LoST query containing geodetic location and geocode urn:service:transformations
service URN, and return a civic location)
6. Security considerations This URN is for converting a dissimilar values meaning the same
thing into another format, perhaps to a specified format, based on
the LoST request. For example, transforming civic location format
value into a coordinate pair location format value.
3.1 Sub-Services for the 'transformation' Service
This section defines the transformation service using the top-level
service label 'transformation'.
urn:service:transformation
urn:service:transformation.geocoding
urn:service:transformation.reverse-geocoding
Other transformations can be added to this document as it
progresses.
4. An Example Transformation
[section under construction]
[Editor's Note: this will show a LoST request, along with 2 LoST
responses - one showing the transformation in the
LoST response, the other showing the URI to be
contacted for the transformation.]
5. Security considerations
This document introduces no additional security considerations from This document introduces no additional security considerations from
that in RFC 5222, the LoST specification, or in RFC 5031, the URN that in RFC 5222, the LoST specification, or in RFC 5031, the URN
Services specification. Services specification.
7. IANA considerations 6. IANA considerations
TBD 6.1. Sub-Services for the 'transformation' Service
8. Acknowledgments This section defines the service registration within the IANA
registry, using the top-level service label 'transformation'.
urn:service:transformation 'transformation' service denotes a
top-level service, and it encompasses all of the services
listed below.
urn:service:transformation.geocoding This service identifier is
used to indicate a conversion from a geodetic coordinate-pair
location format to a civic location format is desired.
urn:service:transformation.reverse-geocoding This service
identifier is used to indicate a conversion from a civic
location format to a geodetic coordinate-pair location format
is desired.
6.2. Initial IANA Registration
The following table contains the initial IANA registration for
transformation services.
Service Reference Description
-------------------------------------------------------
urn:service:transformation [this doc] Transformation services
urn:service:transformation.geocoding
[this doc] geocoding transformation
urn:service:transformation.reverse-geocoding
[this doc] reverse-geocoding
transformation
7. Acknowledgments
The author would like to thank Brian Rosen, Richard Barnes, Andy The author would like to thank Brian Rosen, Richard Barnes, Andy
Newton and Hannes Tschofenig for the useful comments. Newton and Hannes Tschofenig for the useful comments.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[RFC5222] T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig, "LoST: [RFC5222] T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig, "LoST:
A Location-to-Service Translation Protocol", RFC 5222, A Location-to-Service Translation Protocol", RFC 5222,
August 2008 August 2008
[RFC3406] L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom, "Uniform [RFC3406] L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom, "Uniform
Resource Names (URN) Namespace Definition Mechanisms", RFC Resource Names (URN) Namespace Definition Mechanisms", RFC
3406, October 2002 3406, October 2002
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005 Format", RFC 4119, December 2005
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", RFC 4776, November 2006 Information", RFC 4776, November 2006
[RFC5031] H. Schulzrinne, "A Uniform Resource Name (URN) for Emergency [RFC5031] H. Schulzrinne, "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008 and Other Well-Known Services", RFC 5031, January 2008
9.2. Informative References 8.2. Informative References
[] [none]
Authors' Addresses Authors' Addresses
James Polk James Polk
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas, USA Colleyville, Texas, USA
+1.817.271.3552 +1.817.271.3552
mailto: jmpolk@cisco.com mailto: jmpolk@cisco.com
 End of changes. 26 change blocks. 
111 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/