On Oct 11, 2007, at 6:54 PM, DRAGE, Keith ((Keith)) wrote:
There is one major downside to this.
If we are sending stuff in the dialog, it really ought to have some
relation to the dialog, not just be included there because the dialog
happened to exist.....then you end up with people wanting to route the
dialog to a centralised point where you can extract this piggy-backed
information ... Then you end up with a stimulus protocol between
this UE
and this centralised server where the dialog contains absolutely no
knowledge of the state of the session.
Providing an in dialog mechanism makes it much harder to to stop this
happening.
That's back to the question of "Is SIP an application protocol or a
transport protocol"?
Should the SIP-layer software be aware of and coupled to the state of
the application that's using SIP?
If so, then the proper design model is to build a new SIP request
method for every new piece of application functionality.
So for example, DTMF: Using this model of SIP extension, we might
define a new "DTMF" method. It would look just like DTMF-over-INFO,
except the name of the method would be DTMF. It clearly resolves the
INFO-context question, because now we KNOW we're getting dialog-
related DTMF over it, and we know what to do with it. We know what we
can transport in DTMF-requests, because the RFC that defines the DTMF
extension method will also define exactly what payload format to use.
This too is a clean solution to the problem, although it embodies a
different design philosophy than the same-dialog NOTIFY.
This leads back to my question: What is the right extension modality
for SIP? Until we have an answer here, we're going to keep going back
and forth on this. MAKE A DECISION, PEOPLE!
Now for the bad news: People are still having this argument about
HTTP (we had it during XCAP in the GET/PUT vs POST debate) even
though the real world has proven dramatically by example that HTTP is
a transport protocol and is protocol-wise completely decoupled from
the state of the application (see AJAX as an example).
--
Dean
_______________________________________________
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
