(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

Reply via email to