Subject: Re: Eureka! SUBSCRIBE/NOTIFY -- suggestion for compromise

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Sep 1999 13:29:32 -0400

Scott Petrack wrote:
> 
>
> How about this as a slight modification to my proposed signaling:
> 
> If a SUB CRIBE is sent without an SDP body, and the receiver can
> unambiguously determine which PSTN session is being referred to
> (e.g. via some combination of SIP header fields),

It is this part I'm concerned about. We need very explicit rules on
whats being subscribed to. Is it the session initiated with an old
INVITE with the same Call-ID as the SUB SCRIBE? Is it the session in
progress with the user in the To field? Request URI?? I still like the
notion of having the definition of whats being subscribed to in the
body, and depending on the body, having specific rules for determining
this. For SDP - its the session defined by the session ID. For presence
applications, it could be a URI list included in the body. 

I also don't object to a SIP header defining the type of thing being
subscribed to. This header is not actually the thing being described to,
just its type. For example:

SUB-SCRIBE sip:server.com
Content-Disposition: session-subscription
Content-Type:text/uri-list

http://sap-server.isi.edu/sessions/sdp/sdp3883

This basically says I'm subsribing to a session, and this session is
described by an SDP indirectly referenced from an HTTP URL. This helps
separate the representation of the body (SDP or http URL) from its
purpose (session subscription).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF PINT Working Group Mailing List.

---

From: [email-masked] (Igor Faynberg)
Date: Mon, 6 Sep 1999 06:02:06 -0400

Bernie wrote:

>Also SUB SCRIBE with Expires:0? (Although this would be possible, it
>sounds somehow unlogical to me.)

Actually, this seems to be a consistent method in SIP's design--the idempotence
of all SIP operators. Thanks to Lev who pointed that out to me.

Igor

---------