Sunday, March 21, 2010

Re: [Geopriv] Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-filters-10

On Mar 21, 2010, at 3:49 PM, Thomson, Martin wrote:

> So, the rate control does recognize that the first notify message can be empty or might not contain all state:
>
> $3.2: Thus, the first notification might be empty, or certain values might be absent.
>
> The text that was originally quoted, that we're discussing is this:
>
> A compliant notifier MUST generate notifications whenever the time
> since the most recent notification exceeds the value in the "max-
> interval" parameter. Depending on the event package and subscriber
> preferences indicated in the SUBSCRIBE request, the NOTIFY request
> MUST contain either the current full state or the partial state
> showing the difference between the current state and the last
> successfully communicated state.
>
> The second sentence, taken out of context might be interpreted as Ben did - a blanket prohibition on empty notify messages. Reading through again, with complete context, I'm not sure that I agree with this assessment. If the rate-control editors are amenable to a clarification in this section, it would be nice, but I don't see it as necessary.
>

i did not take it to be blanket prohibition on empty NOTIFY requests. I took it to be a prohibition against empty NOTIFY requests sent as a result of the expiration of a max-interval parameter. The language I objected to in the location filter draft seemed to explicitly suggest empty notifies as a result of max-interval parameter.

Here's the language I refer to, in section 3.6, last sentence of paragraph 1 and first sentence of 2:

> [...] Whenever the time since the
> most recent notification exceeds the value in the "max-interval"
> parameter, the current state would be sent in its entirety, just like
> after a subscription refresh.
>
> If complete state is not immediately available, then an empty NOTIFY
> is sent immediately and subsequently a separate NOTIFY containing
> location is generated some time between the time included in 'min-
> interval' and the time in 'max-interval'. An important use case for
> location based applications focuses on the behavior of the initial
> NOTIFY message(s) and the information it returns, for example in case
> of emergency call routing. When an initial NOTIFY is transmitted it
> might not include complete state.

Although the last couple of sentences talk about, I read the first part as suggesting that if state is not available when a max-interval expires, you should send an empty NOTIFY.


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv