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.
