Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00

["Dale Worley" <[e-mail]>]

On Tue, 2009-05-26 at 15:08 -0500, Adam Roach wrote:
> What you're identifying is a general philosophy that the types of state 
> deltas that make sense are better described by the event packages 
> themselves, instead of some generic state-delta mechanism. I'm intrigued 
> by your proposal to add versioning information to the base 
> specification, and would be interested in whether you have a 
> backwards-compatible proposal for doing so.

I can't think of any mechanism that wouldn't take more effort than it is
worth.  E.g., we could easily define an option on the SUBSCRIBE Event
header, and then suitable parameters on the NOTIFY Event header.  But
since all implementations would need to support the old style as well,
nobody would save any coding effort.

> This reflects the evolution of the document from its original mechanism 
> (which was, indeed, more event oriented than state oriented). I have the 
> same model in mind as you do -- that of conveying the state of the 
> resource. I agree that cleaning up all of the "event" language to 
> instead talk about states and state transitions would indeed be an 
> improvement. I'll add this to my list of changes for the next revision.

The reason I'm interested in this is that the sipXecs notifier mechanism
is designed based on the idea of sending state information -- the
application publishes to the notifier subsystem the successive state
values, and the subsystem takes care of sending the NOTIFYs.  But the
code cannot handle *event* notifications in the sense that people
normally use the term.  That is, the sipXecs mechanism was designed to
implement the model that RFC 3265 appeared to use, but as a result, it
cannot be used for "events" that do not fit that model.

This is an example that if the RFC doesn't define a model and require
conformance to it, people will not be able to implement machinery that
can handle subscriptions generically, since each event package will
violate the model in slightly different ways, and each event package
will require additional custom coding.

> Semantically, these are the same thing as hardwired filters on the 
> state. Do you have any concrete suggestions for treatment of this in the 
> base spec? Or should it simply be mentioned that some event packages 
> inherently contain the semantic equivalent of hard-coded filters?

As I think of them, a filter restricts what information a subscriber may
see.  Implied by that is that changes in data that the subscriber may
not see do not trigger notifications to the subscriber.

I think what you're aiming for is an implied "notification threshold",
where a change in certain data does not reach the threshold for sending
a notification.  Now that I go back and look, I see that thresholds are
mentioned once in RFC 3265, in section 5.4.3.

This ties in with the idea of events as state changes -- if we become
more explicit that notification events are state changes, we need to
become more explicit that various mechanisms can modulate which state
changes trigger notification.

> > - In principle, the state should not be affected by who has subscribed
> >   to received notifications for it.  But there are circumstances where
> >   we want to be aware of the set of subscribers, and to be able to
> >   present differing information to them.  The first job can probably
> >   be done (in principle) by examining the "winfo" state, but I don't
> >   know of a solution to the second.

> You're venturing into the realm of things like the presence common 
> policy framework, which I think cover this very well. Do you have a 
> proposal for how to incorporate this into the base specification?

The critical thing is not how to specify filtration, but to make
explicit that it can be done, that we do not restrict the notifier to
presenting the same information to two subscribers to the same resource,
even if their subscriptions are identical.  But that gets hard to
implement within the model that subscribers are receiving some function
of a common state -- if two subscriptions are identical, why would they
receive different information?  (Whereas the naive "state update" idea
presumes that every subscriber sees the same state.)  (Again, the
sipXecs system assumes that what a subscriber sees is not dependent on
the subscriber.)

> Agreed. This version of the document puts far more emphasis on NOTIFY as 
> "the second leg in the three-way handshake." As such, I'm inclined to 
> deprecate the conveyance of any information in SUBSCRIBE responses, and 
> use NOTIFY requests exclusively. I'll do a pass of the document for 
> expires use in this regard.

This problem is pretty messy.  REGISTERs are fairly simple, since the
information flows from UA to registrar and from registrar to UA are
synchronized.  In addition, the registrar cannot spontaneously modify
the registration.  So it's easy for the UA to maintain agreement with
the registrar on when the registration expires.

I like the idea of using the NOTIFYs exclusively for conveying
expiration information, but that's not convenient for programming --
suppose the subscriber sends a reSUBSCRIBE and then doesn't get a
NOTIFY?  That case introduces Yet Another Timer into the code.

I think we can simplify the situation by adding a few restrictions:

- the subscriber may always terminate the subscription (by sending a
SUBSCRIBE with Expires: 0), but otherwise may only postpone the
expiration time of the subscription.

