Subject: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 28 Jul 2008 22:26:27 -0500

http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00

Specifying Derived Location in a PIDF-LO

Abstract
 
   This document describes how specify that a location in a PIDF-LO has
   been derived or converted from a different location.  The source
   location may reside in the same PIDF-LO or be a remote document
   referenced by a location URI and associated id fragement.

Feedback appreciated.

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: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 13:31:29 +0300

Sounds like a useful way to indicate the derived location

Winterbottom, James wrote:
> ------------------------------------------------------------------------
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 29 Jul 2008 07:21:49 -0500

>Sounds like a useful way to indicate the derived location

this does not to me, as it greatly (almost doubles as far as I can 
see) the number of bytes in the LO.

We shouldn't willfully put blinders up to the contraints of a viable, 
in fact built for, transport protocol (i.e., SIP and the 
considerations it has taken great lengths to go to towards MTU 
limitations of UDP over Ethernet).

>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 29 Jul 2008 07:50:54 -0500

I see very real issues with deriving a civic location from a geodetic
location, when wireless geodetic locations became widely available this
"reverse geocoding" caused many problems. Personally I see no value but
many issues that can come about from a derived civic location.

I will try to expand on these issues (while not being able to draw
pictures to illustrate) from a "Lessons Learned" aspect.

1.) Geodetic location comes in and a civic location is derived from the
nearest know civic location, but the geodetic location is centered on a
building in a large campus or a large apartment building. The nearest
civic location is the entrance to the large campus or apartment complex,
so you have lost desirable information of the more precise location in
favor of the civic location given to the campus or apartment building.

2.) Same scenario as above, but this time the nearest civic location is
NOT the same as the civic location provided to the apartment complex or
campus. The nearest civic location is provided and a delayed response is
caused by providing the incorrect civic location.

3.) A geodetic location come in from a boat in the lake, river,  or bay.
The derived civic location is a home on the lake, river, or bay. Delayed
response due to incorrect location being provided.

4.) Vehicle on interstate highway (limited access highway) provides
geodetic location, derived civic location is along the highway but a
delayed response takes place because not only is the civic location
derived incorrect but the responding agency has to drive miles to gain
access to the limited access highway when the correct responding agency
is near the access point of the limited access highway.

I could and can go on and on on scenarios that can (and have) occurred
due to derived locations, but let me put forth another consideration. 

The service providing the derived location is using a spatial dataset,
but it is not being maintained to the same level as the spatial data
being used at the PSAP, out of date information is passed to the PSAP -
LIBALITY ISSUE. We update our spatial data on a minute by minute basis,
with literaily hundreds of changes taking place each day. There are just
so many little differences that could exist between the derived location
and the actual location provided by a trained call taker, that is
familiar with the local geography, that this could easily become a
disaster and gain major news coverage that could deal the industry and
the confidence of the public a significant setback.

Aside from these concerns I did notice a few gramatical inconsistancies
in the draft.

Thanks,

 Marc B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Tuesday, July 29, 2008 5:31 AM
To: Winterbottom, James
Cc: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Announce: Specifying Derived Location in a
PIDF-LO

 

Winterbottom, James wrote:

------------------------

------------------------

Geopriv mailing list

[email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 29 Jul 2008 07:53:54 -0500

If I use a reference to an external location how is this doubling the size of the PIDF-LO?
I also though that location information was generally only going be sent if TLS was used, which would rule out the use of UDP as a viable transport wouldn't it? Certainly I would be uncomfortable sending my location in an unencrypted UDP packet as I hardly think that that meets the general requirements of a using protocol.

Cheers
James

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 29 Jul 2008 07:58:49 -0500

(Let's keep the discussion on the GEOPRIV list now.)

The alternative to this is to not include "derived" location information at all.  You might argue that this is valid, but there are use cases for this.  Attacking the solution because it might be harmful in a subset of cases is not going to change anything.

It might be worth pointing out that including derived location information in the INVITE for an emergency call is bad, I wouldn't be against that.

Cheers,
Martin

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Tuesday, 29 July 2008 1:22 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 29 Jul 2008 07:56:26 -0500

Marc don't shoot the messenger.
There was discussion in ECRIT that having a method of derived was a necessary thing.
What I have tried to say is that if you are going to have that method then it is pretty important to know from what the location was derived. The draft basically provides you a way to tie the derived location back to the source, and it says that if you can't find the source then be careful of how much faith you put into the location.

Yup, it has quite a few typos and grammatical problems that I will fix in the enxt rev.

Cheers
James

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]]
Sent: Tue 7/29/2008 7:50 AM
To: Hannes Tschofenig; Winterbottom, James
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO

