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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 5 Nov 2001 03:24:18 -0800

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 6 Nov 2001 06:37:17 -0800

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

---

From: "Bert Culpepper" <[email-masked]>
Date: Tue, 6 Nov 2001 14:52:18 -0500

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 12:54 PM
> To: 'Bert Culpepper'
> > "authorized", a 200 is sent.
>
> Ummm... no. 202 is a final response. There will be no further final
> responses.

argh...duh. (my memory did fail me, and in a big way :)

>
> > Then immediate NOTIFY to handle forked
> > SUBSCRIBES. [after authorization has occurred]
>
> Such was originally the intention; however, this setup has advantages
> as well as disadvantages. At least, I assume it has advantages, since
> people are arguing for it.
>
> The only factor I'm aware of is that such a scheme makes it possible
> to receive an initial NOTIFY (i.e. one that sets up a new dialog)
> minutes or even hours after sending the SUBSCRIBE unless NOTIFYs
> are sent immediately upon reception of the SUBSCRIBE regardless of
> authorization.
>
> Originally, I was neutral on the topic, but the more analysis I
> do, the more I lean towards the immediate NOTIFY solution.

They don't hurt anything and have their use.  Immediate NOTIFYs are OK.

>
> I don't like the delayed NOTIFYs for a couple of reasons: first,
> it makes implementations keep around the "prototype" dialog (the
> one without a tag on the "To") for an indefinite period of time.
> Immediate notifies allow you to safely discard such state after
> a determinate period of time.
>
> The second issue is user experience: I foresee that the state
> conveyed by NOTIFY messages will often be rendered for users.
> There's an expectation of some amount of chaotic behavior
> upon startup (users can understand different status indicators
> popping up upon program startup or when they add a new resource to
> monitor), but objects being rendered to the user minutes or even
> hours after the initial request makes for bad user interface design.
>
> No one has made any other arguments on the topic of immediate
> or delayed notifies (at least, none that correctly take forking
> into account). The only issue that appears to be a topic of
> discussion right now is whether 202 is to be used at all. This
> seems like such an extreme non-issue that I can't believe people
> are holding up resolution of this draft -- on which several other
> drafts depend -- with what amounts to an aesthetic decision. We're
> not gobbling up a status code that could otherwise be useful,
> since 202 is defined in HTTP. Current client implementations that
> actually implement SIP correctly handle 202 like a 200 (since any
> unknown status code is treated like the x00 code of the same class).
>

A quick read of of 3.3.1, 4.3.3, and 6.2 and I see the use for 202.
Anyway, I myself don't mind both 2xx and immediate NOTIFY.  They both
have their purpose.

> Even if a 202 status code were unleashed on the SIP world, notifiers
> would work just fine sending a 200. There may be packages that
> want to take advantage of the subtle difference between 200 and 202
> to alter processing (forking can be taken out of the picture for these
> cases by packages forcing subscribers to 481 all NOTIFYs that are on a
> dialog other than the one established by the SUBSCRIBE response; this
> doesn't always make sense, but it sometimes does).

Sounds good to me.

>
> I'd love to hear *technical* arguments for or against particular modes
> of operation.
>

I can't think of any reason to change what's been documented.

> /a

Again, thank you for response.

Regards,
Bert

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 7 Nov 2001 03:36:31 -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,

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 7 Nov 2001 03:07:02 -0800

Hi Brian,

These are good arguments but once again it is the complications of forking
that are driving the problem (otherwise you wouldn't need the immediate
NOTIFY at all). 

When a SUBSCRIBE is forked you are only guaranteed of _reliably_ receiving
one of the 2xx responses generated by all notifiers that have created a
subscribe dialog. 

There in lies the problem - using 200/202 to indicate pending/proper
subscription is not a complete/robust solution and therefore should be
removed in favor of the robust solution rather than having two solutions!

I was thinking about the INVITE-response-ACK analogy. In these terms, the
SUBSCRIBE 2xx is really the analog of the INVITE 100 Trying message in the
INVITE  dialog. The 2xx SUBSCRIBE only tells you that the request has been
received and a dialog has been created (ie, from that point on a final
response WILL follow) but it does not attempt to indicate the pending state
of the transaction. The analog of the remaining INVITE responses
(provisional, failure and 2xx) is of course the string of NOTIFY's generated
by the notifier. 

Stretching the analogy a little <grin>, there is no benefit for a 100 Trying
_and_ a 102 Trying message - we should just recommend that the SUBSCRIBE 200
Ok is always sent. If you recommend that the 202 Accepted is sometimes sent
then people will start relying on this response code which is not a good
thing. 

We need a reason code in the NOTIFY for a number of reasons. Currently there
is no mechanism for determining
	- why the subscription is pending [awaiting authorization is only
one possible reason] (this is analog of provisional response codes)
	- why the subscription was rejected [for instance because of
authorization failed] (analog of error response codes).

We don't have this information and it is needed (IMO). This is a robust,
general mechanism and should be preferred over the non-200 2xx responses
that simply lulls people into trusting these SUBSCRIBE responses and don't
provide complete information.

Robert.

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

Hi all, 

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,

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 7 Nov 2001 12:21:41 -0600

Hi Robert,

I guess I just don't see where you are referring to there being two
solutions.

Using the INVITE-response-ACK analogy seems valid only to show that the
SUBSCRIBE/2xx/NOTIFY is also a three-way handshake. The 102 "stretch" (grin)
isn't really a fair comparison, because in the case of an
INVITE-response-ACK, we're not dealing with an isomorphic request (INVITE
has special rules).

You have brought up a good point though, one that I think needs further
examination:
how do we signal that subscription was rejected to the watcher? That seems
like a much
stronger argument towards not having a 202.

Hmmm... 

Brian Stucker
Nortel Networks

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 5:07 AM
To: Stucker, Brian [NGB:B635:EXCH]; 'Bert Culpepper';

Hi Brian,

Robert.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 7 Nov 2001 12:36:02 -0600

Hey James,

The FSMs were designed to show a useful event package that didn't need a
message body to do some work. Taking away the 202, regardless of forking,
implies that all event packages must have message bodies (currently). That
was the point that I was trying to make. The forking issue is still a
problem with or without the 202.

The multiple NOTIFYs is a definite problem. Unless the event package doesn't
care (which I can't off hand think of one that wouldn't) about different
states being reported for the same resource being watched due to multiple
state agents responding to a SUBSCRIBE (forking), we have to do one of two
things:

