[email protected]
[Top] [All Lists]

Re: [Ecrit] LoST Review

Subject: Re: [Ecrit] LoST Review
From: Hannes Tschofenig
Date: Thu, 01 Feb 2007 11:14:06 -0500
Hi Patrik,

thank your for your review comments. I will try to address some of them below:

Marc Linsner wrote:
Hannes and I asked Patrik Falstrom to review the LoST/Mapping Arch
drafts....here is the first of his comments.....

-----Original Message-----
From: Patrik Fältström [mailto:[email protected]] Sent: Wednesday, January 31, 2007 9:13 AM
To: Marc Linsner
Cc: [email protected]; 'Hannes Tschofenig'
Subject: Re: ECRIT help please?

First of all, I read documents serially. So, some concern I have had might
be resolved later on. Because of that, read my comments from top to bottom
and interpret as I have not seen what is below the comment.

            LoST: A Location-to-Service Translation Protocol


   This document describes an XML-based protocol for mapping service
   identifiers and geodetic or civic location information to service
   contact URIs.  In particular, it can be used to determine the
   location-appropriate PSAP for emergency services.

FYI: I have always been nervous when using as an index something that is a
well known abstraction of a location, such as a civic location. My argument all the time has been that the most important piece of the
puzzle is that "the device" have some kind of identifier that later can be
mapped to a PSAP. Secondly (and not the same, note that) that the device can
send information to the PSAP so that the PSAP can (at least in Sweden) (a)
locate the device and (b) reinitiate the connection if the communication

I have seen too many discussions in ECRIT where the two uses of "the
location" (the routing issue, and the data that is sent to the PSAP) is
claimed to be the same.

Anyway... You have heard me saying this before :-)

I am not sure about this comment. I think you need to provide more backgroup regarding your question.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Terminology and Requirements
Notation  . . . . . . . . . . . .  6
   3.  Overview of Protocol
Usage . . . . . . . . . . . . . . . . . .  7
4. LoST Uniform Resource Locators and Their Resolution . . . . . 8
   5.  The <mapping>
Element  . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Data source and version: The 'source', 'sourceId' and
'version' Attributes . . . . . . . . . . . . . . . . . . . 9 5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9 5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9 5.4. Describing the Service with the <displayName> Element . . 10 5.5. The Mapped Service: the <service> Element . . . . . . . . 10
     5.6.  Defining the Service Region with the <serviceBoundary>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.7.  Service Boundaries by Reference: the
<serviceBoundaryReference> Element . . . . . . . . . . . . 11
     5.8.  The Service
Number . . . . . . . . . . . . . . . . . . . . 11
     5.9.  Service URLs: the <uri>
Element  . . . . . . . . . . . . . 11
   6.  Path of Request:  <path>
Element . . . . . . . . . . . . . . . 12
7. Mapping a Location and Service to URLs: <findService> . . . . 13 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 13 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 14 7.3. Components of the <findService> Request . . . . . . . . . 16
       7.3.1.  The <location>
Element . . . . . . . . . . . . . . . . 16
7.3.2. Identifying the Service: The <service> Element . . . 17 7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 17
       7.3.4.  Service
Boundary . . . . . . . . . . . . . . . . . . . 17
7.3.5. Requesting Civic Location Validation . . . . . . . . . 17
     7.4.  Components of the Mapping Response
<findServiceResponse> . . . . . . . . . . . . . . . . . . 19 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 19
       7.4.2.  Civic Address Validation:  the
Element . . . . . . . . . . . . . 20
8. Retrieving the Service Boundary via <getServiceBoundary> . . . 21 9. List Services: <listServices> . . . . . . . . . . . . . . . . 24 10. List Services By Location: <listServicesByLocation> . . . . . 25
   11. Location
Profiles  . . . . . . . . . . . . . . . . . . . . . . 27

Hardie, et al. Expires July 21, 2007 [Page 2] Internet-Draft LoST January 2007

     11.1. Location Profile
