|
|
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:paf@xxxxxxxxx]
Sent: Wednesday, January 31, 2007 9:13 AM
To: Marc Linsner
Cc: leslie@xxxxxxxxxxxxxxx; '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 :-)
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
<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?
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
transaction.
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
[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.
Henning responded to this issue already.
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.
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.
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?
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'
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.
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
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?
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>
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.
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
text.
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
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?
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
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.
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>
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)
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:
<serviceBoundaryReference
source="lost:authoritative.example"
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?
Element
Has to be added.
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?
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
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.
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
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@xxxxxxxxxxx" and
"xmpp:nypd@xxxxxxxxxxx". 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@xxxxxxxxxxx</uri>
<uri>xmpp:nypd@xxxxxxxxxxx</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@xxxxxxxxxxx
and xmpp:munich-police@xxxxxxxxxxxx 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@xxxxxxxxxxx</uri>
<uri>xmpp:munich-police@xxxxxxxxxxx</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@xxxxxxxxxxx</uri>
<uri>xmpp:munich-police@xxxxxxxxxxx</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.
Thanks for the review.
Ciao
Hannes
Patrik
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|