I'm not sure what is the point of this INFO discussion. We won't stop people for using INFO for what they have been using it for quite a few years now, and I don't think it would be a proper use of our time to attempt to do so. Especially after we defined RFCs explaining that INFO was useful for PSTN tunnelling.
However, what we can do is ensure that we do not define any new RFCs that use it. That's easy enough to do. We could also attempt to discourage other Standards Bodies or Forum from using INFO as the kitchen sink (e.g., ECMA TR/87). In the absence of any guidance from us, the natural thing for these organizations to do is to use INFO because it's so simple. So, I'd suggest a Standards Track RFC that updates 2976 and makes it explicit that INFO is strictly for PSTN tunnelling (refer to I think for this purpose, something that caps the use of INFO (from a standards perspective) to the usages documented in IETF so far (i.e., PSTN protocol tunneling as per RFC 3204). We should also describe the main issues with it (i.e., no negotiation, and overloading of signalling channel), and points to alternatives: 1 - SUBSCRIBE/NOTIFY 2 - A separate protocol (possibly bootstrapped through SIP, à la Content indirection 3 - MSRP 4 - etc. _______________________________________________ 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
