LoST
draft-ietf-ecrit-lost-02
ECRIT Working Group
IETF 67
7 November 2006
Andrew Newton
Henning Schulzrinne
Hannes Tschofenig
Ted Hardie
Request/Response Pattern
• XML was refactored so that every
request has a corresponding reply.
• 3 types of requests, 3 type of replies.
– <findService> -> <findServiceResponse>
– <listServices> -> <listServicesResponse>
– <getServiceBoundary> ->
<getServiceBoundaryResponse>
Find Service Include Attribute
• Enables the clients to specify the information
they wish returned.
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true"
include="serviceBoundary invalid valid unchecked">
<location
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Neu Perlach</A6>
<HNO>96</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
Validation Response Example
(current draft XML)
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
<serviceBoundary profile=”
urn:ietf:params:lost:location-profile:civic">
<civicAddress xmlns=”
urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked/>
</findServiceResponse>
Service Boundary References
• Clients indicate their preference for a
reference with the include attribute:
– Contains either serviceBoundary or
serviceBoundaryReference
• They then use the
<getServiceBoundary> request to
obtain the service boundary if they need
it.
Address Validation
• 3 indicators
– <valid> - elements with valid content
– <invalid> - elements with invalid content
– <unchecked> - elements that were not used in the
address validation process.
• Clients use the include attribute to specify
which indicators they wish to see:
– include=‘invalid valid unchecked’
Location Profiles
• Clients and servers denote how they are
expressing location using a location profile
ID.
– It is currently a URN, but will be changed to a
simple token (author team proposal).
• Multiple locations, each denoted by a location
profile ID, may be used in requests and
responses:
– <location> in requests
– <serviceBoundary> in responses
• Each location profile may contain multiple
XML elements from varying namespaces.
Location Profile Example
<findService xmlns="urn:ietf:params:xml:ns:lost1”
xmlns:p2="http://www.opengis.net/gml"
recursive="true" include="uri serviceNumber">
<location profile="urn:ietf:params:lost:location-profile:geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<location profile="urn:ietf:params:lost:location-profile:uber-complex-3d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>-122.422 37.775</p2:pos>
</p2:Point>
</location>
</findService>
MUST Implement Profiles
• Every server and client MUST implement two
baseline location profiles.
– Enables a response in all circumstances.
• “geodetic-2d”
– Client sends a GML position
– Server responds with a GML polygon
• “civic”
– Client sends draft-ietf-geopriv-revised-civic
– Server responds with draft-ietf-geopriv-revisedcivic
Definition of a Location Profile
1)
2)
3)
4)
The token identifying it in the LoST location profile
registry;
The formal definition of the XML to be used in requests,
i.e., an enumeration and definition of the XML child
elements of the <location> element;
The formal definition of the XML to be used in
responses, i.e., an enumeration and definition of the
XML child elements of the <serviceBoundary> element;
The declaration of whether geodetic-2d or civic is to be
used as the baseline profile. It is necessary to explicitly
declare the baseline profile as future profiles may be
combinations of geodetic and civic location information.
Basic Interaction Rules
1)
2)
3)
4)
5)
A client MUST be capable of understanding the response for
the baseline profiles it used in the request.
If a client sends location information conformant to any
location profile other than geodetic-2d or civic, it MUST also
send, in the same request, location information conformant to
one of the baseline profiles. Otherwise, the server might not
be able to understand the request.
Servers MUST implement the geodetic-2d and civic profiles.
A server ignores any location information using non-baseline
profiles it does not understand.
If a server receives a request that only contains location
information using profiles it does not understand, the server
responds with a <locationProfileError>.
Open Issues
• Error responses
– More streamlining to be done.
– Look for more changes to the XML.
• Time-To-Live
– Absolute vs. Relative
• ‘include’ attribute processing
– Minimum set vs. strict set.
– Impacts caching.
• Ordering of element names in <invalid>, <valid>, and
<unchecked>.
• Order preference of location profiles.
• Algorithm for adding <via>.
• Loosen service boundary key reference syntax.
• Signing of service boundaries.
– This is not location signing.
Errors vs. Warnings
(author team proposal)
• Separation of errors and warnings
– Errors contained in their own response
– Warnings packaged with query responses
• Interaction with SIP to be specified in another
document
– SIP/ECRIT chairs get to argue over who gets the
headache.
• Error example:
<errors source=“lost:example.com”>
<notFound message=“you may find what you are
looking for in the last place you search.” />
…
</errors>
Find Service Response/Warning Example
(author team proposal)
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping ttl=“1990-12-31T23:59:60Z”>
<displayName xml:lang="de">München Polizei-Abteilung</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile=”civic”>
<civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:[email protected]</uri>
<uri>xmpp:[email protected]</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<validation><unchecked/></validation>
<warnings>
<locationProfileUnrecognized profile=“martion-civic”/>
</warnings>
<via>lost:esgw.uber-110.de.example</via>
<via>lost:polizei.munchen.de.example</via>
</findServiceResponse>
Reasons for Change
(author team proposal)
• More context sensible errors/warnings.
• Enable insertion of data by resolvers, etc…
without modifying data from the authority.
– Should help caching implementation/performance.
• Absolute TTL and more modular elements to
accommodate future XML D-SIG work.
– But we aren’t doing XML D-SIG in this pass.
List Services Query
(author team proposal)
• In-line with Shida’s comment, there is a
difference between asking a local resolver
what services it supports and asking which
services are supported for a location.
– Query to make <location> optional to specify
which semantic is desired.
• Response to be similar to
<findServicesResponse>, with <services>
instead of <mapping>.