Subject: Re: [Ecrit] LoST Review - part 2

From: Patrik Fältström <[email-masked]>
Date: Thu, 1 Feb 2007 11:45:54 +0100

On 31 jan 2007, at 17.29, Henning Schulzrinne wrote:

> More comments on comments.
>
>>>    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.
>>
>
> 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.

Why do you say that the number should explicitly increase by one?

In DNS one "just" say the number should increase.

Increasing with 2 is violating the spec the way it is written.

>> 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?
>
> Yes, unless there's a better alternative. (We definitely don't want  
> to express time zones, since they don't add any value here.)

I think it is good. I just wanted to make sure you did not want to  
allow timezones (I think the text in the spec you reference is  
confusing -- "canonical format WITH timezone" only allow Z, and not  
timezone).

    Patrik

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 1 Feb 2007 06:40:28 -0500

> Increasing with 2 is violating the spec the way it is written.

The idea was to give implementation guidance, to avoid being asked  
"but increase by how much?" by a reviewer.

As you point out, the increment is not critical, so I'm happy to  
soften the language to a recommendation or drop an explicit increment  
altogether. I do have a second-level intent that people avoid, say,  
using a 32-bit timestamp that then wraps around at some point.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 1 Feb 2007 13:57:29 +0100

On 1 feb 2007, at 12.40, Henning Schulzrinne wrote:

> soften the language to a recommendation or drop an explicit  
> increment altogether. I do have a second-level intent that people  
> avoid, say, using a 32-bit timestamp that then wraps around at some  
> point.

The 32-bit timestamp problem has to do with the maximum value  
possible, and if that is what you are worried about, the protocol  
specification should say what the maximum value is (or that should be  
given by the XML basic type definition, but I think the XML spec does  
not say a maximum size, which imply it can be infinite-1).

One popular integer selection mechanism is YYYYMMDDHHMMSS, for  
example. Should that not be possible?

I.e. in a protocol spec, you must say what the protocol spec is.  
Implementation guidelines are something else. Do not try to write  
both in the same section.

    paf

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 09:40:06 -0500

On Feb 1, 2007, at 7:57 AM, Patrik Fältström wrote:

> specification should say what the maximum value is (or that should  
> be given by the XML basic type definition, but I think the XML spec  
> does not say a maximum size, which imply it can be infinite-1).

I think you right, Patrik.  From the XML Schema spec:

The ·value space· of positiveInteger is the infinite set {1,2,...}.  
The ·base type· of positiveInteger is nonNegativeInteger.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Feb 2007 11:14:06 -0500

Hi Patrik,

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

Marc Linsner wrote:
> Hannes and I asked Patrik Falstrom to review the LoST/Mapping Arch
> drafts....here is the first of his comments.....
> ............................................................................
> ........................................
>
> -----Original Message-----
> From: Patrik Fältström [mailto:[email-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 :-)
>
>   
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.

>>    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.
>>     
>
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.priv.at: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:[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.
>
>   
Thanks for the review.

Ciao
Hannes

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 5 Feb 2007 06:10:18 +0100

To the final comment.

Technically the "+" is not part of E.164. E.164 provides for different number types, e.g. international, local, but does not say how they are distinguished except to indicate that prefixes exist that can perform this.

The "+" comes from another ITU-T recommendation that defines the provision of telephone numbers in a readable format, e.g. for business cards. And incidently this recommendation uses " " rather than "-" as a digit separator.

Regards

Keith

> From: Andrew Newton [mailto:[email-masked]] 
> Sent: 31 January 2007 16:14
> To: "Patrik Fältström"
> Cc: [email-masked]
> Subject: Re: [Ecrit] LoST Review
> 
> 
> On Jan 31, 2007, at 11:06 AM, Patrik Fältström wrote:
> >>>> the timezoned canonical version will always have 'Z' as the 
> >>>> timezone indicator.
> >>>>
> >>>> This is what you want?
> >>
> >> 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.
> 
> 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.
> 
> >>>> Reference a syntax specification. Max 15 char in the 
> string as in 
> >>>> E.164?
> >>
> >> 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?
> 
>  From the schema:
> 
>        element ns1:serviceNumber {
>          xsd:string { pattern = "[0-9*#]+" }
>        }?,
> 
> 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