Subject: [Ecrit] comments on LoST

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Feb 2007 11:18:06 -0500

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
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Feb 2007 11:35:11 -0500

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:[email-masked]]
> Sent: Tuesday, February 13, 2007 11:18 AM
> To: ECRIT
> Subject: [Ecrit] comments on LoST
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Feb 2007 14:20:32 -0500

On Feb 13, 2007, at 11:18 AM, Jonathan Rosenberg wrote:
> 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.

So the semantics of fields of a document passed by a protocol are  
critical, but the semantics of the fields in the protocol are not?   
This needs a better explanation in order to be actionable... or even  
convincing.

> 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.

Other than the timer considerations, I believe you have a point  
here.  While other HTTP using dohickey's out there never actually do  
this, given the seriousness of non-interoperability with LoST  
probably means we need to cover this in more detail.

> 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.

I believe we say that all servers must RECOGNIZE both profiles.  Not  
that they must have mapping data for both profiles, or be able to  
geocode or rev-geocode.  No amount of specification can solve that  
problem.  Either they have the data or they do not.  In general, this  
should not be problem.  Resolution paths will either follow a civic  
chain or a geo chain.

> 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."

I like it.

> I wonder if there should be a separate port number for LoST. See  

If you mean well-known port numbers, then no.  Specification of port  
numbers is done via U-NAPTR.  In practice, I agree that they should  
not be 80 or 443 unless there is good reason.

> 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?

Good question.  I'm not sure about how to the former.  The latter is  
practically done by setting the value to the year 4000.  Perhaps we  
could modify the schema to allow the values of 'NO-CACHE' and 'NO- 
EXPIRATION' to be clearer.

> boundary reference as opposed to the actual service boundary in a  

Hmmm... good question.  I would think that all authoritative servers  
would always send service boundary values so that caching resolvers  
may actually cache them.  As for the resolvers, they probably know  
best what to do based on their configuration.

> geodetic-2d and civic as baseline mandatory-to-implement.

It does, but defining new profiles requires the new profile to  
declare what baseline it is using... because that baseline needs to  
be used if the new profile is not recognized.

> 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.

I believe there was a long thread about this, and the conclusion was  
"don't do it."  Mostly because if you have both a civic and geo  
location, you can issue two separate queries.

> based on your rules this should never happen.

It shouldn't, that's right.  But we don't live in a perfect world.

> Is there support for multiple languages at once here, as is the  
> case with warnings and errors?

It uses the same message pattern as warnings and errors, and neither  
support multiple.

> transaction protocol ontop of HTTP. How long should a client wait  
> for a response?

I'm not falling into that tarpit.  For a discussion on timers, see TCP.

> Do LoST servers need to support pipelining? Do they have to provide  
> both http and https support? Do clients need to support both?

Pipelining: no.
Both HTTP & HTTPS: yes.
Should the doc specify this: yes.

> What about authentication? Can digest be used? What about mutual TLS?

Support for any authentication in the client is optional.  We should  
say this.

> I this this last SHOULD has to be a MUST.

No.  SHOULD is correct.  Implementations will still be inter-operable  
if they violate this advice.

-andy

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Feb 2007 17:28:23 -0500

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Feb 2007 17:49:27 -0500

inline.

Andrew Newton wrote:

>> 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.
> 
> 

No - I'm not saying that of course. What I was expecting is something 
like a section that said "client behavior" and one called "server 
behavior". The client behavior one would tell you rules for constructing 
each of the requests, what to do with various responses, how to handle 
caching, error handling, and so on. Server behavior would be similar, 
talking about rules for recursion, caching, and so on.

Perhaps its a matter of taste.

> Other than the timer considerations, I believe you have a point  here.  
> While other HTTP using dohickey's out there never actually do  this, 
> given the seriousness of non-interoperability with LoST  probably means 
> we need to cover this in more detail.

OK.

> I believe we say that all servers must RECOGNIZE both profiles. 

Right.

> Not  
> geocode or rev-geocode. 

You are more or less requiring one of those two options. Particularly 
for boundary information, I think you are saying that a server *will* 
have to either be able to:

