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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2000 06:11:27 -0400

> -----Original Message-----
> From: Adam B. Roach [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2000 4:25 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available
> 
> 
> Christian Huitema writes:
> >What is the relation between this draft and
> >"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).

Right. One of the outputs of our discussion during the last IETF was the
need for a core mechanism that could be applied to all of the proposed
SUB/NOTIFY applications.

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

I agree with Christian on this one - that is, I think the semantics of a
subscription are always the same. A subscription may or may not appear with
the same To/From/Call-ID as an existing call leg, and that does not change
at all how one subscribes to something. The body always specifies details of
the thing being subscribed to, within the context of the package defined in
the Event header. What you are doing here with call-leg related
subscriptions is a short cut mechanism to describe the event you are
subscribing to. I'd rather keep everything uniform.

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

I think it matches up. In pint, the request URI apparently tells you zero
about whats being subscribed to, neither does the Call-ID. Its the presence
of SDP, and basically the session ID in the SDP that indicates what is being
subscribed to. So, this aligns with what we have here, excepting the absence
of the Event header. Your hack of "not present means PINT" solves that
problem.

> 
> >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.)
> 
> 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:".

Right. Event is a way to scope the type of subscription. I suppose we could
push that into the body as well, but it seems reasonable to keep it in the
headers as it could possible affect routing decisions.

> 
> >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.
> 
> Thank you; this is apparently a feature I overlooked.  I will add 
> this in an upcoming version of the draft.

Its actually not specified right now in draft-rosenberg-impp-presence, but
is rather something that has been discussed on the lists and other places. 

> 
> >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. 
> 
> This linkage only applies for call-related subscriptions; this is
> precicely the kind of subscription that presence does not use.

I don't like this. We need one mechanism, and only one, which tells us what
the duration of a subscription is. Making it event specific (which is
basically what you are doing here, since call-related subscriptions work
only for one of the event types we've seen so far), seems a recipe for
disaster.

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

You are going to need this anyway, I suspect. I bet you that people WILL
want third party subscription mechanisms for call state. 

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

I believe that, in general, your draft is more or less the distillation of
the presence draft, modulo the above issues plus one more.

That additional issue centers around your statement:

     Since forking proxies pass all 200 responses upstream, it is
     expected that these "From" fields will not contain any tags which
     are unknown to the subscriber. However, to make the subscription
     mechanism more robust, subscribers SHOULD be prepared to receive
     notifications with previously unknown tags in the "From" field.

Your assumption here is false. For non-INVITE methods, there is only a
single 200 OK passed upstream. It is this subtlety that led us to say, in
the presence draft:

        For SIP experts - this represents a slightly different
        operation than for INVITE. When a user sends an INVITE,
        they will receive a 200 OK with a tag. Requests in the
        reverse direction then contain that tag, and that tag only,
        in the From field. Here, the response to SUBSCRIBE may
        contain a tag in the To field, and a NOTIFY will contain a
        tag in the From field. However, the UA may receive NOTIFY
        requests with tags in the From field that do not match the
        tag in the 200 OK received to the initial SUBSCRIBE. This
        is because only a single 200 OK is returned to a SUBSCRIBE
        request, as opposed to multiple 200 OK for INVITE. Thus,
        the UA MUST be prepared to receive NOTIFYs with many
        different tags, each from a different PUA.

Besides this issue, and the ones above regarding call-leg specific
subscriptions, I believe there is nothing different between the two (to put
it in Adam's terms, the presence draft is a concrete implementation of the
abstract class defined in his draft, without overriding any of its methods
:) ) I need to go over both with a fine tooth comb to be sure, however.

-Jonathan R.
---
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: "Adam B. Roach" <[email-masked]>
Date: Mon, 30 Oct 2000 11:03:13 -0600 (CST)

>> This is what I describe as "third-party" subscriptions.
...
>subscribing to. I'd rather keep everything uniform.

Okay, this appears to be a popular sentiment. In the interest of making 
implementations cleaner, I believe I'll remove this distinction in 
future versions of the draft. If anyone has any objections to removing
this, speak up now.
 
>is rather something that has been discussed on the lists and other places. 

It makes certain issues much more palatable (e.g. what happens
at the end of a call if there are call-related subscriptions pending?)

<big snip regarding call-related versus non-call related behavior
and the shortcut method of identifying calls which it avails>

Once again, popular sentiment appears to go against the distinction
between call-related an non-call-related event subscriptions. I'll
remove it. This does raise the issue of whether legs which are used
for an ongoing session can be used for SUBSCRIBE/NOTIFY messages.
The presence draft prohibits them, although the rationale isn't
described.

>single 200 OK passed upstream.

This was changed between the bis-00 and bis-01 drafts. I will
update my draft to reflect this change.

Compare section 12.4, "Forking Proxies":

  "2xx: The proxy MUST forward the response upstream towards the client,
        without sending an ACK downstream."

...versus...

  "2xx: If the request was an INVITE, the proxy MUST forward the
        response upstream towards the client, without sending an
        ACK downstream. For other requests, it should only forward
        the response upstream if it has not forwarded any other
        responses upstream."

Note that this has the horrible, horrible side effect that I
can receive a 6xx (or, in timeout situations, even 4xx-5xx
responses) to a SUBSCRIBE request, never see a 200, and still 
have valid outstanding subscriptions. I dislike this behaviour.

Why do we do something so radically different for INVITE than
for anything else? Yes, I know it's needed for cleaner ACK
handling, but what harm comes from *always* proxying 200-class 
responses regardless of the method? As none of us know what the
nature of future methods might be, I beleive this is folly.

>:) ) I need to go over both with a fine tooth comb to be sure, however.

Actually, I think the presence draft still has a bunch of behavior
which I didn't capture, but still needs to be described somewhere. 
The descripiton of presentities that serve as representives of UAs for 
the purpose of user presence is still a concept that needs to be 
defined. Several similar issues dealing explicity with presence (and
not async events in general) were also intentionally left behind.

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