Subject: [Ecrit] LoST Questions/Comments

From: "Avery Penniston" <[email-masked]>
Date: Mon, 10 Aug 2009 16:20:17 -0500

Hello,

I have recently been reviewing the LoST proposed protocol in RFC 5222
and have some questions and comments that I am hoping I can get some
help with.  Since I have joined the list, discussion seems to be
centered around newer topics than 5222, but I would appreciate any
clarification, or comments on any of the points below.  All references
below refer to RFC 5222 unless stated otherwise.

Avery

1.)	 Sec. 1 [Page3] states, "LoST satisfies the requirements [18]
for mapping protocols."  However I haven't seen how LoST handles this
requirement from RFC 5012:
"Ma13.  URL for error reporting:  The mapping protocol MUST support the
ability to return a URL that can be used to report a suspected or known
error within the mapping database." It seems that a source is returned,
but not a specific URL for error reporting.

2.)	Sec. 1[Page 3] states, "For civic addresses, LoST can indicate
which parts of the civic address are known to be valid or invalid, thus
providing address validation, as described in Section 3.5 of [18]. "
However in Sec 3.5 of RFC 5012 it says that a location is valid if the
location is recognizable, AND "can be mapped to one or more PSAPs".  So
is it implied that the request location is invalid if no mappings are
returned in the findServiceResponse?  If that is the case couldn't a
notFound error returned imply the same?  It just seems to me that
perhaps the location might be valid whether or not it maps to a PSAP.

3.)	Sec. 1 [Page 4] states that a LoST server optionally returns
"hints" about the service boundary.  As far as I could tell it was
either a representation of the boundary itself or a reference to it.
Not sure what is meant by hints.

4.)	Sec. 2 [Page 5] in the definition for Service Boundary it states
that it "circumscribes the region within which all locations map to the
same service URI or set of URIs for a given service".  I take this to
mean that it is a polygon representing a service area.  So when
returning service boundaries either in mappings or in
getServiceBoundaryResponse should the boundary returned be the exact
boundary or can a subset of the service boundary be returned?

5.)	Sec. 3 [Page 5] under <findService> it says that, "The same
query type may also ask for location validation and for service numbers,
either combined with a mapping request or separately".  I understand
that the location validation and service numbers are returned in the
response, but I don't see any attribute in <findService> request that
allows the explicit request for service numbers, nor do I see any query
type that allows the location validation or service number query
"separately".

6.)	Sec. 5.1 [Page 7] Regarding the 'lastUpdated' attribute, is it
intended that this time should be the time when the mapping is 'created'
for example when map data is loaded on server, or when map data is
updated, or when the mapping is returned to the client? This seems to
imply that mappings should be created at a time prior to the request
being responded to.  Is that correct?

7.)	Sec. 5.1 [Page 7]  states, "A receiver can replace a mapping
with another one having the same 'source' and sourceId' and a more
recent time in 'lastUpdated'".
I assume this means a client updating its cache, and not a LoST server
in the middle of a recursive query? So replacing a mapping refers to
replacing it in local cache and not replacing the mapping returned to a
client with a newer one than the one received recursively?

8.)	Sec. 5.2 [Page 8] How is it possible for a client to ever update
its cache of mappings with an expiration of "NO-EXPIRATION"?  It seems
that the only way to get new mappings in this case is if it happens to
receive a mapping with a newer 'lastUpdated' attribute.  Until then the
server would return invalid mapping information. When would it be
advisable to use "NO-EXPIRATION"?  Also, if a mapping does not contain
any ServiceBoundary or ServiceBoundaryReference elements is there any
reason to cache it? 

9.)	Sec. 5.4 [Page 8] When returning an "alternate service that
approximates the desired service" is it implied here that the server
MUST return a serviceSubstitution warning?

10.)	Sec. 5.5 [Page 9] states, "If included in a response, the
<serviceBoundary> element MUST contain at least one service boundary
that uses the same profile as the request".  (Also point 9 under sec.
12.1)  This could be difficult when trying to make a geodetic service
boundary polygon 'fit' into a civic profile to match a request using a
civic profile.  I suppose you could omit the service boundary all
together, but it would be nice to return the geodetic version of the
service boundary.

