ext Robert Sparks wrote: > 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.
The way this works now is that we are explicit on what is considered the "entity" and what is not. In the current version of the draft, we explicitly say that the "entity" is the event data in the body plus Content-* and Entity fields in the header. On the other hand, subscription state is *not* part of the entity, and therefore not covered by the entity-tag. This then gives the notifier three choices when it gets a SUBSCRIBE requesting for conditional notification. It will either: 1) report nothing (204 response) if neither entity nor subscription state have changed; 2) suppress the body if only the subscription state has changed; 3) send a full notify if the entity has changed So I think this solves your concern, since the notifier can always report the changes, even in the subscription refresh. Before, this was actually quite poorly defined. > 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 believe currently there are none. However, if in the future there are extensions that should be considered to be part of the "entity" or subscription state, then those event-packages would need to define this behavior. In practice, they would need to cover cases where changes in these additional header fields would trigger a NOTIFY without the body, or a NOTIFY with a body and a changed entity-tag. 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