1. have boundary data stored in both formats, OR
2. be able to convert from geodesic polygons to civic wildcard formats 
automatically AND convert from civid wildcard fromats to geodesic 
polygons automatically

Seems to me that #2 is more or less impossible, and that doing it would 
pretty much require #1 anyway. If that is the case, I want to make sure 
it is clearly stated.

> No amount of specification can solve that  

Right. SO what if a server has boundary information in civic format and 
a client makes a query in geodesic format.

> numbers is done via U-NAPTR.  In practice, I agree that they should  not 
> be 80 or 443 unless there is good reason.

Even if you use NAPTR/SRV you can still have default port numbers; SIP 
does this (port 5060 default). People seem to still find comfort in 
default port numbers for firewall configuration. Trust me, I'm well 
aware of its practical limits....

> EXPIRATION' to be clearer.

It may be a non-requirement; I just want to make sure it was considered.

> would always send service boundary values so that caching resolvers  may 
> actually cache them.  As for the resolvers, they probably know  best 
> what to do based on their configuration.

So, then why bother even supporting explicit inclusion of a service 
boundary? Less options in a protocol is better.

> It does, but defining new profiles requires the new profile to  declare 
> what baseline it is using... because that baseline needs to  be used if 
> the new profile is not recognized.

I'm still lost here (no pun intended). You already specify rules that 
say that a server has to support both baselines. So, if you add a new 
profile, why does it matter whether the client includes geodesic vs. 
civic profiles in addition when it sends a query?

>> location profiles if you have it? It might allow the server to  figure 
>> out which is more accurate and use that one.
> 
> 

OK. Might want to say that.

> It shouldn't, that's right.  But we don't live in a perfect world.

Right. So you should mention this shouldn't happen.

> It uses the same message pattern as warnings and errors, and neither  

Perhaps I was thnking of display names...

>> transaction protocol ontop of HTTP. How long should a client wait  for 
>> a response?
> 
> 

It may be a tarpit, but I dont think you can just skirt the issue 
entirely. Its not really a tcp issue at all. If a server needs to go to 
other servers to get an answer, and THOSe servers are delayed or down, 
what happens? Should the client retry right away? How does the client 
know that the server is trying (in which case a retry on a different 
server is useless) vs. unresponsive (in which case a retry is useful)?

This is one of the dangers of running on http as a substrate. LoST is 
NOT like HTTP in its use of multi-hop resolution. That brings up all 
kinds of new failure modes that you need to consider.

>> both http and https support? Do clients need to support both?

Oh? Why not? Could come in handy when the client is not an endpoint but 
something like a sip proxy or call agent.

> Support for any authentication in the client is optional.  We should  

Right.

> if they violate this advice.

Well, this is another tarpit as you know. I think anything less than a 
MUST will run you into some interesting discussions with IESG.

-Jonathan R.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Feb 2007 18:19:18 -0500

On Feb 13, 2007, at 5:49 PM, Jonathan Rosenberg wrote:
> Right. SO what if a server has boundary information in civic format  
> and a client makes a query in geodesic format.

An error occurs, like <notFound>.  Or the server redirects to a geo  
forrest guide.  But the two resolution paths are different.  There is  
no reason to believe that the same authoritative server MUST have  
both sets of information.

> Even if you use NAPTR/SRV you can still have default port numbers;  
> SIP does this (port 5060 default). People seem to still find  
> comfort in default port numbers for firewall configuration. Trust  
> me, I'm well aware of its practical limits....

Agreed, but what would they be?  80 and 443?  Since it isn't  
essential to specify, I don't see a need to do so.

>>> result is valid only for the purposes of satisfying this one  
>>> query?  Or to say that the results never expire?
>> Good question.  I'm not sure about how to the former.  The latter  
>> is  practically done by setting the value to the year 4000.   
>> Perhaps we  could modify the schema to allow the values of 'NO- 
>> CACHE' and 'NO- EXPIRATION' to be clearer.
>

I don't think it was, nor does the solution seem difficult.  We can  
add this if nobody objects.

>> Hmmm... good question.  I would think that all authoritative  
>> servers  would always send service boundary values so that caching  
>> resolvers  may actually cache them.  As for the resolvers, they  
>> probably know  best what to do based on their configuration.
>