Usage . . . . . . . . . . . . . . . . . . 28
     11.2. Two Dimensional Geodetic
Profile . . . . . . . . . . . . . 30
     11.3. Basic Civic
Profile  . . . . . . . . . . . . . . . . . . . 31
   12. Errors, Warnings, and
Redirects  . . . . . . . . . . . . . . . 32
12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 34
   13. LoST
Transport . . . . . . . . . . . . . . . . . . . . . . . . 35
   14. Relax NG
Schema  . . . . . . . . . . . . . . . . . . . . . . . 36
   15. Internationalization
Considerations  . . . . . . . . . . . . . 43
   16. IANA
Considerations  . . . . . . . . . . . . . . . . . . . . . 44
     16.1. U-NAPTR
Registrations  . . . . . . . . . . . . . . . . . . 44
     16.2. Content-type registration for 'application/lost
+xml' . . . 44
     16.3. LoST Relax NG Schema
Registration  . . . . . . . . . . . . 46
     16.4. LoST Namespace
Registration  . . . . . . . . . . . . . . . 46
     16.5. URL Registration
Template  . . . . . . . . . . . . . . . . 47
     16.6. LoST Location Profile
Registry . . . . . . . . . . . . . . 48
   17. Security
Considerations  . . . . . . . . . . . . . . . . . . . 49
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
   19. Open
Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 52
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
     20.1. Normative
References . . . . . . . . . . . . . . . . . . . 53
     20.2. Informative
References . . . . . . . . . . . . . . . . . . 54
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 Intellectual Property and Copyright Statements . . . . . . . . . . 70

Hardie, et al. Expires July 21, 2007 [Page 3] Internet-Draft LoST January 2007

1.  Introduction

   This document describes a protocol for mapping a service identifier
   [10] and location information compatible with PIDF-LO [8], namely
revised civic location information [11] and GML [13]) to one or more
   service URL.  Example service URL schemes include sip [14], xmpp
[15], and tel [16]. While the initial focus is on providing mapping
   functions for emergency services, it is likely that the protocol is
   applicable to any service URN.  For example, in the United States,
   the "2-1-1" and "3-1-1" service numbers follow a similar
   service behavior as emergency services.

   This document names this protocol "LoST", for Location-to-Service
   Translation.  LoST Satisfies the requirements [18] for mapping
   protocols.  LoST provides a number of operations, centered around
   mapping locations and service URNs to service URLs and associated
   information.  LoST mapping queries can contain either civic or
   geodetic location information.  For civic addresses, LoST can
   indicate which parts of the civic address are known to be valid or
   invalid, thus providing address validation (see Section 3.5 of [18]
   for a description of validation).  LoST indicates errors in the
   location data to facilitate debugging and proper user feedback, but
   also provides best-effort answers.

LoST queries can be resolved recursively or iteratively. To minimize round trips and to provide robustness against network failures, LoST
   caches individual mappings and indicates the region for which the
   same answer would be returned ("service region").

Hmm...so LoST include caching. This is the first thing I think one should
look at. Who defines the appropriate caching time? Do you need notifications
for emergency updates? Etc?

Henning provided an answer for this one already. The caching aspect in LoST refers to the mapping. When a resolver is unable to interact with an authoritive server due to, for example, intermitted connectivity then it can use the cached mapping. The lifetime of the cached mapping is set by the authoritive server.

   As defined in this document, LoST messages are carried in HTTP and
HTTPS protocol exchanges, facilitating use of TLS for protecting the
   integrity and confidentiality of requests and responses.

Oh, no! Not HTTP again!!! Why? Also, you can not rely on client certificates
or other mechanisms for the authentication of the client sending the query.
You need another layer of username/password/ whatever on top of TLS. TLS is
usable for the encryption of the traffic, but not (much) more.
There is nothing wrong with HTTP. It is possible to define other bindings for LoST but at the moment we stick with HTTP.