11.)	Sec. 5.6 [Page 10] states that, "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. "    So this implies that caching is not just
for Mappings but also boundaries.  Is it intended that servers should
maintain a mapping cache and a separate service boundary cache? What
about updating the service boundary information, as it seems that
service boundaries do not have an expiration, lastUpdated, etc.?  

Also the part that says, "...skip checking with the server..." does this
imply that if a service boundary reference is received by the client in
a mapping,  then the client should automatically check to see if that
reference is current if it doesn't have that service boundary cached? If
so how does it determine if it is 'current'?

12.)	Sec. 5.8 [Page 10] Does LoST provide for alternate routing URIs?
Not to be confused with a substitution.  This alternate can help routing
proxies or clients in the event that a service URI is unreachable.  I
know a mapping can contain multiple URIs, but each must use a different
URN schema.

13.)	Sec. 8.2.2 Fig. 3 [Page 13-14] In the returned civic service
boundary, it implies the service is the city of Munich.  I'm guessing
this is okay as long as the civic city boundary does not extend beyond
or overlap the service boundary.   It also assumes that the A3 element
is the smallest boundary element returned in the PIDF-LO; implying that
the A1 and PC elements are either supersets or are ignored.  Is there an
established hierarchy of PIDF-LO civic boundary elements?  

14.)	Sec. 8.3.3 [Page 16] "In recursive mode, the LoST server
initiates queries on behalf of the requester and returns the result to
the requester".  Does recursion imply querying to higher levels in the
hierarchy?  In other words if a LoST Server receives a request for a
service outside the area it covers, should it consult a forest guide to
determine where to query in order to fulfill the recursive query? Its
parent?  Should it only recurse to its children?  

15.)	Sec. 11 [Page 23] Why are via elements optional in
listServicesByLocationResponse?  They are required in a
findServiceResponse are they not?

16.)	Sec. 12 [Page 25] "Requests and responses containing <location>
or <serviceBoundary> elements MUST contain location information in
exactly one of the two baseline profiles." (also points 3 & 4 under sec.
12.1)  Why can't a location be specified in both a civic and geodetic
profile in the same request/response?

17.)	Sec. 12.2 [Page 31] states, "If an authoritative server receives
a query for which the area in the query overlaps the area for which the
server has mapping information, then it MUST return either a mapping
whose coverage area intersects the   query area or a redirect to another
server whose coverage area is a  subset of the server's coverage area".
Why redirect to just a subset, and not a neighboring coverage area?
I.e. the case where a location polygon lies mostly in a neighboring
county and only a small portion of that polygon is overlapping our
service boundary.

18.)	Sec. 12.3 [Page 31] states, "A response MAY contain more than
one <serviceBoundary> element with   profile 'civic'". So I take this to
mean that the request can have at most 1 location of each type of
profile, but serviceBoundaries in the response are allowed multiple of
type 'civic'.  I'm not clear on the purpose here.

19.)	Sec. 12.3 [Page 31] states, "Hence, a response may contain
multiple <serviceBoundary> elements with civic and/or geodetic location
profiles".  So it seems we can mix civic and geodetic-2d in the
response, but not in the request location?  Doesn't this contradict
sec.12 on page 25?

Avery Penniston - Software Developer
GeoComm Inc.
601 W. Saint Germain St., Saint Cloud, MN 56301
Office: 320.240.0040 Fax: 320.240.2389 Toll Free: 888.436.2666
click here to visit www.geo-comm.com

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 12 Aug 2009 14:28:23 +0300

Hi Avery, 

Thanks for the very detailed reading of the document and for your
feedback. 
See my comments below: 

>Hello,
>
>I have recently been reviewing the LoST proposed protocol in 
>RFC 5222 and have some questions and comments that I am hoping 
>I can get some help with.  Since I have joined the list, 
>discussion seems to be centered around newer topics than 5222, 
>but I would appreciate any clarification, or comments on any 
>of the points below.  All references below refer to RFC 5222 
>unless stated otherwise.
>
>Avery
>
>
>for mapping protocols."  However I haven't seen how LoST 
>handles this requirement from RFC 5012:
>"Ma13.  URL for error reporting:  The mapping protocol MUST 
>support the ability to return a URL that can be used to report 
>a suspected or known error within the mapping database." It 
>seems that a source is returned, but not a specific URL for 
>error reporting.

