Hi, A very good mail, Paul. The thing we have been looking at is a mechanism to provide something which the following characteristics: 1. Something similar to subscriptions; and 2. Something which allows "negotiation" without extra roundtrips 2. Something which does not require separate dialogs for each type of data and each direction (i.e. something which is used as part of an invite dialog usage). Yes, there are many questions (which method to use etc) that have to be answered before we have a solution, but we have to start somewhere. I have started to work on a high-level draft on this. OR - we could write a Master Thesis showing there is no problem, ignore the input we get from the real world, and simply tell people to use what we have instead... Regards, Christer
________________________________ From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Tue 23/10/2007 00:22 To: Eric Burger Cc: sip Subject: Re: Complexity (was Re: [Sip] INFO) Eric, Please note that I would be happy to keep telling people to use the standards as they are. But that doesn't seem to be working, and I don't see any way to *make* it work. (Its not working on this list, and its not working for me inside my employer's domain either.) So the alternative seems to be to try and discover *something* that isn't fatally flawed, that we could successfully get people to use in those cases where they won't use what we already have. I view this discussion as trying to figure out what, if anything, that *something* might be. IMO something *similar* to a subscription, which allows negotiation of what is to be subscribed to, but without the extra round trips to set up and tear down, seems like it could do the trick. The specific details are all negotiable. But I think something that can incorporate and coexist with "real" event packages that do the same thing would be a plus. Paul Eric Burger wrote: > 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
