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
We could do that. That's true.
For the cellular case we could support the full
I would, however, leave this as an extension for later.
For the service boundary case we could obviously go for a much simpler
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
I also believe that defining a new location profile (or extending an
existing one) would be much simpler.
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
it. The result will be the same (coarse) location the endpoint
VSP does a LoST query with that location, and should get the same
that is in the Request URI on the call. This validation works for
fine validation, and of course works for LbyV without the
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.
Ecrit mailing list
Ecrit mailing list