-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]
Sent: Tuesday, February 13, 2007 11:18 AM
To: ECRIT
Subject: [Ecrit] comments on LoST
Here are my comments on the latest version of LoST from SVN
(http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-
lost-04.txt).
I have several high level comments.
Firstly, the specification is somewhat confused about whether it is
specifying a data object (like a presence document), in which case the
semantics of the fields are critical, or whether it is specifying a
protocol, in which case state machines, transactions, timers, failures,
element behaviors, and so on, are relevant. I believe LoST is the latter
not the former, yet the spec is mostly written as if it was the former
and not the latter.
Secondly, I think the binding to http and https is not well specified,
and many important details (minimum baseline mandatory requirements,
timer considerations, usage of security techniques, pipelining, etc.)
are not discussed at all.
Thirdly, I have some concerns over the requirement for servers to
support both geodesic-2d and civic for all queries. IN particular, I
fear that it will be common for boundary objects to exist in only one
form or the other, and I don't see how conversion can easily be done
between the two.
More specific comments below:
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.
expand PSAP acronym
This document describes a protocol for mapping a service identifier
[10] and location information compatible with PIDF-LO [7], namely
revised civic location information [11] and GML [13])
missing open paren
While the initial focus is on providing mapping
functions for emergency services, it is likely that the protocol is
applicable to any service URN.
the first sentence mentions service identifiers but doesn't actually say
service URN. Suggest that you add in the first sentence:
"..for mapping a service identifier (in the form of a service URN [10]).."
Example service URL schemes include sip [14], xmpp
[15], and tel [16].
I'm gonna be a nit-picker and point out that these are actually URI and
not URL. That error occurs in many places in the document.
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.
might be good to mention what these are
This document names this protocol "LoST", for Location-to-Service
Translation. LoST Satisfies the requirements [18] for mapping
satisfies
THe last paragraph in the introduction repeats most of which is said
already above. I'll note it does so more clearly than the rest of the
intro. I suggest moving it up towards the front of the introduction.
Also, the introduction is missing an important point that is obvious for
us in this field but probably non-obvious for newbies. I'd suggesting
adding the following text in the intro:
"Numerous techniques have been specified for the discovery of servers
for a particular service, including NAPTR records, SVRLOC and similar
protocols. However, there are an important class of services where the
specific service instance that is to be connected to depends on the
identity of the service and the location of the entity that needs to
reach it. An example of this is emergency telecommunications services,
where the service instance is a Public Safety Answering Point (PSAP)
that has jurisdiction over the location of the user making the call.
Here, the desired PSAP isn't necessarily the one that is topologically
or even line-of-sight closest to the caller; rather, it is the one that
serves the callers location based on geopolitical boundaries. For this
reason, the selected service instance is a function of location and the
desired service."
Section 3 isn't really an overview of operation at all. It mainly
addresses the question of WHEN a user invokes LoST. I was expecting
first an architecture picture that shows a client, a server, and some
backend stuff (other servers). LosT is show as between client and
server. The section would talk about clients issuing requests and
servers answering them. It would mention HTTP and indicate what is
contained in a request, whats in an answer. Mention caching and the use
of regions as a technique to avoid repeated queries on the server. It
would mention the primary primitives provided by lost.
4. LoST servers and Their Resolution
LoST Servers and their Resolution
I wonder if there should be a separate port number for LoST. See RFC 3205.
A receiver can replace a mapping with another one having
the same 'source' and 'sourceId' and a higher version number.
You have not used the term receiver before. Client you mean?
The 'version' attribute is a positive integer that is incremented for
each change in the mapping. The XML data type does not specify an
upper bound for this attribute and thus, the value MUST NOT wrap
around. 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.
Do these have to increase by 1 for each update, or just increase? SHould
be clear.
The contents of this attribute is a
timezoned XML type dateTime, in canonical representation. See
contents are
The 'expires' attribute is REQUIRED to be included in the <mapping>
element.
Is there a way to use LoST without caching? To specify that this result
is valid only for the purposes of satisfying this one query? Or to say
that the results never expire?
On occasion, a server may be forced to return an expired mapping if
it cannot reach the authoritative server or the server fails to
return a usable answer. Clients and servers MAY cache the mapping so
that they have at least some information available. Caching servers
that have such stale information SHOULD re-attempt the query each
time a client requests a mapping.
A meta-issue here, is whether the LoST protocol is meant to just be a
client-server protocol, or whether we are specifying rules for the
entire system. This SHOULD here is a rule for a server to follow when
contacting other servers and thus would not be present in a
client-server protocol spec.
As another issue, this section (section 5) is a mix of behaviors that
define rules around construction of objects and for behaviors of
servers. WHich is it?
Zero or more <displayName> elements describe the service with a
string that is suitable for display to human users, each annotated
with the 'xml:lang' attribute that contains a language tag to aid in
the rendering of text.
Presumably the presence of more than one is to allow responses to convey
multiple languages. Might want to state that.
The <service> element is optional but may also be required if the
mapping is to be digitally signed.
seems like a normative statement is needed here - The <service> element
MUST be present if the mapping is to be digitally signed.
A response MAY indicate the region for which the service URL returned
would be the same as in the actual query, the so-called _service
region_.
I don't understand this definition. I thought it would be something
like: The service region is a set of locations, such that if a client
generates a new query with the same service URN and a location within
the set, the server would return the same service URI in its response.
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
(see Section 11).
and:
A response MAY contain more than one <serviceBoundary> element with
profile 'civic'.
appear to contradict each other. Which is it?
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. 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 unnecessarily refreshing the boundary information just because
the the remainder of the mapping has become invalid.
Any guidelines about when a server is supposed to send a service
boundary reference as opposed to the actual service boundary in a
response?
The Service Number Element
The service number is returned in the optional <serviceNumber>
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
Hardie, et al. Expires August 13, 2007 [Page 11]
Internet-Draft LoST February 2007
service.
This is not true.
So if I'm in an enterprise which requires '9' for an outside line,
wouldn't I have to dial 9 first before this sequence? I think these
service numbers represent numbers that are part of the local *numbering
plan*, and are accessed based on the *dial plan* configured into the
device.
7.3.3. Recursion
LoST <findService> and <listServicesByLocation> queries can be
recursive, as indicated by the 'recursive' attribute. A value of
You haven't mentioned the listServicesByLocation query yet.
The example in Figure 6 demonstrates address
validation, omitting the standard response elements.
but figure 6 is a request, not a response. So how can it omit response
elements? Maybe you mean figure 7?
true. Each element contains a list of tokens separated by white
space, enumerating the civic location lables used in child elements
labels
Note that the same address can yield different responses if parts of
the civic address contradict each other. For example, if the postal
code does not match the city, local server policy determines whether
the postal code or the city is considered valid. The mapping
naturally corresponds to the valid elements.
I think you need a bit more guidance on how to construct the validation
responses. In particular, I think that you would want to indicate that
the most specific address component that is in conflict is the one
listed as in error. For example, if a street address is 65 Main St. and
there is no number 65 on Main St., you would indicate that "65" is in
error, not Main St.
<?xml version="1.0" encoding="UTF-8"?>
<listServices
xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service>
</listServices>
Figure 12: Example of <ListServices> query
The text in section 9 doesnt mention that the query can contain a
service. Presumably this is a request for the server to indicate which
services it supports beneath this root? And that, if absent, its a
request for all services?
There is an assumption that the server knows all of the services it
supports. What about a LoST server that front ends a large number of
back-end servers, forwarding requests to a particular back-end server
based on location? THis front end server doesn't really know what
services it supports.
define the manner in which location information is transmitted. It
possible to standardize other profiles in the future. The two
baseline profiles are:
It is
4. The declaration of whether geodetic-2d or civic is to be used as
the baseline profile. It is necessary to explicitly declare the
baseline profile as future profiles may be combinations of
geodetic and civic location information.
This doesn't make sense to me; I thought this spec defined both
geodetic-2d and civic as baseline mandatory-to-implement.
Requests and responses containing <location> or <serviceBoundary>
elements MUST contain location information in exactly one of the two
baseline profiles, in addition to zero or more additional profiles.
The ordering of location information indicates a preference on the
part of the sender.
THis seems odd. Why can't you include location in both of the location
profiles if you have it? It might allow the server to figure out which
is more accurate and use that one.
1. A client MUST be capable of understanding the response for the
baseline profiles it used in the request.
The word 'profiles' (plural) makes me think you can in fact have
multiple baseline profiles in the request, though the words above forbid
it.
4. Servers MUST implement the geodetic-2d and civic profiles.
What does this mean? Does it mean that it must be able to process
requests with <location> objects in either format? Does it mean it needs
to be able to represent a boundary in either of the two formats? Thats
actually a tall order; I would tend to think that boundaries in
particular would typically exist in only one format and that conversion
is not going to be easy or possible in many cases.
6. If a server receives a request that only contains location
information using profiles it does not understand, the server
responds with a <locationProfileError> (Section 12.1).
based on your rules this should never happen.
7. The <serviceBoundary> element MUST use the same location profile
that was used to retrieve the answer and indicates which profile
has been used with the 'profile' attribute.
'used to retrieve the answer' - what does that mean? What if the server
converts the input format internally prior to looking up the answer in a
backend store?
Also these rules do not place any requirements on clients. Do they need
to support both geodesic-2d and civic? Should be clear either way.
These rules enable the use of location profiles not yet specified,
while ensuring baseline interoperability. Take, for example, this
scenario. Client X has had its firmware upgraded to support the
uber-complex-3D location profile. Client X sends location
You are talking about figures 16 and 17 though you don't reference them.
Servers use this profile by placing a GML [13] <Polygon> element
within the <serviceBoundary> element. This is defined by the
'polygon' pattern in the LoST schema (see Section 14).
Well, servers 'use this profile' by processing <location> requests and
constructing serviceBoundary objects in responses. I think you mean to
say that <location> objects are constructed using <position> and
serviceBoundary elemenets by <Polygon> elements.
Same comment on 11.3.
A LoST server can respond indicating that the querier should redirect
the query to another server, using the <redirect> element. The
element includes a 'target' attribute indicating the LoST application
unique string (see Section 4) that the client SHOULD be contacting
next, as well as the 'source' attribute indicating the server that
generated the redirect response and a 'message' attribute explaining
the reason for the redirect response.
Is there support for multiple languages at once here, as is the case
with warnings and errors?
13. LoST Transport
You might want to include some discussion on timers. LoST layers a
transaction protocol ontop of HTTP. How long should a client wait for a
response?
Do LoST servers need to support pipelining? Do they have to provide both
http and https support? Do clients need to support both?
What about authentication? Can digest be used? What about mutual TLS?
I think this section is a bit underspecified.
16.5. LoST Location Profile Registry
This document seeks to create a registry of location profile names
for the LoST protocol. Profile names are XML tokens. This registry
will operate in accordance with RFC 2434 [2], Standards Action.
I'd suggest you actually include the table that IANA is supposed to
create. I think you want it to look like this:
LoST Location Profiles
Profile Name Specification
--------------------------------------
geodetic-2d RFCXXXX
civic RFCXXXX
Generally, authentication and authorization is not required for
mapping queries. If it is, authentication mechanism of the
underlying transport mechanism, such as HTTP basic and digest
authentication, MAY be used. (Basic authentication SHOULD only be
used in combination with TLS.)
I this this last SHOULD has to be a MUST.
17. Security Considerations
Text in the body of the specification discusses body signatures, but
there is no treatment on how this is done.
In protocols that support
content type indication, LoST uses the media type application/
lost+xml.
What does this mean? That when used with HTTP, LoST objects use this
content-type?
Thanks,
JOnathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit