Hi Hisham,
thanks for the review.
See my answers/comment below in line
/Sal
Hisham Khartabil wrote:
- Section 3 talks about presence, location and tracking applications.
I was confused reading those sections the first time thinking the
presence application sits on the server. Can you replace the word
"application" with "client"?
[Sal] thanks I'll do in the next version of the document.
As a suggestion, I would say the whoel document needs to be updated
with this suggestion
- Section 3.2 talks about filters. A reference is needed to filters RFC.
[Sal] actually the right reference is to "Location Event Filters" draft.
I'll add it.
Also, more text is needed around how this Force extention overrides a
filter criteria and why would someone set a filter only to override it
with a Force.
[Sal] it is not that the Force override the filter criteria, but that
the application is interested in receiving a periodic update even when
the filter criteria does not
satisfy any of the trigger criteria. For example you are interested to
receive an update if someone or something has moved more then 10 meters
(and you can
set a location filter criteria for that) or if it has not moved more
then 10 meters you still want a periodic update to check if it has been
completely still or it has
moved but less then 10 meters.
Of course, the periodic update can be generalized and applied to all the
possible filter criteria.
- Figure 1 needs to be modified to show how filters are affected
[Sal] Figure 1 only describes the Throttle mechanism that does not
affect filters.
- Section 4.3: Need to expand on how the client can reject the
notifier's adjusted intervals?
[Sal] the client can not reject the notifier's adjusted intervals. The
only things it can do is to perform an update subscription with a
different value but that
meet the constraints or subscription that does not contain the throttle
parameter at all.
- I think its a good idea to talk about how a notifier can suggest to
the client the throttling mechanism and throttle interval without the
client asking for it. At least the draft can talk about how if a
notifier has a policy to limit notifications according to
admin throttling settings, those can/cannot be applied without the
client requesting them. That's something that we need to decide,
although it is difficult to mandate that a notifier cannot apply
throttles unless it is asked to do so.
[Sal] I agree that is something we need to discuss and decide how to
proceed.
- "average" I dont understand what that is? is it the average interval
between notifications sent so far? How is that value decided? is
average the wrong word to use here. More explanation is needed.
[Sal] The average rate control is a statistical calculation which varies
slowly over time, it allows the notifier to dynamically increase or
decrease the Notification frequency.
Regards,
Hisham
------------------------------------------------------------------------
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