Because the client may have a good reason for not wanting the value,  
such as it is on a bandwidth limited link.  The client can request  
this, but what is sent is up to the server.

>> declare what baseline it is using... because that baseline needs  
>> to  be used if the new profile is not recognized.
>
> I'm still lost here (no pun intended). You already specify rules  
> that say that a server has to support both baselines. So, if you  
> add a new profile, why does it matter whether the client includes  
> geodesic vs. civic profiles in addition when it sends a query?

Let me revisit the language in the draft and see where we are mis- 
communicating on this.

>>> 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?
> entirely. Its not really a tcp issue at all. If a server needs to  
> go to other servers to get an answer, and THOSe servers are delayed  
> or down, what happens? Should the client retry right away? How does  
> the client know that the server is trying (in which case a retry on  
> a different server is useless) vs. unresponsive (in which case a  
> retry is useful)?
>
> This is one of the dangers of running on http as a substrate. LoST  
> is NOT like HTTP in its use of multi-hop resolution. That brings up  
> all kinds of new failure modes that you need to consider.

The problem is that I am being told, over another draft, that SIP is  
a bad protocol to model this type of stuff after.  Quite frankly, the  
guidance in this area is less than helpful.  My experience so far is,  
"Use TCP.  If you do anything else, don't do bad things... but we can  
enumerate what those bad things are."

> Oh? Why not? Could come in handy when the client is not an endpoint  
> but something like a sip proxy or call agent.

Most HTTP libraries that I'm aware of don't support this.  They do  
support persistent connections, which is good enough.

>> No.  SHOULD is correct.  Implementations will still be inter- 
>> operable  if they violate this advice.
>
> Well, this is another tarpit as you know. I think anything less  
> than a MUST will run you into some interesting discussions with IESG.

And here we get into that area where the IESG is telling a working  
group what to think.  I think our answer is still SHOULD.   
Interoperability is more important to emergency services than some  
notion of protecting network admins from themselves.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Feb 2007 21:09:23 -0500

Well, there are two ways to do this.  One is to keep the data for both, a
real polygon for the geo, and appropriate values in fields of the civic.

The other way is to use geocoding to convert civic to geo and use the
polygons in all cases.  Conversion in this case is acceptable, both because
you don't forward the converted value, and because the database used can be
precisely the database used for other routing purposes.

Which you use depends on what you have available.  With respect to the
emergency case, PSAPs dealing with geo pretty much have to have an accurate
geocode database to be able to dispatch responders appropriately when
location arrives as geo.  Once you have the database, it's much easier and
better to always use the polygon boundaries.  

Brian

> Sent: Tuesday, February 13, 2007 5:28 PM
> To: Brian Rosen
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] comments on LoST
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Feb 2007 11:16:04 -0500

> precisely the database used for other routing purposes.

So here is my concern. The client sends its query using a <location> 
object in civic form. The server has all its information in geodesic. 
So, it converts the civic <location> to geodesic and does its work. But 
now, it has to return the boundary information in civic format. But, in 
this case, it doesn't have it - you only have it in polygon format.

So how does this work.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Feb 2007 11:20:44 -0500

inline.

Andrew Newton wrote:

> no reason to believe that the same authoritative server MUST have  both 
> sets of information.

Then I am misunderstanding the spec. I thought it required servers to 
support both location profiles. What does it mean to 'support'?

>> SIP does this (port 5060 default). People seem to still find  comfort 
>> in default port numbers for firewall configuration. Trust  me, I'm 
>> well aware of its practical limits....
> 
> 
> Agreed, but what would they be?  80 and 443?  Since it isn't  essential 
> to specify, I don't see a need to do so.

You'd go do an iana allocation request and include them in the spec.

> this, but what is sent is up to the server.

Err, I'm confused. I was suggesting that it might be easier to ONLY have 
a service boundary reference in the findServiceResponse. That is, to 
drop support for including the actual service boundary in a find service 
response. Rather, the client always has to fetch it separately. I was 
asking what the use case was for EVER including the actual service 
boundary (as opposed to the reference) in a findServiceResponse. If 
there is none, we can drop it.

