Subject: RE: [Geopriv] draft-thomson-geopriv-geo-shape-00

From: "Abbott, Nadine B" <[email-masked]>
Date: Mon, 6 Mar 2006 16:17:36 -0500

Henning,

Thanks for your expansion of my understanding of possible applications
for PIDF-LO.
And yes, I agree that the initial issue has already been satisfactorily
resoved.

I also agree with your position that it makes sense to specify a way to
describe polygons that can be re-used.
If we can't find a simple way to reference the appropriate description
in the GML standards, 
then the I-D on PIDF-LO Usage Clarification, Considerations and
Recommendations, draft-ietf-geopriv-pdif-lo-profile-03, does provide one
potential collection point for such information.  
I don't know that I would logically look there for GML descriptions of
polygons for other applications like LOST/LUMP, but if the document
cross-references are provided, then it can work.
   
If this PIDF-LO Usage... document is used as the GML polygon description
reference, then I think that we do need to provide clear guidance about
how PIDF-LO is used for emergency call support in the BCP for emergency
calling, as you suggest.

Nadine 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henning Schulzrinne
Sent: Monday, March 06, 2006 3:48 PM
To: Abbott, Nadine B
Cc: [email-masked]
Subject: Re: [Geopriv] draft-thomson-geopriv-geo-shape-00

Nadine,

I think the topic at hand has been resolved, but there's probably a
slightly larger issue that may well lead to other misunderstandings in
the future. Thus, maybe the PDIF/PDIF drafts can make this a bit
clearer. I think there are three somewhat separable issues; from your
note, I think we're largely in agreement:

(1) PIDF-LO will be used to convey information about people or objects
in fairly generic environments. We can't really anticipate what kind of
objects these will be, and they may have odd shapes. (Picture a
presentity that represents some game region or avatar in a new
coordinate system.)

(2) PIDF-LO will be used for some well-defined, fairly narrowly-scoped
applications, such as the body of an INVITE heading to a PSAP. That is
unlikely to require to describe the borders of Manhattan. It probably
makes sense to restrict what PSAPS need to deal with; the BCP for
emergency call device behavior seems like a good place to collect such
information.

(3) Some of the same GML elements used in PIDF-LO will be used as region
descriptions in LUMP/LoST, for example. Another likely application are
privacy policy documents. It makes sense to have a single way to
describe polygons in XML in IETF protocols, not half a dozen, unless
there's a strong need for generic GIS functionality. I don't think we
need additional I-Ds for that, just appropriate language in the PDIF
(spelling intentional, echoing the draft spelling typo...) and geo-shape
drafts.

Does this make sense?

Henning

Abbott, Nadine B wrote:
> I think I need a forest guide to help me sort the forest from the 
> trees....
> 
> Political geographical boundaries, e.g., counties, nations, etc. are 
> likely to be described in the routing databases for location-based 
> services.  Passing around in a PIDF-LO all the geo-coordinate 
> information necessary to describe such a polygon, just to describe the

> presence/location of an individual user, seems like a waste of 
> signaling resources to me, when such a location can so economically be

> described with a civic location object.
> 
> I understood the motivation for providing polygon information in a 
> PIDF-LO to be primarily to describe the estimated coverage of a 
> wireless access point or to describe building or campus locations when

> more accurate  information to pinpoint the location of a user could 
> not be provided.
> If applications arise that require providing more detailed boundaries 
> that are not easily represented by civic location shorthand, then we'd

> want the specification to allow for that. But I wouldn't think it 
> would be the norm? Some implementation guidance seems appropriate for 
> the applications that we do know about.
> 
> I think that the requirements of LUMP/LOST to describe boundary 
> information for serving areas are entirely different from the 
> requirements for the PIDF-LO which is intended to describe the 
> location of an individual.
> I don't think we'd want to impose the needs of the location-based 
> routing information protocols on supporting location information for 
> users in SIP message bodies, myself.  If advice about using GML is 
> needed for other applications, then perhaps there is a need for a BCP 
> or something to provide that advice, rather than morphing PIDF-LO to 
> support all applications.
> Are there not any concerns about the size of PIDF-LO in the message 
> body that would be required to support civic geographic boundaries in 
> terms of vertices in the thousands?
> 
> Respectfully,
> Nadine Abbott
> 
>    
>  
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Henning Schulzrinne
> Sent: Sunday, March 05, 2006 9:57 AM
> To: Winterbottom, James
> Cc: [email-masked]; James M. Polk
> Subject: Re: [Geopriv] draft-thomson-geopriv-geo-shape-00
> 
> There is a big difference between giving implementation advice and 
> artificially restricting functionality. As noted, PIDF-LO has broad 
> applicability, with many applications that we can't predict, most of 
> which won't involve emergency calls or 3G.
> 
> There is a somewhat separate aspect: The description in these drafts 
> is also taken as advice on how to use GML within other IETF documents.

> (My remark was actually triggered by the attempt of a grad student of 
> mine to integrate the polygon description into the LUMP/ LoST test 
> implementation of ours, to describe regions.) There, the 16- point 
> limit makes absolutely no sense.
> 
> On Mar 5, 2006, at 3:01 AM, Winterbottom, James wrote:
> 
>> I would actually suggest in that case that we use the 16 point bound 
>> as a limitation for Location routing applications also. I think that 
>> trying to perform arbitrary spatial lookups based on a polygon 
>> containing many 100s of points is hardly going to be something that 
>> we
> 
>> want to try an do in real or near real time. I might also question 
>> the
> 
>> need for someone to need to express their personal presence in such a

>> way, but that is a different discussion completely.
>>
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 6 Mar 2006 16:36:18 -0500

Unfortunately, putting language in the phone/proxy BCP won't help.  What you
are talking about is what the location server supplies, which in turn would
be what the sighter provides.  You don't want a UA massaging location data
from a big polygon to a little one.  That means what the UA gets has to be a
little one, and that means what sends it location (DHCP, HELD, LCP, ...) has
to only send a little polygon.  It's not clear to me exactly how a presence
system is going to cope with possibly conflicting needs here.  It could deal
with massaging data, but in general, it's not in the emergency call path.

Brian

-----Original Message-----
From: Abbott, Nadine B [mailto:[email-masked]] 
Sent: Monday, March 06, 2006 4:18 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [Geopriv] draft-thomson-geopriv-geo-shape-00

Henning,

   

Nadine 

-----Original Message-----

Nadine,

Does this make sense?

Henning

---

From: [email-masked]
Date: Tue, 7 Mar 2006 10:52:26 -0500 (EST)

For those cases in which more complex geospatial geometry is available:
How about an optional element that allows specification a URL/URI to the
more semantically rich (read more coordinate) geospatial content? That
way, UA messaging can provide the "little" one (which could be a degraded
version of the "real" polygon expression).

Just a thought.

Carl