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

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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