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

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 25 Oct 2000 12:21:00 -0500 (CDT)

>   Was using a header in INVITE/REGISTER requests as a replacement of SUBSCRIBE
>   request considered? 

No, this didn't come up as a suggestion so far. The SUBSCRIBE method 
dates back to February of 1998 (in spirit, at least), and has been 
incorporated into PINT and the "SIP for Presence" work. The intent 
of my draft was to provide a framework which allows multiple uses 
of the SUBSCRIBE and NOTIFY methods in such a way that the different 
uses didn't get in the way of each other. Using any method other 
than "SUBSCRIBE" would leave the current drafts somewhat orphaned.

>   So far I could only see two cases of using SUBSCRIBE. One
>   during call. In that case we could send the subscribe information in
>   INVITE/RE-INVITE requests. Second as part of registration. You register to
>   Proxy, Voice-mail server etc and subscribe to events. So what is the
>   motivation behind having a separate request?

The short answer is: the same reason "INFO" isn't defined as "BYE" with
a "Just-Kidding:" header.

"SUBSCRIBE" isn't what "INVITE" means, in any remote sense; neither is 
it what "REGISTER" is intended to mean. It has been pointed out that 
all methods could be generalised to one method (e.g. replace "BYE"
with "INVITE" and a special header indicating that you are inviting
the other party to end the current session.)

Defining such a system would be quite easy. It would also be patently
ridiculous.

Since asyncronous event subscription is a distinct action which has
no ties to any of the other defined or proposed actions, it seems
reasonable to define a new method.

>   By defining SUBSCRIBE/NOTIFY requests are we trying to achieve the similar
>   functionality that exists in MEGACO/H.248.

Not really. the H.248 event notification, as I understand it, is
more appropriate for terminal/endpoint events (e.g. hookflash,
digit collection, etc). The SIP event notification has so far
been proposed for tasks such as call status, user presence,
and message waiting indication.

>   Is DTMF digit collection a valid usage of this scheme?

That's a religious issue. Search your own soul and figure out
what's true for you. If you want to read evangelical screeds on
both sides of the issue, check the SIP working group mailing
list archives.

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

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

---

From: [email-masked]
Date: Wed, 25 Oct 2000 11:47:03 -0500

I have few comments on this draft.

   request considered? So far I could only see two cases of using SUBSCRIBE. One
   The NOTIFY request seems fine.

Thanks,

Anoop

"Adam B. Roach" <[email-masked]> on 10/25/2000 10:57:28 AM

Sent by:  "Adam B. Roach" <[email-masked]>

To:   [email-masked], [email-masked]
cc:    (Anoop Tripathi/MW/US/3Com)
Subject:  [SIP] New SUBSCRIBE/NOTIFY draft available

For some reason, I haven't seen the I-D action go by for
the SUBSCRIBE/NOTIFY draft yet. Thanks to everyone who gave
input while I was putting this together. Further comments are
very welcome. If comments warrant and time permits, I may well
release a -02 version of this draft in time for the 49th
IETF meeting.

---------------------------------------------------------------------------
Abstract

     This document describes an extension to the Session Initiation
     Protocol (SIP) [1] . The purpose of this extension is to provide
     a generic and extensible framework by which SIP nodes can request
     notification from remote nodes indicating that certain events
     have occurred.

     Concrete uses of the mechanism described in this document may be
     standardized in the future.
---------------------------------------------------------------------------

http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-01.txt