Subject: RE: [SIP] New SUBSCRIBE/NOTIFY draft available

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Oct 2000 18:45:21 -0400

> -----Original Message-----
> From: David Shrader [mailto:[email-masked]]
> Sent: Thursday, October 26, 2000 10:44 PM
> To: [email-masked]; Adam B. Roach
> Cc: [email-masked]; [email-masked]
> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available
> 
> 
> I was also thinking that a BYE would cancel a subscription. 
> At least in the
> context of an interaction begun with an INVITE, maybe that is 
> erroneous.
> When SUBSCRIBE is outside the context of a call, it is not so 
> clear if BYE
> is appropriate since the SUBSCRIBE, expires 0, ... method 
> would work like
> cancelling a registration.

No.

BYE ends a session established by an INVITE. Thats it. SIP processing code
becomes spagetti and impossible to maintain when the method has totally
different semantics depending on the context. It is for this reason as well
that I disagree with Adam's differing semantics of SUBSCRIBE for in call and
out of call methods. SUBSCRIBE means one thing, and one thing only - I want
to receive NOTIFYs on the changes in state of the object described in the
request. 

> 
> On another note, is there really even a need for the Event: 
> header. Wouldn't
> it be more flexible to simply state that if no Event: header 
> is present,
> then you are subscribing to any events that the object 
> desires to expose?

The event header is needed since a single entity can support publication of
numerous types of data that depend on the context. In fact, differing
servers might even be responsible for handling notifications and
subscriptions to the data depending on its broad type. Having an Event
header establishes a context of the subscription. It defines the basic
meaning of the subscription in the absence of a body that further qualifies
it. It needs to be a header since it can affect SIP routing. It helps
tremendously to unify the various disparate uses of subscribe/notify we
currently have.

Michael Hammer writes:
> What is not clear to me is that assuming that someone has 
> registered their 
> presence, and another is interested in subscribing/initiating 
> communications to that person, and the former's identity is 
> not already 
> known in some form to the latter, how does the latter 
> search/browse to find 
> the former?  Is this assumed to be a directory operation 
> outside the scope 
> of SIP and IMPP?

Yes, this is a directory issue outside of SIP. You have the same exact
problem for email, and even for phone numbers. Thats why there is a white
pages. But, white pages aren't part of SS7, and neither is LDAP corporate
directories part of SMTP. Same here.

Anoop Tripathi writes:
>    What is the difference between registering (REGISTER) for 
> an event and
>    subscribing (SUBSCRIBE) to an event?
>        I REGISTER to a proxy server to receive INVITE for my 
> calls or do I
> SUBSCRIBE to my proxy server to NOTIFY me of my calls.

No. SUBSCRIBE is not REGISTER. REGISTER has a very specific meaning - it
establishes address bindings used in call routing, and sometimes acts as a
form of configuration of initial user data (like uploading CPL). SUBSCRIBE
means something different - I want to receive NOTIFYs of changes in the
state of the SUBSCRIBEd object. I would strongly discourage overloading of
any of the existing methods to be used for SUBSCRIBE.

>        All what I am trying to say is did we give enough 
> thoughts in this case
> whether a header would suffice or a new message is required.

None of the existing methods ask a server to send you NOTIFY messages when
the state of an object changes. That is the semantic needed for a
subscription. Thus, a new method is needed.

>    The reason why I ask this question is if tomorrow I come 
> up with a new
>    concept what would be the deciding factors for enhancing 
> REGISTER,SUBSCRIBE
>    or adding a new method.

Headers can only qualify the behavior defined by the method. Think of it as
a software excercise. When do you make somthing a class method, and when is
it an argument to that method? Would you write a pub/sub API that looked
like:

action(SUBSCRIBE, targetname)

or

subscribe(targetname)

I think any good software engineer would prefer the latter. Same is the case
here.

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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: David Shrader <[email-masked]>
Date: Sun, 29 Oct 2000 12:32:21 -0500

> to receive NOTIFYs on the changes in state of the object described in the

What if the object being monitored ceases to exist? That is, I choose to
monitor a call leg (from, to, call-id) and I am not a member of that call
leg and the call ends. Does my subscription get cancelled?

What if I subscribe to an object with a certain event package and the object
(or its server) knows that the object has progressed to a certain state in
which none of the events in the package can occur? Does anything happen to
the subscription, or does it just sit in limbo? I think this is a more
general version of the "object no longer exists" case above.

Any thoughts?

Perhaps both of these are solved on re-subscription. The recipient of the
subscription request might reject the renewal if the object no longer exists
or if the events can no longer occur. Of course, this reject code would only
be possible when the subscription would have been authorized, otherwise we
are potentially giving away state information to unauthorized requestors.

David

----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]
http://www.EyeForTheFuture.com

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 30 Oct 2000 10:38:11 -0600 (CST)

>leg and the call ends. Does my subscription get cancelled?

This problem appears to be solved if we add a general mechanism by
which notifiers can send a general "this subscription is now
over" NOTIFY message, as has been proposed. I intend to add this
mechanism to future version of the draft.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Sean Olson <[email-masked]>
Date: Tue, 31 Oct 2000 09:22:39 +0100

One question on this. It was suggested that the Event: header was not
needed because this information would need to be encoded in the
body anyways. For this particular event:

1) What Content-Type: will we use?
2) What will be placed in the body?

Or has it been decided that the Event: header is OK to leave in?
/sean

"Adam B. Roach" wrote:

> -------------------------- eGroups Sponsor -------------------------~-~>
> eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9699/16/_/782536/_/972923896/
> ---------------------------------------------------------------------_->
>
> To Post a message, send it to:   [email-masked]
> To Unsubscribe, send a blank message to: [email-masked]