Strictly speaking we satisfy the requirement as we "provide the
possibility to return ..." with the extension points offered via
RelaxNG. :-)

More seriously, you are right that we did not define an XML element that
could carry a URL for error reporting. 

>which parts of the civic address are known to be valid or 
>invalid, thus providing address validation, as described in 
>Section 3.5 of [18]. "
>However in Sec 3.5 of RFC 5012 it says that a location is 
>valid if the location is recognizable, AND "can be mapped to 
>one or more PSAPs".  So is it implied that the request 
>location is invalid if no mappings are returned in the 
>findServiceResponse?  If that is the case couldn't a notFound 
>error returned imply the same?  It just seems to me that 

You are again touch on some sensitive issues. Yes, we have noticed that
we used different semantics for the term "location validation" over
time. This has a bit to do with the work done together with NENA where
the terminology also changed over time. 

Looking at RFC 5012 we could call this definition as being valid for
routing purposes:

   Location validation:  A caller location is considered valid if the
      civic or geographic location is recognizable within an acceptable
      location reference system (e.g., United States Postal Address or
      the WGS-84 datum) and can be mapped to one or more PSAPs.  While
      it is desirable to determine that a location exists, validation
      may not ensure that such a location exists, but rather may only
      ensure that the location falls within some range of known values.
      Location validation ensures that a location is able to be
      referenced for mapping, but makes no assumption about the
      association between the caller and the caller's location.

However, the LoST document actually uses a different definition for
location validation, namely one that refers only to civic addresses and
the existence of the address (with respect to a database) for dispatch
purposes. 

For example, if you have the address Otto-Hahn-Ring 100, Munich would
not be valid with the semantic used in LoST but would be valid according
to RFC 5012 (if there is a PSAP boundary that covers the entire region).

How do we fix this? Good question. We could re-issue an update to RFC
5012 to fix the terminology. We could also re-issue RFC 5222 and include
updated terminology there. I don't know what the group thinks about
that.

>"hints" about the service boundary.  As far as I could tell it 
>was either a representation of the boundary itself or a 
>reference to it.

The LoST server either returns nothing, the boundary or a reference to
it. 
The boundary returned in LoST may or may not reflect the exact boundary.
This is what is meant by hint. 

>that it "circumscribes the region within which all locations 
>map to the same service URI or set of URIs for a given 
>service".  I take this to mean that it is a polygon 
>representing a service area.  So when returning service 
>boundaries either in mappings or in getServiceBoundaryResponse 
>should the boundary returned be the exact boundary or can a 
>subset of the service boundary be returned?

It does not need to be the exact boundary. When a boundary is returned
then it has to be a subset (described with the above-stated definition).

The boundary may be described using a civic or a  geodetic location
format. 

>query type may also ask for location validation and for 
>service numbers, either combined with a mapping request or 
>separately".  I understand that the location validation and 
>service numbers are returned in the response, but I don't see 
>any attribute in <findService> request that allows the 
>explicit request for service numbers, nor do I see any query 
>type that allows the location validation or service number 
>query "separately".

There is no mechanisms to ask for location validation or for service
numbers separately. 

The <findService> query returns the service numbers in the <mapping>
element. The <serviceNumber> is a mandatory element. 

>for example when map data is loaded on server, or when map 
>data is updated, or when the mapping is returned to the 
>client? This seems to imply that mappings should be created at 
>a time prior to the request being responded to.  Is that correct?

The 'lastUpdated' attribute refers to the time when the mapping was
created.
Whenever the mapping is changed then a new timestamp must be created. 

The mappings are indeed created prior to the query.  

>with another one having the same 'source' and sourceId' and a 
>more recent time in 'lastUpdated'".
>I assume this means a client updating its cache, and not a 
>LoST server in the middle of a recursive query? So replacing a 
>mapping refers to replacing it in local cache and not 
>replacing the mapping returned to a client with a newer one 
>than the one received recursively?

You are right that this refers to the cache. 

