I think it's almost there. The problem seems to come from the last sentence in the previous paragraph:
> 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 [email protected]) > > 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:[email protected]] >> Sent: Sunday, 21 March 2010 4:09 PM >> To: Thomson, Martin >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email protected]; >> [email protected]; [email protected] Loreto; Cullen >> Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team; >> Hannes Tschofenig; [email protected]; 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. >> >> >> >> >> >> >> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
