Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host

[Andrew Newton <andy at hxr.us>]

Well, the point I was trying to make was that each new location  
profile would have to account for location providing.  So, if we do  
geodetic-3d or rfc3825 or linser-locrel or whatever else comes along,  
we have to account for the fact that output has to also be the  
input.  I know that may not be such a big deal, but we never really  
know.  A simple key is easier on databases than the complex searching  
needed for location information, especially as the location profiles  
get more complex.

I agree about the special case.  But the behavior does not have to be  
a special case, it can be done all the time.  Essentially, a  
reference always exists inside a LoST mapping.  Anytime a LoST  
mapping is converted into a PIDF-LO, such as when the LIS is trying  
to get a the service boundary for a PSAP to use as location  
information, that reference goes along with it.  Later on, a VSP or  
whoever can simply use that reference to check the PSAP URI vs. using  
the location.

I admit, this is an optimization.  But we already have to change LoST  
a little bit.  We might as well try to make the subsequent policing  
against abuse as low cost as possible.

-andy

On Apr 20, 2007, at 4:21 PM, Henning Schulzrinne wrote:

> We had talked about a more generic 2D polygon description earlier,  
> primarily for wireless cases, so we may just get to do it now  
> rather than later.
>
> We already have the necessary location profile (polygon), as it is  
> used for the boundary.
>
> I don't see how re-using the service boundary reference helps. The  
> UA still has to understand the reference and polygon. Can you  
> describe exactly how this would work? I'd rather avoid special- 
> casing this particular use case ("do one thing when you get a  
> reference to a point, do something completely different when you  
> get a reference to a polygon").
>
> On Apr 20, 2007, at 3:50 PM, Andrew Newton wrote:
>
> > After having some more time to noodle on this...
> >
> > On Apr 20, 2007, at 4:50 AM, Hannes Tschofenig wrote:
> >
> > > 7. A VSP wishing to validate the PSAP URI takes the LbyR and  
> > > dereferences
> > > it.  The result will be the same (coarse) location the endpoint  
> > > got.  The
> > > VSP does a LoST query with that location, and should get the same  
> > > PSAP URI
> > > that is in the Request URI on the call.  This validation works  
> > > for coarse or
> > > fine validation, and of course works for LbyV without the  
> > > dereference step.
> >
> > This works without modification of LoST for civic, but I think it  
> > requires a modification of LoST for geo.  The LoST geodetic-2d  
> > location profile takes a point as input, not an area.
> >
> > That being said, I'm willing to live with the change to LoST to  
> > accommodate this requirement.  We could create a new location  
> > profile or modify geodetic-2d, but then every geodetic (or non- 
> > civic) location profile would have to accommodate this use case.   
> > If we are to do this, I'd rather have a more generic mechanism  
> > that requires no changes to location profiles by re-using the  
> > service boundary reference.  Such a service boundary reference  
> > could be conveyed in a PIDF-LO in a new element.  That also allows  
> > LoST resolvers to optimize their lookup to a simple key vs. the  
> > more complex location information.  The VSP wouldn't use the  
> > <findService> query for policing, but the <getServiceBoundary> query.
> >
> > -andy
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit at ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit


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