- Ensure that all of the state agents are synchronized ahead of any
notifications to the watcher for the resource the state agents are sending
NOTIFYs for.

OR

- Ensure that there is only one "logical" state agent. This doesn't mean
that there is only one state agent for the resource, but that anyone
watching the resource talks to a single state agent that is responsible for
aggregating the state information for the resource (limited forking).

I don't see a easy, SIP workable, way of ensuring that all of the state
agents are "sync'd" before notifying the watcher of the resource's state,
but I can see where aggregation can be enforced. This seems to be what these
problems consistiently boil down to.

Some event packages may not care about aggregation, though, and the rules as
to how aggregation is done would likely vary widely depending on the details
of the event package. Maybe some new headers are in order to address this
problem, as you suggest.

Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: James Undery [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 7:35 AM
To: Stucker, Brian [NGB:B635:EXCH]; 'Fairlie-Cuninghame, Robert';
sipping

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,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 15:31:17 -0500

I think James is right here. I don't have a problem with keeping the 202,
but the mapping of SUB/NOT to the INVITE handshake is by now quite clear:

INVITE            SUB/NOT
------            -------

INVITE  <----->    SUBSCRIBE
1xx     <----->     final response to SUBSCRIBE
final resp     <------>   NOTIFY
ACK           <------>  final response to NOTIFY

From this it is clear that we need, within NOTIFY, to convey the full set of
information which would be possible to be conveyed in the final response to
an INVITE. Treating the absence of a body of NOTIFY to imply pending is one
way, but it covers only one case. I think a more generic mechanism, through
some header, like Subscription-Status or something, that has a response code
and reason phrase, is much better and more generic. 

Now, if we take this one step further, it should, in theory, be allowed to
CANCEL a SUBSCRIBE after I get a final response to the SUBSCRIBE, and the
result of that would be to cause all subscriptions that have not generated a
NOTIFY yet (because the subscription wasn't authorized) to immediately send
a NOTIFY with a Subscription-Status of 487. Once you allow this kind of
cancellation, then it no longer becomes neccesary to have an immediate
NOTIFY, for the same reason you don't need to send a 2xx to INVITE
immediately. I'm not proposing that, but I think it is important to consider
how closely we do, or do not, wish to align the two mechanisms together.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> Sent: Wednesday, November 07, 2001 8:35 AM
> To: 'Brian Stucker'; 'Fairlie-Cuninghame, Robert'; [email-masked]

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 7 Nov 2001 16:59:31 -0600

That's another way of doing it. Makes the message a bit bigger though. I
guess the point is that it's becoming clear (at least to me and others) that
the NOTIFY message body is overloaded, and needs to be split up. Adding
support for a new header is simpler than supporting multi-part MIME types, I
would think. 
 
If we want to minimize development impact and message size/complexity, I'd
argue for the header, but otherwise it's really a toss up.
 
Regards,
 
Brian Stucker
Nortel Networks

-----Original Message-----
From: Parameswar, Sriram [NGB:B692:EXCH] 
Sent: Wednesday, November 07, 2001 4:53 PM
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'James Undery';
'Fairlie-Cuninghame, Robert'; [email-masked]; [email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

The new header sounds like a good idea - however the REFER draft sends
status in a NOTIFY using the message/sipfrag. If we are sending the new
Subscriber-Status header - that looks like a SIP status line - do we want to
consider the 'REFER way'?
 
 The Content-Type will tell the subscriber how to handle the status. We
could also have multipart MIME if we want to add both subscription status
and a event status body. So Brian's example would become:
 
NOTIFY [email-masked] SIP/2.0 
Content-Type: message/sipfrag
 
487 Request Terminated 

Just thought I would add that to the mix of ideas.
 
Sriram

__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Interactive Multimedia Server (IMS) Fax: 972-685-3563 
Nortel Networks, Richardson USA  Email: [email-masked] 

-----Original Message-----
From: Stucker, Brian [NGB:B635:EXCH] 
Sent: Wednesday, November 07, 2001 3:59 PM
To: Jonathan Rosenberg; 'James Undery'; 'Fairlie-Cuninghame, Robert';
[email-masked]; [email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

It seems that the real problem is coming down to trying to convey too much
in the NOTIFY message body. 

Really you need to convey two pieces of information: 

- The state of the subscription. 
- The state of the resource being watched by that subscription. 

I would argue that we should keep the immediate NOTIFY to preserve the 3-way
handshake mechanism but add (as has been suggested) a separate header that
keeps track of the subscription state.

Borrowing from the watcherinfo draft, I think it's fair to say that our
subscriptions can be in a finite number of states, and that those states can
be mapped to a SIP response code. So can we...

Always send a 200 OK to the SUBSCRIBE, followed by an immediate NOTIFY.
Within that NOTIFY, we include a new mandatory header called
"subscription-status".

The content of this header is simply the appropriate SIP response code and
reason. For instance: 

A successful subscripton request would be: 

SUBSCRIBE, 200 OK, and... 

NOTIFY [email-masked] SIP/2.0 
Subscription-Status: 200 OK 

If later, the subscription needed to be cancelled... 

NOTIFY [email-masked] SIP/2.0 
Subscription-Status: 487 Request Terminated 

etc. 

Make the reason code mandatory, and the reason phrase optional. 

Subscription-Status = Status-Code SP Reason-Phrase CRLF 

The Status-Code should probably be catgorized to a more definite set of
subscription states. Borrowing from the watcherinfo draft:

- Pending     (182) - instead of 202. 
- Active      (200) 
- Terminated  (4xx, 5xx, 6xx) 

3xx response codes are not allowed in the Subscription-Status, and if the
final (non-2xx) response can be determined by processing the SUBSCRIBE, it
is returned instead of the 200 OK to the SUBSCRIBE itself.

The NOTIFY message body then only contains information on the actual
resource being watched. 

Thoughts? 

Brian Stucker 
Nortel Networks 

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, November 07, 2001 2:31 PM 
To: 'James Undery'; Stucker, Brian [NGB:B635:EXCH]; 'Fairlie-Cuninghame, 
Robert'; [email-masked] 
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01 

INVITE            SUB/NOT 
------            ------- 

INVITE  <----->    SUBSCRIBE 

-Jonathan R. 

--- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave. 
Chief Scientist                             First Floor 
dynamicsoft                                 East Hanover, NJ 07936 
[email-masked]                     FAX:   (973) 952-5050 
http://www.jdrosen.net <http://www.jdrosen.net>                       PHONE:
(973) 952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  

> From: James Undery [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 7 Nov 2001 16:34:38 -0600

Perhaps a good starting point would be the enumeration
of reason-code for the Subscription-Expires header
in the draft-ietf-sip-events-01 draft.

/sean

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: Wednesday, November 07, 2001 4:18 PM
>To: Brian Stucker
>Cc: Jonathan Rosenberg; 'James Undery'; 'Fairlie-Cuninghame, Robert';
>Subject: Re: [Sipping] Immediate NOTIFIES change in sip-events-01
>
>
>There has already been discussion in other threads of need for a Reason
>header, at least for use in ACK and CANCEL. The need here for NOTIFY
>seems similar. (One of my reasons for wanting it is that sometimes an
>ACK is really a NACK, but there is currently no way to indicate this.
>Similarly, here we have a NOTIFY that is sometimes used for something
>quite different than its normal function.)
>
>I don't believe the Reason header was ever fully elaborated, 
>but I think
>the discussion was around something similar to response codes, but that
>there might need to be new ones added.
>
>	Paul
>
>> Brian Stucker wrote:
>> 
>> It seems that the real problem is coming down to trying to convey too
>> much in the NOTIFY message body.
>> 
>> I would argue that we should keep the immediate NOTIFY to 
>preserve the
>> 3-way handshake mechanism but add (as has been suggested) a separate
>> header that keeps track of the subscription state.
>> 
>> Borrowing from the watcherinfo draft, I think it's fair to say that
>> our subscriptions can be in a finite number of states, and that those
>> states can be mapped to a SIP response code. So can we...
>> 
>> Always send a 200 OK to the SUBSCRIBE, followed by an immediate
>> NOTIFY. Within that NOTIFY, we include a new mandatory header called
>> "subscription-status".
>> 
>> The content of this header is simply the appropriate SIP 
>response code
>> and reason. For instance:
>> 
>> The Status-Code should probably be catgorized to a more definite set
>> of subscription states. Borrowing from the watcherinfo draft:
>> 
>> 3xx response codes are not allowed in the Subscription-Status, and if
>> the final (non-2xx) response can be determined by processing the
>> SUBSCRIBE, it is returned instead of the 200 OK to the SUBSCRIBE
>> itself.
>> 
>> From: Jonathan Rosenberg [mailto:[email-masked]]
>> NOTIFY yet (because the subscription wasn't authorized) to 
>immediately
>> send

---

From: "Sriram Parameswar" <[email-masked]>
Date: Wed, 7 Nov 2001 16:52:48 -0600

487 Request Terminated 

Sriram

-----Original Message-----
From: Stucker, Brian [NGB:B635:EXCH] 
Sent: Wednesday, November 07, 2001 3:59 PM
To: Jonathan Rosenberg; 'James Undery'; 'Fairlie-Cuninghame, Robert';

etc. 

Thoughts? 

Brian Stucker 
Nortel Networks 

-----Original Message----- 

INVITE            SUB/NOT 
------            ------- 

INVITE  <----->    SUBSCRIBE 

-Jonathan R. 

---

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 8 Nov 2001 03:01:15 -0800

Hi Jonathan,

> Once you allow this kind of
> cancellation, then it no longer becomes necessary to have an immediate
> immediately.  

I thought that was one point that most people seemed to be in agreement on:
we want the immediate NOTIFY because it is desired that for SUBSCRIBE
requests to know (reliably) in a _timely_ fashion how many entities have
created a dialog.

Given that the 2xx SUBSCRIBE response is not reliable in the forked
scenario, then the NOTIFY request must serve a few purposes:

- act as initial provisional response (e.g. 100 Trying) if the 2xx SUBSCRIBE
didn't make it back (so reliably show state has been created).
- act as delayed provisional response to update the subscriber of
subscription progress
- act as delayed error response
- act as delayed success response (in which case it will carry proper Event
information)

[of course the success or error response can also occur immediately (in the
first NOTIFY) but this is the trivial case.]

Because the SUBSCRIBE 2xx response is not reliable in all cases it should
not carry much information. The 2xx SUBSCRIBE response maps to just a 100
Trying in the INVITE dialog analog (in my mind) [general provisional
responses are usually delayed - 100 Trying must be immediate] The
subscription state should only be reported through a reliable general
mechanism such as what is being suggested (Subscription-Status). I am in
full agreement here.

I do think we want to force the analogy too much - the users of SUBSCRIBE
and INVITE are substantially different and will probably have different
requirements.

The CANCEL/BYE analogy is achieved by sending a SUBSCRIBE with Expires: 0.
Once again, in a timely manner you will receive back a NOTIFY from all
points where the terminating SUBSCRIBE reached. 

Robert.

> Sent: Wednesday, November 07, 2001 8:31 PM
> To: 'James Undery'; 'Brian Stucker'; 'Fairlie-Cuninghame, Robert';
> [email-masked]
> immediately send

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Thu, 8 Nov 2001 09:49:38 -0600

> Hello,
>
>as SUBSCRIBE is compared to INVITE, can't we send an ACK request to the
>response of the SUBSCRIBE? I'm not sure if a ACK would pass a 
>proxy when no
>INVITE did before????

I understand what you are going for, but I have two immediate
gut reactions. 1) I hope no proxies out there try to block
an ACK because they don't remember the ACK. 2) ACK is so closely
tied to INVITE in the current spec. that it would be difficult
to extend it to other methods in most implementations.

BR,
sean

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 9 Nov 2001 00:07:52 -0600

I guess I don't follow how ISUP cause codes have much bearing on the status
of a subscription. Maybe you can explain a bit more?
 
The Subscription-Status header that I'm proposing would be an offshoot of
the sipfrag used in the REFER method, only as a header to avoid the
complexity of multi-part MIME types, etc.
 
Brian

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, November 08, 2001 3:51 PM
To: Paul Kyzivat
Cc: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'James Undery';

One caution on using Response codes versus Reason codes:  If you collect all
the cause codes used in ISUP, it would likely be more than 100.  That could
upset the numbering scheme.  This would argue for using the Reason codes.
It was also pointed out before that these are needed in the requests not the
responses.

Mike

At 05:18 PM 11/7/2001 -0500, Paul Kyzivat wrote:

I don't believe the Reason header was ever fully elaborated, but I think
the discussion was around something similar to response codes, but that
there might need to be new ones added.

        Paul

> I would argue that we should keep the immediate NOTIFY to preserve the
> The content of this header is simply the appropriate SIP response code
> http://www.jdrosen.net <http://www.jdrosen.net                     />
PHONE: (973) 952-5000
> http://www.dynamicsoft.com <http://www.dynamicsoft.com/> 
> 
> 

<http://www1.ietf.org/mailman/listinfo/sipping> 

_______________________________________________ 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: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2001 23:55:57 -0600

I guess I don't agree that we need to have a Subscription-Expires header if
we have a Subscription-Status header. In previous emails to the list I've
provided what I think is a mapping from the values in the current
Subscription-Expires header over to what could be used in
Subscription-Status.

Is there a reason that we can't use the Expires header in conjunction with
the Subscription-Status alternative to cover off on any information the
Subscription-Expires header was trying to provide?

As for the Reason header, I'd have to disagree with using that as well. The
Subscription-Status header could be sent in every NOTIFY, not just the ones
where the status changes, to describe the state of the subscription. So it's
not that this is the reason that the NOTIFY is being sent, it's the state of
the subscription itself. Two different things.

I could send:

NOTIFY
...

As part of a subscription that was already active. The reason for the NOTIFY
in that case would be because the resource being watched changed, not the
status of the subscription itself.

Adam, do you have any thoughts on this alternative? Am I understanding the
usage of the Subscription-Expires header correctly?

Cheers,

Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, November 08, 2001 1:55 PM
To: Bob Penfield
Cc: [email-masked]
Subject: Re: [Sipping] Immediate NOTIFIES change in sip-events-01

see below.

	Paul

Bob Penfield wrote:
> 
> ----- Original Message -----
> From: "Paul Kyzivat" <[email-masked]>
> To: "Brian Stucker" <[email-masked]>
> Cc: "Jonathan Rosenberg" <[email-masked]>; "'James Undery'"
> <[email-masked]>; "'Fairlie-Cuninghame, Robert'"
<[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Wednesday, November 07, 2001 5:18 PM
> I think Reason is slightly different than a Subscription-Status. Reason
was
> intended to send additional information on a CANCEL or a BYE (i.e. why the
> session is being terminated), similar to a cause code in ISUP. I like the
> idea of a Reason header for BYE, CANCEL, and even ACK. But, I think the
> subscription status should be separate as it conveys "Status" of the
dialog.

I am suggesting generalizing Reason, so in a way it doesn't matter if it
was intended for this or not.

I think Reason may be viewed as providing information about the reason
the message containing it was sent. This makes sense for BYE, CANCEL,
and ACK. Now we are in the situation of wanting to know more about why a
NOTIFY has been sent, so it might work well there too.

On the other hand, I am not yet convinced this is the right answer.

It really depends on whether the domain of reasons is the same for all
of these.
So far most examples have been reusing response codes. If everything
fits into
this model, then I think it is appropriate to use Reason here too.

The alternative proposal so far seems to be to use Subscription-Status
instead of or in addition to Subscription-Expires. There seems to be a
valid argument that Subscription-Expires is still needed, because it
carries a different kind of value. If so, I think it would be better to
save a header and use Reason + Subscription-Expires rather than
Subscription-Status + Subscription-Expires.

	Paul

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 9 Nov 2001 03:14:06 -0800

In the diminutive case where the first NOTIFY contains actual Event
information, the use of a separate ACK just increases the number of messages
required. Also regardless of whether proxy should or should not treat ACK as
a separate transaction, I'll bet this will cause many problems existing
proxies.

I think the immediate NOTIFY mechanism seems to work well within the
existing SUB/NOT framework for all our reliability requirements (with the
addition on a Subscription-Status header).

Robert.

> From: Brazier Lachlan [mailto:[email-masked]]
> Sent: Friday, November 09, 2001 10:44 AM
> To: 'Bob Penfield'; [email-masked]
> Cc: [email-masked]'
> Subject: AW: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> Hi,
> 
> > 
> > ACK can only be used for INVITE. 
> 
> Why's that?
> 
> I include the response from Sean Olson:
> 
> 1) I hope no proxies out there try to block 
> Regarding 1)
> I really assume that no proxy blocks an ACK, when it has no 
> Call state for
> it.
> 
> Regarding 2)
> Why's that? This would mean that an ACK request is 
> "untouchable" for other
> drafts. Because of 1), I don't see how proxies have a problem 
> with an ACK.
> This leaves UA's; but if UA's are implemented for SUB/NOTIFY, 
> they can add
> waiting for an ACK request as well.
> 
> My reasons for waiting for an ACK are:
> 
> * We know we need a 3 way- handshake because of forking --> 
> Why not use one
> we know is working (INVITE/response/ACK). Note, I'm not 
> saying to use it the
> same way as with INVITE. The ACK would be meaningfull only for the
> endpoints, even with error responses. But as the endpoints 
> need to handle
> the SUBSCRIBE request, they can wait for an ACK before 
> sending the NOTIFY.
> If they sent an error response, they will just drop the ACK.
> 
> * Repetition: 
> A sends a SUBSCRIBE. Proxy P forks the subscribe. Several 2xx 
> message come
> back. As the request was a SUBSCRIBE, only one response will be passed
> further on. Now A ACK's the response. As the To header in the 
> ACK has a
> Tag, the proxy can fork the ACK if it wishes (for RFC2543 
> reasons), and
> everybody will know if it's response arrived at the 
> subscriber or not, and
> can send the NOTIFY in case of yes, and do nothing in case of no.
> 
> As far as I see, this is exactly what we wanted.
> 
> Please also note, that I believe that a Subscription-Expires 
> header and a
> Subscription-Status header are still usefull in a NOTIFY request.
> 
> Cu
> Lachlan
>

---

From: Brazier Lachlan <[email-masked]>
Date: Fri, 9 Nov 2001 14:57:59 +0100

> >
> > Sorry for being unclear; I did'nt say to use the ACK like
> > with the INVITE.
> > Because of the SUBSCRIBE request, only one 2xx response will
> > be carried
> > upstream. The the ACK will be forked from the proxy to every
> > endpoint (=
> > presentity). This way every endpoint will know wheter it's
> > response was
> > received or not (because only the right tag in the To header
> > will match).
> > I thought this was what we wanted.
> > General I don't see why the ACK request should be "untouchable".
> 
> The problem is unreliable transport and specfically 
> retransmission in this
> case. You'd have to alter ACK behaviour to cope with 
> non-INVITE requests,
> this is ugly.

Ok, agreed, and I received other reasons why ACK won't work in a neat way. 
But this also means, that every draft which depends on a 3-way handshake,
has to invent it new from the beginning.

Lachlan

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 9 Nov 2001 09:36:21 -0600

>waiting for an ACK request as well.

If you look at the design and implementation of the SIP
protocol you will see that there is a set of behaviors
for an INVITE/response/ACK sequence and a set of behaviors
for everything else. This applies to both the UA and
the (stateful) proxy. Proxying on an ACK for which you
don't have call state is one thing. Proxying on an ACK
for a SUBSCRIBE is a completely different proposition.
A three-way handshake might have been usefully applied
across all SIP requests, but as it is, it currently
only applies to INVITE. That is fairly well entrenched.
I don't think most implementors would be willing to change
this, but I can only speak for myself. I would be curious
to hear other opinions as well.

cheers,
/sean

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 9 Nov 2001 08:01:38 -0800

I agree with James - why are we even bothering to discuss this?
 
Robert.

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Friday, November 09, 2001 3:36 PM
To: 'Brazier Lachlan'; 'Bob Penfield'; [email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

cheers, 
/sean

---

From: Michael Hammer <[email-masked]>
Date: Fri, 09 Nov 2001 11:43:02 -0500

Brian,

I may have confused the original discussion of Reason header with the new
need related to the Sub-Status header.  Whether we call it a status
or a reason, the intent appears to be to provide more detail with element
under consideration.  In the case of original Reason code, it was
aimed toward the session, in the case of the Subscription-Status, it is
about the Subscription.

My question would then be whether to have two headers specific to each
element or one header whose values would indicate which element is given
added detail.

In your view, would one ever request a Subscription for Notification
about the status of a Session or Registration, or just to independent
information services?

Mike

At 12:07 AM 11/9/2001 -0600, Brian Stucker wrote:

I
guess I don't follow how ISUP cause codes have much bearing on the status
of a subscription. Maybe you can explain a bit
more?

The Subscription-Status
header that I'm proposing would be an offshoot of the sipfrag used in the
REFER method, only as a header to avoid the complexity of multi-part MIME
types, etc.

Brian

-----Original Message-----

From: Michael Hammer
[mailto:[email-masked]]

To: Paul Kyzivat

Cc: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'James
Undery'; 'Fairlie-Cuninghame, Robert'; [email-masked];
[email-masked]

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

One caution on using Response codes versus Reason codes:  If you
collect all the cause codes used in ISUP, it would likely be more than
100.  That could upset the numbering scheme.  This would argue
for using the Reason codes.  It was also pointed out before that
these are needed in the requests not the responses.

Mike

At 05:18 PM 11/7/2001 -0500, Paul Kyzivat
wrote:

There has already been discussion in other threads of need for a
Reason

header, at least for use in ACK and CANCEL. The need here for
NOTIFY

seems similar. (One of my reasons for wanting it is that sometimes
an

ACK is really a NACK, but there is currently no way to indicate
this.

Similarly, here we have a NOTIFY that is sometimes used for
something

I don't believe the Reason header was ever fully elaborated, but I
think

the discussion was around something similar to response codes, but
that

Paul

preserve the

response code

> To: 'James Undery'; Stucker, Brian [NGB:B635:EXCH];

> 'Fairlie-Cuninghame,

> I think James is right here. I don't have a problem with keeping
the

> 202,

> but the mapping of SUB/NOT to the INVITE handshake is by now
quite

> clear:

INVITE
SUB/NOT

------
-------

> From this it is clear that we need, within NOTIFY, to convey the
full

> set of

> information which would be possible to be conveyed in the
final

> response to

> an INVITE. Treating the absence of a body of NOTIFY to imply
pending

> is one

> way, but it covers only one case. I think a more generic
mechanism,

> through

> some header, like Subscription-Status or something, that has a

> Now, if we take this one step further, it should, in theory,
be

> allowed to

> CANCEL a SUBSCRIBE after I get a final response to the
SUBSCRIBE, and

> the

> result of that would be to cause all subscriptions that have
not

> generated a

immediately

> a NOTIFY with a Subscription-Status of 487. Once you allow this
kind

> of

> immediately. I'm not proposing that, but I think it is important
to

> consider

> how closely we do, or do not, wish to align the two mechanisms

> together.

> Jonathan D. Rosenberg,
Ph.D.
72 Eagle Rock Ave.

> Chief
Scientist
First Floor

dynamicsoft
East Hanover, NJ 07936

[email-masked]
FAX:   (973) 952-5050

http://www.jdrosen.net
PHONE: (973) 952-5000

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

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

Sipping mailing list
http://www1.ietf.org/mailman/listinfo/sipping

_______________________________________________ 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: Michael Hammer <[email-masked]>
Date: Fri, 09 Nov 2001 11:44:39 -0500

(Trying to resend in plain text, sorry for hitting the wrong button.)

Brian,

I may have confused the original discussion of Reason header with the new 
need related to the Sub-Status header.  Whether we call it a status or a 
reason, the intent appears to be to provide more detail with element under 
consideration.  In the case of original Reason code, it was aimed toward 
the session, in the case of the Subscription-Status, it is about the 
Subscription.

In your view, would one ever request a Subscription for Notification about 
the status of a Session or Registration, or just to independent information 
services?

Mike

At 12:07 AM 11/9/2001 -0600, Brian Stucker wrote:
>I guess I don't follow how ISUP cause codes have much bearing on the 
>status of a subscription. Maybe you can explain a bit more?
>
>One caution on using Response codes versus Reason codes:  If you collect 
>all the cause codes used in ISUP, it would likely be more than 100.  That 
>could upset the numbering scheme.  This would argue for using the Reason 
>codes.  It was also pointed out before that these are needed in the 
>requests not the responses.
>
>Mike
>
>for questions on current sip Use [email-masked] for new developments of core SIP

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 9 Nov 2001 11:35:22 -0600

Yes, but you're also taking the view that getting multiple NOTIFY messages
back from a SUBSCRIBE is always a bad thing, and we should use the ACK to
limit this. There are times when getting back multiple NOTIFY messages, even
if you didn't get the 2xx responses that preceeded them, is useful. So why
remove that?

Regards,

Brian

-----Original Message-----
From: Brazier Lachlan [mailto:[email-masked]]
Sent: Friday, November 09, 2001 5:35 AM
To: 'Fairlie-Cuninghame, Robert'; Brazier Lachlan; 'Bob Penfield';
[email-masked]

Hi,

> a separate transaction, I'll bet this will cause many 
I would say, NOTIFY's from several clients to the subscriber including the
responses is a higher network load as one forked ACK.

> addition on a Subscription-Status header).

My problem was not the mechanism itself, but the handling of several
NOTIFY's at the SUBSCRIBER.

Lachlan

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 9 Nov 2001 11:38:19 -0600

Well that depends. They could copy what SUBSCRIBE/NOTIFY does if that's good
enough for their use.

Brian

-----Original Message-----
From: Brazier Lachlan [mailto:[email-masked]]
Sent: Friday, November 09, 2001 7:58 AM
To: 'James Undery'; Brazier Lachlan; 'Fairlie-Cuninghame, Robert'; 'Bob
Penfield'; [email-masked]
Cc: [email-masked]; [email-masked]'
Subject: AW: [Sipping] Immediate NOTIFIES change in sip-events-01

Lachlan

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 9 Nov 2001 11:53:06 -0600

Thanks Mike,

(I can read either format as I use Outlook.)

I think I'm seeing where you are coming from with the Reason header. My
thinking was that the Subscription-Status code be limited only to the actual
status of the subscription itself, and speak nothing about the service the
subscription may be providing. 

To my mind, the state of the resource that the subscription is tracking can
be any arbitrary value, and is described in the NOTIFY message body as is
currently put forth. 

The state of the subscription watching the resource, however, can only be in
a finite number of states. Borrowing from the watcherinfo draft (which I
think expresses these states very adequately), the subscription can only be:

- Pending (202)
- Active (183, 200)
- Terminated (301, 302, 401, 402, 403, 408, 486, 487, 500, 503, 603,)

And that's it. I feel that we can easily map the SIP response codes, which
are well known and understood, to describe these states adequately, and thus
using the Reason header may be more than what we really need. To me, the
reason for the notify is contained in the message body. The status of the
subscription itself is contained in the Subscription-Status header. If there
is no message body to the NOTIFY, this would be because the resource being
watched only has 1 state to it, and does not require any information about
it's current properties to be sent to the watcher (as they can all be
implied from simply receiving the notification). If this is not the case,
and the resource is more complex, then a message body must always be
included to describe it's properties at the time the notification was sent
(ie. the reason for sending it is because the properties of the watched
resource changed, not because the subscription changed).

I can definitely see us subscribing to the state of a registration. It's
already being proposed in the 3GPP forum. However, in the case of
subscribing to a registration, we  should (in my mind) transport the reason
for sending the notify in the message body as the resource being watched is
the registration.

Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, November 09, 2001 10:45 AM
To: Stucker, Brian [NGB:B635:EXCH]
Cc: Paul Kyzivat; Jonathan Rosenberg; 'James Undery';

Brian,

Mike

SIP

---

From: Michael Hammer <[email-masked]>
Date: Tue, 20 Nov 2001 10:44:05 -0500

Jonathan,

Agree with the idea that such a header would be about the subscription 
status rather than the transaction status.  But, I am still mulling over 
the question of whether a forking action affects not only the transaction, 
but in essence forks the subscription as well.  Long after the initial 
Subscription transaction has ended, there may be multiple nodes active 
maintaining subscription state and reporting that back to the subscriber.

Would the forking proxy need to indicate to the tines that "subscription" 
forking has occurred?
Would the nodes sending Notifies need to indicate that they are only one 
tine of the fork as part of the status?

Have I wandered past left field onto the warning track?  :-)

Mike

At 02:05 AM 11/20/2001 -0500, Jonathan Rosenberg wrote:
>This thread ended abruptly, but its really important, and I'd like to see it
>terminate.
>
>I think there is consensus that we need some kind of header in the NOTIFY to
>convey some kind of state. A few proposals were floated, to use the Reason
>header we've discussed in other contexts, or a new header. To me, the most
>important thing to understand is what are the semantics we are trying to
>convey.
>
>First, does this header convey the status of the susbcription or the
>SUBSCRIBE transaction? This was also debated in this thread. I think we
>should convey the status of the susbcription, not the transaction. The
>transaction itself has already terminated. Although the final response code
>may not be reliably delivered to the UAC because of forking, its not clear
>what the value of sending it in the NOTIFY would be. It opens up a very
>large can of worms for mapping everything we do with responses, into the
>NOTIFY request. For example, if I got a SUBSCRIBE with a body I didn't
>understand, would I send a 200 OK to that, and then a NOTIFY like:
>
>NOTIFY
>Status: 415 I dunno
>Accept: application/new-filter-type
>
>And then the subscriber retries the SUBSCRIBE using only this filter-type.
>
>Do we want to go this far? This will require a serious redefinition of many
>of the headers and processing rules, to map response processing to request
>processing. I'm not sure we should go that far, and I don't know where to
>draw the line. This would be optimizing a lot of processing for the forking
>case, which is a mistake, I think. Also, you are now faced with the problem
>of mapping the status in the NOTIFY to a specific SUBSCRIBE transaction.
>
>So, what would we do in this case above, where some of the notifiers can't
>process the NOTIFY because the body is of the wrong type? So long as ONE of
>them can process the type, the subscription will succeed there, and you'll
>get back the 200 OK from that one, and then a NOTIFY. If none of them
>supports the type, you'll get back a 415, and can then try again. So, if the
>function you want is for the SUBSCRIBE to succeed at any one of the
>recipients, it is OK to not worry about this problem. If, however, the goal
>is to create successful subscriptions at all elements that received the
>forked SUBSCRIBE, I think that this is a bigger problem, and I am not sure
>we should try to tackle that.
>
>
>I think it makes much more sense to have NOTIFY convey the state of the
>subscription. This natually aligns with what NOTIFY is for (state of the
>thing the subscription refers to). Furthermore, the states of the
>subscription are more easily enumerable (and watcherinfo defines them, as
>has been pointed out). We clearly have a need to know this state at the
>subscriber, even for non-forking cases, whereas knowing the state of the
>transaction, above, is only needed for forking (the SUBSCRIBE response
>itself is sufficient for the non-forking case).
>
>Thus, we only need a header to convey those states. I see little value in
>this case of using sip response codes, since this will only be a source of
>confusion about how to map a particular response code to a particular
>subscription state. I would prefer a header defined specifically to convey
>subscription states.
>
>-Jonathan R.
>
>---
>Sent: Friday, November 09, 2001 12:53 PM
>To: Michael Hammer
>Cc: Paul Kyzivat; Jonathan Rosenberg; 'James Undery'; 'Fairlie-Cuninghame,
>Robert'; [email-masked]; [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Nov 2001 12:03:53 -0500

> Sent: Tuesday, November 20, 2001 10:44 AM
> To: Jonathan Rosenberg
> Cc: 'Brian Stucker'; Paul Kyzivat; Jonathan Rosenberg; 'James Undery';
> but in essence forks the subscription as well. 

Yes, it does.

> Long after 
> the initial 

Right.

> Would the forking proxy need to indicate to the tines that 

No. Why would this be different than INVITE?

> tine of the fork as part of the status?

No, they can't even know that. Each subscription will have its own dialog
ID.

-Jonathan R.
---

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 20 Nov 2001 12:00:33 -0600

If there is a header in the NOTIFY, it will tell the watcher that it's
forked by default if we immediately send back a NOTIFY as the draft
currently stands.

The way forking is handled in the -01 draft is as good as it gets without
deprecating SIP. Having the forking proxy tell us it forked does this, so I
don't think we want to do that. I don't think it's necessary either.

In each NOTIFY, the TO tag should vary, and because of this, the watcher
will see 'hey, I've got more than one tag coming back at me, it must have
forked'... The only case where knowing or not knowing might change things is
if the event package did something special if there was only one response
returned, versus many. In that case, it would have to wait for awhile to see
how many responses it got back before proceeding.

If we put a header in, which I had previously suggested throwing a subset of
the response codes in, because they were well understood and easily
mappable, and we already do this with REFER. 

I don't buy in to the header processing argument saying that you'd have to
do response code processing in a request message. It's a string. You can put
whatever you want there and it shouldn't be any more complex to put "200" as
it is "active." The reason for arguing that we use the response codes is
because they're there, and the semantics are well known. If it's a hassle to
folks to keep straight what 200 means in a subscription-status header, then
let's change it to something everyone can easily understand.

Mapping the status of a subscription in a NOTIFY to a specific SUBSCRIBE
transaction shouldn't be that difficult, because you already have to do so
with the -01 revision of the draft by paying attention to the message body
of the NOTIFY that gets sent back.

Splitting out the subscription status from the message body of the NOTIFY
seems to makes sense. If there is trepidation about doing so with a header,
are there other suggestions as to how to do it?

Thoughts?

Brian Stucker

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 9:44 AM
To: Jonathan Rosenberg
Cc: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat; Jonathan Rosenberg;
'James Undery'; 'Fairlie-Cuninghame, Robert'; [email-masked];
[email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

Jonathan,

Mike

immediately

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Nov 2001 02:28:42 -0500

> Sent: Tuesday, November 20, 2001 4:44 PM
> To: 'Jonathan Rosenberg'; 'Brian Stucker'; Michael Hammer
> Cc: Paul Kyzivat; 'James Undery'; 'Fairlie-Cuninghame, Robert';
> Replace "SUBSCRIBE" with "INVITE." This is a general problem.
> 
> Fast-forward a few years; I send an INVITE with SDP-NG as the body.
> It forks to your mobile phone, your work phone, and your spiffy new
> home phone. Your mobile and work phones send 415 responses. Your
> home phone (which is nowhere near you) sends 180, and ultimately
> a 200 (at which point the built-in answering machine fires up).
> 
> Replace 415 with any 400-class response that isn't a final
> failure (401, for example). What happens here? You have your
> service set up to reach you at three destinations, but it isn't
> working!

True. The point I have been making is that the semantics of INVITE are to
reach the user at one of the locations, not to get a dialog with all three.
Thus, one can argue (albeit weakly) that the above case is not so
catastrophic, since I have establsihed a dialog with one. I would agree its
not ideal.

> 
> The problem you describe isn't specific to SUBSCRIBE. In fact, it's
> far more annoying in the INVITE case than it can ever hope to be
> for SUBSCRIBE.
> 
> I think this problem needs to be solved -- but it certainly shouldn't
> be solved in a way that is specific to SUBSCRIBE.

Agreed. The merging of challenges in 401/407 is one step towards that, and
it works nicely when all UA challenge. The problem that is arising here is
when you have a mix of things that send different responses, so that some of
the ones that "need more information to proceed" are lost at the forking
proxy.

I'm not sure there is an easy solution to this, and I'm not yet convinced
its a real enough problem to worry about. 

-Jonathan R.

---

---

From: Michael Hammer <[email-masked]>
Date: Wed, 21 Nov 2001 10:21:08 -0500

Robert,

With your construction below, I gather that you think that the expires, 
state, and reasons will be specific to Subscriptions and not applicable to 
other things, such as sessions in general.

I see an Expires, but not a State or Reason header for sessions.  Should 
these constructions be parallel?  Can the three fields be separate headers 
and used for either Session or Subscription?

Mike

At 05:54 AM 11/21/2001 -0800, Fairlie-Cuninghame, Robert wrote:
>Adam,
>
>I too agree - the NOTIFY should only try to convey information about the
>subscription not the transactions.
>
>However I don't think the Subscription-Expires (in its current form) is well
>suited to that purpose. Currently the "Subscription-Expires" reason only has
>any meaning when the Expires valid is set to zero. In other words, the
>header is a cobbling together of two functions - subscription expires (on
>success) and a failure reason.
>
>It cannot convey information that the subscription is pending (or why) or
>when a subscription becomes active.
>
>I would support a extension of the header to include a subscription state:
>
>Subscription-Expires: <expires> <state> <Reason>
>
>[This syntax is also backwards compatible.]
>
>An example of subscription states:
>         "pending"
>         "active"
>         "terminated"
>
>The expires value for a successful session should only be taken from an
>"active" Subscription-Expires indication. In other states it will be equal
>to the Expires header value.
>
>Comments?
>
>Robert.
>
> > Sent: Tuesday, November 20, 2001 10:00 PM
> > I agree with Jonathan's analysis of the situation.
> >
> > As it stands, we have a mechanism which allows us to convey
> > whether the subscription is active: is Subscription-Expires > 0?
> > We also have a way to indicate roughly why this value
> > is anything other than what the subscriber might expect.
> >
> > Is this sufficient? I think it is. The reason codes seem better
> > geared towards conveying transaction state (like they do in
> > REFER). I agree with Jonathan that we want to convey subscription
> > state, not transaction state.
> >
> > This still leaves the authentication issues, to which the reason
> > codes offered an incomplete solution. As I previously
> > argued, authentication through a forking proxy is a general
> > problem which impacts INVITE (and all other methods) at least
> > as severely as it does SUBSCRIBE. I am loathe to solve a general
> > problem in a method-specific manner.
> >
> > Perhaps I don't understand the problem that people are trying
> > to solve here, but I think the current mechanism (Subscription-Expires
> > with an optional reason parameter) accomplishes what is necessary to
> > make things go.
> >
> > If someone has additional requirements that aren't fulfilled by this
> > scheme, please explain the problem you see with the current draft.
> >
> > /a
> >

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 21 Nov 2001 10:48:12 -0800

For an INVITE session these session states/cause are indicated by the 1xxx,
2xx, 4xx+ and the as yet undefined BYE Reason header.

Sure ideally it would be nice to have something that is general enough to be
able to work for any session entity - however we are trying to characterise
Subscriptions here. Who's to say whether these session states/cause will be
sufficient and/or applicable to some other "non-INVITE general session
entity". 

We know for an INVITE session (more-or-less) what needs to be characterised
however there are already established methods for some of these session
states/causes that are inherently specific to the INVITE/ACK exchange (e.g.,
INVITE provisional and error responses); there is also an as yet undefined
set of CANCEL/BYE reasons states.

So in answer to your question, yes I believe that it is not wholly
unthinkable to concentrate only on what we need to for subscriptions.
Whether or not we need to break Subscription-Expires in two headers: one
handling expiration values and another reusable "general" state/reason
header is another question. 

I am fine with keeping it all in one Subscription specific header (as
suggested in earlier email). Anyone else have an option?

Robert.

> Sent: 21 November 2001 15:21
> To: Fairlie-Cuninghame, Robert
> Cc: [email-masked]'; 'Jonathan Rosenberg'; 'Brian Stucker';
> Paul Kyzivat; 'James Undery'; [email-masked]

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 23 Nov 2001 02:06:31 -0800

Hi Bert,

> Well, we've lost the Expires header in NOTIFYs.  However, if 
> subscription
> state other than active/non-active is needed we'll need something like
> this header extension.  The only comment I have then is do we need
> "active" and "terminated", since the expires value indicates "active"
> when >0 and "terminated" when 0.
> 

I guess I was going for simplicity over non-redundant representation. Yes -
in most cases the reason phrase is probably not required for the active
state and the  expires valid is not required for the terminated state (and
of marginal use in the pending state). I don't see this as any great
problem. 

Some of the failure reasons I was thinking of:

State		Reason		Cause

pending	awaiting-auth	Awaiting authorization of SUBSCRIBE
		awaiting-object	Awaiting the subscribed object to become
					 active/valid.
active

terminated	object-not-found  Request subscription object could not be
located
		auth-failed		Authorization Failed
		object-terminated Subscribed object terminated.
		subscriber-req	Subscriber issued SUBSCRIBE with Expires 0
notifier-req	Notifier requested subscription termination
		expired		Subscriber did not refresh subscription.
		
Robert.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 16:42:58 -0500

> Sent: Friday, November 23, 2001 5:07 AM
> To: 'Bert Culpepper'
> Cc: [email-masked]

It sure seems like we are conveying the subscription states and events
specified in
http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-00.txt. Seems
like we should unify those. In fact, one might argue that the truly unified
thing to do is to include the actual watcher info doc in the body,
http://www.jdrosen.net/papers/draft-ietf-simple-winfo-format-00.txt, rather
than have a header translation for it. After all, what we are trying to
convey is subscription state, and thats exactly what watcherinfo is for. I'm
not saying we should go that far, but there should be some form of alignment
here.

-Jonathan R.

---

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 28 Nov 2001 12:22:49 -0600

I agree. The states you have in your WATCHERINFO format draft work just
fine. I think putting the complete document into a NOTIFY is a bit much,
given we don't need any of the other fields particularly, and other than the
first-subscribed field, they are either redundant to information already in
the NOTIFY (duration, notify-address, etc.), or they can be calculated
directly from the information in the NOTIFY (most-recently-subscribed).

It would be nice if we included status portion of the watcherinfo format in
the NOTIFY message. I can't see much use in including the event field since
(presumably) the watcher will know what event triggered the NOTIFY, and if
they can't, they can use watcherinfo to get it. Really, we're just trying to
denote the basic state of the subscription, right?

So, instead of potentially having to change two drafts, why not extend one a
little bit.

How about this revised section 3.2.3 to the -01 events draft:

-----

3.2.3. "Subscription-Expires" Header

     The following header is defined for the purposes of this
     specification.

     Subscription-Expires =  "Subscription-Expires" ":"
                              ( SIP-date | delta-seconds )
                               *( ";" subexp-params )
                             ";" "state" "=" state-code

     subexp-params        =   "reason" "=" reason-code
                            | generic-param

     state-code           =   "pending"
                            | "active"
                            | "terminated"

     reason-code          =   "migration"
                            | "maint"
                            | "refused"
                            | "timeout"
                            | reason-extension

     reason-extension      =   token

     Subscription-Expires is added to the definition of the element
     "request-header" in the SIP message grammar.

-----

... and then put little blurbs into the sections that talk about NOTIFY
generation saying which state is the correct one to put into the message.

Brian Stucker
Nortel Networks

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, November 27, 2001 3:43 PM
To: 'Fairlie-Cuninghame, Robert'; 'Bert Culpepper'
Cc: [email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

-Jonathan R.

---

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 28 Nov 2001 11:00:13 -0800

This sounds like a good suggestion to me Brian.

I would like to suggest the watherinfo reason codes are expanded a little.
For instance, the watcherinfo assumes that the pending states is waiting for
authorization. It could however be pending while waiting for the subscribed
object to become active (note: I am not referring to the subscribed Event
package here). This sort of behavior may be typical/useful when you are
trying to subscribe to an event that has not started yet (and yet you desire
to have the subscription in place _before_ the event begins). I also think
the rejection/termination reasons could be expanded a little more.

Regards,

Robert.

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: 28 November 2001 18:23
To: Jonathan Rosenberg; 'Fairlie-Cuninghame, Robert'; 'Bert Culpepper';
[email-masked]
Cc: [email-masked]

     reason-extension      =   token 

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, November 27, 2001 3:43 PM 
To: 'Fairlie-Cuninghame, Robert'; 'Bert Culpepper' 
Cc: [email-masked] 
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01 

here. 

-Jonathan R. 
---