> Because RFC 2976 is wrong, and we are willing to correct our mistakes.
So lets start. But I'm not willing to restrict INFO to ISUP & QSIG MIME only. BR Roland > -----Ursprüngliche Nachricht----- > Von: Eric Burger [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 18. Juni 2007 19:23 > An: Jesske, Roland; [email protected] > Betreff: Re: AW: [Sip] INFO usage (or not) > > > Because RFC 2976 is wrong, and we are willing to correct our > mistakes. Good news is that other than 3204, there are no > documented standards track uses of INFO. There is one > informational RFC that talks about its use in the wild (for > media server control), but if you look at it (RFC 4722) you > will see the #1 reason for using info was that in the day, > there was no other alternative. > > Given NO IETF standards use INFO, and we have been explaining > why it is a bad idea for close to five years now, I do not > see the problem with setting the record straight. > > -- > Sent from my wireless e-mail device. Sorry if terse. We all > need lemonade: see > <http://www.standardstrack.com/ietf/lemonade> for what lemonade is. > > -----Original Message----- > From: Jesske, R <[EMAIL PROTECTED]> > To: Eric Burger; [EMAIL PROTECTED] > <[EMAIL PROTECTED]>; [email protected] <[email protected]> > Sent: Mon Jun 18 02:01:29 2007 > Subject: AW: [Sip] INFO usage (or not) > > Hi, > Why should be RFC's that are now 6 Years out in the world be > restricted? > RFC 2976 clearly states for what INFO can be used. > I'm concerned about implementations that works with INFO > regarding the rules defined within 2976. > Many implementations work based on that RFC. Like define a > MIME, put it into INFO and it works. > > I thought also that INFO was defined to put in some end to > end information that shall be exchanged by UA's. > Why to restrict such a use in such a case? > > If RFC 2976 will be changed is backward compatibility guaranteed? > > Best Regards > > Roland > > > > -----Ursprüngliche Nachricht----- > > Von: Eric Burger [mailto:[EMAIL PROTECTED] > > Gesendet: Sonntag, 17. Juni 2007 11:53 > > An: Keith Drage; IETF SIP List > > Betreff: 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 > > > > 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
