Subject: [Ecrit] New versions of -framework and -phonebcp

From: "Brian Rosen" <[email-masked]>
Date: Thu, 10 Jul 2008 16:16:28 -0400

These versions incorporate all last call comments except as I have stated in
prior email. 

The majority of changes have to do with:
* More explicit text and references to -profile for multiple locations

* Requiring the return of dialstrings on LoST for sos service URNs.

* Lots of typos and wording changes.

I did end up adding a couple of requirements, and thus needed to renumber
the requirements, so diffs look bad.

I ask commenters to look at the text to make sure I made all the changes you
requested (with the exceptions covered in the emails).

Chairs can consider if they wish to hold a short 2nd WGLC.  There are a
couple of substantive changes and added requirements, but not a whole lot
text is modified in any but trivial ways.  

Brian

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

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Fri, 11 Jul 2008 11:59:31 +0200

Brian,

thank you for submitting the new versions of your documents.
However, I'm afraid you forgot my comments (except the LoSt dialstring "must").
My old posting:
http://www.ietf.org/mail-archive/web/ecrit/current/msg04936.html
In your reply to this mail you agreed to these points.

Karl Heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 11 Jul 2008 10:25:18 -0400

I am sorry, I don't know how I missed these.

>page 7: "The phone gets location from the DHCP server in civic
>[RFC4676] or geo" -> should it be "and/or"?
The text makes clear that multiple locations are problematic. Multiple
versions of the same location are problematic.  I worry about systems trying
to be helpful and giving you a measured location and also giving you a
derived (geo coded or reverse geo coded) version of the same location.

This does raise yet another issue about this general subject; looking at the
list at:
http://www.iana.org/assignments/method-tokens
There is no method for "derived".  So:
I will add text to -framework covering this subject
I will ask IANA to create a "Derived" method token
I will add a requirement to -phonebcp that says if you get both and one is
derived, you must use the non-derived value.

I've made the other changes in my source file and they will appear in the
next version.

Brian
> -----Original Message-----
> From: Karl Heinz Wolf [mailto:[email-masked]]
> Sent: Friday, July 11, 2008 6:00 AM
> To: Brian Rosen
> Cc: ECRIT
> Subject: Re: [Ecrit] New versions of -framework and -phonebcp
> 
> Brian,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 12 Jul 2008 12:04:21 +0300

Could you describe the semantic of the "Derived" method a bit more?

Brian Rosen wrote:
>>> These versions incorporate all last call comments except as I have
>>>       
>> stated in
>>     
>>> prior email.
>>>
>>> I did end up adding a couple of requirements, and thus needed to
>>>       
>> renumber
>>     
>>> I ask commenters to look at the text to make sure I made all the changes
>>>       
>> you
>>     
>>> couple of substantive changes and added requirements, but not a whole
>>>       
>> lot
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 12 Jul 2008 09:43:01 -0400

The "Derived" method is used when the PIDF creator has a location available
in one form (civic or geo) using another method, and derives a location in
the other form.  So for example, the determination method might be GPS,
which creates a geo and the PIDF includes a civic derived from that geo.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, July 12, 2008 5:04 AM
> To: Brian Rosen
> Cc: 'Karl Heinz Wolf'; 'ECRIT'
> Subject: "Derived" method
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 12 Jul 2008 16:48:48 +0300

Thanks.

Brian Rosen wrote:
>>> versions of the same location are problematic.  I worry about systems
>>>       
>> trying
>>     
>>> This does raise yet another issue about this general subject; looking at
>>>       
>> the
>>     
>>> list at:
>>> I will add a requirement to -phonebcp that says if you get both and one
>>>       
>> is
>>     
>>> I've made the other changes in my source file and they will appear in
>>>       
>> the
>>     
>>> next version.
>>>
>>> Brian
>>>
>>>       
>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen <[email-masked]>
>>>>         
>> wrote:
>>     
>>>>> I ask commenters to look at the text to make sure I made all the
>>>>>           
>> changes
>>     
>>>> you
>>>>
>>>>         
>>>>> Chairs can consider if they wish to hold a short 2nd WGLC.  There are
>>>>>           
>> a
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 12 Jul 2008 17:18:52 +0300

The problem is a bit with the semantic of the method token given that it 
was supposed to be used to indicate the location determination method.
There are some "wrong" entries in the table already with that semantic 
since something like "DHCP" refers to an LCP rather than the actual 
location determination method.