Regarding the security mechanisms. We assume that server-side authentication and that works with TLS perfectly fine. For client-side authentication TLS can also be used but we assume that the client will typically not be authenticated by the LoST server since it does not provide a particular advantage. For the resolver to a Forest Guide TLS with client-side authentication can be used and there is no big magic about it. Both pre-shared secret and asymmetric cryptography can be used for that purpose.

Also, if a SIP proxy runs the LoST clients towards a LoST resolver then mutual TLS based authentication can be used without major problems particularly when someone considers an architecture similarly to the one envisioned by the 3GPP or ETSI TISPAN right now.

This implies to me that the payload that is moved with the HTTP protocol
have to include enough signatures, passwords, usernames and possibly
encryption to handle the authentication and authorization of the LoST

There might be a need to sign individual XML elements at the LoST layer but this is not described at the moment. This might be useful when dealing with forged LoST location->PSAP service area mappings.

Lets see below how this problem is resolved.

This document focuses on the description of the protocol between the mapping client (seeker or resolver) and the mapping server (resolver or other servers). The relationship between other functions, such as
   discovery of mapping servers, data replication and the overall
   mapping server architecture are described in a separate document

   The query message carries location information and a service
   identifier encoded as a Uniform Resource Name (URN) (see [10]) from
   the LoST client to the LoST server.  The LoST server uses its
   database to map the input values to one or more Uniform Resource
   Identifiers (URI) and returns those URIs along with optional
information, such as hints about the service boundary, in a response
   message to the LoST client.  If the server cannot resolve the query
itself, it may in turn query another server or return the address of

Hardie, et al. Expires July 21, 2007 [Page 4] Internet-Draft LoST January 2007

   another LoST server, identified by a LoST URL (Section 4).

I am a little bit nervous about the fact that the server can either give back a referral OR do a recursive query. For the client the difference is of course that all clients MUST implement the ability to handle referrals, but on the other hand, the ability for a server to query another server might not have to be in this document. Why is that needed? Because it is needed to know wether the data comes from an authoritative source? Or "just" because it imitates the way DNS works?

We'll see.
Henning responded to this issue already.

addition to the mapping function described in Section 7, the protocol
   also allows to retrieve the service boundary (see Section 8) and to
   list the services available for a particular location (see
   Section 10) or supported by a particular server (see Section 9).

Hardie, et al. Expires July 21, 2007 [Page 5] Internet-Draft LoST January 2007

2.  Terminology and Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [1].

   This document furthermore uses the terminology defined in [18].

"Warning" :-) I have not read this [18] document.

Hardie, et al. Expires July 21, 2007 [Page 6] Internet-Draft LoST January 2007

3.  Overview of Protocol Usage

   The client may perform the mapping at any time.  Among the common
   triggers for mapping requests are:

   1.  When the client initially starts up or attaches to a network.

   2.  When the client detects that its location has changed
sufficiently that it is outside the bounds of the service region
       returned in an earlier LoST query.

   3.  When cached mapping information has expired.

   4.  When invoking a particular service.  At that time, a client may
       omit requests for service boundaries or other auxiliary

   A service-specific Best Current Practice (BCP) document, such as
   [20], governs whether a client is expected to invoke the mapping
service just before needing the service or whether to rely on cached
   answers.  Cache entries expire at their expiration time (see
   Section 5.3), or they become invalid if the caller's device moves
   beyond the boundaries of the service region.

Hardie, et al. Expires July 21, 2007 [Page 7] Internet-Draft LoST January 2007

4.  LoST Uniform Resource Locators and Their Resolution

LoST servers are identified by LoST Uniform Resource Locators (URLs),
   which follow the format of URLs defined in RFC 3986 [7], with the
   following ABNF:

      LoST-URI = "lost:" host

   'host' is defined in Section 3.2.2 of RFC 3986 [7].

   An example is 'lost:lostserver.example.com'

