|
|
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 could do that. That's true.
For the cellular case we could support the full
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt.
I would, however, leave this as an extension for later.
For the service boundary case we could obviously go for a much simpler
approach.
We already have the necessary location profile (polygon), as it is
used for the boundary.
Yes.
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").
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
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|