Now, I wonder whether it is possible to put more than one token into the 
method element. The data type is string and hence it would be possible.

To pick your example, could you indicate <method>gps derived</method>?

Ciao
Hannes

PS: I wonder whether there is actually a way to deprecate certain tokens 
from the registry. Nothing is indicated in RFC 4119. "802.11" and "DHCP" 
"LLDP-MED" really does not belong in there. FCFS as a policy for 
assignment does not sound useful to me either; expert review would be 
more useful.

Hannes Tschofenig wrote:
>>>>> However, I'm afraid you forgot my comments (except the LoSt 
>>>>> dialstring
>>>>> "must").
>>>>> My old posting:

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 12 Jul 2008 21:37:23 -0500

Hi Brian,

For derived to really have a clear meaning it needs to be totally unambiguous what the location is derived from.
The example I always hear is a civic address derived from a geodetic shape, or vice versa. In this case, you need to provide both locations in the PIDF-LO document, and somehow, there needs to be a link between them. Simply havinf both locations in the same document isn't sufficient, I think you need the equivalent of an <xref> tag, or something like that.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Hannes Tschofenig
Sent: Sat 7/12/2008 4:04 AM
To: Brian Rosen
Cc: 'ECRIT'
Subject: [Ecrit] "Derived" method

------------------------------------------------------------------------------------------------
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]

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 13 Jul 2008 11:18:12 -0400

I think we can get quite carried away with all the possibilities, and there
is no reason to be carried away.

The possibilities are:
1. There is exactly one location, and it's marked "Derived".  There is no
need for more information.
2. There are exactly two locations, and one is marked "Derived".  This means
the other is the original
3. There are more than two locations and one or more is marked "Derived".  I
think we can ignore this case, or at least say that there is no way to
understand what is derived from what.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Saturday, July 12, 2008 10:37 PM
> To: Hannes Tschofenig; Brian Rosen
> Cc: ECRIT
> Subject: RE: [Ecrit] "Derived" method
> 
> Hi Brian,
> 
> For derived to really have a clear meaning it needs to be totally
> unambiguous what the location is derived from.
> The example I always hear is a civic address derived from a geodetic
> shape, or vice versa. In this case, you need to provide both locations in
> the PIDF-LO document, and somehow, there needs to be a link between them.
> Simply havinf both locations in the same document isn't sufficient, I
> think you need the equivalent of an <xref> tag, or something like that.
> 
> Cheers
> James
> 
> 
>

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 14 Jul 2008 08:56:27 +0200

Thank you for incorporating my comments.

> derived, you must use the non-derived value.

how should a DHCP server for example indicate "Derived" then?

karl heinz

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 12:18:09 -0500

At 09:18 AM 7/12/2008, Hannes Tschofenig wrote:
>The problem is a bit with the semantic of the method token given 
>that it was supposed to be used to indicate the location determination method.

this is simply not true.  Your definition is adding meaning that isn't there.

The <method> element is the indication, solely created by the 
endpoint (as an LG), of how it received (i.e., "discovered") location 
information (not LO, but LI).

Case in point, if a target has a sighter that derives location based 
on triangulating the position of the target, yet delivers that LI via 
DHCP, the <method> would NOT say

         <method>triangulation</method>

it would say

         <method>dhcp</method>

and be correct.

>There are some "wrong" entries in the table already with that 
>semantic since something like "DHCP" refers to an LCP rather than 
>the actual location determination method.

This is not true either.  If a target (as an LG) discovers its LI 
from DHCP (Option 99 or 123), then this is the <method>

         <method>dhcp</method>

James W. added some additional semantics to the additional values 
without running them by the WG when he IANA registered them, so the 
non-4119 defined values haven't been fully vetted.

This is because 4119 doesn't require any review of any kind before 
adding new IANA entries to this registry.

>Now, I wonder whether it is possible to put more than one token into 
>the method element. The data type is string and hence it would be possible.
>
>PS: I wonder whether there is actually a way to deprecate certain 
>tokens from the registry. Nothing is indicated in RFC 4119. "802.11" 
>and "DHCP" "LLDP-MED" really does not belong in there. FCFS as a 
>policy for assignment does not sound useful to me either; expert 
>review would be more useful.

Hennes - these 4119 values were the only ones that ever were "expert 
reviewed", if you consider Geopriv a place where that can take place.

