In a significant number of cases, the identities known by the LIS are not
AoRs.
The LIS is operated by an access network. That network has a "subscriber",
but the subscriber may or may not be the same as the entity sending the
PIDF. Lots of examples of that:
* Broadband ISP with AOL or Vonage sending IM/SIP signaling with location
* Starbucks as the ISP with VPN to enterprise phone system
* Enterprise ISP which knows room numbers and jack wallplate numbers, but
not who
is in a conference room at any specific time
* Location from a commercial GPS system which has no real "identity" at all
other than a MAC address.
It's only in something like a cellphone network where the identity in the
PIDF and the identity in whatever is conveying the PIDF could reasonably be
the same thing. And only in those cases could you have something we would
recognize as an AoR in the PIDF. I'm not at all sure we will see that AoR
in the PIDF, but at least in that case it could be.
Brian
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Thursday, July 16, 2009 12:09 AM
> 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