Have this URI spec been reviewed on the URI-review list? If not, I urge you to pass it on asap.

That's a good hint. I will do that.

If a LoST URL contains a host name rather than an IP address, clients
   need to use U-NAPTR [12] using the U-NAPTR specification described
   below to obtain a URI (indicating host and protocol) for the
   applicable LoST service.  In this document, only the HTTP and HTTPS
   URL schemes are defined.  Note that the HTTP URL can be any valid
   HTTP URL, including those containing path elements.

The following two DNS entries resolve the LoST URL "lost:example.com" to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL
   http://lostserver.example.com, with the former being preferred.

(1) Please use the same examples all the time. Above you use the example lostserver.example.com, and now example.com.

(2) Why do you not only use SRV records for this as lost is only defined for HTTP/HTTPS?

lost:example.com -> _lost._tcp.example.com:80

I do not see any need for NAPTR records, unless LOST can be used with some other protocol than HTTP. That is though not what it seems the overall design is for.

I.e. possible over-engineering for an abstraction that in reality is not, and will never, be used.

I don't think it is a too complex design. Furthermore, in the beginning we also spoke about other LoST bindings.


       IN NAPTR 100  10   "u"    "LoST:https"
            "!*.!https://lostserver.example.com/secure!";  ""

       IN NAPTR 200  10   "u"    "LoST:http"
            "!*.!http://lostserver.example.com!";  ""

How do the end device get the LOST URL?

Hardie, et al. Expires July 21, 2007 [Page 8] Internet-Draft LoST January 2007

5.  The <mapping> Element

The <mapping> element is the core data element in LoST, describing a
   service region and the associated service URLs.  Its parameters
indicate when the mapping was last updated, how long it is valid, its
   version and the authoritative source for the mapping, along with a
   unique identifier.  Elements within the <mapping> element then
   provide a human-readable description, the service URN, a service
   boundary, the service URIs, and a service number.  All elements
   except the service URN are optional.

Are really all elements optional? sourceId, version, and source attributes as well?

This draft contain a lot of words. Not as crisp as I would like to see a protocol specification. Why for example does the above paragraph point out "...provide a human-readable description..." etc, and then the first thing that happen below in 5.1 is that it talks about "Data source and version". Attributes that are not mentioned above?

Improving readability is a good thing. We should probably shorten the above paragraphs to avoid too much repetition.

  Below, we describe the
   components in turn.

Unnecessary text.

5.1.  Data source and version: The 'source', 'sourceId' and 'version'

The 'source', 'sourceId' and 'version' attributes uniquely identify a
   particular mapping record.  They are created by the authoritative
source for a mapping and never modified when a mapping is served from a cache. The 'source' attribute contains a LoST URL identifying the
   authoritative generator of the mapping.  The 'sourceId' attribute
   identifies a particular mapping.

Should not the URI definition include the ability to also include the sourceId and version in the URI?

Else you will not be able to get a URI for the record itself, and I think that would be an opportunity that should not be missed.

   The attribute contains a token,
   which is opaque, but MUST be unique among all different mappings
   maintained by the authoritative source for that particular service.

"The attribute" that this sentence talks about, is that the "sourceId" attribute? Not clear.

Why btw are several attributes in the same section of the spec? Better with one attribute per section and a crisp short definition of that attribute.

In previous versions of the document we had each attribute and each element in a separate subsection. Unfortunately, it does not well describe the relationship between the elements that really belong together. Hence, we changed the style a bit.

For example, a UUID is a suitable format. The 'version' attribute is a positive integer that is incremented by one for each change in the

So if the difference between two records I happen to have is 4, there MUST have been that number of versions in between? It is unclear in this text as no MUST, SHOULD etc is in use if this increment of one is mandatory or not. Makes the protocol unclear and might lead to incompatible implementations.

   Thus, a higher version number refers to a more recent
   mapping.  A mapping maintains its sourceId value as long as it
   remains logically the same, e.g., represents the same service