BTW -- you were there for this expert review...  perhaps you will 
reconsider this stance once you re-evaluate how these entries are 
4119 intended.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2008 20:30:25 +0300

RFC 4119 isn't super exhaustive in the description of the semantic of 
the element and what it is being used for.

What could be more useful for the Location Recipient to know:

* Location was obtained using DHCP, or LLDP-MED

OR

* Location was determined using manual configuration, wiremap database, 
triangulation.

Ciao
Hannes

James M. Polk wrote:
>> The problem is a bit with the semantic of the method token given that 
>> it was supposed to be used to indicate the location determination 
>> method.
>
> The <method> element is the indication, solely created by the endpoint 
> (as an LG), of how it received (i.e., "discovered") location 
>> semantic since something like "DHCP" refers to an LCP rather than the 
>> actual location determination method.
>
> This is not true either.  If a target (as an LG) discovers its LI from 
> DHCP (Option 99 or 123), then this is the <method>
>
>         <method>dhcp</method>
>
> reconsider this stance once you re-evaluate how these entries are 4119 
> intended.
>
>
>
>
>> Hannes Tschofenig wrote:
>>> Thanks.
>>>
>>> Brian Rosen wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 12:33:07 -0500

>need for more information.

I agree with this

>the other is the original

I do not agree with this.

Here's how I got there

The <method> element is a sub-element of what element?

Is it <location-info>?

no -- it's parallel to it

therefore the <method> element has to be THE way the whole LO was 
discovered, regardless of how many formats (civic, geo, 
whatever's_coming_next) are in the LO.

IF there are two locations, and they were discovered using different 
methods, that's TWO PIDF-LOs; else there's confusion.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2008 20:45:22 +0300

> methods, that's TWO PIDF-LOs; else there's confusion.

That does not seem to be right.

When I return civic and geo then I doubt that both are determined using 
the same mechanism.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Jul 2008 13:51:37 -0400

Perhaps we need to re-examine what we need.

It doesn't seem useful to me to know by which protocol the PIDF creator
learned location ('dhcp').

It does seem useful to understand the determination mechanism that was used
to discover the location ('a-gps').

If we need to update 4119, let's do that.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> James M. Polk
> Sent: Monday, July 14, 2008 1:18 PM
> To: Hannes Tschofenig
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] "Derived" method
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Jul 2008 13:53:20 -0400

I would say this is an error.

I think we need to determine what "method" should mean (prior email) first,
but then we should fix this so that each location info section has its own
method.

Brian

> From: James M. Polk [mailto:[email-masked]]
> Sent: Monday, July 14, 2008 1:33 PM
> To: Brian Rosen; 'Hannes Tschofenig'
> Cc: 'ECRIT'
> > > ----------------------------------------------------------------------
> ----
> > > ----------------------
> > > ----------------------------------------------------------------------
> ----
> > > ----------------------
> > > [mf2]
> >

---

From: Marc Linsner <[email-masked]>
Date: Mon, 14 Jul 2008 13:54:44 -0400

I'm not convinced any of this information is useful to a LR.

Would the pizza be warmer when delivered if the delivery person had this
information?

What would the LR do if the location information is wrong and they knew it
was derived by a ouija board vs. a wiremap database vs. triangulation?

What if the wiremap database was populated using gps?

-Marc-

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2008 20:57:15 +0300

> learned location ('dhcp').
Unless you are the author of that protocol and you want to keep track of 
the deployment :-)

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2008 21:03:07 +0300

That's actually a good question: Is the <method> element really so useful?

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Jul 2008 14:03:38 -0400

You can reasonably infer things based on it.

For example, wiremap data would never change.  GPS data might.  If you
measured wiremap data with gps, it would not likely change.  No guarantees.

Another example would be "cell".  If you ask for an update later, in some
countries, you likely will get a better location (using a different method).

Brian

> Marc Linsner
> Sent: Monday, July 14, 2008 1:55 PM
> To: Hannes Tschofenig; James Polk
> Cc: 'ECRIT'

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 13:05:56 -0500

At 12:30 PM 7/14/2008, Hannes Tschofenig wrote:
>RFC 4119 isn't super exhaustive in the description of the semantic 
>of the element and what it is being used for.
>
>* Location was determined using manual configuration, wiremap 
>database, triangulation.