>its cache of mappings with an expiration of "NO-EXPIRATION"?
>It seems that the only way to get new mappings in this case is 
>if it happens to receive a mapping with a newer 'lastUpdated' 
>attribute. Until then the server would return invalid mapping 
>information. When would it be advisable to use 
>"NO-EXPIRATION"?  Also, if a mapping does not contain any 
>ServiceBoundary or ServiceBoundaryReference elements is there 
>any reason to cache it?

The usage of "NO-EXPIRATION" is IMHO only useful in controlled
environments where you want to force caching for a long time.

If there is no boundary associated with the mapping then the information
the client gets depends on the location it used in the request. For
example, if I asked for Germany then the response it gets would be
either be an error, or a mapping and that mapping would be usable for
all places within Germany. 

>approximates the desired service" is it implied here that the 
>server MUST return a serviceSubstitution warning?

Yes. The <service> element would then contain the Service URN that was
used for the lookup. 

><serviceBoundary> element MUST contain at least one service 
>boundary that uses the same profile as the request".  (Also 
>point 9 under sec.

>This could be difficult when trying to make a geodetic 
>service boundary polygon 'fit' into a civic profile to match a 
>request using a civic profile.  I suppose you could omit the 
>service boundary all together, but it would be nice to return 
>the geodetic version of the service boundary.

We discussed this offlist and I agree that it would be useful to provide
this type of feature. An additional warning code would have to be
specified. 

>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
>for Mappings but also boundaries.

This is a mapping:

<mapping
       expires="2007-01-01T01:44:33Z"
       lastUpdated="2006-11-01T01:00:00Z"
       source="authoritative.example"
       sourceId="cf19bbb038fb4ade95852795f045387d">
       <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>
       <serviceNumber>911</serviceNumber>
     </mapping>

It may contain a service boundary. 

You always cache the whole thing; not parts of it. 
When when you compare whether you have something in the cache already
then the place to start the search is the unique identifier.

> Is it intended that servers 
>should maintain a mapping cache and a separate service 
>boundary cache?

Nope; not in my understanding of an implementation. 

 What about updating the service boundary 
>information, as it seems that service boundaries do not have 
>an expiration, lastUpdated, etc.?  

The mapping as a whole has this information and it applies to the
mapping structure in general. 

>
>Also the part that says, "...skip checking with the server..." 
>does this imply that if a service boundary reference is 
>received by the client in a mapping,  then the client should 
>automatically check to see if that reference is current if it 
>doesn't have that service boundary cached? If so how does it 
>determine if it is 'current'?

The 'source', 'sourceId', and 'lastUpdated' attributes uniquely identify
a particular mapping record. 

If a client receives a mapping that does not include a serviceBoundary
element but rather a <serviceBoundaryReference> element then by checking
these three attributes mentioned above it could tell whether it is
useful to perform the lookup. Whenever the mapping data is changed then
the unique identification has to change as well. 

>Not to be confused with a substitution.  This alternate can 
>help routing proxies or clients in the event that a service 
>URI is unreachable.  I know a mapping can contain multiple 
>URIs, but each must use a different URN schema.

The current spec does not allow multiple URIs with the same URI scheme
to be returned. 

It is, however, possible to provide "load balancing" via the usage of
DNS. The returned URIs will need to be resolved via DNS, see Section 4
of RFC 5222. 

It is also possible to return multiple <mapping> elements in the
response. We actually did not say whether you could include the same URI
in these mappings. Hmmmm. 

>boundary, it implies the service is the city of Munich.

The service that is being asked for is 'urn:service:sos.police'. In the
example we assume that the query for 'urn:service:sos.police' will lead
to a result for this specific service.

>  I'm 
>guessing this is okay as long as the civic city boundary does 
>not extend beyond
>or overlap the service boundary.

The query in Figure 3 provides this address: 
 
         <country>DE</country>
         <A1>Bavaria</A1>
         <A3>Munich</A3>
         <A6>Otto-Hahn-Ring</A6>
         <HNO>6</HNO>
         <PC>81675</PC>

If there is a police PSAP who is responsible for that area then we are
fine. From the response in Figure 4 we can tell that the indicated
boundary that will lead to the same result is 