boundary or replaces an earlier service boundary. A receiver should

Lower case "should" here...

   be able to replace a mapping with another one having the same
   'source' and 'sourceId' and a higher version number.  All three
   attributes are REQUIRED for all <mapping> elements.

This is not what section 5 said above.

You have an attack vector if someone manage to spoof a record into a cache with a version number that is extremely high. How large can this version number be?

5.2.  Time of Last Update: The 'lastUpdated' Attribute

   The 'lastUpdated' attribute describes when the mapping was last
   changed.  The contents of this attribute is a timezoned XML type
   dateTime, in canonical representation.  The attribute is REQUIRED.

Note that according to of http://www.w3.org/TR/2001/REC- xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong source) the canonical representation of a time is always in UTC, so the timezoned canonical version will always have 'Z' as the timezone indicator.

This is what you want?

We probably should be explicit that the canonical representation is UTC with the 'Z' as the timezone indicator.
5.3.  Validity: The 'expires' Attribute

   The 'expires' attribute contains the absolute time until which the
   mapping is to be considered valid.

Does not "expires" contain the dateTime spec of when the mapping is changing state from valid to not valid? The text above to me seems to be the reverse.

Henning indicated that it might be good to change the text. That's fine with me.

   The contents of this attribute is
   a timezoned XML type dateTime, in canonical representation.  See
   Section 3 regarding how this value is to be utilized with a cache.
   The 'expires' attribute is REQUIRED to be included in the <mapping>

Hardie, et al. Expires July 21, 2007 [Page 9] Internet-Draft LoST January 2007

On occasion, a resolver may be forced to return an expired mapping if
   it cannot reach the authoritative server or the server fails to
return a usable answer. Seekers and resolvers MAY cache the mapping
   so that they have at least some information available.  Resolvers
   SHOULD re-attempt the query each time a seeker requests a mapping.

I think you should try to only use the terms "client" and "server" throughout the document when you talk about the protocol. We already know that a server can act as a proxy, and then act as a client.

Try to not use the term "resolver". Experience from the DNS show it is a confusing term.

Good hint

5.4.  Describing the Service with the <displayName> Element

The <displayName> element describes the service with a string that is
   suitable for display to human users, annotated with the 'xml:lang'
   attribute that contains a language tag to aid in the rendering of

Why is lang tag needed for the rendering? Because of alternate displayName elements with different lang tags?

As indicated by Henning people in the working group believed that the text will be different in different regions and potentially multiple versions might be returned.

5.5.  The Mapped Service:  the <service> Element

Here you start talking about elements and not attributes. That is confusing.

   The 'service' element identifies the service for which this mapping
   applies.  It is usually the same service URN as in the request.

Usually? That is an interesting term to have in a protocol specification... :-)

We will remove it.

However, if the requested service, identified by the service URN [10]
   in the <service> element in the request, does not exist for the
   location indicated, the server can either return an
   <serviceNotImplemented> (Section 12.1) error or can provide an
   alternate service that approximates the desired service for that

But if the response is <serviceNotImplemented>, is that "error" part of the <service> element? We talk about the content of the <service> element here, and I see either the URN of the service, or the URN of an alternative service. Not a third alternative.

Once again, not crisp enough, risk that the result is non- interoperable implementations.

   In the latter case, the server MUST include a <service>
element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request. The <service> element may also
   be required if the mapping is to be digitally signed.

Resolvability of that URN? It is not a lost URL that is given back so it is a referral within the protocol?

The service element contains a URN based on the service URN document. It is not meant to be resolved into something else.

5.6.  Defining the Service Region with the <serviceBoundary> Element

Element and not attribute again.

A response can indicate the region for which the service URL returned
   would be the same as in the actual query, the so-called _service

What is "can" in this sentence? What does that word imply? That it might not indicate the same region as in the actual query?

   The service region can be indicated by value or by
   reference (see Section 5.7).  If a client moves outside the service
   area and wishes to obtain current service data, it MUST send a new
   query with its current location.

