Subject: RE: [Sip] Subscribe/Notify and Refer/Notify

From: Adam Roach <[email-masked]>
Date: Mon, 21 Oct 2002 15:52:17 -0500

> However, to start with, can we have the doubts (in my previous email)
> cleared by the 
> author in this list ?

Sorry; I thought that, since you sent the same note to me privately,
you wanted a private response (which I provided). Comments inline.

> In this case, subscription and dialog are created before 
> getting 2xx for the
> intial SUBSCRIBE.
> However, if Subscriber doesn't get any final response and the 
> transaction
> timer for SUBSCRIBE
> transaction times out, what should be the action on the part 
> of subscriber :
> a) Remove the subscription
> b) Keep the subscription and remove the SUBSCRIBE transaction 
> gracefully.

b. 

Ambiguity noted; this will be clarified in the next version of the
document.

> ii) As per the Refer/Notify draft, the subscription expiry 
> time, before the
> Subscriber gets NOTIFY
>    depends on "Refer-To" header.
> 
>   E.g., in the draft, this line is mentioned :
>     Subscription-State: active;expires=(depends on Refer-To URI)
>    a) What exactly is meant by this ? 

I'll let Robert address this one. (Is this an ambiguity in
the REFER draft, or did Amit miss something?)

>    b) If no NOTIFY is received before the REFER (Refer/2xx) 
> transaction
> times  out, does that mean that subscription/dialog
>    is automatically removed ? OR is subscriber supposed to 
> wait for the
> NOTIFY till some "Configured" time ?

If the REFER times out, assume the subscription did not succeed.
Note that the dialog may or may not disappear, depending on whether
the REFER was sent on an existing dialog; see the dialog handling
mentioned in RFC 3265.

In general, RFCs don't cover all possible failure cases; it's assumed
that implementors will think through the ramifications of the
decisions they make, and try to make things behave in a sensible
fashion. This seems to be one of those cases.

/a
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Oct 2002 09:39:42 -0500

> it won't be too much effort to make the next version of 3265 compliant
> with 3261.  i can do that after the working group has made an
> announcement that the current version will be changed and 
> that there is
> no requirement that the next version will be backwards compatible with
> the current one.

Okay, you missed the sarcasm, apparently; I'll have to be more direct.
It's a lot easier to be critical than useful, as you've made a point
of demonstrating. I'd love to hear constructive comments on the
mechanism, and already have extensive notes on what needs to be
clarified in future versions of the draft (such as your earlier
suggestion that a clear dialog-establishing state machine be defined).

Most of your other comments, though, have not been suggestions as
much as sniping. Standing on the sidelines throwing rotten tomatoes
isn't going to yield much progress.

> i can't understand how 3265 got through the iesg review process.  i
> would think that the first thing they require is 
> compatibility with the
> newly released sip rfc.

Reading through the sniping in this paragraph (and taking it in the
context of your previous rants), I'll address what I think is the
underlying annoyance here: SUBSCRIBE/NOTIFY is complicated.

Contrary to your insinuations, the complications in the protocol
were not added merely because I'm a twisted and sadistic
person. Each mechanism in the protocol has a genesis, and each
additional complication has been carefully weighed against the
gains provided.

As happens a lot around here, I believe the main problem is that
there is a lack of historical perspective on the issue.

If you poke around a little bit, you can find early drafts of
SUB/NOT [1]. They did little more than define the SUBSCRIBE and
NOTIFY methods, plus the "Event" header. All other handling was
relegated to normal SIP dialog (call leg) establishment.

This specification was not considered complete enough, as it didn't
address the race condition that will typically occur between the
SUBSCRIBE response and the NOTIFY request, notifier-
initiated dialog termination, forking of SUBSCRIBE responses,
migration of subscriptions between nodes, and a wide variety of
other requirements that various parties felt were necessary for
a general purpose mechanism.

So, over two years and ten revisions of the document, each
problem and requirement was addressed in the most straightforward
way possible, and, for each issue, a consensus was reached
within the SIP working group(s).

As is the nature of such changes, each of these new features and
bugfixes to the protocol increased the complexity somewhat. And
that's where it is today. I'm sorry that it annoys you so much.

If you have suggestions for improvement that don't contravene
the requirements imposed on SUB/NOT by the underlying protocol
and by the users of the protocol (check the minutes from the
last seven or so SIP working group meetings), I'm very happy
to listen and incorporate them.

But leave the rotten tomatoes at home, please.

/a

[1]
http://www.softarmor.com/sipwg/drafts/morgue/draft-roach-sip-subscribe-notif
y-00.txt