<country>DE</country>
            <A1>Bavaria</A1>
            <A3>Munich</A3>
            <PC>81675</PC>

As mentioned previously, this may not be the real boundary for that
PSAP. 

So, the address in Figure 3 has to be within the indicated boundary.
There are corner cases I forgot to mention -- largely for the geodetic
case where the provided location is not a boundary but rather a location
shape with less accuracy. Then, the provided location may overlap with
multiple boundaries and then you need to figure out with what boundary
it overlaps most. 

It 
   It also assumes that the A3 element
>is the smallest boundary element returned in the PIDF-LO; 
>implying that the A1 and PC elements are either supersets or 
>are ignored.  Is there an established hierarchy of PIDF-LO 
>civic boundary elements?  

There is no hierarchy of PIDF-LO elements as such. 

>initiates queries on behalf of the requester and returns the 
>result to the requester".  Does recursion imply querying to 
>higher levels in the hierarchy?  In other words if a LoST 
>Server receives a request for a service outside the area it 
>covers, should it consult a forest guide to determine where to 
>query in order to fulfill the recursive query? Its parent?  
>Should it only recurse to its children?  

This depends largely on the setup of the LoST infrastructure. 

Let's pick an example: An ISP runs a caching LoST server and the
authoritive LoST servers are run by the government of a specific
country. The country LoST server is the forest guide. 

So, an ISP LoST server could be configured to first talk to the country
LoST servers. If the request is still not fulfilled then the country
LoST server would then talk to other forest guides. 

>findServiceResponse are they not?

The statement in Section 11 is wrong: 

"
 This response MAY contain
   <via> elements (see Section 6) and MUST contain a <serviceList>
   element, consisting of a whitespace-separated list of service URNs.
"

The <via> elements are mandatory (also in the RelaxNG schema). 

>or <serviceBoundary> elements MUST contain location 
>information in exactly one of the two baseline profiles." 
>(also points 3 & 4 under sec.
>12.1)  Why can't a location be specified in both a civic and 
>geodetic profile in the same request/response?

The request only carries one location element at the time. If the end
host (or whatever entity) has multiple location objects then it needs to
issue separate queries. 

RFC 5222 defines two mandatory-to-implement baseline location profiles,
namely a geodetic-2d and a civic profile. 

Page 25 then says: 

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

There is no negotiation happening between the involved parties and we
would like to avoid the case where you get a response but you have no
clue what it means. 

For example, if someone defines a new civic location profiles that
allows to express interior location in a more precise fashion then you
could still add location using this new profile but you have to include
location using the fields known from the currently defined civic profile
as well. 

>a query for which the area in the query overlaps the area for 
>which the server has mapping information, then it MUST return 
>either a mapping
>I.e. the case where a location polygon lies mostly in a 
>neighboring county and only a small portion of that polygon is 
>overlapping our service boundary.
>

The paragraph you are referring to was written to discuss the case where
the provided location information is in the form of a location shape
that a certain amount of uncertainty (expressed using the different
shape types). Then, you can run into the case that multiple mapping
could be returned. You might want todo that. However, one needs to avoid
the case where you redirect forwards and backwards and no result is
being produced. These paragraphs are trying to explain these scenarios. 

>mean that the request can have at most 1 location of each type 
>of profile, but serviceBoundaries in the response are allowed 
>multiple of type 'civic'.  I'm not clear on the purpose here.

The propose of allowing multiple <serviceBoundary> elements is to be
able to express more complex "shapes". For example, imagine that a PSAP
serves "Finland, Espoo", "Finland, Helsinki", "Finland, Vantaa" and
"Finland, Kauniainen". 

>multiple <serviceBoundary> elements with civic and/or geodetic 
>location profiles".  So it seems we can mix civic and 
>geodetic-2d in the response, but not in the request location?  
>Doesn't this contradict
>sec.12 on page 25?

The reason is that the group decided that a request for multiple
location elements (which might point to different physical locations)
should better be dealt with by issuing multiple independent queries.

Ciao
Hannes
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 12 Aug 2009 11:09:50 -0400

I think the Error Reporting URI is obtained by querying LoST with a
distinguished service URN, which yields the URI of the error reporting
service.  We need to define that service URN.

> There is no hierarchy of PIDF-LO elements as such.
I think this is an impractical answer, and the A levels are a hierarchy.

If I say it's good in Munich, it's good in Munich DE, and not any Munich,
for example.  The higher A levels are by default included.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Wednesday, August 12, 2009 7:28 AM
> To: ext Avery Penniston; [email-masked]
> Subject: Re: [Ecrit] LoST Questions/Comments
> 
> Hi Avery,
>

---

From: "Avery Penniston" <[email-masked]>
Date: Wed, 12 Aug 2009 15:51:08 -0500

Hi Hannes, Brian, et al.,

I think a hierarchy for PIDF-LO is essential for comparing civic
locations in order to mitigate relational ambiguity of locations. Brian
mentioned that the A elements already provide a level of hierarchy, and
it makes sense, for example, to include the country code to disambiguate
Munich, DE from any Munich.  But what about cases where the A1 element
is provided as well,(i.e. Munich, Bavaria, DE), and a comparison
location does not include that element (i.e. Munich, DE).  Should these
locations not be equal because one contains additional information?  The
answer might be that, no, they are equivalent because there is only 1
Munich in Germany, and the A1 element becomes irrelevant.  But this
forces another burden on the LoST Server to verify, if any elements in
the A levels (above the lowest one provided) are missing, that a child
element's value is only found only once in the higher A element that it
is aware of in order to be valid.  So for example, if a location had a
fictitious PIDF-LO of <country>de</country><A5>Zeppelin Square</A5>,
then the LoST server would have to check all of Germany to make sure
there is only 1 neighborhood of that name.  This becomes more tedious
the bigger the 'gap' between the highest and lowest A element provided.

Brian, on the other topic for error reporting, are you suggesting a new
query/response type for LoST? Such as:
   <getErrorURI>
     <service>urn:service:sos.police</service>
     <location 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>
     </location>
   </getErrorURI>

   <getErrorURIResponse>
     <service>urn:service:sos.police</service>
     <uri>mailto:[email-masked]</uri>
   </getErrorURIResponse>

Also, I have added some additional comments on my original points below:

2.)[Address Validating] I can see this is a bit tricky as it seems the
LVF 
requirement from NENA may seek a different interpretation of what it
means
to be valid.  But it seems to me that it only makes sense to ask a LoST
server if a location is valid for routing. Asking it for validity for
dispatch 
seems to fall under the scope of a local PSAP.  It seems that LoST's
function 
is simply to route a call to that PSAP, and defining whether an address
is 
complete or accurate enough(valid) seems beyond scope.  But since NENA
has a 
genuine need for this, I can see how it might seem easy to logically
group LoST
with dispatch validation from NENA's point of view.

5.)[Service Numbers] Maybe 5222 should not include the part about being
able 
to query separately. Also the Relax-NG schema for mapping shows the 
"ServiceNumber"element to be optional.

6.)[lastUpdated Attribute] I have another question regarding the
'lastUpdated' 
attribute.  Suppose in a LoST server a mapping is returned by value
normally,
then a client requests that it be returned by reference which the server
then does.
Should the lastUpdated attribute be updated? Or does the 'lastUpdated'
only refer
to changes in either the service URIs and/or the service boundary
definition?

8.) [NO-EXPIRATION attribute] So I gather that a seeker can infer the
service 
boundary (or subset of it) by using the location it passed in. 

11.) [Service Boundary caching] This is still a bit confusing. Does the
word
'identifier' here refer to the SourceId of the mapping, not the key of
the
service boundary? And 'checking with the server whether the boundary has
been
updated' refers to re-querying the server for findService to see if the
mapping
lastUpdated is newer than what is cached, rather than calling
getServiceBoundary??

12.) [Alternate Mappings] I wasn't really suggesting the case where a
server
goes down and needs to fail-over, I was suggesting a scenario where a 
natural disaster occurs in ZoneA, and overflow can go to ZoneB's PSAP in
a
temporary fashion.  I suppose a response could return multiple mappings
and include
some element in LoST's extensibility indicating when a mapping is an
alternate.