Thanks,

 Marc B

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

 

Winterbottom, James wrote:

Geopriv mailing list

[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 16:02:41 +0300

When you want to convey information about
* your derived location, and
* the original information
then this is a good way to go.

I agree that XML isn't super small.

I do, however, think that just providing a token saying that the current 
location is "derived" does not provide a lot of info for the recipient.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 29 Jul 2008 08:10:47 -0500

>If I use a reference to an external location how is this doubling 

Are there 2 (as in TWO) <location-info> elements?

that doubles the size

I see 2 in the example IN YOUR ID...  you've made this point in a 
previous message and I still see TWO <location-info> elements, where 
there should be only one in as many cases as we we can limit

this isn't *just* a URI element added to what's already there in the LO

>I also though that location information was generally only going be 
>sent if TLS was used, which would rule out the use of UDP as a 
>viable transport wouldn't it? Certainly I would be uncomfortable 
>sending my location in an unencrypted UDP packet as I hardly think 
>that that meets the general requirements of a using protocol.

James, YOU keep making these points as if everyone has YOUR values 
and uses protocols only YOUR way.  Are you (as a single entity) 
representative of the entire human race?

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 16:13:35 +0300

Hi Marc,

I agree with you that re-coding isn't the ideal solution.
Now, the question is: What do we do when someone still does it? We are 
not the deployment police.
Should we indicate the fact that re-coding has happened? How should we 
indicate it?

Ciao
Hannes

Marc Berryman wrote:
> location, when wireless geodetic locations became widely available 
> this “reverse geocoding” caused many problems. Personally I see no 
> value but many issues that can come about from a derived civic location.
>
> pictures to illustrate) from a “Lessons Learned” aspect.
>
> 1.) Geodetic location comes in and a civic location is derived from 
> the nearest know civic location, but the geodetic location is centered 
> on a building in a large campus or a large apartment building. The 
> nearest civic location is the entrance to the large campus or 
> apartment complex, so you have lost desirable information of the more 
> precise location in favor of the civic location given to the campus or 
> apartment building.
>
> 2.) Same scenario as above, but this time the nearest civic location 
> is NOT the same as the civic location provided to the apartment 
> complex or campus. The nearest civic location is provided and a 
> delayed response is caused by providing the incorrect civic location.
>
> 3.) A geodetic location come in from a boat in the lake, river, or 
> bay. The derived civic location is a home on the lake, river, or bay. 
> Delayed response due to incorrect location being provided.
>
> access to the limited access highway when the correct responding 
> agency is near the access point of the limited access highway.
>
> being used at the PSAP, out of date information is passed to the PSAP 
> - LIBALITY ISSUE. We update our spatial data on a minute by minute 
> basis, with literaily hundreds of changes taking place each day. There 
> are just so many little differences that could exist between the 
> derived location and the actual location provided by a trained call 
> taker, that is familiar with the local geography, that this could 
> easily become a disaster and gain major news coverage that could deal 
> the industry and the confidence of the public a significant setback.
>
> Aside from these concerns I did notice a few gramatical 
> inconsistancies in the draft.
>
> Thanks,
>
> Marc B
>
> Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO
>

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 29 Jul 2008 08:19:47 -0500

James,
 Did not intend to send flaming arrows toward the messenger, just
pointing out the operational issues to the rest of the group.

Marc B

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 7:56 AM
To: Marc Berryman; Hannes Tschofenig
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a
PIDF-LO

Marc don't shoot the messenger.
There was discussion in ECRIT that having a method of derived was a
necessary thing.
What I have tried to say is that if you are going to have that method
then it is pretty important to know from what the location was derived.
The draft basically provides you a way to tie the derived location back
to the source, and it says that if you can't find the source then be
careful of how much faith you put into the location.

