I have a few very minor issues, and a bunch of nits. None of these are so important that they need to be fixed immediately.
I'm sure that Rohan's affiliation has changed. Last time I saw him it certainly wasn't Plantronics.
Title: The "reporting" aspect was long ago removed. I'd propose simply:
Filtering Location Notifications in Presence
No need to mention PIDF-LO. There might be a need to mention SIP, in which case it becomes
Filtering Location Notifications in Session Initiation Protocol (SIP) Presence
Section 1, OLD:
RFC 3265 can be used with so-called 'filters'...
NEW:
SIP events [RFC3265] can be used with filters...
Q: what is "so-called" about them? Is the term not defined in RFC 4660? This phrase has negative connotations. (I suspect that this is symptomatic of Rohan's views on the filtering docs. Not undeserved, but also unnecessary.)
Section 1: Is it worth stating in the introduction that this document mixes new mechanisms with documentation of existing mechanisms?
Section 1: wayward apostrophe: s/presence event package'/presence event package/
Section 3.*: Suggest a better namespace prefix to use in examples might be "lf:" rather than the generic "ext:".
Section 3.4: It's unclear what the effect of uncertainty is on this. An implementation is asked to make a Boolean decision, but not given the necessary tools to ensure that the decision it makes is the one that is expected.
Section 3.5:
For the example above, if the 'exact' attribute was "true", then the
only possible response is either a "civic" location or an error
message.
What does it mean to provide an "error message" in the context of being unable to provide the requested location type? In this case, I'd suggest:
s/or an error message./or no location information./
Section 3.6: (This is recent text, so this is actually the first time that I've read it.) No specific comment here (aside from a wayward period.). However, the example does look a little like a wall of text. I can see several paragraphs there. Perhaps if this "example" was split into a sub-section, there wouldn't be a tendency to try to create the ultimate paragraph.
Section 5: I don't think that the third bullet is necessarily true. This document doesn't really build in PIDF-LO, but it does depend on its format. If, in that fact, there are security considerations, I'm not aware of them.
Section 5: Is it worth noting that there are no policies that dictate what filters may be used? I tend to object to live tracking as a general rule, but am offered no means to control this behaviour by watchers (I can tell them not to get location, even black out certain areas, but not limit rates). Are we satisfied that this document leans on the "local policy" crutch in this area?
--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Alissa Cooper
> Sent: Tuesday, 13 October 2009 2:58 AM
> To: GEOPRIV
> Subject: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06
>
> This is a GEOPRIV Working Group Last Call for comments on
> draft-ietf-geopriv-loc-filters-06
> (http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-06)
>
> Please send your comments no later than Monday, November 2, 2009.
>
>
>
> _______________________________________________
> 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
