(As WG chair) We have got a number of threads floating round on INFO usage, and it would be nice to identify this into a potential body of work, and see if there is support for it.
We have two previous drafts that never went anywhere, although contents of both carried support in the WG at the time: http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 The Session Initiation Protocol (SIP) INFO method defines a means for transporting mid-dialog application layer data between user agents. Its initial use was to support the transport of ISUP mid-call messages which could not be mapped to any other SIP request method. However, since its initial usage for that purpose, INFO has seen widespread abuse as a means for introducing non-standard and non-interoperable extensions to SIP. For this reason, we now believe INFO should be considered harmful, and therefore, deprecated in its current form. http://tools.ietf.org/html/draft-willis-sip-infopackage-00 The SIP INFO method (RFC 2976) establishes a method by which applications may transfer application-specific information within a SIP dialog. However, RFC 2976 does not provide a mechanism for describing and documenting an application of INFO, nor does it provide a mechanism by which applications may negotiate such uses. This document provides a framework for documenting and naming specific uses of INFO (called INFO packages), for registering those package names with IANA, and for negotiating the support for various INFO packages between applications using SIP. In the thread so far there have also been suggestions that cover: - support to mediactrl for their discussion on requirements - something for hitchhiker's guide to point to: - something that answers all the questions that recur on this list on INFO usage - "I've been getting a lot of offline questions asking for the "right" way to carry information related to the session-usage (often information that's being tunneled around from companion or gatewayed protocols)." - INVITE dialog usage only, or already covered by RFC 2976 - It would be OK with me if we ALSO had this type of guidance ("don't look HERE, look over THERE") available ("stated strongly enough in an easy to stumble across place"), but if coming up with that guidance takes more than about a week, I don't see a lot of reason to hold up on "don't go there" while we explore alternatives. - INFO and DTMF - XML payloads - But people really need is guidance on when to use INFO, when to use events, and when to use something entirely different. - identification of purpose of info (Content-Type? - impacted by multipart/mixed) - any framework for control of usages (IANA registration? - RFC 3427 update) Would anybody out there like to have a go at drafting an abstract for a potential WG deliverable (and also identifying level - Info, BCP, standards track) and submitting it to the list for discussion. Remember an abstract needs to: ------------------------------------------------------------------------ ------- Every RFC must have an Abstract section following the Copyright notice. An Abstract will typically be 5-10 lines. An Abstract of more than 20 lines is generally not acceptable. The Abstract section should provide a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document. In addition to its function in the RFC itself, the Abstract section text will appear in publication announcements and in the online index of RFCs. Composing a useful Abstract generally requires thought and care. Usually an Abstract should begin with a phrase like "This memo ..." or "This document ...". A satisfactory abstract can often be constructed in part from material within the Introduction section, but a good abstract will be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is tempting, but it may result in an Abstract that is both incomplete and redundant. Note also that an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract section. An Abstract should be complete in itself; it should not contain citations unless they are completely defined within the Abstract. Abbreviations appearing in the Abstract should generally be expanded in parentheses. There is a small set of reasonable exceptions to this rule (see guidelines on abbreviations, above.) ------------------------------------------------------------------------ ------ And as such should give a clear idea of whether there is anything we should charter here or not. Regards Keith _______________________________________________ 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
