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

[Adam Roach <[e-mail]>]

[as an individual]

Many thanks to Dale for reviewing the document. He caught a number of 
legacy issues that existed in 3265 that very much deserve cleanup for a 
bis version, as well as a few issues with the new text.

Several responses inline.


Dale Worley wrote:
> I'm glad we're cleaning up how we define events.  But there are a few
> things left to clean up:
>
> ** Technical
>
> * What is a resource?
>
> It looks like the draft cleans up the question of what is a resource,
> in that section 3.1.2 paragraph 2 states that the request-URI
> identifies the resource in question.  However, given the error in the
> first sentence of that paragraph (discussed below), I'd suggest
> promoting the statement that the request-URI identifies the resource
> to the beginning of the paragraph.
>   

This paragraph is actually copied verbatim from section 3.1.2 of RFC 3265.

> * What is state?
>
> There is a lot of ambiguity over what constitutes the "state" that the
> event system transmits.  These ambiguities bedevil attempts to
> implement generic event system "toolkits" as well as complicating the
> definition of new event packages.  (In the call-completion committee
> we've run into trouble with this.)
>
> In theory, we want the resource to have a certain set of state
> information, and that state information progresses through a series of
> different values over time.  Each time the state changes, every
> subscriber to that state would be notified of the new state value.  We
> further envision that a subscriber might supply a "filter" which is
> applied to every state value; then only the output of the filter would
> be sent to the subscriber, and the subscriber would be notified when
> the filtered state changed.
>
> Layered onto this nice, clean system are a set of issues, most of
> which we haven't addressed systematically:
>
> - If we want to be able to send state deltas, there needs to be a
>   defined way of taking the difference between two state values.
>   (This is well-described in the draft.)
>
> - In most event package definitions, we include the version number and
>   the partial/full indication *in* the state, rather than treating
>   them as *attributes of* the state value contained in a NOTIFY.
>   Since most definitions require the version number to start counting
>   from 0 independently for each subscription, the version number is
>   clearly not part of the state itself.
>   


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.


> - We haven't been clear about the difference between "state" (which
>   possesses values over time) and "events" (which happen instantly).
>   Generally, the event packages have been consistent in using state
>   rather than events.  (E.g., the dialog package's <state> element has
>   an attribute telling how a dialog entered its current state, but
>   that value is actually state, since it is "historical information",
>   a new subscriber could properly see the same value.)
>
>   State-orientation makes implementation easier, although it has some
>   unspoken implications; e.g., since notifications may be missed in
>   some way, the subscriber may see fewer state transitions than did
>   thenotifier, and so the event package must be organized so that this
>   is not a problem.  But we still have a tendency to use the word
>   "event" too much, even in the name of the mechanism.  For instance,
>   in the abstract:
>
>       The purpose of this extension is to provide an extensible framework
>       by which SIP nodes can request notification from remote nodes
>       indicating that certain events have occurred.
>
>   Similarly, 3.2.1 says:
>
>       NOTIFY bodies are expected to provide additional details about the
>       nature of the event which has occurred and the resultant resource
>       state.
>
>   The essential point is that the only *events* that can be reported
>   are the changes in an ongoing *state value*.  Though we've been
>   consistent about that fact, it's not clearly stated anywhere.
>   

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.

> - Many event packages contain data which is expected to change
>   frequently, but we do not expect each change to cause sending of the
>   state value.  For example, the dialog event package contains
>   "duration" elements telling how long each dialog has been
>   established, in seconds.  Clearly, this value changes every second.
>   Similarly, the "reg" event package contains the CSeq value of the
>   most-recent registration of a contact.  Changes in either of these
>   values are not intended to cause notification, but that is not
>   stated in the package definitions, nor is the possibility made clear
>   in the event framework.
>   

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?

> - 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?

> * Expiration time
>
> There is a problem regarding how the expiration time of a subscription
> is indicated that I don't think has ever been resolved.  It probably
> isn't a problem in practice, but it would help if we agreed on a
> solution.
>
> The difficulty regards how the subscriber should track the
> end-of-subscription time that is established when a re-subscribe is
> done.  The subscriber will receive a response to its SUBSCRIBE, and
> also the NOTIFY that it stimulates.  It may also receive other NOTIFYs
> stimulated by state changes.  All of these carry expiration times, or
> rather, the length of time from the present that the subscription will
> last.  The various NOTIFYs can be put in order by their CSeqs, and the
> latest one clearly supersedes the others.  But the relationship
> between a received NOTIFY and a success response to a SUBSCRIBE is
> harder to discern, as the subscriber does not know the order in which
> they were sent, and so does not know which represents the most recent
> state of the notifier.
>
> I think this problem is obviated by the fact that the notifier must
> always send a NOTIFY after receiving any SUBSCRIBE, so that the
> subscriber can in pratice disregard SUBSCRIBE responses, assuming that
> the network is reliable.
>
> But if we take this interpretation, then the wording in the draft
> should be adjusted in a number of places where it gives equal respect
> to the expiration time reported in a SUBSCRIBE response and that in a
> NOTIFY.
>   

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.