Yup, it has quite a few typos and grammatical problems that I will fix
in the enxt rev.

Cheers
James

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]]
Sent: Tue 7/29/2008 7:50 AM
To: Hannes Tschofenig; Winterbottom, James
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a
PIDF-LO

Thanks,

 Marc B

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

 

Winterbottom, James wrote:

Geopriv mailing list

[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 16:25:49 +0300

>> sent if TLS was used, which would rule out the use of UDP as a viable 
>> transport wouldn't it? Certainly I would be uncomfortable sending my 
>> location in an unencrypted UDP packet as I hardly think that that 
>> meets the general requirements of a using protocol.
>
> James, YOU keep making these points as if everyone has YOUR values and 
> uses protocols only YOUR way.  Are you (as a single entity) 

I am not sure why you guys are arguing around on this issue.

* We know that location information is encoded in XML and not 
particularly small.
* We also know that there are security issues with passing location 
information around. Hence, we use security protocols.

What we should think about is whether it makes sense to indicate that 
location was derived. If you want to indicate that location was derived 
then there is the question on how to express that fact.

Ciao
Hannes

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 29 Jul 2008 08:56:32 -0500

As long as it clearly noted that the location is derived from geodetic
then I am fine. How to indicate? Provide both geodetic and derived. If
geodetic is provided then one can safely assume the provided civic is
derived (I would hope).

Marc B

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 8:14 AM
To: Marc Berryman
Cc: Winterbottom, James; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Announce: Specifying Derived Location in a
PIDF-LO

Hi Marc,

Ciao
Hannes

Marc Berryman wrote:
> this "reverse geocoding" caused many problems. Personally I see no 

PIDF-LO

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 29 Jul 2008 07:04:39 -0700

Hannes is right to point out that it is better to be clear than to
assume.

PIDF-LO has already has had capability of providing multiple locations -
even more than 2.  If there is a label 'derived', for one of them, there
needs to be a identifier that points back to the original.  This is
better than guessing.

-roger marshall. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Berryman
> Sent: Tuesday, July 29, 2008 6:57 AM
> To: Hannes Tschofenig
> As long as it clearly noted that the location is derived from 
> geodetic then I am fine. How to indicate? Provide both 
> geodetic and derived. If geodetic is provided then one can 
> safely assume the provided civic is derived (I would hope).
> 
> Marc B
> 
> Now, the question is: What do we do when someone still does 
> it? We are not the deployment police.
> Should we indicate the fact that re-coding has happened? How 
> should we indicate it?
> 
> Ciao
> Hannes
> 
> Marc Berryman wrote:
> >

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 29 Jul 2008 09:31:39 -0500

At 08:25 AM 7/29/2008, Hannes Tschofenig wrote:

>>>I also though that location information was generally only going 
>>>be sent if TLS was used, which would rule out the use of UDP as a 
>What we should think about is whether it makes sense to indicate 
>that location was derived. If you want to indicate that location was 
>derived then there is the question on how to express that fact.

no

it should be talked about in a way to determine whether this id done at all.

I do not believe that someone can say "well, it's being done now, so 
we might as well standardize it"... that won't stop me (or someone 
else) from doing the same thing about another topic the rest of the 
WG might not like/accept.

Some things ought to remain out of the standards, and I am not 
hearing a good enough reason to include this one in our efforts.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 29 Jul 2008 11:39:56 -0400

Actually, no.

All you need to specify that a location is derived is to have the method
token set to derived.

James thinks there is value in linking the derived PIDF to the original
PIDF.

That is a separate question.

I think there is some merit in the basic idea of linking.

I wonder if this is a specific case of a more general notion: expressing a
relationship between two PIDFs?

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Tuesday, July 29, 2008 9:26 AM
> To: James M. Polk
> Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in a
> PIDF-LO
> 
> 
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 29 Jul 2008 10:48:46 -0500

Read the draft folks.

This is _exactly_ what the draft does: it defines how to indicate that a location is derived.  It also specifies how to identify the location that it was derived from.

Cheers,
Martin

