> 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.
I was taking that to set the context for the problem paragraph, and your language breaks that connection. I _think_ that's the right thing, but I suggest interested parties look at both paragraphs together.
OTOH, 3 occurrences of the word "immediately" in the same sentence might be a bit much :-) Maybe something like the following:
A notifier is required to send a NOTIFY request immediately after creation of a subscription. If state is not available at that time, then the NOTIFY request may be sent with no content. ... "
On Mar 26, 2010, at 2:51 PM, Thomson, Martin wrote:
> (dropping ietf@ietf.org)
>
> So I'd like to close this, so I'll summarize and propose an action:
>
> Question: max-interval expires, is it permitted for a notifier to generate an empty notify?
>
> Position: This is NOT desirable behaviour. A notifier has advance warning that it needs to generate state and can do so. I don't actually see a need to support empty notifications once the subscription is established and the notifier is providing state. It's only going to lead to unexplained holes.
>
> Text: (for loc-filters, no change to rate-control)
>
> OLD:
> 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
> NEW:
> Immediately after the creation of a subscription,
> if complete state is not immediately available, then an empty NOTIFY
> is sent immediately. A separate NOTIFY containing
> location is subsequently generated some time between the time included in 'min-
> interval' and the time in 'max-interval'. An important use case for
>
>
> I think that this addresses the problem. Whether or not this was the original intent of the authors, we didn't really discuss this particular wrinkle.
>
> --Martin
>
>
>> -----Original Message-----
>> From: Ben Campbell [mailto:ben@estacado.net]
>> Sent: Sunday, 21 March 2010 4:09 PM
>> To: Thomson, Martin
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); aki.niemi@nokia.com;
>> krisztian.kiss@nokia.com; salvatore.loreto@ericsson.com Loreto; Cullen
>> Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team;
>> Hannes Tschofenig; geopriv@ietf.org; Adam Roach
>> Subject: 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.
>>
>>
>>
>>
>>
>>
>>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