> 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?

> * 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.

> 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").

> ** Editorial
>
> * section 2
>
> The definition of "subscription" doesn't mention that the existence of
> a subscription means that the notifier will send state updates to the
> subscriber.
>   

Good point.

> * section 3.1
>
> This paragraph should say something like "The SUBSCRIBE method is used
> to requrest the creation of a subscription which will send current
> state and state updates from a remote node."
>   

Yes, that's more explicit.

> * 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?

> * section 4.1.3
>
>    NOTIFY requests MUST contain "Subscription-State" header fields which
>    indicate the status of the subscription.
>
> This is an instance where plurals should be made singular for clarity:
>
>    A NOTIFY request MUST contain a "Subscription-State" header field
>    which indicates the status of the subscription.
>   

Agreed.

> * section 4.1.3
>
>    giveup:  The subscription has been terminated because the notifier
>       could not obtain authorization in a timely fashion.  If a "retry-
>       after" parameter is also present, the client SHOULD wait at least
>       the number of seconds specified by that parameter before
>       attempting to re-subscribe; otherwise, the client MAY retry
>       immediately, but will likely get put back into pending state.
>
> The last clause would read better as:
>
>       the client MAY retry immediately, although the new subscription will
>       likely go into the pending state.
>
> The subscription doesn't really "get put back" into pending, since it
> is now in terminated.
>   

That's a reasonable clarification.

> * section 4.2.1.2
>
>    Note that a NOTIFY message is always sent immediately after any 200-
>    class response to a SUBSCRIBE request, regardless of whether the
>    subscription has already been authorized.
>
> Perhaps it is better to say:
>
>    Note that a NOTIFY message is always sent immediately after any
>    200-class response to a SUBSCRIBE request, regardless of the state
>    of the created subscription (e.g., pending).
>   

Okay.

> * section 4.2.1.4.  Refreshing of Subscriptions
>
>    When a notifier receives a subscription refresh, assuming that the
>    subscriber is still authorized, the notifier updates the expiration
>    time for subscription.  As with the initial subscription, the server
>    MAY shorten the amount of time until expiration, but MUST NOT
>    increase it.
>
> Here is one of the places where the discussion of "shortening
> expiration time" is ambiguous.  Reading it literally, it means that
> the notifier cannot increase the absolute expiration time *relative to
> what it was before the SUBSCRIBE arrived*, as "the amount of time
> until expiration" is an attribute of the subscription.  Of course,
> what is meant, the notifier sets a new expiration time which may be no
> longer-from-present that the duration requested in the SUBSCRIBE.
>   

I'll see if I can adapt some language from 3261 regarding REGISTER 
handling to make this clearer.

> * 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.

> * 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.

> * section 4.5.1
>
>       Because GRUUs are guaranteed to route to a *** a specific device, this
>
> Contains duplicate word "a".
>   

I'll fix that.

> * 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. :)

> * section 5.3
>
>    Any event package that supports delta changes to states MUST include
>    a version number that increases by exactly one for each NOTIFY
>    transaction in a subscription.
>
> And it must include a full/partial state indicator.
>   

Good point.

> * 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.

> * sectin 5.4.3
>
>    It is expected that most, but not all, event packages will define
>    syntax and semantics for SUBSCRIBE method bodies;
>
> This reads strangely, since only one defined event package has
> SUBSCRIBE bodies.
>   

I think we optimistically believed that people would define filters 
along with their event packages, instead of choosing to bolt them on 
later. But your observation that this didn't play out the way we 
expected is a good one, and I'll revise the text accordingly.

> * section 5.4.7
>
>    and whether state information is complete or deltas for
>    notifications
>
> This is awkwardly phrased.  Perhaps end the sentence before this
> clause and continue:
>
>     It also includes whether state deltas can be used, and if so, how they
>     are interpreted by the subscriber to update its record of the state;
>     see Section 5.3.
>   

Okay.

> * section 7
>
> The IANA Considerations section does not name the new SUBSCRIBE and
> NOTIFY methods, which is needs to do in order to register the methods.
> (RFC 3265 doesn't do this either, although the IANA database
> entries for SUBSCRIBE and NOTIFY references RFC 3265.)
>   

I have an open action item to figure out how the IESG wants us to handle 
IANA registration sections of bis RFCs. But this is a good catch, and 
one that I don't recall being pointed out before. I'll make a note of 
it, with action pending on the final guidance I get regarding IANA 
sections in bis docments.

/a