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

[Adam Roach <adam@dynamicsoft.com>]

> 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
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip