Subject: [Ecrit] LoST Review

From: "Marc Linsner" <[email-masked]>
Date: Wed, 31 Jan 2007 09:51:18 -0500

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

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: Wednesday, January 31, 2007 9:13 AM
To: Marc Linsner
Cc: [email-masked]; '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:[email-masked]" and
>    "xmpp:[email-masked]".  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:[email-masked]</uri>
>        <uri>xmpp:[email-masked]</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:[email-masked]
>    and xmpp:[email-masked].  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:[email-masked]</uri>
>        <uri>xmpp:[email-masked]</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:[email-masked]</uri>
>        <uri>xmpp:[email-masked]</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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Jan 2007 15:55:03 +0100

Note that I have NOT followed the discussion on the mailing list, and  
in my review of the document I most certainly reopen issues that the  
wg for many many many months ago have put to sleep.

So, do not get stuck on the issues I rise. See this review as if  
someone from the outside that sort of know what you are doing (or  
think he knows what you are doing, but is wrong :-) ) is reading the  
document for the first time.

      Regards, Patrik

On 31 jan 2007, at 15.51, Marc Linsner wrote:

>> much

---

From: Andrew Newton <[email-masked]>
Date: Wed, 31 Jan 2007 10:53:34 -0500

Patrik, thanks for the read.  You found a lot of readability issues.

In-line you will find my responses to some of the issues:

>> usable for the encryption of the traffic, but not (much) more.

A couple of counter comments:

1) We've been back and forth on HTTP.  As anybody who has read this  
list knows, I've proposed other solutions.  But we've settled here as  
a compromise.  So I think it is fair that the group can ask "Why not  
HTTP?"

2) I agree that client side certs will not work, but it is not a  
technology issue.  They certainly work technically.  But the  
deployment model makes any type of client side authentication difficult.

>> an authoritative source? Or "just" because it imitates the way DNS

I agree.  We need to clarify this.

>> not, and will never, be used.

First, we do want the ability to specify full HTTP URIs in the  
resolution process.  Second, we have talked about other protocols.   
The compromise to stick only with HTTP is that we don't have enough  
deployment experience, but we'd like the ability to do something  
later if necessary.

>> How do the end device get the LOST URL?

Via DHCP and other configuration methods.

>> Are really all elements optional? sourceId, version, and source

Good catch.  The mapping in the schema says they are not:

div {
   mapping =
     element ns1:mapping {
       element ns1:displayName {
         xsd:string,
         attribute xml:lang { xsd:language }
       }*,
       service,
       (serviceBoundary | serviceBoundaryReference)?,
       element ns1:uri { xsd:anyURI }*,
       element ns1:serviceNumber {
         xsd:string { pattern = "[0-9*#]+" }
       }?,
       extensionPoint,
       expires,
       attribute lastUpdated { xsd:dateTime },
       source,
       attribute sourceId { xsd:token },
       attribute version { xsd:positiveInteger },
       message
     }
}

>> about "Data source and version". Attributes that are not mentioned

I agree.

>> think that would be an opportunity that should not be missed.

There is no need for this.   Plus, a specific <mapping> may not  
apply.  It depends on the input.

>> the timezoned canonical version will always have 'Z' as the timezone

I think so, though we could be a bit more explicit, huh?

>> displayName elements with different lang tags?

Yes.

>> Reference a syntax specification. Max 15 char in the string as in  

I don't believe emergency numbers such as 911 or 112 or E.164 numbers.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 31 Jan 2007 10:54:40 -0500

Comments on the comments; I'm hoping that Patrik is on the list.

Thanks for the comments!

To simplify discussion a bit, I'm stripping out the text. I think  
most of the comments can be understood as-is.

> drafts....here is the first of his comments.....

LoST only deals with mapping and doesn't say anything about whether  
the same location is delivered to the PSAP. Indeed, for geo, this is  
unlikely to be the case if the device moves around.

Thus, I don't understand the comment.

> for emergency updates? Etc?

The authoritative server defines the object lifetime, as discussed  
later. There are several other layers of indirection, such as DNS  
NAPTR, SRV and proxies, that are much better for short-term changes.  
Duplicating this at the LoST level seems unlikely to be effective or  
necessary.

> Oh, no! Not HTTP again!!! Why? Also, you can not rely on client  

Because it works :-)

> usable for the encryption of the traffic, but not (much) more.

Hmm, server certs seem to be fairly widespread. If they are deeply  
problematic, I think the world has larger problems than the use of  
LoST over HTTP.

> encryption to handle the authentication and authorization of the LoST

LoST deals with public information, so client authentication is  
generally not a concern. It is also not clear to me that if we should  
need client authentication, why Basic or Digest (or client certs)  
would not be sufficient. It would be helpful to have this concern  
elaborated on, as this is a fairly fundamental design issue.

> an authoritative source? Or "just" because it imitates the way DNS

