Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

From: "Brian Stucker" <[email-masked]>
Date: Wed, 7 Nov 2001 03:26:10 -0600

Hi all,

I think Adam's current approach is the one we should take forward for
several reasons, which (if accepted) I also believe should be added to the
draft at some point just to clarify things a bit more (although I think the
-01 revision to the draft went a very long way to make many issues much
clearer, thanks Adam).

We will need the 202 Accepted. Here's why:

The 2xx response and the NOTIFY are the second leg in a 3-way handshake. The
2xx response is used to acknowledge the receipt of the SUBSCRIBE a contact
address of the entity being subscribed to, and the NOTIFY is used to detect
and acknowledge any forking of the SUBSCRIBE that may have occurred by an
intermediary proxy.

So, because they logically form a two-part response to the SUBSCRIBE, one
could argue that we could indicate that a subscription is "pending" by
transmitting that fact in either message. Instead of having a 202 returned
to us, we can create an "illegal" NOTIFY message (one with no message body)
to indicate that we're in a pending state. Therefore, always send back the
200 and an "illegal" (blank) NOTIFY message. If I understand correctly, this
is what has been put forth by some.

Ok, now if we look at the events draft for what it really is: synchronizing
a slave finite state machine (watcher) to a master finite state machine
(state agent) then things become much clearer. The problem with that
argument then becomes clear when I have a state machine that looks something
like this.

Master FSM:

   +------------+       (authorized)
   | Null State |------------------------------+
   +------------+                              |
         | (not authorized)                    |  subscribe / 200
         | subscribe / 202                     | 
        \|/                                   \|/
         '                                     '
   +---------------+  authorize / null  +--------------+
   | Pending State |------------------->| Active State |--+
   +---------------+                    +--------------+  |
      |    ^                                      ^       | event "A" /
notify "A"
      |    |  event "A" / null                    |       |
      +----+                                      +-------+

Slave FSM:

   +---------------+  "A" notify / do something  +--------------+
   | Pending State |---------------------------->| Active State |--+
   +---------------+                             +--------------+  |
      |    ^                                               ^       | 
      |    |                     A" notify / do something  |       |
      |    | 202 / do nothing                              |       |
      +----+                                               +-------+

If you take away the 202 Accepted, then the only means we have to convey if
we're in the pending state or not is the NOTIFY message (that's all that's
left). This forces the master state machine to look like:

Master FSM:

   +------------+       (authorized)
   | Null State |--------------------------------------------+
   +------------+                                            |
         | (not authorized)                                  |  subscribe /
200 &
         | subscribe / 200 & notify (blank)                  |  notify
(active)
        \|/                                                 \|/
         '                                                   '
   +---------------+  authorize / notify "A"           +--------------+
   | Pending State |---------------------------------->| Active State |--+
   +---------------+                                   +--------------+  |
      |    ^                                                     ^       | 
      |    |  event "A" / null           event "A" / notify "A"  |       |
      +----+                                                     +-------+

Slave FSM:
    
      +---+
      |   | 200 / do nothing
      |  \|/
      |   '
   +---------------+  (active) notify / do nothing  +--------------+
   | Pending State |------------------------------->| Active State |--+
   +---------------+                                +--------------+  |
      |    ^                                                  ^       | 
      |    |                       "A" notify / do something  |       |
      |    |                                                  +-------+
      |    | (blank) notify / do nothing
      +----+

Now the state machine becomes much more complex. I have to have a message
body that says I'm in the pending state, the active state, and finally a
message body that actually tells me to go do something. Now I actually have
to define a message body where a 202 would have sufficed nicely before. We
simply stay in the pending state until we need to do something, even if
we're authorized.

An example of such an event package would be:

Let's say we have a lazy client device that doesn't want to keep track of
it's registration expiration timer. We define the event package
"expiration-warning", and subscribe to the contact address that we're
interested in tracking so that the network will tell us when the expiration
interval for that contact is 95% expired. When the contact is about to
expire it simply sends a NOTIFY with the event header set to
"expiration-warning" and our device will re-register and re-subscribe again.

- There's no need to have a message body because we can convey everything we
need in the message headers.
- We can imply that the subscription is authenticated, but not authorized
until 95% of the interval for that expiration timer has passed. When the
timer has run down far enough, we implicitly authorize the subscription and
send a notify to let them know that their registration is about to expire.

Very simple, if we keep the 202. Still possible, but a little more complex
if we get rid of it. 

Hopefully this makes sense.

Regards,

