wdiff draft-polk-ecrit-lost-transformations-urn-00.txt draft-polk-ecrit-lost-transformations-urn-01.txt

ECRIT WG James Polk
Internet-Draft Cisco Systems
Expires: April 19, Sept 8, 2010 March 8, 2010 October 19, 2009
Intended Status: Standards Track (PS)
Updates: RFC 5222 (if published)

The Transformations Uniform Resource Name (URN)
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

This Internet-Draft is submitted to IETF 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 April 19, September 8, 2010.

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 (http://trustee.ietf.org/license-info). document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.

Abstract

This Code Components extracted from 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 must include Simplified BSD License text as described in
Section 4.e of
choice. Within this 'transformations' URN, there are two
sub-elements specifically created for geocoding the Trust Legal Provisions and reverse
geocoding location formats by this document. are provided without
warranty as described in the BSD License.

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 [RFC 2119].

1. Introduction

Many devices are starting to use location in one of many formats,
but not always the same format. The most common of these formats is
civic location (defined by RFC 4119 & 4776) and geodetic
(coordinate) location (like GPS). Various arguments have been made
to have all devices choose one format - and move forward with that.

This is like choosing one signaling protocol for voice or file
transfer. These two will remain to have multiple choices document creates a URN for years
(decades?) to come. Location formats probably is no different.

In the interim, i.e., before one format is chosen to solve
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 transformations 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 used by LoST
(Location-to-Service Translation Protocol) [RFC5222] can be used to accomplish this conversion. The
service [RFC5222]. Today, the
most obvious transformation using LoST is converting coordinate from one location format
to civic addressing,
called geocoding, and converting civic addressing to geodetic
location, called reverse-geocoding. another. Within each LoST request, there 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 provided,
along with a service is identified by URN the requester by a URN. The LoST server
then determines uses to determine which URI is appropriate for that service within
that location. LoST servers need
to accept give in the LoST response, based on the location of the
requester. Fundamentally, LoST handles most locations - most likely
in both the
civic and geodetic formats, thus LoST servers are and civic formats [RFC4119]. It seems only
logical to convert ask the LoST server, who likely has both location formats
loaded, to transform one location format to another.

This document specifies how the other format.

Transforming a geodetic coordinate pair to a civic location plus address
is called geocoding. The reverse, transforming a service identifier
wishes to receive back civic address into
a converted location, and not geodetic coordinate pair is called reverse-geocoding. If a URI to be
contacted.

To accomplish LoST
server does not have both formats present for this service, transformation,
but knows of a new service URN has remote server to be created contact for
each type of conversion. The end device performs a such an operation, the
LoST request
with its non-preferred location format it possesses, with server returns the URN URI of that remote server in the type of conversion LoST
response, leaving it wants, and the response will contain to the
converted location.

2. Transformations URN host to request this conversion of
formats. This document creates latter operation will likely not be done using LoST,
but rather a URN for transformations, protocol such 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 HTTP(S). 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.

3. does not
specify how this latter transaction occurs.

2. One Transaction Verses Two

Strictly speaking, LoST is about including a URN of a service, and
the location of the requester in a request message, and getting a
response message that includes the URI of who the original requester
needs to contact for that service. In some cases, for
transformations, a LoST server can possess both versions multiple formats of the
same information. This is most true for location information in two
different formats. If a user wants to convert, or transform one
location format to another, it can ask a LoST server for who to
contact to make this conversion or transformation. On the other
hand, and within the same LoST request (implicit or explicit), if it can
convert one
the LoST server has both formats of the same location format - it should be
able to another. 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, cannot perform this transformation, or is
unwilling to, the LoST reply will response should include only the URI of the
server to be connected for this conversion. transformation.

With this as a background, here are two possibilities for a LoST
query for location transformation:

Option #1 - For LoST servers that have the transformation
information local to it, or otherwise chooses to have a
single LoST transaction fulfill the transformation
request, the response can have the transformation in the
response.

Option #2 - For time in which a LoST server does not have the
transformation information local (or decides it does not
want to go fetch the information requested for a single
LoST transaction with the requester), or otherwise does
not want to provide this transformation information in a
single transaction - the LoST server can merely provide
a URI of the server that can answer this transformation
query in the LoST response.

4. Registration of Template

TBD (and will follow

This document leaves it up to the rules according implementation to RFC 3406 [RFC3406])

5. Examples decide which way
it wants to go - of the 2 choices above.

If a transformation cannot be performed by the LoST Request and Response

TBD

(will show server, the
response SHOULD contain the URI of where to contact that can do this
service, or provide an error indicating it cannot.

3. Transformations URN

This document creates the service URN for transformations to be used
by the LoST protocol, as shown here:

urn:service:transformations

This URN is for converting a dissimilar values meaning the same
thing into another format, perhaps to a specified format, based on
the LoST query containing geodetic request. For example, transforming civic location and geocode format
value into a coordinate pair location format value.

3.1 Sub-Services for the 'transformation' Service

This section defines the transformation service URN, and return 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 civic location)

6. 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
that in RFC 5222, the LoST specification, or in RFC 5031, the URN
Services specification.

6. IANA considerations

TBD

6.1. Sub-Services for the 'transformation' Service

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
Newton and Hannes Tschofenig for the useful comments.

8. References

9.1.

8.1. Normative References

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997

[RFC5222] T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig, "LoST:
A Location-to-Service Translation Protocol", RFC 5222,
August 2008

[RFC3406] L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom, "Uniform
Resource Names (URN) Namespace Definition Mechanisms", RFC
3406, October 2002

[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005

[RFC4776] H. Schulzrinne, " Dynamic "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ",
Information", RFC 4776, November 2006

[RFC5031] H. Schulzrinne, "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008

9.2.

8.2. Informative References

[]

[none]

Authors' Addresses

James Polk
3913 Treemont Circle
Colleyville, Texas, USA
+1.817.271.3552

mailto: jmpolk@cisco.com