ietf
[Top] [All Lists]

Re: Last Call: draft-ietf-geopriv-http-location-delivery (HTTP Enabled Location Delivery (HELD)) to Proposed Standard

2009-06-24 13:55:19

Great - thanks.

On Jun 24, 2009, at 10:40 , Mary Barnes wrote:

Ben also had a set of comments (editorial/clarifications) per these
threads:
http://www.ietf.org/mail-archive/web/gen-art/current/msg04156.html
http://www.ietf.org/mail-archive/web/gen-art/current/msg04163.html

These were not posted to GEOPRIV WG mailing list - I will post a summary
of the changes and a link to the review when I submitted the updated
document which I'm working on right now and hope to
submit shortly.

Mary.

-----Original Message-----
From: Cullen Jennings [mailto:fluffy(_at_)cisco(_dot_)com]
Sent: Wednesday, June 24, 2009 12:30 PM
To: Barnes, Mary (RICH2:AR00); Bernard Aboba; Ben Campbell; Martin
Thomson; James Winterbottom; Barbara Stark
Cc: Richard Barnes; IETF Discussion
Subject: Re: Last Call: draft-ietf-geopriv-http-location-delivery (HTTP
Enabled Location Delivery (HELD)) to Proposed Standard


So to follow up on the gen-art and sec reviews (thank you btw) ... I
tried to look at all the traffic and I put the changes into an RFC Ed
note. Please have a look at this and let me know if I did not get it
right. Thanks, Cullen



In first paragraph of section 3 change

OLD:
    This document does not specify how LI is
    determined.

New:
    This document assumes that the Device and Access Provider have no
    prior relationship other than what is necessary for the Device to
    obtain network access.  This document does not specify how LI is
    determined.



In section 8, change
Old:
The LIS MUST NOT rely on device support for cookies [RFC2965] or use
   Basic or Digest authentication [RFC2617].

New:

   A Device that conforms to this specification MAY choose not to
   support for HTTP authentication [RFC2617] or cookies [RFC2965].
   Because the Device and the LIS may not necessarily have a prior
   relationship, the LIS SHOULD NOT require a Device to authenticate,
   either using the above HTTP authentication methods or TLS client
authentication. Unless all Devices that access a LIS can be expected
   to be able to authenticate in a certain fashion, denying access to
   location information could prevent a Device from using
   location-dependent services, such as emergency calling.



Add the following paragraph to the end of  Section 6.6:
New:
    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.





On May 26, 2009, at 7:29 , The IESG wrote:

> The IESG has received a request from the Geographic Location/Privacy
> WG
> (geopriv) to consider the following document:
>
> - 'HTTP Enabled Location Delivery (HELD) '
>   <draft-ietf-geopriv-http-location-delivery-14.txt> as a Proposed
> Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to
> the ietf(_at_)ietf(_dot_)org mailing lists by 2009-06-09. Exceptionally, comments

> may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain
> the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-d
> elivery-14.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa
> g=16080&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf-announce



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>