You started it. :) I'm fine with leaving things well enough alone, declaring victory, moving on, and letting someone who needs an INFO like mechanism be the one to go through the torture of defining something that everyone can agree upon or living with RFC-3265 for their purposes. No more uses of INFO will be approved in the future, no evaluation given about existing uses, and a pointer off to the email archives for futher information (perhaps an informational reference? Is that allowed? Hmmm...)
Pretty soon I think we're going to have sent the equivalent number of email messages on this topic INFO to have conveyed a single DTMF digit using KPML. :) Regards, Brian > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Monday, October 22, 2007 10:55 AM > To: Paul Kyzivat; Hadriel Kaplan > Cc: sip > Subject: Complexity (was Re: [Sip] INFO) > > Folks, this is getting *way* out of hand. > > We have one group of people saying we have working, > interoperable, satisfies all requirements, protocol > mechanisms for event notification. > > We also, I believe, have consensus, that in some corner cases, like > SIP-H.323 gateways, it would be nice to save two messages in > each direction by not having to explicitly subscribe for some events. > > Now the question in my mind is, "How complex do we want to make SIP?" > > Speaking as Chair and a Participant in the LEMONADE work > group, I fully endorse the work and, as often is the case, > added complexity, to address unique network topologies that > impacts lots of users. For more information on LEMONADE, see: > http://www.ietf.org/html.charters/lemonade-charter.html > http://www.standardstrack.com/ietf/lemonade/ > > If I am willing to add quite a bit of complexity to what is > considered a complex protocol like IMAP, why am I pushing > back on adding complexity to SIP? It is because mobile > Internet access, and as such mobile E-Mail access, is soon to > become the predominant modality of user access. Rather than > being an unusual corner case, mobile access, and its > intermittent connectivity, low power devices, and relatively > low bandwidth issues, will shortly be the normal case. > > What is different here? For one thing, we have had 13 years > of experience since RFC 1740 (IMAP4) was published. > Interestingly, at the time, bandwidth and connectivity then > was only slightly better than current mobile networks. > However, the content of messages has changed by orders of > magnitude, which has driven the need for adding complexity to > the protocol suite to serve this important market. > > I do NOT see this situation here. > > Review the archives of the past five days. Many of the > proposals are of the > vein: > > 1. Add something like accepts/sends to create an > INFO-in-an-INVITE mechanism, but if you need to say anything, > use SUBSCRIBE/NOTIFY > > 2. Add something like implicit subscriptions to NOTIFY, > somewhat specified in an INVITE, but if you need to say > anything, use SUBSCRIBE/NOTIFY > > 3. (1) above isn't INFO, so we have to create a new method > and state machine to support it. > > 4. (2) above is *not* NOTIFY (I'll address that in a separate > thread), so we have to create a new method and state machine > to support it. > > 5. If you do not buy my argument (2) is not the same as the > existing NOTIFY, it means you will be putting a bunch of "if" > statements, as the behavior will be different if there is an > explicit SUBSCRIBE outside a dialog or an implicit SUBSCRIBE > within an INVITE-initiated dialog. > > With regards to point 5, I strongly urge those in the SIP > audience that do not have Computer Science degrees to review > Cyclomatic Complexity (McCabe). > > Adding complexity to the protocol *stack* to optimize a > corner case is, in the words of my eldest, "less than ideal." > > Please let us not go there. > > > On 10/18/07 8:46 AM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > > [snip] > > > SIP is not simple. If you have mastered doing the rest of sip then > > this is not a burden. IMO people are more concerned with extra > > messages and extra state than they are with making it extra simple. > > > > I do agree that things should be as simple as possible - > but no simpler. > > Too often things are made "simple" at the expense of being > inadequate > > for the real job. INFO is in fact an example of this. > > [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
