Re: [Ecrit] LoST Questions/Comments

["Winterbottom, James" <[e-mail]>]

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: [e-mail] on behalf of Avery Penniston
Sent: Wed 8/12/2009 3:51 PM
To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
Subject: Re: [Ecrit] LoST Questions/Comments
 
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:[e-mail]</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


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