There's a difference. Creating complexity in parallel to existing mechanisms is one thing because it's optional you can pick and choose the complexity you want. Overlaying it on top of an existing mechanism is much worse. That's the concern I've had about using NOTIFY that Eric did a much better job of quantifying than I have been. I'm worried about stateful middleboxes that are going to have to figure out what the heck just happened with this weird NOTIFY and why this isn't an error to them even though they don't support it. You changed the rules of the game in a non-backwards-compatible way.
Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Monday, October 22, 2007 5:30 PM > To: Eric Burger > Cc: sip > Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) > > Eric, > > I disagree with your *quantitative* assessments of how much > thee things increase complexity (by factors of 2 or 4). But I > certainly agree that complexity *will* increase. > > In the end everything we are doing increases complexity, so > maybe we should all pack up shop and go home. > > Ultimately this all comes down to deciding how complex things > have to get before people can do what they think they need to do. > > Paul > > Eric Burger wrote: > > > > > > On 10/17/07 2:18 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > > [snip] > >> One agreed upon, NOTIFY may be sent in the agreed upon > direction(s) > >> within the INVITE dialog usage. Whether an initial NOTIFY > is required > >> will be determined on a per-event-package basis. (Its not > needed to > >> establish the dialog, so its a matter if it is > semantically needed in > >> the context of the event type.) > > > > Which is not the way NOTIFY works today, which means the > sender has to > > have code to the effect: > > > > if( !real_notify(event_object) ) > > { > > if( needs_first_notify(event_object) ) > > { > > send_event(event_object); > > } > > } > > else > > send_event(event_object); > > > > Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised > > the complexity of your notification stack by 2. > > > > [snip] > > > >> There is no separate subscription or timer. The dialog usage is > >> refreshed by INVITE or UPDATE in the conventional manner. > Events to > >> be exchanged are renegotiated from scratch with every > reINVITE or UPDATE. > > > > So what does the NOTIFY put into expires? I hear hk now: > "Just stuff > > it with 99999." OK, this now adds another hack into > send_event(), "If > > I am a real SUBSCRIPTION, return the timer; if I am not, return > > 99999." Just upped the complexity by 1. > > > > Worse yet, what does the recipient do when it gets a BYE? > Now it has > > either a resource leak or more code: > > > > if( got_bye(dialog_object) ) > > { > > for each pseudo-dialog subscription in the (dialog_object) > > { > > consider the subscription terminated; > > } > > } > > > > Upping the complexity by 2, again. > > > > Hey - we are not done yet! I will leave as an exercise to > the reader > > the amount of complexity added to create the implicit > subscription in > > the first place. > > > > I forgot, this really is targeted for devices that will hard code > > everything and not support any real SUBSCRIBE/NOTIFY packages. > > [facetious] > > > > It would be much cleaner to call this thing "NOTQUITENOTIFY". > > > > Of course, since we are anal about messages and bandwidth, > let's save > > 300ns and just call the method "I". [joking] > > > > [snip] > > > > > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
