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

From: "Dale Worley" <[email-masked]>
Date: Mon, 01 Jun 2009 15:54:20 -0400

On Tue, 2009-05-26 at 15:08 -0500, Adam Roach wrote:
> > ** Editorial

Comments on the comments on my editorial points:

> > * section 3.1.2
> >
> >    The Request URI of a SUBSCRIBE request, most importantly, contains
> >    enough information to route the request to the appropriate entity per
> >    the request routing procedures outlined in SIP [RFC3261].
> >
> > This is not necessarily true -- the routing is also affected by any
> > Route headers in the request.  In sipX, we use that feature so that we
> > can present to the notifier a resource name (request-URI) that need
> > not be the same as the SIP URI of the notifier.
> >   
> 
> Would "The Request URI of a SUBSCRIBE request, in conjunction its Route 
> header fields, contains enough information..." satisfy your concern?

I would prefer that the RFC say that SUBSCRIBEs to be routed as generic
requests are.  That avoids having to enumerate any complications of the
routing process as defined elsewhere.  The distinctive thing about
SUBSCRIBEs is that the request-URI (of the SUBSCRIBE when it arrives at
the notifier) identifies the resource.

> > * section 4.4.1
> >
> >    NOTIFY requests are matched to such SUBSCRIBE requests if they
> >    contain the same "Call-ID", a "To" header field "tag" parameter which
> >    matches the "From" header field "tag" parameter of the SUBSCRIBE, and
> >    the same "Event" header field.  Rules for comparisons of the "Event"
> >    header fields are described in Section 8.2.1.
> >
> > This is awkward.  How about:
> >
> >    NOTIFY and SUBSCRIBE requests are within the same subscription
> >    usage if they contain the same "Call-ID", a "To" header field "tag"
> >    parameter which matches the "From" header field "tag" parameter of
> >    the SUBSCRIBE, and the same "Event" header field.  Rules for
> >    comparisons of the "Event" header fields are described in Section
> >    8.2.1.
> >   
> 
> Actually, I think this would be best served by recasting the association 
> as it relates to 3261 dialogs, and then adding on the "Event" matching. 
> I'll see if I can come up with something reasonable that conveys enough 
> information.

You're right there.  Re-reading my proposal, I see that it is not
exactly correct either, but if we inherit 3261 dialogs, and then add the
Event type/tag match, it will be exactly correct.

> > * section 4.4.2.
> >
> > Notifier migration is an interesting concept.  But note that the text
> > is incorrect:
> >
> >    Upon receipt of this NOTIFY message, the subscriber SHOULD attempt to
> >    re-subscribe (as described in the preceding sections).  Note that
> >    this subscription is established on a new dialog, and does not re-use
> >    the route set from the previous subscription dialog.
> >
> > It's not correct to say the subscriber is "re-subscribing" (in the
> > sense of the draft).  
> 
> I can see your point. I'll change it to something like "initate a new 
> subscription to the resource."
> 
> > There is also the technical question of what
> > request-URI the subscriber should use to re-subscribe.  (see above)
> >   
> 
> I think the intention was always that the subscriber would use the same 
> Request-URI (and, if relevant, Route) that was used to set up the 
> subscription that has just terminated. I'll clarify this point.

One additional point to claify:  What you mean is the request-URI/Route
of the *initial* SUBSCRIBE for the subscription.  Reading your sentence
quickly, one might consider (as I once did) using the
target-URI/route-set of the established subscription, which is not
guaranteed to work.  (E.g., in sipX, the route-set URIs can carry
authorization information that is bound to the dialog identifiers.)

There are some tricky problems regarding attempting to reestablish a
subscription.  (Think of time-based routing.)  I think that the proper
way to deal with them is to ignore them (in regard to these passages),
and leave the subscriber with a generalized (and vague) obligation to
"reestablish the subscription" -- the problems are implied by that
commandment (if the implementer knows what he is doing).

> > * section 5.1
> >
> >    When designing an event package using the methods described in this
> >    document for event notification, it is important to consider: is SIP
> >    an appropriate mechanism for the problem set?  Is SIP being selected
> >
> > The initial "is" of the clauses are not consistently capitalized.
> >   
> 
> This issue isn't as simple as it appears at first. See, for example, 
> <http://en.wikipedia.org/wiki/Colon_(punctuation)#Use_of_capitals>. If I 
> changed it to a capital letter, there's a good chance that I'd get a 
> request to change it back from someone who has a different sense of 
> aesthetics than  you do (and I believe that there's a strong argument to 
> be made that the form in the current document is the more common form 
> for both American and British English). I've had to mediate these kinds 
> of disputes before, and was kind of hoping to avoid them this time -- in 
> particular, I don't want to have to add another paragraph like the final 
> paragraph of section 1.2 to clarify how I have chosen to treat colons 
> and capitalization.
> 
> So, unless there is an argument that can be made regarding clarity, I'm 
> not accepting comments on the topic of typographical conventions. :)

I wasn't aware of just how many ways one can handle the colon -- "The
wonderful thing about standards is that there are so many to choose
from!"

