Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand geospatialinfointo the query?

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Jun 2006 17:33:30 +0100

This seems to me to getting back to the real issue of which entity is responsible for ensuring that the information is representing one unambiguous location, and which entity has to take what action if it doesn't.

This could be any of (if I understand the terms in the requirements document correctly):

The calling user
The emergency service routeing proxy (or mapping client)
The mapping server.

Certainly we place constraints on the calling user, by specifying a syntax for the location object, but that does not prevent it being ambiguous. 

I would also suggest that whatever we agree must always produce the same result. Tom has made the suggestion that in cases of ambiguity, simplicity would argue for the mapping server to take the first of any ambiguous values. If I wrote my software a different way, I am sure I could argue that the simplest implementation would be to take the last of any ambiguous values. But I am not convinced it is the function of the mapping server to sort out ambiguity in the first place.

regards

Keith

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: 08 June 2006 08:17
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ecrit] [issue2] Is it allowed to specify civicand
> geospatialinfointo the query?
> 
> 
> I think that you meant to ask me, so I'll answer.  I'm not 
> sure if that's a good thing or not to be mistaken for Tom ;)
> 
> I'm not sure if I understand your scenario.  Do you have a 
> server that doesn't support geo, but has extra information 
> that it can use?
> 
> The only scenarios that I can see arising from this are those 
> where one piece is not understood (either the geo, or civic 
> part).  Two things can happen
> 
>   - the other pieces are sufficient to get a result (I don't 
> understand civic, but I don't care about altitude), or
> 
>   - the other pieces are pretty ambiguous (I don't understand 
> geo, and the second floor anywhere on the planet isn't 
> specific enough for me).
> 
> > -----Original Message-----
> > From: Shida Schubert [mailto:[email-masked]]
> > Sent: Thursday, 8 June 2006 4:20 PM
> > To: Thomson, Martin
> > Cc: [email-masked]
> > Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand
> > geospatialinfointo the query?
> > 
> > 
> > Hi Tom;
> > 
> > I agree with you to some extent but I am still not comfortable.
> > 
> > As long as the two information really supplement each 
> other, and one of
> > the information is sufficient to find the proper PSAP URI and both
> > information only resolves to one PSAP URI if both were 
> queried, I might
> > be able to live with that.
> > 
> > Just out of curiosity. Assuming LoST supports query with location
> > information with two location type as long as it is a 
> compound location
> > information where two information supplement each other, what would
> > happen if LoST server that was queried did not support geo and it
> > happend to have the supplementary information in geo(latitude)?
> >
> > If it does not understand civic location format, it is 
> unable to identify
> > the information to be used to find the proper PSAP and 
> might proceed to
> > query the database using the location info provided in geo 
> format(only
> > latitude info.
> > 
> > I guess it could return an error stating that it's an 
> invalid location
> > as well as default uri for the service requested(e.g. 
> Default PSAP URI
> > for the
> > region LoST server is responsible)...
> > 
> > Regards
> > Shida
> > 
> > Thomson, Martin wrote:
> > > It is better to think of anything that appears within a single
> > <location-info> element as a single location.  You aren't 
> sending more
> > than one location to the LoST server.  If you think about 
> it as a single
> > "location" with multiple parts (elements), the fears about multiple
> > responses disappear.
> > >
> > > The only valid concern that remains is LoST server 
> complexity.  But when
> > you scratch beneath the surface a little, this begins to be 
> less of a
> > source of intestinal torment.  If we consider the occasions 
> where this
> > composite location is possible, it quickly resolves down to 
> the floors
> > altitude case, and not a whole lot more.  In other words, I 
> can't think of
> > a good alternative example.  That means that the LoST 
> server can safely
> > ignore the "<civicAddress><FLR>2</FLR></civicAddress>" that 
> goes along
> > with the geodetic information, except where you have the 
> weird case where
> > the bottom-floor cinema is served by a different PSAP to 
> the upper-floors
> > (not my example).
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Shida Schubert [mailto:[email-masked]]
> > >> Sent: Thursday, 8 June 2006 11:57 AM
> > >> To: Tom-PT Taylor
> > >> Cc: Thomson, Martin; [email-masked]
> > >> Subject: Re: [Ecrit] [issue2] Is it allowed to specify civic and
> > >> geospatialinfointo the query?
> > >>
> > >>
> > >> Hi Tom;
> > >>
> > >> According to what I understand the issue still remains because
> > >> Rule#5 and Rule#6 allows a compound location information 
> composed of
> > >> both geo and civic in single <location-info> element.
> > >>
> > >> Two of which location type is a supplementary location 
> info(floor or
> > >> altitude)
> > >> that can be dropped from the LoST query is probably not 
> easy to find
> > out.
> > >> I guess we can't expect all the intermediary that 
> supports LoST client
> > >> functionality,
> > >> the ability to compute the two location inside one 
> <location-info>
> > >> element to
> > >> seek out the proper location information to submit with 
> the LoST query.
> > >>
> > >> I think I understand the problem, but I still feel very 
> uncomfortable
> > to
> > >> send
> > >> more than one location to LoST server in a single query. 
> I'd rather
> > >> loose the
> > >> ability to express the flexibility the pidf-lo-profile has about
> > >> including more
> > >> than one location.
> > >>
> > >> If more than one location needs to be included in single 
> location-info
> > >> element,
> > >> may be we can define a new element or an attribute to an "tuple"
> > element
> > >> to express that a location information A adds additional info to
> > location
> > >> information B?
> > >>
> > >> Thanks & Regards
> > >> Shida
> > >>
> > >> Tom-PT Taylor wrote:
> > >>
> > >>> OK, I've looked over the draft, and the rules make 
> sense. I would
> > >>> still, as the "call server" programmer, choose the 
> first location-info
> > >>> element and send only it. There's no way we should 
> expect the mapping
> > >>> server to wade through potentially many objects when (within our
> > >>> charter) it makes sense to reply to only one of them.
> > >>>
> > >>> Thomson, Martin [Business:EXTRNL:ANDREW] wrote:
> > >>>
> > >>>> I'd like to clarify my position, because I think that 
> this discussion
> > >>>> has headed off course a little.
> > >>>>
> > >>>> Firstly, I'd recommend that people read the PDIF-LO 
> [sic] profile
> > >>>> draft. That draft talks about cardinality and I think 
> that it is
> > >>>> extremely important to this discussion.
> > >>>>
> > >>>> 
> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-04.txt
> > >>>>
> > >>>> This document notes that it is possible to have civic 
> and geodetic
> > >>>> that together form a complex to describe a single location. The
> > >>>> example used is a set of 2-dimensional coordinates 
> with an altitude
> > >>>> expressed in building floors. This is the reason that I support
> > >>>> both, not because I see that the LoST server being able to make
> > >>>> intelligent decisions about multiple conflicting pieces of
> > >>>> information.
> > >>>>
> > >>>> Here's how I see this working. The seeker has a 
> PIDF-LO. They apply
> > >>>> the selection methods described in the above document 
> to select a
> > >>>> single tuple that contains location information.
> > >>>> (XPath="/presence/tuple[status/geopriv][1]")
> > >>>>
> > >>>> Whatever location information that tuple contains, be 
> it geodetic or
> > >>>> civic, the seeker lifts the contents of the 
> location-info element and
> > >>>> puts it in an appropriate LoST query.
> > >>>>
> > >>>> Here are the applicable rules:
> > >>>>
> > >>>> Rule #1: A geopriv element MUST describe a discrete 
> location. Rule
> > >>>> #4: Providing more than one location in a single 
> <location-info>
> > >>>> element SHOULD be avoided where possible. Rule #5: 
> When providing
> > >>>> more than one location in a single <location- info> element the
> > >>>> locations MUST be provided by a common source. Rule 
> #6: Providing
> > >>>> more than one location in a single <location-info> 
> element SHOULD
> > >>>> only be done if they form a complex to describe the 
> same location.
> > >>>> For example, a geodetic location describing a point, 
> and a civic
> > >>>> location indicating the floor in a building. Rule #8: 
> Where a PIDF
> > >>>> document contains more than one tuple containing a 
> status element
> > >>>> with a geopriv location element , the priority of 
> tuples SHOULD be
> > >>>> based on tuple position within the PIDF document. That 
> is to say,
> > >>>> the tuple with the highest priority location occurs 
> earliest in the
> > >>>> PIDF document. Initial priority SHOULD be determined by the
> > >>>> originating UA, the final priority MAY be determined 
> by a proxy along
> > >>>> the way, or the UAS.
> > >>>>
> > >>>>
> > >>>>
> > >>>>> -----Original Message----- From: Hannes Tschofenig
> > >>>>> [mailto:[email-masked]] Sent: 
> Wednesday, 7 June 2006
> > >>>>> 9:30 PM To: [email-masked] Subject: [Ecrit] [issue2] 
> Is it allowed
> > >>>>> to specify civic and geospatial infointo the query?
> > >>>>>
> > >>>>>
> > >>>>> Hannes Tschofenig <[email-masked]> added 
> the comment:
> > >>>>>
> > >>>>> TENTATIVE SUMMARY:
> > >>>>>
> > >>>>> Here is the update:
> > >>>>>
> > >>>>> * Either civic OR geospatial in a LoST query
> > >>>>>
> > >>>>> Marc, Henning, Shida, Richard, Brian, John 
> Schnizlein, Byron Smith,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> * Both civic AND geospatial possible in a LoST query
> > >>>>>
> > >>>>> Roger, Martin, Andy, James W.
> > >>>>>
> > >>>>> These folks don't seem to take a clear position:
> > >>>>>
> > >>>>> John Hearty, Jean-Francois, Clive D.W. Feather
> > >>>>>
> > >>>>> __________________________________________________ LoST Issue
> > >>>>> Tracker <[email-masked]>
> > >>>>> <http://www.tschofenig.priv.at:8080/lost/issue2>
> > >>>>> __________________________________________________
> > >>>>>
> > >>>>> _______________________________________________ Ecrit 
> mailing list
> > >>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> > >>>>>
> > >>>> 
> ---------------------------------------------------------------------
> > --
> > >>>>
> > >> -------------------------
> > >>
> > >>>> 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]
> > >>>>
> > >>>>
> > >>>> 
> ---------------------------------------------------------------------
> > --
> > >>>>
> > >> -
> > >>
> > >>>> _______________________________________________ Ecrit 
> mailing list
> > >>>> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> > >>>>
> > >>> _______________________________________________
> > >>> Ecrit mailing list
> > >>> [email-masked]
> > >>> https://www1.ietf.org/mailman/listinfo/ecrit
> > >>>
> > >>>
> > >>>
> > >
> > > 
> --------------------------------------------------------------
> ----------
> > ------------------------
> > > 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]
> > >
> > >
> > >
> > 
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> 
> --------------------------------------------------------------
> ----------------------------------
> 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]
> 

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

---

From: "Hearty, John" <[email-masked]>
Date: Mon, 12 Jun 2006 13:04:02 -0600

>(1) a (purportedly) single location determined by two different  
>mechanisms, i.e., with the potential that civic and geo are actually  
>not referring to the same point or building due to measurement errors  
>of various sorts;

This is the case I was thinking of.  However, I can't think of any
reasons why the LoST server would want to take the less accurate
location into account when determining an answer.  If someone can think
of a good reason, then it makes sense to allow both in one query.  If
not, one or the other in a single query makes the most sense to me for
this case.

John

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, June 08, 2006 7:39 AM
To: Thomson, Martin
Cc: [email-masked]
Subject: Re: [Ecrit] [issue2] Is it allowed to specify civicand

I have no objection to having a "hybrid" address if it is indeed  
logically a single address which can never, ever lead to two  
different PSAPs. As Marc notes, one has to ask if this is really the  
best way to organize location information since we are now  
commingling two very different cases:

(1) a (purportedly) single location determined by two different  
mechanisms, i.e., with the potential that civic and geo are actually  
not referring to the same point or building due to measurement errors  
of various sorts;

(2) a hybrid location, where x and y coordinates are specified in geo  
and z coordinates in "civic" (floors)

Plus, there are then the various civic "enhancements" such as  
building names, suite number or tenant name that are useful in  
practice, so they might also get thrown in for model (2).