> Behalf Of Roger Marshall
> Sent: Tuesday, 29 July 2008 3:05 PM
> CONFIDENTIALITY NOTICE: The information contained in this message may
> be privileged and/or confidential. If you are not the intended
> recipient, or responsible for delivering this message to the intended
> recipient, any review, forwarding, dissemination, distribution or
> copying of this communication or any attachment(s) is strictly
> prohibited. If you have received this message in error, please notify
> the sender immediately, and delete it and all attachments from your
> computer and network.
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Jul 2008 18:29:24 +0100

Moreover, it doesn't just *identify* what location the derived location
was derived from, it enables the recipient to get the source location
(or at least request it, with LbyR).  This seems to me like a major step
toward providing better location even when people do geo-code.

For this function, I think a little bit of length is unavoidable I don't 
think there's a way to do the above (provide source location) without 
either including the source or a reference to it.  And, of course, the 
use of this extension is optional; maybe you just can't use it in a 
low-bandwidth environment.

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 29 Jul 2008 16:34:31 -0500

James,

Please look at the example below and tell me how this is twice the size of an existing PIDF-LO?
This is in the draft, and IS just adding a URI element, it is just that we have the flexibility to have the URI point to an element in the same document.

<?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="ness">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <civicAddress xml:lang="en-AU"
         dl:derivedFrom="held://lis.example.com:9128/xyz#freddy">
                 <country>AU</country>
                 <A1>NSW</A1>
                 <A3>     Wollongong
                 </A3><A4>North Wollongong
                 </A4>
                 <RD>Flinders</RD><STS>Street</STS>
                 <RDBR>Campbell Street</RDBR>
                 <PC>2500</PC>
                 <POBOX>Private Box 15</POBOX>
               </civicAddress>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Derived</method>
           </gp:geopriv>
         </status>
         <timestamp>2008-07-24T12:28:04Z</timestamp>
       </tuple>
     </presence>

Next, please explain to me how an unencrypted plain-text UDP packet containing my SIP identity and my location information complies with 3863?

YOU go on and on and on about this stuff, yet then YOU turn around with complete and utter this kind of garbage. It would be  nice, just once, to see you say something constructive rather than feeling you always have to compete.

Cheers
James

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Tue 7/29/2008 8:10 AM
To: Winterbottom, James; Hannes Tschofenig
Cc: [email-masked]; [email-masked]
Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in  a PIDF-LO

that doubles the size

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 29 Jul 2008 16:37:02 -0500

Thanks Marc, that is what the draft does.
It also gives you the option of not transporting the geodetic location, but provides a pointer to where it can be obtained to address the size issue that the other James is talking about.

Cheers
James

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]]
Sent: Tue 7/29/2008 8:56 AM
To: Hannes Tschofenig
Cc: Winterbottom, James; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO

Marc B

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 8:14 AM
To: Marc Berryman
Cc: Winterbottom, James; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Announce: Specifying Derived Location in a
PIDF-LO

Hi Marc,

Ciao
Hannes

PIDF-LO

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 29 Jul 2008 16:41:28 -0500

To be clear, this is expressing a relationship between any two things that have an XML <id> attribute.
The draft shows how this can be done to link two location chunks providing the location chunks follow the rules laid out in PIDF-LO profile.

Derived from is one way this can be used.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Tue 7/29/2008 10:39 AM
To: 'Hannes Tschofenig'; 'James M. Polk'
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location in aPIDF-LO
 
Actually, no.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 29 Jul 2008 18:21:49 -0400

If you were generalizing it:
1. You would want some more generalized id I think.  Perhaps that is what
you have, but I don't really see it so far.  Specifically, it has to be
unique across PIDFs/XML documents/message bodies.  A GUID might be
appropriate

2. You want to specify the relationship.  "Derived from" is one
relationship.  "Same target, different time" is another. 

> Sent: Tuesday, July 29, 2008 5:41 PM
> To: Brian Rosen; Hannes Tschofenig; James M. Polk
> Subject: RE: [Ecrit] [Geopriv] Announce: Specifying Derived Location in
> aPIDF-LO
> 
> The draft shows how this can be done to link two location chunks providing
> the location chunks follow the rules laid out in PIDF-LO profile.
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 29 Jul 2008 19:19:02 -0500

Hi Brian,

