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

From: "Brian Stucker" <[email-masked]>
Date: Wed, 7 Nov 2001 15:58:56 -0600

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

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

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 8:35 AM
> To: 'Brian Stucker'; 'Fairlie-Cuninghame, Robert'; [email-masked]
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Nov 2001 17:18:04 -0500

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

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Thu, 8 Nov 2001 08:51:47 -0500

----- 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
Subject: Re: [Sipping] Immediate NOTIFIES change in sip-events-01

> there might need to be new ones added.

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2001 14:55:07 -0500

see below.

	Paul

> 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: Michael Hammer <[email-masked]>
Date: Thu, 08 Nov 2001 16:50:34 -0500

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

> 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

> response code

> 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

> 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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2001 19:05:37 -0500

Are you talking about what kind of codes to use in a Reason header?

The ISUP codes don't (as far as I can see) have anything to do with
NOTIFY reasons, but I suppose they do have something to do with
BYE/CANCEL/ACK reasons.

This might suggest that NOTIFY reasons need to be drawn from a different
domain than BYE/CANCEL/ACK reasons, and so require a different header.
Or, it might mean that the reason header is a bad idea. 

I don't recall if the reason header was ever worked out in detail -
especially wrt how codes were to be assigned. I seem to recall that
response codes, with some extensions, were proposed. One possibility
would be to start assigning extra values up in the 7xx and beyond
regions.

(I really dislike numeric codes, in http, sip, or anywhere. I personally
would rather use hierarchical names, like FQDNs. But that is a separate
issue.)

	Paul

Michael Hammer wrote:
> 
> 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
>

---

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

Paul,

Yes.  Another factor here may be that the scope of the response code
relates to the transaction at hand and not necessarily to the session as
a whole.  A Reason code's scope, on the other hand, would be to
provide more context about the state of the entire session.  (Or so
I am thinking.)

With respect to Notify, response codes should provide detail to the
specific transaction, while Reason codes would extend to the nature of
what it was that was subscribed to, which could be session-related or
non-session-related.  That latter could pertain to the registration
state that spans multiple sessions, or even something orthogonal to
sessions and related to whatever information service is involved.
In that final situation, I start wondering who is to manage the code set
and whether that then becomes the domain of the information service to
define the codes as part of the payload of the Notify.  Need to draw
a line here somewhere.

Mike

At 07:05 PM 11/8/2001 -0500, Paul Kyzivat wrote:

Are you talking about what kind of codes to
use in a Reason header?

BYE/CANCEL/ACK reasons.

This might suggest that NOTIFY reasons need to be drawn from a
different

domain than BYE/CANCEL/ACK reasons, and so require a different
header.

response codes, with some extensions, were proposed. One
possibility

regions.

(I really dislike numeric codes, in http, sip, or anywhere. I
personally

would rather use hierarchical names, like FQDNs. But that is a
separate

issue.)

Paul

Michael Hammer wrote:

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

> > Reason

NOTIFY

> > > It seems that the real problem is coming down to trying to
convey

> > too

> > > I would argue that we should keep the immediate NOTIFY to
preserve

> > > 3-way handshake mechanism but add (as has been suggested)
a

> > separate

> > > Borrowing from the watcherinfo draft, I think it's fair to
say

> > > our subscriptions can be in a finite number of states, and
that

> > those

> > > NOTIFY. Within that NOTIFY, we include a new mandatory
header

> > called

> > > The content of this header is simply the appropriate SIP
response

> > code

> > > The Status-Code should probably be catgorized to a more
definite

> > set

> > > 3xx response codes are not allowed in the
Subscription-Status, and

> > if

> > > The NOTIFY message body then only contains information on
the

> > actual

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

INVITE
SUB/NOT

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

> > > INVITE  <----->
SUBSCRIBE

ACK
<------>  final response to NOTIFY

final

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

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

> > > cancellation, then it no longer becomes neccesary to have
an

> > immediate

Ph.D.
72 Eagle Rock Ave.

Scientist
First Floor

dynamicsoft
East Hanover, NJ 07936

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

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

> > > > To: 'Brian Stucker'; 'Fairlie-Cuninghame,
Robert';

> > [email-masked]

> > > > Subject: RE: [Sipping] Immediate NOTIFIES change
in

> > sip-events-01

Sipping mailing list