It is interesting to have "if...wishes...MUST" in the same sentence. What if he do not wish to obtain current service data? I.e. the "if" make the MUST loose its power.

This sentence should be removed since this aspect is covered in the Phone BCP document.

   The service region is described by
   value in one or more <serviceBoundary> elements, each formatted
   according to a different location profile, identified by the
   'profile' atribute.

Change the order of the attributes...to me it seems this is a forward reference to "profile" attribute that btw is not defined in section 5.

The profile attribute is not described in Section 5. That's true.
We have designated a separate section for the aspect of location profiles in Section 11.

It might not hurt to put a reference to Section 11 in there.

   The client only processes the first element that
   it can understand according to its list of supported location
   profiles.  Thus, the elements are alternative descriptions of the
   same service region, not additive geometries.

What if there is a difference? Is a difference allowed?

That's something that has to be described in the Phone BCP for emergency services.
Not in this document since it is application specific.

The server returns all suitable service regions, using all available location profiles, so that intermediate caches have this information
   available for future queries.

Is "suitable" same as "match the query"?

Hardie, et al. Expires July 21, 2007 [Page 10] Internet-Draft LoST January 2007

5.7.  Service Boundaries by Reference: the <serviceBoundaryReference>

Since geodetic service boundaries may contain thousands of points and
   thus be quite large,

Can it? Hmmm....(reader start to think here)...yes it can! :-)

   clients may opt to conserve bandwidth and
   request a reference to the service boundary instead of the value
described in Section 5.6. The identifier of the service boundary is
   returned as an attribute of the <serviceBoundaryReference> element,
   along with a LoST URL identifying the server from where it can be

Should the reference not be "just" a URL? (See above)

You mean " A URL instead of a LoST URL"?

   The actual value of the service boundary is then
   retrieved with the getServiceBoundary (Section 8) request.

   The identifier is a random token with at least 128 bits of entropy
   and can be assumed to be globally unique.  It uniquely references a
particular boundary. If the boundary changes, a new identifier MUST be chosen. Because of these properties, a client receiving a mapping
   response can simply check if it already has a copy of the boundary
   with that identifier.

Should the reference then not be a URL plus an identifier?

Currently, the structure is as follows:

     key="7214148E0433AFE2FA2D48003D31172E" />

The identifier is in a separate attribute.

   If so, it can skip checking with the server
whether the boundary has been updated. Since service boundaries are
   likely to remain unchanged for extended periods of time, possibly
   exceeding the normal lifetime of the service URL, this approach
avoids refreshing the boundary information even if the cached service
   response has gotten stale.

...even if the URL changes for the object.

5.8.  The Service Number

Element or attribute?


Has to be added.

   The service number is returned in the optional <serviceNumber>

Aha, element!

   It contains a string of digits, * and # that a user on a
   device with a 12-key dial pad could use to reach that particular

Reference a syntax specification. Max 15 char in the string as in E.164?

5.9.  Service URLs: the <uri> Element

The response returns the service URLs in one or more <uri> elements.
   The URLs MUST be absolute URLs.  The ordering of the URLs has no
   particular significance.  Each URL scheme MUST only appear at most
   once, but it is permissible to include both secured and regular
versions of a protocol, such as both 'http' and 'https' or 'sip' and

How to handle load balancing, or the fact two PSAPs might cover the same area?

Does that NEVER happen?

Did this document not say earlier that all matching service areas (and for me because of that srevice URLs) should be returned that matches? This "one scheme only" to me say that the server must choose "the best one", which seems weird. Or am I confused?

We had a discussion about load balancing here. See http://www.tschofenig.com:8080/lost/issue9. After the discussion the person that initially proposed it decided to withdraw the issue.

Hardie, et al. Expires July 21, 2007 [Page 11] Internet-Draft LoST January 2007

6.  Path of Request:  <path> Element

