Indicating the package is possible; it is what Dean's draft of 4 years ago proposed. However, it is not what is there today. Moreover, it is doubtful that any of the myriad INFO exploits would use the mechanism. If one is going to upgrade one's mechanism, one might as well do the right thing.
I would also offer we learn the lesson from the e-mail world of X-mumble headers. It is true that we need a mechanism to experiment with new extensions to SIP. However, formalizing that mechanism is asking for a rash of incompatible half-baked protocols, some of which, while broken, hijack SIP. The INFO draft as it currently stands still "allows" for such experimentation with INFO. It sounds like if we do want to work on this draft, the language needs to be clearer that (1) INFO is not gone and (2) INFO is *not* how you deploy something outside of the lab. Just for those who may have missed it, Section 4 states: In recognition of existing, proprietary use of INFO, proxies MUST NOT take any action other than that described by RFC 3261 and RFC 2976 with respect to handling INFO requests. This is the escape clause. On 7/23/07 11:45 PM, "Xavier Marjou" <[EMAIL PROTECTED]> wrote: > Hi Eric, > > I also do not understand why it would not be possible to indicate in > the transaction of the initial INVITE what type of INFO is exactly > required/supported (negotiation and subscription stage) and to send > the event information with an INFO during the dialog (notification > stage). > > Concerning draft-burger-sip-info-00, I think the draft is not fair > with this poor INFO message. Indeed, the INFO message helps a lot to > quickly implement/have some features (e.g. full intra requests of > mmusic-xml-media-control, DTMF, MSCML, ...) while waiting for > implementations of the IETF standardized solutions (e.g. > rtcp-feedback, kpml, media-control, ...). Though I agree there are > some cons with features based on INFOs messages, there are also some > pros with this approach, (ie: same as for everything ;-) but I won't > go over such details. Thus, I think that even if the IETF does not > want to recommend the INFO message, the IETF should at least recognize > it for experimental uses (i.e. roughly an equivalent of RTCP APP > packet) and even documents these uses. Otherwise, we can end up with > some types of INFO messages that are broadly used but that are even > not documented within IETF documents (e.g. application/dtmf-relay for > INFO with DTMF) > > Xavier > > > > On 7/20/07, Eric Burger <[EMAIL PROTECTED]> wrote: >> 12 second proof point of why content type doesn't work. >> >> So here comes an INVITE. I am an INFO-friendly UAS. I negotiate by using >> Accept. >> >> This INVITE has the line: >> Accept: application/kpml-response+xml >> >> >> Wow! This is great! I know the UAC *wants* DTMF. Why? Because it accepts >> a DTMF content type. Excellent - I can now send them DTMF. >> >> The user enters a digit, and I send an INFO with type >> application/kpml-response+xml. >> >> UAC says, "What the heck was that?" >> >> >> 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 >> > 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
