Filtering Location Notifications in the Session Initiation Protocol (SIP)
RFC 6447
Discuss
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Lars Eggert (was Discuss) No Objection
Non-blocking comments: Section 3.1., paragraph 1: > The <moved> element MUST contain a value in meters indicates the > minimum distance that the resource must have moved from the location > of the resource since the last notification was sent in order to > trigger this event. Note that the condition could be met by a change > in any axis including altitude. But surely not only by change along a single axis, right? (I think what you mean is that the length of the vector between the two points is longer than <moved>.) Section 5.2.3, paragraph 1: > If the Target was previously outside the region, the notifier sends a > notification when the Target's location is within the region with at > least 50% confidence. Similarly, when a Target starts within the > region, a notification is sent when the Target's location moves > outside the region with at least 50% confidence. Why 50%? Why not 30 or 70%? (Magic number.) Section 5.2.3, paragraph 2: > Note that having 50% confidence that the Target is inside the area > does not correspond to 50% outside. The confidence that the location > is within the region, plus the confidence that the location is > outside the region is limited to the confidence of the location. The > total confidence depends on the confidence in the location, which is > always less than 100% (95% is recommended in [RFC5491]). The benefit > of this is that notifications are naturally limited: small movements > at the borders of the region do not trigger notifications. Whether the last sentence is true depends entirely on how accurate the positioning is compared to the movement. Section 9., paragraph 0: > 9. References idnits reports several unused references, including normative ones. Section 3.3., paragraph 5: > In times where it is desireable to know if any one element of a list Nit: s/desireable/desirable/
(Cullen Jennings; former steering group member) (was Yes) Discuss
AD needs to review LC comments
(Jari Arkko; former steering group member) (was Discuss) Yes
(Robert Sparks; former steering group member) (was No Objection, Discuss) Yes
===Comments below pertained to -10 and have been addressed=== Section 3.6 should be more clear on whether it is restricting the use of all the mechanics in event-rate-control, or only noting which of those mechanics need to be used to achieve the purpose addressed in this draft. In particular, I suggest changing "The implementation of only these two attributes" to "The use of only these two attributes". Ben Campbell's genart review comments are related. These are very small nits: 2nd paragraph of 3.3 would read more correctly if you said A1, A2, A3 _and_ PC change. <changes> is a typo The labels for figure 3 and 4 are wrong - should say Element Value Change Example
(Adrian Farrel; former steering group member) No Objection
I found the second paragraph of Section 1 hard to parse The frequency of notifications necessary for various geographic location applications varies dramatically. The subscriber should be able to get asynchronous notifications with appropriate frequency and granularity, without having to issue a large number of notifications that are not important to the application. The second sentence appears to mix "getting" notifications with "issuing" notifications. Are you attempting to distinguish asynchronous notifictations from requst/response transactions? --- Nit of the smallest type Section 1 s/that allows the number/that allow the number/
(Alexey Melnikov; former steering group member) No Objection
3.3. Element Value Changes
Figure 3 shows an example where a notification is sent when the civic
address tokens A1, A2, A3, or PC change (all 4 must change in order
to let the <trigger> element evaluate to TRUE). In times where it is
desireable to know if any one individual of a list of CAtypes change,
then they have to be put into separate <changes> filters to ensure
you are notified when any of the element values change.
In the last sentence: do you mean something like:
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
</trigger>
<trigger>
<changed>//ca:A2</changed>
</trigger>
<trigger>
<changed>//ca:A3</changed>
</trigger>
<trigger>
<changed>//ca:PC</changed>
</trigger>
</filter>
instead of:
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
<changed>//ca:A2</changed>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
?
3.5. Location Type:
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true"> geodetic
Are leading spaces insignificant in this case?
</lf:locationType>
</what>
</filter>
</filter-set>
(Dan Romascanu; former steering group member) (was Discuss) No Objection
1. The draft could use a careful editing for English usage. Some problems are simple statement structure (e.g., "This document defines a new event filters and describes others using existing mechanisms that may be relevant to a subscriber in the context of location filtering:" does not grammatically connect to the following list). Other problems leave out information (e.g., the text of section 3.1 does not state that the <moved> element is a child of the <trigger> element, although the example makes that clear). 2. Section 3.2, speed changes: The statement "An implementation MUST support the functionality as shown in Figure 2 with <ns-bindings> replacing the prefix. No other variant is supported." is nowhere near clear enough to be a specification. 3. Section 3.6, rate control: It might be useful to provide a more extended example than figure 9, one that shows the initial SUBSCRIBE and NOTIFY, and the subsequent SUBSCRIBE that lengthens the max-interval value.
(Gonzalo Camarillo; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns that are not included in my DISCUSS position. Please consider them.
(Tim Polk; former steering group member) No Objection