>> entirely. Its not really a tcp issue at all. If a server needs to  go 
>> to other servers to get an answer, and THOSe servers are delayed  or 
>> down, what happens? Should the client retry right away? How does  the 
>> client know that the server is trying (in which case a retry on  a 
>> different server is useless) vs. unresponsive (in which case a  retry 
>> is useful)?
>>
> The problem is that I am being told, over another draft, that SIP is  a 
> bad protocol to model this type of stuff after.  Quite frankly, the  

The real issue here is, will we see interop problems because servers 
timeout before clients do? Seems like there are real things here needing 
specification.

-Jonathan R.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Feb 2007 11:30:10 -0500

You have the polygons for "city" "county" "state" etc.  You intersect them
with the service boundary polygon.  You take the smallest, totally enclosed
area.

Brian

> Sent: Wednesday, February 14, 2007 11:16 AM
> To: Brian Rosen
> Cc: 'ECRIT'

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Feb 2007 12:44:15 -0500

On Feb 14, 2007, at 11:20 AM, Jonathan Rosenberg wrote:
>>> Right. SO what if a server has boundary information in civic  
>>> format  and a client makes a query in geodesic format.
>> An error occurs, like <notFound>.  Or the server redirects to a  
>> geo  forrest guide.  But the two resolution paths are different.   
>> There is  no reason to believe that the same authoritative server  
>> MUST have  both sets of information.
>
> Then I am misunderstanding the spec. I thought it required servers  
> to support both location profiles. What does it mean to 'support'?

A server cannot return an error indicating it did not recognize one  
of those profiles.

>>> Even if you use NAPTR/SRV you can still have default port  
>>> numbers;  SIP does this (port 5060 default). People seem to still  
>>> find  comfort in default port numbers for firewall configuration.  
>>> Trust  me, I'm well aware of its practical limits....

That is an answer for "how". I asked about "what".

> Err, I'm confused. I was suggesting that it might be easier to ONLY  
> have a service boundary reference in the findServiceResponse. That  
> is, to drop support for including the actual service boundary in a  
> find service response. Rather, the client always has to fetch it  
> separately. I was asking what the use case was for EVER including  
> the actual service boundary (as opposed to the reference) in a  
> findServiceResponse. If there is none, we can drop it.

Well, it prevents another round trip in cases where the value is  
needed.  But I see your point.

> The real issue here is, will we see interop problems because  
> servers timeout before clients do? Seems like there are real things  
> here needing specification.

That's a good point.  Suggestions are welcome.  But I'll also point  
out that DNS has not such timer specifications.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Feb 2007 15:57:27 -0500

> You'd go do an iana allocation request and include them in the spec.

I see no reason for LoST to use anything beyond port 80 or 443 as  
long as it uses HTTP/S. LoST is very much in the same spirit as XML- 
RPC or SOAP, both of which use port 80/443.

> findServiceResponse. If there is none, we can drop it.

I've made that argument in the past. The one argument that was  
offered in favor of retaining by-value inclusion of boundaries is  
that civic boundaries are likely to be small in size, so the overhead  
of retrieving the boundary separately is far larger than including  
it, due to the need to issue a separate query for the by-reference case.

Personally, I still think that simplicity would be a good thing here.

> here needing specification.

The case that can occur is that the seeker asks the resolver and the  
resolver asks the authoritative server (or similar variations).

If the seeker timeout is shorter than the resolver timeout, nothing  
bad happens - the resolver caches the answer it eventually got for  
the next querier, possibly a re-attempt by the same seeker.

If the converse occurs (seeker timeout > resolver timeout), the  
seeker gets a failure indication from the resolver.

Thus, I don't see a need to specify an explicit timeout. In many  
practical cases, the timeouts will be driven by the TCP or HTTP  
library, so they may not be configurable in any event. Any such  
choice would likely be completely arbitrary.

Henning

---

From: Shida Schubert <[email-masked]>
Date: Wed, 14 Feb 2007 16:06:11 -0800

Hi Andrew;

My comments inline.

