> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Friday, October 12, 2007 11:45 AM > To: DRAGE, Keith (Keith) > Cc: IETF SIP List; Audet, Francois (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) > > > 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.
You forgot about supported. > > 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. INVITE Supported: foo Allow: INFO Accept: application/foo 200 OK Supported: foo Allow: INFO Accept: application/foo ... INFO Content-Type: application/foo [DTMF] Where is this broken? > > 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! You can't feasibly make a clean one. There will always be SDP vs. non-SDP extension modalities. > > 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 > _______________________________________________ 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