16.) [request/response profiles] As far as 'the request only carries one
location
element at a time', that is not the impression I got from 5222 nor the
RELAX schema
which indicates 1 or more. It says "The <findService> query communicates
location 
information using one or more <location> elements".

I understand each LoST server must understand both 'civic' and
'geodetic-2d' base
profiles, which means that as long as the request/response contains 'a'
base
profile, it should be ok.  What I was getting at is why there is a
separation
necessary between the civic and geodetic in a request.

17.) [Redirect] So what you are saying, is that if a LoST server can
answer a 
query it must, or redirect to a server which is a child server?

19.) [request/response profiles again] Please see my comments on 16
above.  Also 
please note the 'and/or' in my orginal quote from RFC 5222.  This seems
to say that
a response can contain a civic AND geodetic location.  This seems to
contradict 
sec. 12 [Page 25] where it says "Requests and responses containing
<location>
or <serviceBoundary> elements MUST contain location information in
exactly one 
of the two baseline profiles." Note the phrase 'exactly one'.

Thanks for taking the time to look at my questions/comments.

Avery

> Of Brian Rosen
> Sent: Wednesday, August 12, 2009 10:10 AM
> To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; Avery Penniston;
> [email-masked]
> > >4.)	Sec. 2 [Page 5] in the definition for Service Boundary
it
> states
> > >6.)	Sec. 5.1 [Page 7] Regarding the 'lastUpdated' attribute,
is
> it
> > >8.)	Sec. 5.2 [Page 8] How is it possible for a client to
ever
> update
> > >12.)	Sec. 5.8 [Page 10] Does LoST provide for alternate
routing
> URIs?
> > host (or whatever entity) has multiple location objects then it
needs
> > to

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 12 Aug 2009 16:31:40 -0500

Hi Avery,

There are quite strong recommendations being made in Geopriv about countries profiling civic addresses for their jurisdictions.
http://www.ietf.org/id/draft-ietf-geopriv-civic-address-recommendations-03.txt

Doing this ensures that civic addresses have specific forms for specific countries and the comparison issues you describe below become unnecessary, because you don't conform to the normalized form for the jurisdiction then your location is invalid.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Avery Penniston
Sent: Wed 8/12/2009 3:51 PM
To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [Ecrit] LoST Questions/Comments

   <getErrorURIResponse>

Avery

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Aug 2009 18:16:01 -0500

Hi Avery,

When you request a hierarchy, or ordering, of civic addresses, this is OK for the top-level A* parameters, but it quickly fails at other levels.  It is even not possible when comparing A* parameters with non-A* parameters.  

For instance, postal codes often cover an area equivalent to a suburb in scale, which is A4.  Thoroughfares frequently pass through multiple suburbs (A4), sometimes even states (A1).

While it's nice in theory, you can't rely on ordering outside of A*.  As a hint, the civic address "boundary" can only be interpreted in a very narrow way: 

  If any of the provided elements change from that specified, the provided service URI no longer applies and a new LoST request is needed.

It's a shame that LoST doesn't actually say this.  It should.

--Martin

> Of Avery Penniston
> Sent: Thursday, 13 August 2009 6:51 AM
<snip>

---

From: "Avery Penniston" <[email-masked]>
Date: Thu, 13 Aug 2009 16:09:26 -0500

James, thanks for the info on the work going on in Geopriv.  I'm interested to see how that discussion shakes out.  Specifically on how abbreviations/alternate spellings should be handled, how elements other than A elements get defined for super/sub sets,  and how to compare optional elements when left blank in one location, but supplied in another.  Perhaps the questions I have about civic location comparison belong in the Geopriv WG.

Martin, I think what you are saying is that if two civic locations do not match exactly (both the elements provided, and the blank elements) then, currently, LoST should consider them not equal.  But should LoST try to determine if one location 'fits' inside another?  For example a resolver wants to check if a location is found within one of its cached mapping service boundaries. 

 If the request location is something like:
          <country>DE</country>
          <A1>Bavaria</A1>
          <A3>Munich</A3>
          <A6>Otto-Hahn-Ring</A6>
          <HNO>6</HNO>
          <PC>81675</PC>

