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

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Mon Jul 14 2008 - 14:28:42 EDT

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: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] 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" <Hannes.Tschofenig@gmx.net> 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:Hannes.Tschofenig@gmx.net]
>>>>>>>>> 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:khwolf1@gmail.com]
>>>>>>>>>>> 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 <br@brianrosen.net>
>>>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ecrit mailing list
>>>>>>>>>> Ecrit@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> Ecrit@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> Ecrit@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Mon, 14 Jul 2008 14:28:42 -0400

This archive was generated by hypermail 2.1.8 : Mon Jul 14 2008 - 14:29:00 EDT