To prevent loops and to allow tracing of request and response paths,
   all requests that allow recursion include a <path> element that
   contains one or more <via> elements, each possessing an attribute
   containing a LoST URL.  The order of <via> elements corresponds to
   the order of LoST servers, i.e., the first <via> element identifies
   the server that first received the request from the seeker.  The
   authoritative server copies the <path> element verbatim into the

I don't know enough about XML to say whether this ordering is ok or not. This is the first time ordering among elements exists in this spec though.
The order matters here in order to determine which server was traversed first.

If a query is answered iteratively, the querier includes all servers
   that it has already contacted.

   The example in Figure 5 indicates that the answer was given to the
   responding server by the LoST server at esgw.ueber-110.de.example,
   which got the answer from the LoST server at

This is also sent in a request? How else can one prevent loops if a server is acting as a client and do a recursive search, walking into servers that the originator already have queried?

I don't understand exactly how this can help with loop prevention. Just how it can help loop detection on the client side. If it is not passed also in requests.

Hardie, et al. Expires July 21, 2007 [Page 12] Internet-Draft LoST January 2007

7.  Mapping a Location and Service to URLs: <findService>

7.1.  Overview

   The <findService> query constitutes the core of the LoST
   functionality, mapping civic or geodetic locations to URLs and
associated data. After giving an example, we enumerate the elements
   of the query and response.

7.2.  Examples

7.2.1.  Example Using Geodetic Coordinates

The following is an example of mapping a service to a location using
   geodetic coordinates, for the service associated with the police

   <?xml version="1.0" encoding="UTF-8"?>

     <location profile="geodetic-2d">
       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
          <p2:pos>37.775 -122.422</p2:pos>


                 Figure 2: A <findService> geodetic query

   Given the query above, a server would respond with a service, and
   information related to that service.  In the example below, the
   server has mapped the location given by the client for a police
service to the New York City Police Deparment, instructing the client
   that it may contact them via the URIs "sip:[email protected]" and
   "xmpp:[email protected]".  The server has also given the client a
geodetic, two-dimensional boundary for this service. The mapping was
   last updated on November 1, 2006 and expires on January 1, 2007.
   This instructs the client that if its location changes beyond the
   give service boundary or the expiration time has been reached, it
   would need to requery for this information.

Does "lastUpdated" imply that it is correct from that point in time? To me that is not crystal clear. One might update a record one month ahead of a move for example.

Hardie, et al. Expires July 21, 2007 [Page 13] Internet-Draft LoST January 2007

   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
       sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
       <displayName xml:lang="en">
         New York City Police Department
       <serviceBoundary profile="geodetic-2d">
         <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
               <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>
       <uri>sip:[email protected]</uri>
       <uri>xmpp:[email protected]</uri>
       <via source="lost:authoritative.example"/>
       <via source="lost:resolver.example"/>

             Figure 3: A <findServiceResponse> geodetic answer

7.2.2.  Civic Address Mapping Example

   The following is an example of mapping a service to a location much
   like the example in Section 7.2.1, but using civic address location
   information.  In this example, the client requests the service
associated with police (urn:service:sos.police) along with a specific
   civic address (house number 6 on a street named Otto-Hahn-Ring in
   Munich, Germany).

Hardie, et al. Expires July 21, 2007 [Page 14] Internet-Draft LoST January 2007

   <?xml version="1.0" encoding="UTF-8"?>
   <findService xmlns="urn:ietf:params:xml:ns:lost1"
     recursive="true" serviceBoundary="value">

               Figure 4: A <findService> civic address query

   Given the query above, a server would respond with a service, and
   information related to that service.  In the example below, the
   server has mapped the location given by the client for a police
   service to the Muenchen Polizei-Abteilung, instructing the client
   that it may contact them via the URIs sip:[email protected]
   and xmpp:[email protected]  The server has also given the
   client a civic address boundary (the city of Munich) for this
   service.  The mapping was last updated on November 1, 2006 by the
   authoritative source "lost:polizei.muenchen.de.example" and expires
   on January 1, 2007.  This instructs the client to requery for the
