Re: 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.