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
