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

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Oct 2000 11:07:30 -0700

Adam,

What is the relation between this draft and
"draft-rosenberg-impp-presence-00.txt" ? I think that we need to work
further, and have a single solution that encompasses PINT, IMPP and
"events." In particular, we will need to align on the following points:

1) the IMPP draft defines that "SUBSCRIBE" creates a subscription session,
identified by its own Call-Id. The session expires when the life time of the
subscribe expires before being renewed by another subscribe for the same
call-id, or if the subscriber sends a subscribe with a null lifetime. 

2) In IMPP, the object to which you subscribe is identified by the
request-URI. In PINT, we want to know about the handling of a call. If we
subscribe to a call, we have to explicit the syntax of the URI that defines
"the call."

3) In the IMPP discussion, we agreed that we should be able to have some
amount of security about transport boundaries, for example when you
translate a SIP Notify into an IMXP Notify. This implies that the meat of
the notification should be carried in the payload, which can be passed
unchanged accross system boundaries, rather than in the headers, which will
probably be lost. Use of a common syntax is necessary if you want to allow
encryption or digital signature of the payload. The agreement is to define
that syntax in XML. This implies that the events should be reported as XML
tokens in the payload, not as SIP Headers. It is in fact a sound
architecture: use the header for "transport control", use the payload for
"information." (The basic format of the payload should come from the IMPP
working group; we have all possibilities to extend it.)

4) In the IMMP discussion, we also agreed that the publisher/presentity
should be able to terminate a subscription at any time, and should be able
to report this event in a Notify.

In your draft, you mention a possible linkage between the duration of the
subscription session and the duration of a call. I think that the Notify
solution presented above (4) solves that problem without requiring any
additional linkage between the call and the subscription session. Note that
we must be clear as to whether it is OK or not to send a SUBSCRIBE on a
session that started with an INVITE. I would rather not; if that is OK,
however, we must clearly specify the expected behavior.

I understand the need to decouple the SIP syntax from the vagaries of the
IMPP working group. But I think that it would be beneficial to merge your
draft with the sip-impp draft, or at least with the protocol description
part of that draft.

-- Christian Huitema

> -----Original Message-----
> From: Adam B. Roach [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2000 8:57 AM
> To: [email-masked]; [email-masked]
> 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-subscri
be-notify-01.txt

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

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

---

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

Christian Huitema writes:
>"draft-rosenberg-impp-presence-00.txt" ? 

My intention was to synchronise the drafts as closely as possible.
To my knowledge, the events draft allows for all of the behaviours
described in the presence draft (with one minor exception; see below).

>I think that we need to work
>"events." 

I agree 100%. My entire goal in composing this draft is to have
a framework which allows PINT and IMPP to co-exist with a whole
slew of other extensions based on asyncronous notification.
If we have no framework, each extension will just cobble on their
own semantics, probably conflicting with several others.

>call-id, or if the subscriber sends a subscribe with a null lifetime. 

This is what I describe as "third-party" subscriptions. The behavior
is, to my knowledge, identical between the presence and events draft.
If I have left something out in this regards, please let me know.

(From section 5.1.1:)

    "Third-party SUBSCRIBE requests will not correlate to any
     previously-existing call leg in the server. The Call-ID of
     resource-related requests will be unique to the SUBSCRIBE and any
     subsequent NOTIFY requests."

>subscribe to a call, we have to explicit the syntax of the URI that defines

Once again, I beleive that the behavior in the events draft is
lined up with that in the presence draft (section 5.1.3):

    "The Request URI of a SUBSCRIBE request, most importantly,
     contains enough information to route the request to the
     appropriate entity. It also contains enough information to
     identify the resource for which event notification is desired,
     but not necessarily enough information to uniquely identify the
     nature of the event (e.g. "sip:[email-masked]" would be
     an appropriate URI to subscribe to for my presence state; it
     would also be an appropriate URI to subscribe to the state of my
     voice mailbox)."

If you have any ideas about how this mechanism can be refined to
align more closely with PINT, I'm open to suggestions. Note that,
from where I stand, the description in my draft is not fundimentally at 
odds with PINT.

>working group; we have all possibilities to extend it.)

The draft I just published accomodates this model quite well.
As in the presence draft, the URI indicates the object to which
a subscription is being requested. I suspect that, for presence,
an XML-based presence syntax (or one that can be freely translated
to and from XML) will be carried in the body.

The only headers added by the events draft are "Event:" and
"Allow-Event:". "Event:" is used solely as an opaque token to 
differentiate beween different event extensions (e.g. PINT and 
presence). You can think of it as very roughly analogous to the 
"Required:" header for SIP extensions. Similarly, "Allow-Events"
can be thought of as similar to "Supported:".

>to report this event in a Notify.

Thank you; this is apparently a feature I overlooked.  I will add 
this in an upcoming version of the draft.

>additional linkage between the call and the subscription session. 

This linkage only applies for call-related subscriptions; this is
precicely the kind of subscription that presence does not use.

As I ask in the draft: is there any sensible reason for keeping
subscription state which relates exclusively to a call which
is over? After a call is over, nothing about it will change. There
is no relevant state. The only thing possible that I can think of
is synthetic events like "the call has been over for five minutes
now." Is that useful? Is it even sane?

>Note that
>session that started with an INVITE. 

That was my intention when I drafted the following paragraph:

    "Call-member SUBSCRIBE requests will be correlated in the same way
     that any other call-related request is (e.g. BYE) using To, From,
     and Call-ID; these subscriptions will generally be used to
     request information about the specific call."

I'll add some text indicating more explicitly that I'm referring
to a session which has been initiated by an INVITE. Let me know
if that doesn't address your point.

>I would rather not; if that is OK,

It's not a particularly special case; refreshes occur as normal
(using the same call-leg as the original SUBSCRIBE), and notifications
occur as normal (once again, using the same call-leg as the original
SUBSCRIBE). The only difference, as currently defined, is that
the subscriptions automatically vanish at the end of a call -- because
it doesn't seem to make sense not to.

What does this gain you? It's a very simple way for call-leg related
event extensions to use an existing mechanism to say "I want events
relating to *this* call leg" without defining an additional
correlation mechanism. The alternative is for these types of
extensions to go out of their way to define a leg correlation
mechanism for the body of their message: 

SUBSCRIBE sip:[email-masked] SIP/2.0
To: <sip:[email-masked]>;tag=abcd
From: <sip:[email-masked]>;tag=ef01
Call-ID: [email-masked]
CSeq: 2874 SUBSCRIBE
Event: foo
Content-Type: text/fooml
Content-Length: 205

<leginfo>
  <to uri="sip:[email-masked]" tag="1111" />
  <from uri="sip:[email-masked]" tag="2222" />
  <call-id value="[email-masked]" />
</leginfo>
<event>
...
</event>

>draft with the sip-impp draft, or at least with the protocol description

My hope is that, once the events draft is complete, the presence
draft will be somewhat thinner, and have the luxury of concentrating
on presence instead of event notification. If you feel that there
are any generally applicable features included in the presence
draft which I have failed to clearly incorporate in my draft, please
point them out.

Thanks for your comments.