Andrew Newton wrote:
> A server cannot return an error indicating it did not recognize one of
> those profiles.
So are you saying that server may only support 1 of the mandatory
profile, and if it was queried with
the profile that it doesn't support it can't return an error? If that's
the case the text needs to be
clarified. Also, with recursion being false as a default, if the server
in question doesn't support the
profile asked, what is it supposed to do? Is there a case where service
resolution to "urn:service:A"
is provided for profile 1 while not provided for profile 2? If there is
<listServicesByLocationResponse>
needs more information to provide the client with knowledge that some
service resolutions are provided
only for a certain profile.

Also what is a geo forrest guide? This is a term I have never heard before?
I didn't think there was a distinction in forrest guide based on the
location profile.. My understanding
was the same as Jonathan that LoST server had to provide resolution to 2
mandatory profiles.

Regards
Shida

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Feb 2007 21:30:33 -0500

On Feb 14, 2007, at 7:06 PM, Shida Schubert wrote:
> clarified.

What do you mean by "support"?  Because it cannot return a location  
profile error for either of the two base profiles.  As to what data  
it MUST have, the answer is ZERO.  No server is required to have data  
for either profile unless it has data for a profile derived from a  
base profile.

> Also, with recursion being false as a default, if the server
> profile asked, what is it supposed to do?

Again, what do you mean by "support"?  A server can always return  
<notFound> for anything you pass to it.  That's not very useful, but  
is allowable.

> Is there a case where service
> is provided for profile 1 while not provided for profile 2?

Probably, but my crystal ball isn't that good.

> If there is

That's not a bad idea, but is also unnecessary.

> was the same as Jonathan that LoST server had to provide resolution  

I simply meant a forrest guide populated with the geo data.

-andy

---

From: Shida Schubert <[email-masked]>
Date: Wed, 14 Feb 2007 22:00:34 -0800

Hi Andy;

 Let me try again. My comments inline..

Andrew Newton wrote:
> profile error for either of the two base profiles.  As to what data it 
> MUST have, the answer is ZERO.  No server is required to have data for 
> either profile unless it has data for a profile derived from a base 
> profile. 
I somehow understood that support for both profiles meant.
 " If the server was able to provide resolution for service B in region 
A, then the service MUST be
    able to provide resolution for region A in both civic/geo location 
profiles."
 
 Now, obviously that's not what "support" means. It merely means that 
LoST server is able to
understand the profile(schema).
 
 So if support simply implies that server understands the profile 
<notFound> is really
useless and some additional information should be provided to aid the 
client in making
an intelligent decision.  

 If it can't return an error, some sort of warning that provides the 
seeker with a hint
implying which profile is needed for the resolution may be desirable.

 Further, it would be useful to have the ability to express the "profile 
type supported"/service
in <listServiceResponse> as well as <listServiceByRegion>.

 If the seeker(client) checks to see what service, resolver supports and 
it sees that
it supports the service it is interested in, how would it know that the 
resolution is only
provided for profile A? It can't... If the seeker is smart enough it 
might attempt the
query with civic, and if fails try again with geo. But what if the 
resolution is only provided
for one of the optional profile(call it geo-x) that client doesn't 
support? Current text
doesn't prevent this from happening does it?

 If its mandatory to provide mapping for one of the base profile, client 
will simply try
the other base profile if one fails. But reading your comment I just 
don't see that is how
it works. I am assuming from your comment that if the mapping for 
service:pizza is
provided only for optional location profile X? The "service:pizza" will 
be listed in the
<listServiceResponse> as supported service. Client interested in the 
resolution of
"service:pizza" may try the query with every profile it understands only 
to find out
that none of the profile the client supports can be used for resolution...

 This can be avoided by simply returning which profile the resolution is 
available for.
> <notFound> for anything you pass to it.  That's not very useful, but 
  According to my understanding <notFound> can be returned
under various cases as follows. The example illustrated assumes that
query was composed using geo.

 1. If the server doesn't provide resolution for the region in query and 
recursive
     was set to "false" or not declared.

 2. If the server doesn't have the geo data for the service:pizza and 
recursive was
     set to "false" or not declared.
  > Would be nice to provide with information of why it failed and 
possibly the
      profile which can be used to obtain the mapping.

 3. If the server is aware of another authoritative server that can 