Here is a quote from RFC 4119

"2.2.3.  'method' Element

    The optional 'method' element describes the way
    that the location information was derived or
    discovered. "

How isn't this exactly what you said above?

"Derived" and "Obtained" are synonyms

>>endpoint (as an LG), of how it received (i.e., "discovered") 
>>location information (not LO, but LI).
>>
>>Case in point, if a target has a sighter that derives location 
>>based on triangulating the position of the target, yet delivers 
>>that LI via DHCP, the <method> would NOT say
>>
>>>Now, I wonder whether it is possible to put more than one token 
>>>into the method element. The data type is string and hence it 
>>>would be possible.
>>>
>>>tokens from the registry. Nothing is indicated in RFC 4119. 
>>>"802.11" and "DHCP" "LLDP-MED" really does not belong in there. 
>>>FCFS as a policy for assignment does not sound useful to me 
>>>either; expert review would be more useful.
>>
>>Hennes - these 4119 values were the only ones that ever were 
>>"expert reviewed", if you consider Geopriv a place where that can take place.
>>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 13:07:23 -0500

At 12:45 PM 7/14/2008, Hannes Tschofenig wrote:

>>IF there are two locations, and they were discovered using 
>>different methods, that's TWO PIDF-LOs; else there's confusion.
>
>When I return civic and geo then I doubt that both are determined 
>using the same mechanism.

tell me how many times DHCP Option 99 and 123 "cannot" be in the SAME message?

(then re-read what you wrote above, please)

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 13:09:28 -0500

>If we need to update 4119, let's do that.

until we have viable determination mechanisms agreed to, we cannot do 
any of this

We shouldn't guess which ones will be passed by the WG.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 13:11:10 -0500

>but then we should fix this so that each location info section has its own

err, <method> has a clear definition now.

If you want to change that definition, then we need to have a 
discussion - including the impact of changing the original definition.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 13:11:57 -0500

>What if the wiremap database was populated using gps?

bingo

---

From: Marc Linsner <[email-masked]>
Date: Mon, 14 Jul 2008 14:18:32 -0400

Brian,

> You can reasonably infer things based on it.

This will make the pizza warmer how?

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Mon, 14 Jul 2008 14:28:42 -0400

I don't have any suggestions for pizza warming, other than that it seems 
to be inversely related to CO2 emissions -- the more the delivery driver 
drives, the cooler my pizza gets.  (Perhaps if we all order enough 
pizza, this could offset global warming?)

However, I would like to suggest that this conversation move over to the 
GEOPRIV list.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Jul 2008 14:30:01 -0400

The system may make intelligent choices on how/when/whether location updates
should be made.  If you get "cell", you can't use it.  If you get a-gps, you
probably can.

It's useful enough that PSAPs want to know if its gps or TDOA for example
(although they likely don't care really about the variants; they really want
to know handset based vs network based).  Their expectation of what happens,
and when is guided by the information.  It also is useful in post mortem
examinations (statistical analysis for example).

You can't, in at least the current environment, get rid of it, and no one,
that I know wants 'dhcp' as an answer.  They really don't care about the
protocol.  They care about how it was determined, not how it was configured
or conveyed, using our current terminology.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Monday, July 14, 2008 2:19 PM
> To: Brian Rosen
> Cc: 'ECRIT'
> database,
> that
> >>>> this is simply not true.  Your definition is adding meaning that
> isn't
> >>>> there.
> >>>>
> endpoint
> from
> 4119
> >>>>>>> which creates a geo and the PIDF includes a civic derived from
> that
> >>>>>>> geo.
> >>>>>>>
> >>>>>>> Brian
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> couple of substantive changes and added requirements, but not
> a
> >>>>>>>>>>> whole
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> lot
> >>>>>>>>>>
> >>>>>>>>>>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 13:40:34 -0500

>That's actually a good question: Is the <method> element really so useful?

yes

but it needs have to say only a little bit of information to make it 
useful without getting so bloated it doesn't make sense anymore.

Think about which direction this element is defined from. It's from 
the point of view of the Target/LG, not from the network.  In other 
words, how did the endpoint learn about its location.  Looking at the 
original IANA registered list for method in 4119 and you should be 
able to see this easily.

As soon as we start to think about this from a point of view of the 
network, someone's gonna bring up "is this method reeeally a method I 
can trust or not?"  I.e., can the method be validated?

