[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] LoST Review
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:paf at cisco.com]
Sent: Wednesday, January 31, 2007 9:13 AM
To: Marc Linsner
Cc: leslie at thinkingcat.com; '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
> draft-ietf-ecrit-lost-03.txt
>
> Abstract
>
> 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
breaks.
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 :-)
> 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
> <locationValidation>
> 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
> location-to-
> 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?
> 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.
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
transaction.
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
> [19].
>
> 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.
> In
> 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",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
> 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
> information.
>
> 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.
> 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.
> example.com.
>
> 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?
> Below, we describe the
> components in turn.
Unnecessary text.
> 5.1. Data source and version: The 'source', 'sourceId' and 'version'
> Attributes
>
> 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.
> 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
> mapping.
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 3.2.7.2 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?
> 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.
> 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>
> element.
>
>
>
>
> 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.
> 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
> text.
Why is lang tag needed for the rendering? Because of alternate
displayName elements with different lang tags?
> 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... :-)
> 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
> location.
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?
> 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
> region_.
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.
> 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 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?
> 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>
> Element
>
> 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
> retrieved.
Should the reference not be "just" a URL? (See above)
> 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?
> 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?
> The service number is returned in the optional <serviceNumber>
> element.
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
> service.
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
> 'sips'.
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?
>
>
>
>
>
>
>
>
>
>
>
>
> 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
> response.
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.
> 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
> polizei.muenchen.de.example.
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
> (urn:service:sos.police).
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <findService
> xmlns="urn:ietf:params:xml:ns:lost1"
> xmlns:p2="http://www.opengis.net/gml";
> serviceBoundary="value"
> recursive="true">
>
> <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>
> <service>urn:service:sos.police</service>
>
> </findService>
>
> 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:nypd at example.com" and
> "xmpp:nypd at example.com". 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"
> xmlns:p2="http://www.opengis.net/gml";>
> <mapping
> expires="2007-01-01T01:44:33Z"
> lastUpdated="2006-11-01T01:00:00Z"
> source="lost:authoritative.example"
> sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
> <displayName xml:lang="en">
> New York City Police Department
> </displayName>
> <service>urn:service:sos.police</service>
> <serviceBoundary profile="geodetic-2d">
> <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>
> </serviceBoundary>
> <uri>sip:nypd at example.com</uri>
> <uri>xmpp:nypd at example.com</uri>
> <serviceNumber>911</serviceNumber>
> </mapping>
> <path>
> <via source="lost:authoritative.example"/>
> <via source="lost:resolver.example"/>
> </path>
> </findServiceResponse>
>
> 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">
> <location
> profile="civic">
> <civicAddress
> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
> <country>Germany</country>
> <A1>Bavaria</A1>
> <A3>Munich</A3>
> <A6>Otto-Hahn-Ring</A6>
> <HNO>6</HNO>
> <PC>81675</PC>
> </civicAddress>
> </location>
> <service>urn:service:sos.police</service>
> </findService>
>
> 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:munich-police at example.com
> and xmpp:munich-police at example.com. 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">
> <mapping
> expires="2007-01-01T01:44:33Z"
> lastUpdated="2006-11-01T01:00:00Z"
> source="lost:esgw.ueber-110.de.example"
> sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" >
> <displayName xml:lang="de">
> Muenchen Polizei-Abteilung
> </displayName>
> <service>urn:service:sos.police</service>
> <serviceBoundary
> 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>
> <PC>81675</PC>
> </civicAddress>
> </serviceBoundary>
> <uri>sip:munich-police at example.com</uri>
> <uri>xmpp:munich-police at example.com</uri>
> <serviceNumber>110</serviceNumber>
> </mapping>
> <path>
> <via source="lost:esgw.ueber-110.de.example"/>
> <via source="lost:polizei.muenchen.de.example"/>
> </path>
> </findServiceResponse>
>
> 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
> response.
>
> 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
> reference.
>
> 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"?>
> <findService
> xmlns="urn:ietf:params:xml:ns:lost1"
> recursive="true"
> validateLocation="true"
> serviceBoundary="value">
> <location profile="civic">
> <civicAddress
> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
> <country>DE</country>
> <A1>Bavaria</A1>
> <A3>Munich</A3>
> <A6>Otto-Hahn-Ring</A6>
> <HNO>6</HNO>
> <PC>81675</PC>
> </civicAddress>
> </location>
> <service>urn:service:sos.police</service>
> </findService>
>
> 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">
> <mapping
> expires="2007-01-01T01:44:33Z"
> lastUpdated="2006-11-01T01:00:00Z"
> source="lost:authoritative.example"
> sourceId="4db898df52b84edfa9b6445ea8a0328e"
> version="1" >
> <displayName xml:lang="de">
> Muenchen 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:munich-police at example.com</uri>
> <uri>xmpp:munich-police at example.com</uri>
> <serviceNumber>110</serviceNumber>
> </mapping>
> <locationValidation>
> <valid>country A1 A3 A6</valid>
> <invalid>PC</invalid>
> </locationValidation>
> <path>
> <via source="lost:authoritative.example"/>
> <via source="lost:resolver.example"/>
> </path>
> </findServiceResponse>
>
> Figure 7: A <findServiceResponse> message with address validation
> information
>
I stopped here, as the findServiceResponse needed a lot of thinking.
I do not have that before monday next week.
Patrik
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit