Subject: [Geopriv] A means for deriving location

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 14 Jul 2008 20:03:52 -0500

Hi Brian et al,

My thoughts on the derived location method are a little different. I
want to ensure that the linkage can be done, and I think this can be
done quite easily.

We define a new name space that defines a two attribute, the
sourceLocation attribute and the derivedFrom attribute. An XMl schema
for this is provided at the bottom of this email. Both the example below
and schema have been compiled and tested,

So here is what it would like for a specific PIFD-LO, where the street
address is derived from a geodetic location obtained using a GPS. 
The source location is identified as dl:sourceLocation="firstSource"
The derived location is identified as dl:derivedFrom="#firstSource"

This will allow you to have any number of derivations that you want in a
very easy to use manner.

<?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
         xmlns:dl="urn:ietf:params:xml:ns:geopriv:derived"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:gs="http://www.opengis.net/pidflo/1.0"
         entity="pres:[email-masked]">
       <tuple id="nesspc-1">
        <status>
          <gp:geopriv>
             <gp:location-info>
                 <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
				    dl:sourceLocation="firstSource">
                 <gml:pos>-34.410649 150.87651</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   30
                 </gs:radius>
               </gs:Circle>
             </gp:location-info>
             <gp:usage-rules/>
             <method>GPS</method>
           </gp:geopriv>
         </status>
          <timestamp>2007-06-22T20:57:29Z</timestamp>
        </tuple>
       <tuple id="ness">
          <status>
           <gp:geopriv>
             <gp:location-info>
               <civicAddress xml:lang="en-AU" 
				      dl:derivedFrom="#firstSource">
                 <country>AU</country>
                 <A1>NSW</A1>
                 <A3>     Wollongong
                 </A3><A4>North Wollongong
                 </A4>
                 <RD>Flinders</RD><STS>Street</STS>
                 <RDBR>Campbell Street</RDBR>
                 <LMK>
                   Gilligan's Island
                 </LMK> <LOC>Corner</LOC>
                 <NAM> Main Bank </NAM>
                 <PC>2500</PC>
                 <ROOM> 398 </ROOM>
                 <PLC>store</PLC>
                 <POBOX>Private Box 15</POBOX>
               </civicAddress>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Derived</method>
           </gp:geopriv>
        </status>
          <timestamp>2007-06-24T12:28:04Z</timestamp>
       </tuple>
     </presence>

<?xml version="1.0"?>
  <xs:schema
      targetNamespace="urn:ietf:params:xml:ns:geopriv:derived"
      xmlns:xs="http://www.w3.org/2001/XMLSchema">
  	<xs:attribute type="xs:anyURI" name="derivedFrom"/>
	<xs:attribute type="xs:token" name="sourceLocation"/>
  </xs:schema>

Cheers
James
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Jul 2008 21:26:46 -0400

If you open that can of worms, I'd go in a slightly different direction.  I
would create an element called "reference" or "id" and give it some value
that should be unique.  Then I would create a "derivedFrom" that could
contain such an id.  Both of these would be inside a location-info.

I've heard a couple of times a request to have some kind of a unique ID in a
PIDF, which would be fine if it was actually a location-info.  I think
that's better than creating a new namespace just for linkages.

We need some verbiage on when you used a new id.  I think it's a new
measurement, interpreted broadly enough that if anything in the
location-info changed, the id would need to be different.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Winterbottom, James
> Sent: Monday, July 14, 2008 9:04 PM
> To: [email-masked]
> Subject: [Geopriv] A means for deriving location
> 
> Hi Brian et al,
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Jul 2008 00:35:40 -0500

Before we get too carried away with all this - this really is a can 
of worms (i.e., there be dragons there) due to its impact on SIP as a 
message body that just doubled in size.  I don't think the impact 
will be felt as much when using NOTIFYs and PUBLISHs, but the impact 
on INVITE and UPDATE will be great (given that nearly all traverse 
more than one proxy which has to add headers of its own per proxy hop).

This is a HUGE hurdle, IMO - that affects multiple WGs in RAI -- as 
well as other SDOs and consortia

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Jul 2008 00:39:51 -0500

Hi James,

I am not sure what the impact here is beyond bits. Certainly I don't
expect each and every proxy to examine and understand the contents of
this message. We already have a PIDF-LO, this is just adding one extra
tuple.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, 15 July 2008 3:36 PM
> To: Brian Rosen; Winterbottom, James; [email-masked]
> Subject: Re: [Geopriv] A means for deriving location
> 
> >If you open that can of worms, I'd go in a slightly different
direction.
> I
> >I've heard a couple of times a request to have some kind of a unique
ID
> in a
> > > From: [email-masked] [mailto:[email-masked]]
On
> Behalf
> > > This will allow you to have any number of derivations that you
want in
> a
> > >       <xs:attribute type="xs:token" name="sourceLocation"/>
----------------------------------------------------------------------
> ----
> > > ----------------------
----------------------------------------------------------------------
> ----
> > > ----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Jul 2008 15:24:04 -0500

James

"Just adding one extra tuple..."

Your lack of appreciation of the message size issues SIP has been 
facing for years now is interesting, yet not completely surprising. 
You're not a SIP guy, and you don't really want to listen to me about 
anything.

So, if you are truly inclined, forward your post below to the main 
SIP list, asking if this "extra tuple" (and its additional 200 to 300 
or even 400 bytes) will be ok to add to SIP messages...

PS - You might want to read RFC 3428, specifically regarding the 
limitations imposed on message size that were foreseen in 2003, then 
consider MSRP (session-mode instant messaging) was created because of 
the size limitations folks were running into already (in 2006).

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Jul 2008 16:39:25 -0500

Hi James,

I have never claimed to be a SIP guy, and I do listen about SIP, and I have asked you a question or two in the past about specific things that you have failed to answer or even respond to. I do however claim to be a location a guy, and it would be nice if you listened to us from time to time!

If you look at my example more carefully, you will note that the derivedFrom attribute is a URI, this URI could be a location URI, so there is no need for the extra tuple. My point was that if SIP packet sizes is so critical then there should have been a much stronger objection to representing location as a PIDF-LO in the first place, and FAR FAR FAR LESS resistance to the notion of a location URI, something that I have been battling your (and others) opposition to for the best part of 5 years!

Regards
James

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Tue 7/15/2008 3:24 PM
To: Winterbottom, James; Brian Rosen; [email-masked]
Subject: RE: [Geopriv] A means for deriving location
 
James

James