Maybe this is a geopriv topic, but this strikes me as a recipe for  
confusion. Having to pick apart the various cases of

- geo has altitude, civic has (only) a floor, but maybe also a  
building name -> could be (1) or (2)

- geo has no altitude, civic has only floor (but maybe also building  
name and tenant or house number) -> (2)

- geo has no altitude, but civic has street-level addressing -> (1)

- and plenty more

seems to lead to lots of special cases that are likely to increase as  
we add more elements to either civic or geo.

Henning

On Jun 7, 2006, at 11:35 PM, Thomson, Martin wrote:

> <location-info> element as a single location.  You aren't sending  
> more than one location to the LoST server.  If you think about it  
> as a single "location" with multiple parts (elements), the fears  
> about multiple responses disappear.
>
> The only valid concern that remains is LoST server complexity.  But  
> when you scratch beneath the surface a little, this begins to be  
> less of a source of intestinal torment.  If we consider the  
> occasions where this composite location is possible, it quickly  
> resolves down to the floors altitude case, and not a whole lot  
> more.  In other words, I can't think of a good alternative  
> example.  That means that the LoST server can safely ignore the  
> "<civicAddress><FLR>2</FLR></civicAddress>" that goes along with  
> the geodetic information, except where you have the weird case  
> where the bottom-floor cinema is served by a different PSAP to the  
> upper-floors (not my example).
>