Thanks for the constructive input.
I do think that we need to determine if this is something that people
think is generally worthwhile doing. I am hearing one resounding no, and
at least one saying they would prefer that derived locations didn't
happen but if they are going to then it is better we can see where they
came from.

So before we decide to make a generic solution for any linking between
any PIDF elements, can we have a clear yes or no whether people want a
linkage mechanism. If we decide we want to do this, then we have to
decide where to do it, ECRIT, GEOPRIV, or SIMPLE (since this is the
organization that owns PIDF).

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 30 July 2008 8:22 AM
> To: Winterbottom, James; 'Hannes Tschofenig'; 'James M. Polk'
> > To be clear, this is expressing a relationship between any two
things
> that
> > have an XML <id> attribute.
> > Subject: Re: [Ecrit] [Geopriv] Announce: Specifying Derived Location
in
> > I wonder if this is a specific case of a more general notion:
expressing
> a
> > > Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived
Location
> in
> > a
> viable
> > > >> transport wouldn't it? Certainly I would be uncomfortable
sending
> my
> and
that
> --
> > ----------------------
> --
> > ----------------------

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 30 Jul 2008 03:05:22 -0700

Yes, I'm an advocate of a linking mechanism.  Though I'm not sure that
it needs to be as general as Brian suggests. 

-roger.

> [mailto:[email-masked]] On Behalf Of Winterbottom, James
> Sent: Tuesday, July 29, 2008 5:19 PM
> Location inaPIDF-LO
> I do think that we need to determine if this is something 
> that people think is generally worthwhile doing. I am hearing 
> one resounding no, and at least one saying they would prefer 
> that derived locations didn't happen but if they are going to 
> then it is better we can see where they came from.
> 
> So before we decide to make a generic solution for any 
> linking between any PIDF elements, can we have a clear yes or 
> no whether people want a linkage mechanism. If we decide we 
> want to do this, then we have to decide where to do it, 
> ECRIT, GEOPRIV, or SIMPLE (since this is the organization 
> that owns PIDF).
> 
> Cheers
> James
> 
> 
> 
> > > Subject: RE: [Ecrit] [Geopriv] Announce: Specifying 
> Derived Location
> in
> > > aPIDF-LO
> > >
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.
> > >

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 30 Jul 2008 05:17:10 -0500

Can we PLEASE keep this discussion to GEOPRIV only?  I'm getting far too many extra emails.

The linking mechanism proposed is already almost as general as Brian wants.  A GUID makes the element identifier (semi-)globally unique.  But without a means to access that element globally, there is no point in going to that effort.

Using the mechanisms built in to XML for identifying elements is the right thing to do.  Using a URI is the right thing to do.

In all this discussion, all I'm seeing is agreement with what is in the draft.

Cheers,
Martin

> Sent: Wednesday, 30 July 2008 11:05 AM
> To: Winterbottom, James; Brian Rosen; Hannes Tschofenig; James M. Polk
> Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location
> inaPIDF-LO
> 
> > > Subject: RE: [Ecrit] [Geopriv] Announce: Specifying Derived
> Location
> > in
> > > aPIDF-LO
> > >
> > > 1. You would want some more generalized id I think.  Perhaps that
> is
> > what
> > > you have, but I don't really see it so far.  Specifically, it has
> to
> > be
> > > > > From: [email-masked] [mailto:geopriv-
> [email-masked]]
> > On
> > > > Behalf
> > > > > Of Hannes Tschofenig

---

From: "Marc Berryman" <[email-masked]>
Date: Wed, 30 Jul 2008 06:50:50 -0500

James,

Existing NENA Standards state that when geodetic is available it will be
delivered. I think it is preferred that a pointer provide the derived
location and to always deliver the geodetic location in the PIDF-LO,
either LbV or LbR.

Marc B

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 4:37 PM
To: Marc Berryman; Hannes Tschofenig
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a
PIDF-LO

It also gives you the option of not transporting the geodetic location,
but provides a pointer to where it can be obtained to address the size
issue that the other James is talking about.

Cheers

James

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

To: Hannes Tschofenig

derived (I would hope).

Marc B

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

To: Marc Berryman

PIDF-LO

Hi Marc,

indicate it?

Ciao

