Subject: Re: [Geopriv] [Ecrit] "Derived" method

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

Marc Linsner wrote:
> Brian,
> 
> 
>> You can reasonably infer things based on it.
> 
> This will make the pizza warmer how?
> 
> -Marc-
> 
>> 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
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>> Marc Linsner
>>> Sent: Monday, July 14, 2008 1:55 PM
>>> To: Hannes Tschofenig; James Polk
>>> Cc: 'ECRIT'
>>> Subject: Re: [Ecrit] "Derived" method
>>>
>>> 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-
>>>
>>>
>>> On 7/14/08 1:30 PM, "Hannes Tschofenig" <[email-masked]> wrote:
>>>
>>>> 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:
>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hannes Tschofenig wrote:
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Brian Rosen wrote:
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Could you describe the semantic of the "Derived" method a bit more?
>>>>>>>>>
>>>>>>>>> Brian Rosen wrote:
>>>>>>>>>
>>>>>>>>>> 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,
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 10, 2008 at 10:16 PM, Brian Rosen <[email-masked]>
>>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ecrit mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
> 
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

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