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

From: "Dale Worley" <[email-masked]>
Date: Tue, 28 Apr 2009 18:35:14 -0400

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.

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

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

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

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

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

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

Note that if we tighten up some of the previously-stated rules, the
race condition problem becomes easier to solve.  For instance, if we
demand that a re-subscribe can never bring forward the endpoint
(excepting if it makes the endpoint be now, i.e., terminating the
subscription), then the subscriber can always trust the *furthest*
endpoint that it has been informed of (unless it sees a termination).

* Notifier migration

Notifier migration is an interesting concept and seems like it might
be very useful.  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.
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.

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

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

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

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

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

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

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

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

* 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).  There is also the technical question of what
request-URI the subscriber should use to re-subscribe.  (see above)

* section 4.5.1

      Because GRUUs are guaranteed to route to a *** a specific device, this

Contains duplicate word "a".

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

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

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

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

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

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

Dale