Hannes

Marc Berryman wrote:

> value but many issues that can come about from a derived civic

location.

PIDF-LO

------------------------

------------------------

 

[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 30 Jul 2008 08:15:27 -0400

Marc B

We would state that derived locations MUST NOT be sent in an emergency call.
I could imagine sending derived locations within an ESInet, although I would
discourage that.

Brian

  _____  

Of Marc Berryman
Sent: Wednesday, July 30, 2008 7:51 AM

James,

Existing NENA Standards state that when geodetic is available it will be
delivered. I think it is preferred that a pointer provide the derived
location and to always deliver the geodetic location in the PIDF-LO, either
LbV or LbR.

Marc B

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 4:37 PM
To: Marc Berryman; Hannes Tschofenig
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO

It also gives you the option of not transporting the geodetic location, but
provides a pointer to where it can be obtained to address the size issue
that the other James is talking about.

Cheers

James

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

To: Hannes Tschofenig

derived (I would hope).

Marc B

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

To: Marc Berryman

PIDF-LO

Hi Marc,

indicate it?

Ciao

Hannes

Marc Berryman wrote:

location.

PIDF-LO

------------------------

------------------------

 

----------------------------------------------------------------------------
--------------------

----------------------------------------------------------------------------
--------------------

[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 30 Jul 2008 10:20:34 -0500

At 07:58 AM 7/29/2008, Thomson, Martin wrote:
>The alternative to this is to not include "derived" location 
>information at all.  You might argue that this is valid, but there 
>are use cases for this.  Attacking the solution because it might be 
>harmful in a subset of cases is not going to change anything.

this is a solution without a substantial requirement to justify its creation.

Where is that requirements document that doesn't have a solution with 
reverse engineered requirements to fit the solution?

I will push for a requirement that doesn't double the size of the LO, 
and can't believe if most don't agree with this.  That said, this 
isn't even under specific discussion, because of the lack of the 
requirements discussion. We're just looking at the solution.

Don't we keep talking about how bad an idea this is (solutions before 
requirements)?

>It might be worth pointing out that including derived location 
>information in the INVITE for an emergency call is bad, I wouldn't 
>be against that.

how about just having a URI (to be dereferenced) as the only 
<derived-from> element value?

I keep seeing a separate <location-info> element with a full location 
as the derived location. This is the waste, and expensive, bandwidth 
hog that should be avoided.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 30 Jul 2008 16:25:49 -0500

Hi Marc,

Thanks for that, though that does seem like a matter for ECRIT to think about.
The draft doesn't say which one to send, just how to link the locations.

Cheers
James

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]]
Sent: Wed 7/30/2008 6:50 AM
To: Winterbottom, James; Hannes Tschofenig
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a PIDF-LO
 
James,

Marc B

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 4:37 PM
To: Marc Berryman; Hannes Tschofenig
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Announce: Specifying Derived Location in a
PIDF-LO

Cheers

James

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

To: Hannes Tschofenig

derived (I would hope).

Marc B

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

To: Marc Berryman

PIDF-LO

Hi Marc,

indicate it?

Ciao

Hannes

Marc Berryman wrote:

location.

PIDF-LO

------------------------

------------------------

 

[mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 30 Jul 2008 16:44:55 -0500

Hi James,

"how about just having a URI (to be dereferenced) as the only 
<derived-from> element value?

I keep seeing a separate <location-info> element with a full location 
as the derived location. This is the waste, and expensive, bandwidth 
hog that should be avoided."

[AJW] The only reason you keep seeing this is because you haven't read the draft:
The abstract says "The source
   location may reside in the same PIDF-LO or be a remote document
   referenced by a location URI and associated id fragement."

Section 4 on page 7 is titled "Linking to External Locations"
With figure 2 showing how this is done.

And to cap it off I sent an email to the list yesterday asking how figure 2 supposedly doubled the size the PIDF-LO. 
http://www.ietf.org/mail-archive/web/geopriv/current/msg06141.html

The concept of this is a trivial thing and really doesn't warrant a complete requirements document for it. If you want more information in the document about taking care not to over inflate the PIDF-LO when SIP is being used over UDP, we can do that. I have received some other very good feed back from others also that I will include in the next rev.

Cheers
James

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 30 Jul 2008 17:53:43 -0500

>In all this discussion, all I'm seeing is agreement with what is in the draft.

hmmm - I was the third person to reply to this thread, and I replied 
negatively.

Did you miss that message in your count of the 5 or so messages that 
there are to count?

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 31 Jul 2008 02:46:48 -0500

>    referenced by a location URI and associated id fragement."

I'm saying it shouldn't be possible to have this long, protracted 
dual <location-info> element in the first place.

>With figure 2 showing how this is done.

this should be your proposal

>And to cap it off I sent an email to the list yesterday asking how 
>figure 2 supposedly doubled the size the PIDF-LO.

great -- but some of us are occasionally busy enough that we don't 
get to our email within 1 day's time, so stop berating me for not 
immediately having read and understood and agreed with your note....

jeez, dude, lighten up

>The concept of this is a trivial thing and really doesn't warrant a 
>complete requirements document for it.

that, I believe, is your opinion -- which occurs towards your work.

>If you want more information in the document about taking care not 
>to over inflate the PIDF-LO when SIP is being used over UDP, we can do that.

ignorance of the constraints of other protocols is an interesting 
plea, especially when we've talked about this topic before -- 
including face2face.

>I have received some other very good feed back from others also that 
>I will include in the next rev.
>
>Cheers
>James
>
>
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 31 Jul 2008 16:24:03 -0500

Hi James,

The big PIDF-LO horse has long since bolted from the stables.
If you are looking for a lean and slick way to represent location for specific functions, such as routing, then we need to totally re-think our representation and perhaps look at binary forms.

I think that it is too late to argue that PIDF-LO is too big.

Cheers
James

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Thu 7/31/2008 2:46 AM
To: Winterbottom, James; Thomson, Martin; Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in  a PIDF-LO

jeez, dude, lighten up

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 31 Jul 2008 15:46:42 -0600

Not to muddy the water on this topic, but if there is ever a need for a more compact LO in addition to the current LO, consider GeoJSON approach which is modelled on GeoRSS GML. Very compact and still human readable.

A GeoJSON polygon coding looks like:

 {"type":"Feature", "id":"OpenLayers.Feature.Vector_124", "properties":{}, "geometry":{"type":"Polygon", "coordinates":[[[-1.40625, 24.2578125], [-4.21875, 7.3828125], [42.890625, 3.8671875], [29.53125, 29.1796875], [10.546875, 25.6640625], [-1.40625, 24.2578125]]]}, "crs":{"type":"OGC", "properties":{"urn":"urn:ogc:def:crs:OGC:1.3:CRS84"}}}

As one of the original GeoRSS authors, I am a bit biased :-)

Carl

---

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Aug 2008 09:57:22 +0100

>Not to muddy the water on this topic, but if there is ever a need for a more compact LO in addition to the current LO, consider GeoJSON approach which is modelled on GeoRSS GML. Very compact and sti…

While I would be happy to agree to "compact", I think your value of human readable
is for some value of human that wouldn't include most of the planet.  As a rule of
thumb, anything that involves floating point numbers and mixed/nested brackets and braces is not really human readable.  Can we maybe agree on "textual" :) ?

The key thing that makes an LO in geopriv, though, is the policy association
with the location.  If we wish to make a compact LO based on GeoJSON,
we'd need to find some equally compact way of expressing the policies.

regards,

Ted

>From: "Winterbottom, James" <<mailto:[email-masked]>[email-masked]>
>To: "James M. Polk" <<mailto:[email-masked]>[email-masked]>; "Thomson, Martin" <<mailto:[email-masked]>[email-masked]>; "Hannes Tschofenig" <<mailto:[email-masked]>[email-masked]>
>Cc: <<mailto:[email-masked]>[email-masked]>
>> Cc: <mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>[email-masked]
>> <https://www.ietf.org/mailman/listinfo/geopriv>https://www.ietf.org/mailman/listinfo/geopriv
>
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=200;
>	creation-date="Thu, 31 Jul 2008 15:12:56 GMT";
>	modification-date="Thu, 31 Jul 2008 15:12:56 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 3594.txt (TEXT/ttxt) (0081526B)