My interpretation of James' concern relates not to the act of the LIS
providing an unlinked presentity to the target, but what the target does
with this in follow-on actions.
I wonder if there would be value in offering guidance (within HELD) to
targets explaining that during this 'LCP' process a fictitious presentity
was used and the 'entity' attribute needs changed/linked prior to use in a
presence/location application?
-Marc-
On 7/16/09 1:29 AM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
> Hi James,
>
> I can't see that there is anything wrong with this paragraph at all.
>
> First sentence covers the topic generally without direct guidance; the second
> is more specific; the final statements are extremely specific.
>
> Besides, they are the same thing in this context. See Section 3, paragraph 2.
>
> --Martin
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of James M. Polk
>> Sent: Thursday, 16 July 2009 2:09 PM
>> To: geopriv@ietf.org
>> Subject: [Geopriv] Issue in HELD, confusing device ID with entity=
>> attribute
>>
>> Mary (and all)
>>
>> Hannes just quoted text from the main HELD spec that happens to
>> confuse two different identities, making them appear as if they are
>> the same, when they are not.
>>
>> As noted in the "HTTP Enabled Location Delivery (HELD)"
>> [I-D.ietf-geopriv-http-location-delivery] Section 6.6:
>>
>> says:
>>
>> The LIS MUST NOT include any means of identifying the Device in
>> the PIDF-LO unless it is able to verify that the identifier is
>> correct and inclusion of identity is expressly permitted by a
>> Rule
>> Maker. Therefore, PIDF parameters that contain identity are
>> either omitted or contain unlinked pseudonyms [RFC3693]. A
>> unique, unlinked presentity URI SHOULD be generated by the LIS
>> for
>> the mandatory presence "entity" attribute of the PIDF document.
>> Optional parameters such as the "contact" element and the
>> "deviceID" element [RFC4479] are not used.
>>
>> RFC 4479 discusses device ID as probably the hardware device's MAC
>> address.
>>
>> The entity= attribute within the <presence> element is the presentity's
>> URI.
>>
>> The above paragraph from [I-D.ietf-geopriv-http-location-delivery]
>> discusses the two as if these are the same identity, and they are not
>> (they are not even at the same OSI layer, one is at layer 2, the
>> other is at layer 7).
>>
>> This paragraph needs to be fixed.
>>
>> I apologize for not noticing this earlier.
>>
>> BTW - I agree the device ID (i.e., the MAC address of the device the
>> user is logged into) should not be included). But the entity=
>> attribute as the AOR of the presentity is probably going to be there
>> more of the time -- and should not be "SHOULD NOT linkable".
>>
>> James
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> ------------------------------------------------------------------------------
> ------------------
> 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
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