A server can obviously choose to only refer, so I don't quite  
understand the comment. The reason for referrals is two-fold:

- allows intermediaries to cache results

- avoids multiple trips across a possibly narrow-bandwidth last-hop link

> urge you to pass it on asap.

Will do so.

> example lostserver.example.com, and now example.com.

Noted.

> not, and will never, be used.

I tend to agree with that simplification.

> How do the end device get the LOST URL?

Later.

> Are really all elements optional? sourceId, version, and source

Just the elements, not the attributes. Maybe that's too non-obvious a  
distinction.

> see a protocol specification. Why for example does the above

I'm always happy to remove text, as long as somebody else then  
doesn't complain that they need more examples, more background and  
design information and a longer security considerations section...

> sourceId and version in the URI?

At this point, the URI does not attempt to provide the ability to  
issue arbitrary LoST queries. We'd have to add a lot more to the URI  
to be able to do this, such as the location information and query  
type. One could define a URI that allow to simply retrieve a specific  
mapping, but not be rich enough to express a query.

> think that would be an opportunity that should not be missed.

Retrieving a particular mapping by identifier (as opposed to by  
location) doesn't seem a particularly important operation for LoST,  
but I don't have a strong opinion on this.

[Since this is getting far too long for a single message, I'll  
continue the discussion in a separate message.]

>
> Why btw are several attributes in

Good question; unlike email, it seems highly unlikely (and broken) if  
the requests take more than a few milliseconds for each hop, so  
second-resolution timestamps are unlikely to be useful and below  
that, clock synchronization seems to make the timestamp more or less  
random.

Henning

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Jan 2007 17:06:17 +0100

On 31 jan 2007, at 16.53, Andrew Newton wrote:

> list knows, I've proposed other solutions.  But we've settled here  
> as a compromise.  So I think it is fair that the group can ask "Why  
> not HTTP?"

Of course. Regarding the "real world", I do understand why you choose  
HTTP. But, at the same time I will never stop asking "why http?" :-)

> deployment model makes any type of client side authentication  

Correct. I just would not like the architecture of the protocol rely  
on the fact certs in both ends work for anything else than encrypting  
the session. This was a generic advice I got as AD :-) from my wg  
participants once upon a time. Maybe the current AD have a different  
policy?

> deployment experience, but we'd like the ability to do something  

Ok, fine.

> Via DHCP and other configuration methods.

Ok. Maybe that should be spelled out.

> apply.  It depends on the input.

Ok.

> I think so, though we could be a bit more explicit, huh?

No no. I just wanted you to understand that the way *I* read your  
spec, the dateTime will always be in UTC. Just so people do not  
misunderstand what the paragraph in 5.2 say.

I think using UTC is fine.

> I don't believe emergency numbers such as 911 or 112 or E.164 numbers.

Correct, as countries (Sweden at least) have as a requirement for E. 
164 that it is possible to call an E.164 from any other E.164. They  
are from the same "namespace" though...and because of that have  
similar constraints. Maybe that is in the schema though?

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Jan 2007 17:14:58 +0100

> Comments on the comments; I'm hoping that Patrik is on the list.

Yes I am. But I have not read all messages as you could see on my  
comments :-)

> problematic, I think the world has larger problems than the use of  

Well, it all depends on what you use the fact the cert "worked" for.  
I just do not want you "trust" the cert more than what you in reality  
can.

As we all know, certs of CAs exist in browsers that we never check,  
and if one get a question about a cert from an unknown CA, we all  
"just click ok-continue". The end result because of this is an  
encrypted session, with some automatic checks between the DN in the  
cert and domain name.

That is not bad!

I just do not want you (as architects of this protocol) trust the  
fact you manage to get a TLS session "too much", for some definition  
of "too much".

> - avoids multiple trips across a possibly narrow-bandwidth last-hop  

I think referrals are good. But, my recommendation is always  
regarding these things that a server can always refuse a request on  
doing referral (because of load or whatever), and because of that  
clients must be able to manage without getting the referral request  
fulfilled.

> Just the elements, not the attributes. Maybe that's too non-obvious  
> a distinction.

For me it was. Sorry...

> issue arbitrary LoST queries. We'd have to add a lot more to the  
> URI to be able to do this, such as the location information and  
> query type. One could define a URI that allow to simply retrieve a  
> specific mapping, but not be rich enough to express a query.

What I was thinking of was the fact a reference to an object seems to  
contain both a lost URI for the server one go to, and the ID of the  
object itself. I "just" had the idea that the lost uri spec could be  
extended just a little bit with an optional object id, so it is  
possible to express the location of a location object (or whatever  
you call it) with a URI (only).

> Good question; unlike email, it seems highly unlikely (and broken)  
> if the requests take more than a few milliseconds for each hop, so  
> that, clock synchronization seems to make the timestamp more or  
> less random.

