Hi, [Christer] The questions you ask in your e-mail I think we need to get an answer to in any case, no matter what/if we do with INFO. My opinions in-line.
>>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? [Christer] No. >If so, then the proper design model is to build a new SIP request method for every new piece of application >functionality. [Christer] No. That is unflexible, doesn't help innovation and deployments of applications, and considering the time it takes to get stuff through the IETF process (there would be lots of discussions about the application itself, which has nothing to do with the SIP protocol and how it is used )it probably would mean that people would use non-standard mechanisms anyway. Our job is to provide tools for people doing applications. >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. [Christer] I don't think we need a DTMF method. We may solve one issue, but tomorrow there may a new one... >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! [Christer] My question is: are we really talking about SIP extension here? Yes, in order to make INFO work (or if we would do something related to in-dialog notifications), we may have to do something. But, after that is done, we don't need to extend anything. People using INFO (or something else) may have to register whatever packages/content-types etc etc, but that is not an extension of the protocol. Regards, Christer >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