Should it attempt to match it with a cached mapping that has a boundary like this?:
          <country>DE</country>
          <PC>81675</PC>

Without having some type of definition that describes how the different CAType elements relate to one another spatially, location matching could be quite an expensive task on the server. 

Avery

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2009 6:16 PM
> To: Avery Penniston; Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo);
> [email-masked]
> Subject: RE: [Ecrit] LoST Questions/Comments - civic hierarchy
> 
> Hi Avery,
> 
> When you request a hierarchy, or ordering, of civic addresses, this is
> OK for the top-level A* parameters, but it quickly fails at other
> levels.  It is even not possible when comparing A* parameters with non-
> A* parameters.
> 
> For instance, postal codes often cover an area equivalent to a suburb
> in scale, which is A4.  Thoroughfares frequently pass through multiple
> suburbs (A4), sometimes even states (A1).
> 
> While it's nice in theory, you can't rely on ordering outside of A*.
> As a hint, the civic address "boundary" can only be interpreted in a
> very narrow way:
> 
>   If any of the provided elements change from that specified, the
> provided service URI no longer applies and a new LoST request is
> needed.
> 
> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2009 4:32 PM
> To: Avery Penniston; Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo);
> [email-masked]
> Subject: RE: [Ecrit] LoST Questions/Comments
> 
> Hi Avery,
> 
> There are quite strong recommendations being made in Geopriv about
> countries profiling civic addresses for their jurisdictions.
> Doing this ensures that civic addresses have specific forms for
> specific countries and the comparison issues you describe below become
> unnecessary, because you don't conform to the normalized form for the
> jurisdiction then your location is invalid.
> 
> Cheers
> James
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Aug 2009 18:01:18 -0500

> Martin, I think what you are saying is that if two civic locations do
> not match exactly (both the elements provided, and the blank elements)
> then, currently, LoST should consider them not equal.  But should LoST
> try to determine if one location 'fits' inside another?  For example a
> resolver wants to check if a location is found within one of its cached
> mapping service boundaries.

Without the need for interoperable exchange formats, an implementation of a LoST server could have additional information that says that one civic address is entirely contained within another.  This information would not necessarily be able to be represented in the synchronization protocol.  

> Without having some type of definition that describes how the different
> CAType elements relate to one another spatially, location matching
> could be quite an expensive task on the server.

Yes, I would imagine that this location is considered to be "within" the specified boundary "address".  The boundary effectively states that any location with the same country and postal code is within the boundary.

The consumer of a LoST boundary (client, or caching server) has a very simple algorithm to follow.  For each specified element in the boundary "address", compare for equality.  If a boundary-specified element is either not equal or absent in the request address, the address is outside the boundary.  Additional elements in the request address that were not specified in the boundary address can only be considered to be unimportant.

Worst case, which is always available, is that the LoST server maintains an exhaustive list of civic addresses that are within the boundary.  Obviously, there might be certain simplifications that could be made (such as ignoring interior elements).

These things will vary, depending on the needs of the specific LoST application.  In Australia and many other countries emergency services are centralized.  Therefore, a LoST server that serves those countries is able to correctly determine a route for emergency services based on the <country> tag alone.  In the US, things are much more complicated and the LoST server therefore needs much more extensive information.

Two important considerations:

 1)  It is not possible to indicate that a certain element MUST be absent when expressing a boundary.  This is a failing of the system, and one that might need to be addressed.  

   Deployment experience might show that this is not necessary, but I've seen evidence enough that civic addresses are capable of producing just about any corner case imaginable.

 2)  Any single boundary "address" is not necessarily complete on its own.  A complete boundary specification might require the union of multiple such boundaries.  In some cases, this can get extremely complicated.

  To give an example of this, imagine the case where a road is used as a dividing line.  If, as is common in many places, odd numbered houses are on one side of the road and even on the other, the boundary specification for either region cannot simply indicate the road, it must specify each house number individually.  That's quite costly, but the only choice available, given the specification (or, as I noted previously, absence thereof).

Cheers,
Martin

> > > element's value is only found only once in the higher A element
> that
> > it
> > > is aware of in order to be valid.  So for example, if a location
> had
> > a
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > [mf2]