"No" is a perfectly alright answer. I just wanted to know that you  
had been thinking of "more data in a via header"... Time was an example.

    Patrik

---

From: Andrew Newton <[email-masked]>
Date: Wed, 31 Jan 2007 11:13:37 -0500

> I think using UTC is fine.

Then you read it correctly... or said more accurately, your  
interpretation is as we intended.  I still think we could be a heck  
of a lot more specific.

> similar constraints. Maybe that is in the schema though?

 From the schema:

We don't say anything about E.164.  And E.164 numbers cannot be  
dialed on a lot of phones.  How do you dial the beginning "+"  
character.  These are dialstrings that must be recognized by the UA.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 31 Jan 2007 11:29:49 -0500

More comments on comments.

> incompatible implementations.

I'm not sure why this matters. If a version exists only for a  
femtosecond, did it really exist, even though nobody could ever see  
it? Did the tree fall in the forest if nobody heard the sound?

What interoperability problem would you imagine?

I'm trying to avoid unnecessary text.

> cache with a version number that is extremely high. How large can

It's an XML integer. I don't think restricting the range would  
ameliorate that problem since being able to pick something that is  
only modestly large would have the same effect. Longer-term, these  
mappings will be signed.

> the timezoned canonical version will always have 'Z' as the timezone

Yes, unless there's a better alternative. (We definitely don't want  
to express time zones, since they don't add any value here.)

> changing state from valid to not valid? The text above to me seems to

This seems to be the same thing. It is valid until 'expires' arrives;  
I'll rephrase to use invalid.

> Try to not use the term "resolver". Experience from the DNS show it

Please take a look at the architecture document, where these terms  
are defined, to see if they are sufficiently precise for our  
purposes. I'll avoid the terminology here, to avoid cross-references.  
As you say, they are probably not necessary here.

> displayName elements with different lang tags?

Yes. For example, in Canada, the mapping would presumably return both  
the English and French version.

> might not indicate the same region as in the actual query?

MAY; fixed.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 31 Jan 2007 11:51:55 -0500

> Better with one attribute per section and a crisp short definition of

Each definition is one or two sentences long; I broke them into  
paragraphs.

> Element and not attribute again.

I don't see the problem with defining an element here.

> make the MUST loose its power.

MUST is probably not quite appropriate here. It is a simple condition  
(if the client wants something, it needs to do something), so I  
removed it.

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

I don't understand this comment.

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

The paragraph is not really necessary; I just dropped it.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 31 Jan 2007 12:28:36 -0500

[I'm skipping the parts where I made wording updates to hopefully  
address the issue.]

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

Not quite. It couldn't really be a LoST URL, unless we add the query  
type as an attribute to that URL. This doesn't seem to be a good  
approach. We clearly don't want to allow random URLs, such as an http  
or mailto URL here, so allowing URLs just seems to open up more error  
conditions.

> How to handle load balancing, or the fact two PSAPs might cover the

We had a long discussion on this early on. We have several mechanisms  
at the SIP layer to do load balancing and it seems unwise and  
unnecessary to add another one, which would likely have to replicate  
much of the NAPTR and SRV (weight/priority) mechanisms.

Also, as soon as you present multiple URIs with the same scheme, the  
client has to choose somehow, as presenting two URLs to the user and  
asking which one they like better is not too useful. If the two PSAPs  
are cooperating, they can easily define a record in the DNS to do  
randomization.

In extreme cases such as territorial disputes, returning two  
<mapping>s is probably a better option, although that still doesn't  
help the end user all that much.

> "the best one", which seems weird. Or am I confused?

We generally do not try to address overlapping service areas for one  
service, for the reasons above. I don't see how a user can make a  
reasonable choice.

> not. This is the first time ordering among elements exists in this

Ordering in XML seems common. After all, the outcome of

<li>Boil water.
<li>Add noodles and simmer for 5 minutes.

is different from

<li>Add noodles and simmer for 5 minutes.
<li>Boil water.

> Just how it can help loop detection on the client side. If it is not

Yes, it is ("querier includes all servers it has already contacted").  
If you have a hybrid iterative-recursive query, i.e,. that starts  
iteratively and then goes recursive, the initial query will have the  
list of servers already visited.

> ahead of a move for example.

We have not defined mappings that only become valid in the future.  
This is only used to indicate how long the mapping has been unchanged  
and is just an informational item. It is not strictly necessary for  
caching, so I'm happy to remove it.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 31 Jan 2007 12:45:28 -0500

> encrypted session, with some automatic checks between the DN in the  

Once the CA or public key can't be verified, you could be talking to  
a man-in-the-middle instead, so the crypto property is also greatly  
diminished. Fortunately, it is unlikely that LoST is accessed through  
a user interface with click-happy users.

> clients must be able to manage without getting the referral request  

Agreed and noted.