then all hell breaks loose with complexity, because that cannot be 
solved within a text string. It has to include a URI to the asserter 
of the method...

do we really want to go down that path?

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 13:43:19 -0500

At 01:28 PM 7/14/2008, Richard Barnes wrote:
>I don't have any suggestions for pizza warming, other than that it 
>seems to be inversely related to CO2 emissions -- the more the 
>delivery driver drives, the cooler my pizza gets.

not if the drive has the pizza warmer tied to the engine

d`oh!

seriously, what pizza driver isn't environmentally friendly and 
drives an electric car?

there should be a law saying this

;-)

>  (Perhaps if we all order enough pizza, this could offset global warming?)
>
>However, I would like to suggest that this conversation move over to 
>the GEOPRIV list.
>
>--Richard
>
>
>
>Marc Linsner wrote:
>>Brian,
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 14 Jul 2008 16:53:39 -0500

PIDF-LO profile already says this. If you have two different methods, they must reside in the separate <geopriv> elements.

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Mon 7/14/2008 12:53 PM
To: 'James M. Polk'; 'Hannes Tschofenig'
Cc: 'ECRIT'
Subject: Re: [Ecrit] "Derived" method

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 14 Jul 2008 16:58:37 -0500

I agree with Brian it that its sole benefit is really an indicator to location recipients that it MAY be possible to get a better location. I say may, because in many cases A-GPS is not going to be as good as a cell-based location from a femto or pico-cell. Still I think it has some benefit, but as Marc says, probably not for the pizza delivery guy.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Mon 7/14/2008 1:03 PM
To: 'Marc Linsner'; 'Hannes Tschofenig'; 'James Polk'
Cc: 'ECRIT'
Subject: Re: [Ecrit] "Derived" method

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 14 Jul 2008 18:40:04 -0400

I had to go back and look at the structures again.  I'm not enough of an XML
expert here, but I gather that because we extended PIDF to include the
geopriv element, and the extension is in a sequence, a single PIDF can have
multiple geopriv elements, each of which has a location-info, method,
usage-rules and provided-by elements.  Multiple methods = multiple geopriv
elements, but within one PIDF.

So, we're back to seeing if we can agree on what method means.
I think we should say it always means how location was determined, and not
how it was configured.  I think we should say if you send method=Derived,
then you SHOULD send another geopriv element with method=something else, but
in any case, you mark method=derived on the derived geopriv element.  If you
have more than two geopriv elements and one or more has method=derived, then
relationships between determination methods and derivations cannot be
determined.

Brian

> Sent: Monday, July 14, 2008 5:54 PM
> To: Brian Rosen; James M. Polk; Hannes Tschofenig
> Cc: ECRIT
> PIDF-LO profile already says this. If you have two different methods, they
> must reside in the separate <geopriv> elements.
> 
> > >3. There are more than two locations and one or more is marked
> "Derived".
> > I
> > > > shape, or vice versa. In this case, you need to provide both
> locations
> > in
> > > > > to be helpful and giving you a measured location and also giving
> you
> > a
> > > > > I will add a requirement to -phonebcp that says if you get both
> and
> > one
> > > > is
> > > > >>> Chairs can consider if they wish to hold a short 2nd WGLC.
> There
> > are
> > > > a

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 14 Jul 2008 19:45:01 -0500

I think it is useful in much the same way that it would be useful to
know whether the person calling you on the PSTN is doing so from a POTS
phone, a CDMA phone, a GSM phone.... that is, not very.

In theory, more information is always better/nicer. In practice, I doubt
this is going to appeal to anything more than very small niche
applications.

I can even see that network operators are not going to be in the least
bit desirous of spelling out the location determination mechanisms from
competitive and other perspectives. As such, we'll likely see some bland
descriptor used if any at all.

There are actually a lot of subtle nuances involved when it comes to
real location determination mechanisms - especially in the wireless
world and these will defy categorization anyway. A system that uses a
combination of RF fingerprinting, propagation modelling, timing based
multilateration, and device-based measurements such as GPS is going to
be able to take its pick as far as which box to tick.

Ultimately, I think the high runner question is going to be the same one
that it always comes down to: how accurate is the information? To
communicate this, you need uncertainty+confidence. And despite a strange
comment on another thread, this applies just as much to GPS as anything
else.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hannes Tschofenig
Sent: Tuesday, 15 July 2008 4:03 AM
To: Marc Linsner
Cc: 'ECRIT'
Subject: Re: [Ecrit] "Derived" method

That's actually a good question: Is the <method> element really so
useful?

Ciao
Hannes

database,
that
isn't
endpoint
the
from
>>>> Now, I wonder whether it is possible to put more than one token
into
>>>> tokens from the registry. Nothing is indicated in RFC 4119.
"802.11"
4119
>>>>>> the other form.  So for example, the determination method might
be
>>>>>> GPS,
that
>>>>>>>> you a
>>>>>>>> and one
>>>>>>>>>> There are
a

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 23:58:27 -0500

At 04:53 PM 7/14/2008, Winterbottom, James wrote:

>PIDF-LO profile already says this. If you have two different 
>methods, they must reside in the separate <geopriv> elements.

I agree with James (W) this should be good enough.

Let me correct myself (from an earlier message) in saying (I think) 2 
geopriv elements accomplishes the same thing as 2 PIDF-LOs, since a 
PIDF with 2 LOs has two geopriv elements.

---

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

At 04:58 PM 7/14/2008, Winterbottom, James wrote:

>I agree with Brian it that its sole benefit is really an indicator 
>to location recipients that it MAY be possible to get a better 
>location. I say may, because in many cases A-GPS is not going to be 
>as good as a cell-based location from a femto or pico-cell.

I think - though I'm not 100% positive - that "cell" cannot 
distinguish between regular cell tower and femto or pico -- therefore 
if "cell" is the method, it should already have a very good fix on 
the target's position, given how small the range is of femto and pico 
cells. A classic "rebid" should accomplish little more resolution in 
determining where a target is.

On an aside, I'd like to know if there is a way for a target to know 
which type of cell tower (access point-ish) thingy it is connecting 
through. Does anyone know this now?

>Still I think it has some benefit, but as Marc says, probably not 
>for the pizza delivery guy.

Well, it might if the (regular) cell tower determines call routing, 
but is too coarse for delivery -- and a subsequent location 
determination provides a greater precision (in time for the pizza to 
be delivery hot and toasty).

---

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

Brian

I think you're mixing capabilities between a PIDF-LO and what we 
shorten the acronym by calling it just a PIDF.

The key is that each LO has one method, which is accomplished by the 
limitation of the geopriv element to only ever having one.

2 completely separate PIDF-LO message bodies has just as much 
location information as 1 PIDF with two geopriv elements (each with 
exactly 1 method). There is enough separation at this point.

Having more than 1 method within a geopriv element means you have at 
least two different location formats, if not repetitive subelements 
of the same location format.

This would be bad.

I know when I wrote the sections of 4119 (it sez so in the 
acknowledgements section - so check it out) that I wrote/created the 
method element to be from the target's point of view, to give the 
call taker more information about how the target learned, or 
"discovered" its location.  This is to, over time, give PSAP call 
takers more information about learning which methods are more precise 
during the first responder dispatch phase of what the location is used for.

For example, with wifi, if the call taker knows this, s/he can tell 
the fire department the target is within 100m of a certain location 
-- because that is the radius of the radio tether of the AP.

Whereas, if the call taker learns that gps is the method, and it is 
to a non-tall-building, the location supplied probably is trustworthy 
- regardless of where it looks like the caller is from. Malibu 
canyons came to mind, because the terrain is so rough, and so many 
die there and aren't found for years/decades.

James

---

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

Dodging the comment about how I used a FCFS registry in the correct way.

I actually think both James and Hannes are right.
James is right, in that if an end-point learns its location from a DHCP
server and then wants to construct a PIDF-LO, it has only three options
for <method>.

1) It simply doesn't set it at all
2) It sets it DHCP
3) It sets it to something else, like manual.

I agree with James that dhcp is the most appropriate thing to set it to.

However Hannes is also right. If I am using HELD, for example, and I
received back a fully formed PIDF-LO, then the LIS that provided me that
information should set the <method> to be the way in which it determined
the location of the Target. 

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> James M. Polk
> Sent: Tuesday, 15 July 2008 3:18 AM
> To: Hannes Tschofenig
> Cc: 'ECRIT'
> >that it was supposed to be used to indicate the location
determination
> >>>in one form (civic or geo) using another method, and derives a
location
you
> >>>>>This does raise yet another issue about this general subject;
looking
> at
and
There