> >
> > * section 5.4
> >
> >    Event packages are not required to reiterate any of the behavior
> >    described in this document, although they may choose to do so for
> >    clarity or emphasis.  In general, though, such packages are expected
> >    to describe only the behavior that extends or modifies the behavior
> >    described in this document.
> >
> > This reads strangely, as it suggests that an event package description
> > might contradict the RFC.
> >   
> 
> We certainly can't prevent it. :)
> 
> Examples of where this happens include filtering and throttling, which 
> do actually change things like when NOTIFY messages are sent. 3265bis 
> (and 3265) say this happens when the state changes. The throttling 
> document says this happens when the state changes and/or when other 
> criteria are met.

Good point.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 04 Jun 2009 15:30:50 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Jun 2009 16:23:21 -0400

> what I wrote in the previous section.)

As appealing as this proposal is, I see a couple of issues:

After a (re)SUBSCRIBE, you will receive both a 200(SUBSCRIBE) and a 
NOTIFY. There is no guarantee which will arrive first. Which one do you 
believe for the expiration time? If it was a reSUBSCRIBE, the subscriber 
doesn't even know if the NOTIFY was a result of the reSUBSCRIBE or was 
sent previously. Perhaps saying that you can only extend, not reduce, 
would help here.

But the no-reduce rule has its own trouble. In particular my usual 
source of exceptions to everything: 3pcc. The subscriber may think he is 
continuing a single subscription. But a middle box may be moving a 
subscription from one UAS to another. The new target may not be willing 
to support such a long subscription, and so may have need to reduce it.

(Perhaps an answer to that would be to put the burden on the middle box 
to "make it right" by managing different expiration times on the two 
sides. But that can be difficult.)

And then there is the general issue: practically speaking, can we ever 
add new restrictions? Backward compatibility issues will require most 
everyone to support cases where those restrictions aren't observed.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 05 Jun 2009 16:02:31 -0400

> sent previously. Perhaps saying that you can only extend, not reduce, 

If the notifier can only extend subscriptions, then the subscriber can
believe the furthest expiration that it has seen, and does not need to
know the order in which the various messages were sent.

> to support such a long subscription, and so may have need to reduce it.

That's an annoyingly realistic problem.

> sides. But that can be difficult.)

That would add a lot of complexity that is not now needed.

> everyone to support cases where those restrictions aren't observed.

I think that we can escape the general issue in this case.  Partly,
because current implementations rarely use the full range of allowed
behavior, and partly because we can add some hacks what I have proposed
to accommodate current behavior.

But I need to think about this more...

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 10 Jun 2009 15:12:04 -0400

> That's an annoyingly realistic problem.

In this situation, can we demand that the middle box terminate the
subscription (rather than shorten it), with the expectation that the
subscriber will create a new subscription?  (In terms of message
traffic, there is little additional load.)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jun 2009 16:16:45 -0400

Do we have a way of terminating a subscription that subscribers are 
likely to interpret as "sorry but I'd like you to try again"?

The closest I can think of would be send a REFER.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 10 Jun 2009 16:21:31 -0400

> The closest I can think of would be send a REFER.

The use of REFER was mentioned earlier by Adam, IIRC.

In all the cases I know of, a subscription is either a state query
(expires=0, in which case this question can't arise), or a subscription
that is intended to be kept in force perpetually (in which case, if the
subscription is terminated by the notifier, the subscriber will attempt
to reestablish the subscription).

Dale

---

From: Byron Campen <[email-masked]>
Date: Wed, 10 Jun 2009 15:32:39 -0500

3265 specifies that a reason param of "deactivated" on a NOTIFY  
terminated should cause the UAC to immediately re-establish the  
subscription.  (See Sec 3.2.4, or 4.1.3 in bis-00) Whether this is  
actually implemented... *shrug*

Best regards,
Byron Campen

>>>> But the no-reduce rule has its own trouble. In particular my  
>>>> usual source of exceptions to everything: 3pcc. The subscriber  
>>>> may think he is continuing a single subscription. But a middle  
>>>> box may be moving a subscription from one UAS to another. The new  
>>>> target may not be willing to support such a long subscription,  
>>>> and so may have need to reduce it.
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jun 2009 16:39:34 -0400

> actually implemented... *shrug*

OK. That is what I was looking for.
In that case I think Dale's approach can fly.
If people haven't implemented it, maybe they will when it starts to be 
useful to do so.

	Thanks,
	Paul

>>>>> source of exceptions to everything: 3pcc. The subscriber may think 
>>>>> he is continuing a single subscription. But a middle box may be 
>>>>> moving a subscription from one UAS to another. The new target may 
>>>>> not be willing to support such a long subscription, and so may have 
>>>>> need to reduce it.

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 10 Jun 2009 18:12:04 -0400

> If people haven't implemented it, maybe they will when it starts to be 

Well, as I said before, I think that in 99% of the current
implementation situations, the subscriber will re-subscribe as a matter
of policy.  But it's good for the termination message to have an
explicit semantic for that behavior as well.

Dale