provide resolution
     for the geo but recursive is either not declared or set to "false"
  > Would be nice to provide information that resolution can be provided by
     server X or redirect.

 4. recursive was set to true, but no authoritative server owned data 
for the
    service:pizza in geo.
  > Again would be nice to provide which profile would succeed.

 After I wrote this I looked at the schema and saw that defaultValue for
recursive is "true" but section 7.3.3 says it's default value is 
"false". I am
a bit confused is the default "false" or "true"?

-- Text from section 7.3.3 --
 "A value of "true" indicates a recursive query, with the default being
 "false" when the attribute is omitted.
-----------------------------

3 of the cases above can be avoided by setting recursive="true".

 Anyhow, I do believe that normative behavior of client and server
for any services in general should be declared somewhere and should be
added as a milestone of this WG. Ideally general behavior of client/server
is included in this document but I understand that there is an extraneous
pressure for this work to be completed. Furthermore I understand that
phone-bcp is covering the normative behavior for emergency case but
what's debated above is not limited to emergency case.. I think...
 
 Regards
  Shida
 
> That's not a bad idea, but is also unnecessary.
 Sure may be not necessary but I believe it's useful.
> I simply meant a forrest guide populated with the geo data.

 Okay thanks.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Feb 2007 09:57:45 -0500

On Feb 15, 2007, at 1:00 AM, Shida Schubert wrote:
> useless and some additional information should be provided to aid  
> the client in making
> an intelligent decision.

This implies that the client making the query in geo also has the  
same location in civic and vice versa.  That's a pretty big  
assumption.  We have discussed this issue in great detail on this  
list, and the consensus was that if a client has location in both geo  
and civic and wishes to get an answer for both, the client will  
simply make two separate queries -- one for geo and one for civic.  A  
<notFound> for one query will not prevent it from getting the  
information for the other.

> Further, it would be useful to have the ability to express the  
> "profile type supported"/service

I'm indifferent to this idea.  If others support it, we could add it in.

> "false" when the attribute is omitted.

That'll have to get fixed.  I'm inclined to have it default to true.

-andy

---

From: Shida Schubert <[email-masked]>
Date: Thu, 15 Feb 2007 09:26:25 -0800

Andrew Newton wrote:
> This implies that the client making the query in geo also has the same 
> location in civic and vice versa.  That's a pretty big assumption.  We 
> have discussed this issue in great detail on this list, and the 
> consensus was that if a client has location in both geo and civic and 
> wishes to get an answer for both, the client will simply make two 
> separate queries -- one for geo and one for civic.  A <notFound> for 
> one query will not prevent it from getting the information for the other.
 No! Client may not have the same location in civic and geo, the 
location that these two profiles
may overlap but probably has different accuracy. My geo location that I 
get from
my GPS may be very accurate to a point and because of its accuracy would 
be the preferred
location to be used when my UA sends a LoST query.

 According to your comment, there is a possibility that geo may not 
resolve to any URI even
when recursive="true", because none of the authoritative servers 
responsible for the region
may hold the resolution data for geo.
 
 If I obtain an error <notFound> but I know from 
<listServicesByRegionResponse> that resolution
for the service I want is provided, I may want to re-try query with 
inaccurate civic location
information I obtain through DHCP.

 If resolution for civic is available, at least I get some URI to 
contact the service I am interested in,
accurate location information can be provided then.

 * I really hope that for an emergency case(service:sos), there will be 
a text in phone-bcp
mandating the administrator of LoST to maintain mapping data for both 
geo/civic within the region
so client only supporting geo or vice versa will at least get some kind 
of resolution. Furthermore,
to increase the chance of obtaining the mapping data, I would also 
recommend recursive=true
at all time.

 One question was unanswered..

 If resolution is provided only for non mandatory-to-implement profile, 
would it still be listed
in the <listServicesResponse> as service supported? If so I do think 
that's problematic.

 Although I am aware that it is out of scope of protocol definition, but if
there is no indication of which profile is supported(data 
available)/service,  some text imposing
/recommending the server to provide resolution in at least one of the 
base profile should exist
for the protocol to be useful...

> That'll have to get fixed.  I'm inclined to have it default to true.
 I am inclined to have it default to true as well.

 Regards
  Shida