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