information if its location changes beyond the given service boundary
   (i.e., beyond the city of Munich) or after January 1, 2007.

Hardie, et al. Expires July 21, 2007 [Page 15] Internet-Draft LoST January 2007

   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
       sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" >
       <displayName xml:lang="de">
         Muenchen Polizei-Abteilung
       <uri>sip:[email protected]</uri>
       <uri>xmpp:[email protected]</uri>
       <via source="lost:esgw.ueber-110.de.example"/>
       <via source="lost:polizei.muenchen.de.example"/>

          Figure 5: A <findServiceResponse> civic address answer

7.3.  Components of the <findService> Request

The <findService> request includes attributes that govern whether the
   request is handled iteratively or recursively, whether location
   validation is performed and which elements must be contained in the

7.3.1.  The <location> Element

   The <findService> query communicates location using one or more
   <location> elements, which MUST conform to a location profile (see
   Section 11).  There MUST be no more than one location element for
   each distinct location profile.  The order of location objects is
   significant; the server uses the first location object where it
   understands the location profile.

Ok, more ordering here. I presume that is ok...

Using the first it understand is good.

Hardie, et al. Expires July 21, 2007 [Page 16] Internet-Draft LoST January 2007

7.3.2.  Identifying the Service:  The <service> Element

   The type of service desired is specified by the <service> element.
   It contains service URNs from the registry established in [10].

7.3.3.  Recursion

   LoST <findService> and <listServicesByLocation> queries can be
   recursive, as indicated by the 'recursive' attribute.  A value of
   "true" indicates a recursive query, with the default being "false"
   when the attribute is omitted.  In recursive mode, the LoST server
   initiates queries on behalf of the requester and returns the result
   to the requester, inserting a <via> element to track the response
   chain.  The <via> elements are appended in responses in order of
   visit, i.e., the first <via> element contains the authoritative
   server and <via> elements below indicate servers that the response
   traversed on its way back to the original querier.

Do you need time stamps on the via headers?

7.3.4.  Service Boundary

   LoST <mapping> elements can describe the service boundary either by
   value or by reference.  Returning a service boundary reference is
   generally more space-efficient for geospatial (polygon) boundaries
   and if the boundaries change rarely, but does incur an additional
   <getServiceBoundary> request.  The querier can express a preference
for one or the other modality with the 'serviceBoundary' attribute in the <findService> request, but the server makes the final decision as
   to whether to return a reference or a value.  Servers SHOULD NOT
   return a by-value service boundaries if the querier requested a

7.3.5.  Requesting Civic Location Validation

   Civic address validation is requested by setting the optional
   attribute 'validateLocation' to true.  If the attribute is omitted,
   it is assumed to be false.  The response is described in
   Section 7.4.2.  The example in Figure 6 demonstrates address
   validation, omitting the standard response elements.

Hardie, et al. Expires July 21, 2007 [Page 17] Internet-Draft LoST January 2007

   <?xml version="1.0" encoding="UTF-8"?>
     <location profile="civic">

      Figure 6: A <findService> query with address validation request

Hardie, et al. Expires July 21, 2007 [Page 18] Internet-Draft LoST January 2007

   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
       version="1" >
       <displayName xml:lang="de">
         Muenchen Polizei-Abteilung
       <serviceBoundary profile="civic">
       <uri>sip:[email protected]</uri>
       <uri>xmpp:[email protected]</uri>
       <valid>country A1 A3 A6</valid>
       <via source="lost:authoritative.example"/>
       <via source="lost:resolver.example"/>

     Figure 7: A <findServiceResponse> message with address validation

I stopped here, as the findServiceResponse needed a lot of thinking. I do not have that before monday next week.

Thanks for the review.



Ecrit mailing list
[email protected]

Ecrit mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>