I'm still pretty uncomfortable with suppressing the entire NOTIFY for
a refresh subscription. There are mechanics that involve the
Subscription-State
header and its possible extension that I fear we will interact with
in unexpected ways.
I will admit that all the specific instances of that I can think of
right now you can work
around by being really careful with the success response to the
reSUBSCRIBE. Can
anybody come up with a case (or imagine an extension) where the
response to the
reSUBSCRIBE won't have the right stuff?
I'm ok with suppressing bodies of subsequent NOTIFYs.
RjS
On Aug 27, 2007, at 2:37 AM, Aki Niemi wrote:
All,
Currently, the draft explicitly scopes the conditional notification
mechanism to the very first NOTIFY that gets triggered by a SUBSCRIBE.
Jonathan made a proposal to refactor the subnot-etags so that the
mechanism would conditionally suppress either the entire
notification or
the notification body of any subsequent NOTIFY.
For example, if the entity-tags match this would automatically
suppress
the NOTIFY immediately after a subscription refresh, as well as any
NOTIFY bodies thereafter where the entity-tag has not changed, but
e.g.,
the subscription state has.
In practice, we would now only have a single "Suppress-If-Match"
header
field, and the notifier's behavior would be altered to suppress
everything if the entity-tags match and there are no other reportable
changes; otherwise if the entity-tags match but the subscription-state
has changed, the notifier only suppresses the body.
I think this is a great idea since both the efficiency of the
mechanism
increases (suppresses more redundant information), while the
complexity
actually decreases (there is now only a single behavior for the
notifier
to follow). However, this does require some pretty extensive
changes to
the draft, which makes this maybe more of a redesign after all ;).
But I'm at least convinced this is what we should do, so I will go
ahead
and make those changes, unless someone vehemently disagrees.
Objections?
Cheers,
Aki
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