- the notifier may always terminate the subscription (by sending a
NOTIFY with Subscription-State: terminated), but otherwise may only
postpone the expiration time of the subscription.

Within these rules, the notifier behaves much as it does now.  (The only
change being that when a subscription is refreshed, the notifier may not
shorten the requested subscription duration to before the previous
expiration time.)  And the subscriber can interpret both the 200's for
the SUBSCRIBEs and the NOTIFYs consistently -- the latest expiration
seen is the one currently in effect.  (The only restriction is that the
subscriber should never bring in an established expiration time.)

> > If we do not assume that the subscriber can reliably get a NOTIFY from
> > every SUBSCRIBE, then working out a reliable solution is more
> > difficult, due to the race condition.
> >
> > There are related problems regarding terminology.  The "length of a
> > subscription" can mean two things, the "time from present" that it
> > expires, or the absolute endpoint of the subscription.  The draft says
> > in various circumstances that a subscription cannot be lengthened
> > without being specific what this means.  As far as I can tell: when
> > processing a SUBSCRIBE, a notifier must update the subscription
> > endpoint of the subscription so that the time from present is no
> > larger than what the subscriber requested (which is likely later than
> > the previous endpoint); a notifier may unilaterally bring sooner the
> > endpoint of a subscription so long as it notifies the subscriber; a
> > subscriber's refresh duration request is unconstrained (in that it may
> > require bringing forward the endpoint of the subscription, as well as
> > postponing it).
> >   
> 
> The rules are intended to operate exactly like expiration handling for 
> REGISTER. Is there any language you think is particularly ambiguous?

The complexity comes because we want to allow a notifier to unilaterally
terminate a subscription.  And, as far as I can tell, to unilaterally
shorten it.  I don't think that registrars have this capability.  (See
what I wrote in the previous section.)

> > * Notifier migration
> >
> > Notifier migration is an interesting concept and seems like it might
> > be very useful.
> 
> Note that the preponderance of this text was copied verbatim from 
> RFC3265, section 3.3.5.
> 
> > But how does a subscriber take advantage of it?  The
> > text in 4.4.2 assumes that the subscriber will send a new
> > out-of-dialog SUBSCRIBE to whatever URI it did originally.  But will
> > that obtain an alternative notifier for the resource whose notifier
> > just ceased?  The possibilities of SIP routing make that doubtful.
> >   
> 
> Not really. There are a couple of architectures we had in mind when we 
> designed this mechanism:
> 
>    1. The proxy/registrar has a "default" destination that it will send
>       SUBSCRIBE requests to when a user has no registered UAs. This
>       "default" destination could serve proper state for the
>       corresponding resource (or even act as a simple "parking lot",
>       from which subscribers will be migrated once the watched user has
>       a UA registered).
> 
>    2. The notifier is part of a cluster of notifiers that can all
>       service requests corresponding to the user. In order to take the
>       notifier offline, it informs its clustering mechanism that it is
>       no longer accepting new traffic, and then sends NOTIFY messages to
>       each subscribed UA for the purpose of moving them to a notifier
>       that is not going offline. Once all such subscriptions are shed,
>       the node can be taken out of service. A similar mechanism can be
>       used to rebalance subscriptions after adding notifiers to a cluster.
> 
> In any case, it's not the subscriber taking advantage of this mechanism; 
> it's the notifier.

Thinking about this some more, it seems to be clear that there is no
better alternative than "resubscribe to the request-URI you subscribed
to".  There are all sorts of possible snafus, but they are no different
than anywhere else in SIP.

If the notifier wants to direct the subscriber to a particular
alternative notifier, it can use REFER, as you describe below:

> > What we want is for the notifier to give the subscriber a
> > globally-routable URI that will reach an alternative notifier, but
> > there seems to be no mechanism to carry the URI.
> >   
> 
> At the risk of triggering your "REFER means everything" rant, I think 
> this kind of operation would best be served by using REFER to initiate 
> the equivalent of a "blind transfer" of the subscription. This looks a 
> lot like figure 1 of
> draft-ietf-sipping-cc-transfer-12 (except with "SUBSCRIBE" instead of 
> "INVITE").

Hmmm, that seems like a good idea.  You can avoid my rant by explicitly
defining this mechanism in the draft -- that a notifier can explicitly
replace itself with another notifier by sending a REFER within the
subscription dialog.  Using REFER is also upward compatible, since the
subscriber will fail the REFER if it does not implement the mechanism.

Dale