There are also issues on whether or not the allowed/desired INFO types should be specified somewhere. Furthermore, whether or not content-type is good enough for INFO type is not a consensus either.
If there are too many misuses (or abuses) of INFO then we need to realize if it's due to lack of INFO understanding or lack of defined functionality. We should map these cases. So far I have not seen many claims that INFO is required for something specific, either because most implementers do not use it or because it is deemed so unworthy in these discussions that people are shy. My personal feeling is that INFO is too broken to be fixed at this point. If implementers used INFO to solve issues, in a way that seems as if INFO should not be used in a normative RFC, then we should think of alternative solutions. However, I might change my mind if I see good usages of INFO. Gilad > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 5:05 PM > To: Jesske, R > Cc: [email protected] > Subject: Re: AW: AW: [Sip] INFO usage (or not) > > > > Jesske, R wrote: > >> 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. > > There are a variety of things we could do, together or separately: > > 1)revise 2976 to restrict INFO to standardized usages. Make any other > usage MUST NOT. > > 2)establish an IANA registry for uses of INFO based on Content-Type. > It would define what information is needed to define a usage. > Initially populate it with the existing standardized usages. > The criteria for adding new uses could be: > a) Stds track RFC > b) Informational RFC > c) FCFS > > 3)establish a policy that the WG won't approve any other usages of INFO, > beyond the existing ISUP/QSIG ones. (Then we don't need a registry.) > > 4)do nothing - status quo. Existing uses > > IMO anything that bans the current practices (i.e. (1)) that haven't > been standardized is futile - it won't cause them to stop. IMO we seem > to have a significant majority in favor of (3), though apparently not a > consensus. > > So I think the realistic possibilities are (2) or (4). And (2a) is > pretty much the same as (1) so it isn't realistic either. > > One of the other variants of (2) could reflect the realities and improve > on the current situation in that at least the existing usages would be > documented in public. > > Paul > > > 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 > > > > > _______________________________________________ > 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
