My preference would be to restrict the use of INFO to supporting legacy PSTN protocols. We could even restrict it to the ones in RFC 3204.
In other words, let's just cap it. And yes, I'd say Standards track that updates RFC 2976. > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 17, 2007 02:53 > To: Keith Drage; IETF SIP List > Subject: Re: [Sip] INFO usage (or not) > > How about this: > > This document describes why the Session Initiation Protocol > (SIP) INFO method, introduced in RFC 2976, has serious issues > with any use outside its use as a transport mechanism for > ISDN User Part (ISUP) call signaling in SIP-signaled > networks. In the years since the introduction of the INFO > method, the IETF has published numerous, interoperable > extensions to SIP. > This document explains why there are INFO-based, proprietary > protocols in the wild; the flaws of using INFO; and > prescriptions for how to use existing, interoperable SIP > mechanisms to accomplish most any of these tasks. > > > My personal preference is for the document to be Standards > Track and be a Work Group chartered item. The reason is that > for this document to be useful, it MUST update RFC 2976. If > it updates RFC 2976, then newbies get the pointer when the > download RFC 2976, pointing them to this document, before > they go off, create draft-mumble-foo-over-INFO, and get > flamed on the list. The essence of the normative content of > the document is, "one MUST NOT use INFO for anything other > than transporting ISUP or QSIG messages." > > Because the normative content is so thin, I could understand > not saying that and making the document Informational (or > BCP). However, I really and truly believe that will > significantly reduce the impact the document will have. > > > Outline: > Introduction > - Requirements for UA-to-UA signaling > - The INFO method > - The INFO method for ISUP signaling > Issues with INFO > - No or incomplete negotiation > - No real identification of payload purpose on receipt > Alternatives to INFO > - State Updates: SUBSCRIBE / NOTIFY > - DTMF Transport: KPML (an example of state updates) > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > - Prescriptions for deciding which method is appropriate > under what circumstances Update to RFC 2976 > - Limiting use of INFO to ISUP transport only Security Considerations > > > > > > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)" > <[EMAIL PROTECTED]> wrote: > > > (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 > > > 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 > _______________________________________________ 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