Brian

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 8:37 AM
To: 'Bert Culpepper'; [email-masked]; [email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

Hi Bert,

The problem is that when a SUBSCRIBE is forked the 2xx response is no-longer
reliable for _all_ 2xx responses sent. [Hence the need for the three way
handshake.]

Now as one proper solution is always better than two, I think it is better
that the NOTIFY (which is reliable) contains the indication of whether the
subscription has been setup fully (rather than the SUBSCRIBE response -
which is both unreliable and does not properly infer how many dialogs have
been established). The SUBSCRIBE 200 OK means that a dialog has been
established and a NOTIFY will follow immediately - which is precisely the
behavior we must always have (ie 202 Accepted is no longer needed so lets
make thing _simpler_ => 200 OK always). 

In my opinion, the NOTIFY should indicate any "pending state"  of the
subscription (e.g. pending authorization) AND more-over this _mechanism_
should not be Event package specific.

Robert. 

> -----Original Message-----
> From: Bert Culpepper [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 2:17 PM
> To: 'Fairlie-Cuninghame, Robert'; [email-masked]; 'Sriram
> Parameswar'; [email-masked]
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> Hello Robert,
> 
> If my memory serves me correct, the 202 was "defined" to indicate
> "acceptance" of the SUBSCRIBE but not authenticated and/or authorized.
> This way re-transmissions of the SUBSCRIBE can be prevented while the
> device obtains the user's permission to accept the SUBSCRIBE, for
> example.  (It may take some time for this causing the 200 to be
> "delayed", therefore 202 was defined.)  Once the subscription is
> "authorized", a 200 is sent.  Then immediate NOTIFY to handle forked
> SUBSCRIBES.
> 
> regards,
> Bert
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > Fairlie-Cuninghame, Robert
> >
> > > Given that we fork, the NOTIFY actually serves some portion
> > > of the purpose that the 202 does. That's why Robert's arguments
> > > aren't necessarily valid.
> >
> > I lost you there. Why is 202 needed (instead of simple
> > SUBSCRIBE 200 OK)?
> > The NOTIFY will always be sent immediately, so surely 202 
> is no longer
> > needed for SUBSCRIBE.
> >
> > > There's a further advantage with the immediate notifies: you can
> > > be assured that you will know how many SUB/NOT dialogs have been
> > > established within a small period of time (less than a minute,
> > > at least) by counting the number of NOTIFY messages you get.
> > > Once again, this is a consideration driven by forking.
> >
> > Okay. That's a subtle point but I see it.
> >
> > However, with the current arrangement it is actually making it more
> > difficult to determine how many _real_ subscriptions you have
> > (due to the
> > fact that the initial NOTIFY may be a dummy event). This
> > means that in order
> > to know whether or not a _REAL_ subscription has yet been
> > created (i.e.
> > successfully authorized, etc, etc) is now largely Event
> > package specific - a
> > subscriber must now differentiate a "dummy" NOTIFY from a
> > "real" NOTIFY.
> >
> > In my mind we MUST have a non-Event-specific mechanism to
> > differentiate a
> > dummy initial NOTIFY (i.e., used just for a three-way
> > handshake) from a
> > NOTIFY carrying actual initial state information (which may
> > also be the
> > initial NOTIFY). This doesn't have to be anything complicated
> > but in my mind
> > it must be part of the SIP event specification.
> >
> > For instance, if the NOTIFY does not contain a message body
> > then it can be
> > considered that the dialog has been created but the
> > subscription is still
> > "pending" (i.e., unauthorized or a number of other reasons).
> > On the other
> > hand, I think it would be better to have some explicit reason
> > code rather
> > than relying on the lack of a event message body. We do 
> need something
> > though - rather than making each Event package come up with
> > its own scheme
> > to communicate when a subscription actually becomes useful
> > and/or why it is
> > still pending.
> >
> > Cheers,
> >
> > Robert.
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: 05 November 2001 19:57
> > > To: 'Sriram Parameswar'; [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> > >
> > >
> > > Sean is absolutely correct: the three-way handshake becomes
> > > crucial in the forked-SUBSCRIBE case. Everyone needs to carefully
> > > consider forking when they are discussing this issue. It would be
> > > extremely straightforward (and exactly like Sriram descibed)
> > > if forking didn't exist.
> > >
> > > But, we fork. It's just part of the protocol.
> > >
> > > Given that we fork, the NOTIFY actually serves some portion
> > > of the purpose that the 202 does. That's why Robert's arguments
> > > aren't necessarily valid.
> > >
> > > There's a further advantage with the immediate notifies: you can
> > > be assured that you will know how many SUB/NOT dialogs have been
> > > established within a small period of time (less than a minute,
> > > at least) by counting the number of NOTIFY messages you get.
> > > Once again, this is a consideration driven by forking.
> > >
> > > Just some grist for the mill. Make sure that any further 
> discussions
> > > on this topic consider and address forking.
> > >
> > > /a
> > >
> > > > -----Original Message-----
> > > > From: Sean Olson (EUS) [mailto:[email-masked]]
> > > > Sent: Monday, November 05, 2001 1:09 PM
> > > > To: 'Sriram Parameswar'; [email-masked]'; 
> [email-masked]';
> > > > [email-masked]'
> > > > Subject: RE: [Sipping] RE: Sipping digest, Vol 1 #172 - 5 msgs
> > > >
> > > >
> > > > But the three-way handshake *IS* needed for establishing
> > > > legs in the forking scenario. Or has that changed?
> > > >
> > > > /sean
> > > >
> > > > -----Original Message-----
> > > > From: Sriram Parameswar [mailto:[email-masked]]
> > > > Sent: Monday, November 05, 2001 12:10 PM
> > > > To: [email-masked]'; [email-masked]';
> > > > [email-masked]'
> > > > Subject: [Sipping] RE: Sipping digest, Vol 1 #172 - 5 msgs
> > > >
> > > >
> > > >
> > > > Robert;
> > > >
> > > > I agree with you - that the 'empty or neutral' NOTIFY does
> > > > not buy us anything, and we should probably eliminate it.
> > > > However we should retain the semantics that 202 means
> > > > Authenticated but not Authorized and a 200 OK response to
> > > > SUBSCRIBE as being both Authenticated and Authorized. In
> > > > either case there is no requirement for an immediate NOTIFY
> > > > (there may not be a reportable state associated with the
> > > > subscribed object).
> > > >
> > > > On the flip side, a discussion on the SIMPLE list (Adam
> > > > contributed)stated that the immediate NOTIFY formed part of a
> > > > 'Three way handshake'. A combination of signals results in a
> > > > 3-way handshake as follows:
> > > >
> > > >         * SUBSCRIBE
> > > >         * 202-NOTIFY
> > > >         * 200 OK for the NOTIFY
> > > >
> > > > I would contend that a 3-way handshake is _not_ necessary.
> > > >
> > > > Regards,
> > > >
> > > > Sriram
> > > >
> > > > __________________________________________
> > > > Sriram Parameswar              Phone: 972-685-8540
> > > > Interactive Multimedia Server (IMS) Fax: 972-685-3563
> > > > Nortel Networks, Richardson USA  Email:
> > [email-masked]
> > > >
> > > >
> > > >
> > > > Message: 1
> > > > From: "Fairlie-Cuninghame, Robert" <[email-masked]>
> > > > To: "[email-masked]'" <[email-masked]>
> > > > Cc: "[email-masked]'" <[email-masked]>
> > > > Date: Mon, 5 Nov 2001 03:24:18 -0800
> > > > charset="iso-8859-1"
> > > > Subject: [Sipping] Immediate NOTIFIES change in sip-events-01
> > > >
> > > >
> > > > Hi Adam,
> > > >
> > > > The new PDF format looks good.
> > > >
> > > > I wish to discuss the following section:
> > > >
> > > > 8.3 Immediate notifies
> > > >
> > > > There has been discussion, but no consensus, on the issue of
> > > > whether each
> > > > SUBSCRIBE must have an immediate NOTIFY message sent in
> > > response. In
> > > > attempts to follow the prevailing sentiment, this draft
> > had become
> > > > inter-nally inconsistent.
> > > >
> > > > This version of this document has eliminated these
> > > inconsistancies by
> > > > requir-ing notifiers always to send a NOTIFY immediately upon
> > > > receiving a
> > > > SUB-SCRIBE. This decision does not necessarily represent
> > > > group consensus,
> > > > and further discussion may be warranted.
> > > >
> > > > ---
> > > >
> > > > As Adam rightly says in a later section, this burdens Event
> > > > packages with
> > > > have to support and fake/dummy NOTIFIES while authorization
> > > > is pending. [And
> > > > just makes things plain messy!]
> > > >
> > > > Firstly I address these questions to the list as a whole
> > > > [since Adam is just
> > > > documenting list consensus].
> > > >
> > > > So what information is the immediate NOTIFY providing? None.
> > > > We have a 202
> > > > Accepted that informs the subscriber that the SUBSCRIBE
> > > > request is being
> > > > processed (and that it may take a non-trivial amount of time).
> > > >
> > > > The subscriber knows that the subscription is in effect when
> > > > the first
> > > > _real_ NOTIFY arrives, so sending a dummy NOTIFY immediately
> > > > is actually
> > > > confusing things! What is the rationale?
> > > >
> > > > If this does stay Adam, the rationale needs to be added and
> > > > the 202 Accepted
> > > > response code can be removed as far as I can see.
> > > >
> > > > Regards,
> > > >
> > > > Robert.
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "James Undery" <[email-masked]>
Date: Wed, 7 Nov 2001 13:34:49 -0000

Hi

This still doesn't cover Robert's point, i.e. you will only see one final
response and potentially multiple NOTIFYs. Your FSMs are already overly
simplified because of ignoring this complexity.

My personally favoured solution would be to include optional subscription
status info in NOTIFYs as a header. e.g. Replace Subscription-Expires with
something like a Subscription-State header that contained status (optional),
expires and expiry-reason (optional) parameters.

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian Stucker

Hi all,
draft at some point just to clarify things a bit more (although I think
the -01 revision to the draft went a very long way to make many issues much

Master FSM:

      +---+
      |   | 200 / do nothing
      |  \|/
      |   '

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 8:37 AM
To: 'Bert Culpepper'; [email-masked]; [email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

Hi Bert,