Re: [Ecrit] comments on LoST

So you are saying its not hard for a server to convert a boundary 
definition that is in civic format to one in geodesic format? Seems near 
impossible to me. The server would more or less have to havve all 
boundary objects in both formats, I would think.

-Jonathan R.

Brian Rosen wrote:

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

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit