Subject: Re: [Sip] INFO usage (or not)

From: "Eric Burger" <[email-masked]>
Date: Mon, 18 Jun 2007 10:26:57 -0700

I agree: in a limited deployment scenario, like an application server connected to a media server using a yellow cable as a proxy and an application bought from a single systems integrator, there is no interoperability problem. However, the info incompatibility problem is real - I have experienced it in the wild.

You are correct in asserting that one can make INFO work - we were doing it in 2001.  However, working in the Internet is a different case altoghether.

--
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: Christer Holmberg (JO/LMF) <[email-masked]>
To: Eric Burger; Keith Drage <[email-masked]>; IETF SIP List <[email-masked]>
Sent: Mon Jun 18 02:19:55 2007
Subject: RE: [Sip] INFO usage (or not)

Hi,

I am very concerned some some people use the word "newbies", and make it sound that people using INFO are beginners which have no clue about SIP.

Also, I have never heard about interoperability problems with INFO. One reason people are using INFO for certain things IS in order to interop with other implementations.

I am also confused that people seem to think that INFOs will start flying around for no reason, without the sender having any clue about whether the receiver will understand them or not. As we have discussed, there ARE mechanisms in SIP to negotiate what content types etc entities support. Yes, MAYBE we need to extend that (e.g. being able to indicate which methods can be used to carry a specific content type), if what we have is not enough. But, to me that is not the same thing has having "tons of problem".

Having said that, if there are issues with INFO, I have nothing against discussing them. But, if you are going to talk about alternative solutions, you also need to look at possible issues with those (having to set up multiple dialogs just in order to send some DTMFs associated with another dialog etc). 

We can sit in our <insert-your-favorite-Hilton-hotel> meeting rooms and write whatever you-must-to-this-and-you-must-not-do-that documents, but if we don't care about the feedback we get from the real world OUTSIDE the meeting room it won't help much. In the long run it will cause more harm than good.

Regards,

Christer

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: 17. kesäkuuta 2007 12: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-masked]> 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-masked] for questions on current sip Use 
> > [email-masked] 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-masked] for questions on current sip 
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 18 Jun 2007 22:10:42 +0200

Hi, 

>I agree: in a limited deployment scenario, like an 
>application server connected to a media server using a yellow 
>cable as a proxy and an application bought from a single 
>systems integrator, there is no interoperability problem. 
>However, the info incompatibility problem is real - I have 
>experienced it in the wild.

So, why don't you explain what problems you have seen?

Because, I have seen implementations - from different vendors - working fine togheter.

Of course, maybe there are also implementations which do NOT interop widely, but they probably have been implemented without any use of the negotiation mechanisms etc that we have in SIP, with a very limited deployment scope in mind. There is not much we can do about that, but those kind of scenarios are not what I have been talking about.
 
>You are correct in asserting that one can make INFO work - we 
>were doing it in 2001.  However, working in the Internet is a 
>different case altoghether.

What do you mean by "Internet"?

Regards,

Christer

> 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.
> 
> I am very concerned some some people use the word "newbies", 
> and make it sound that people using INFO are beginners which 
> have no clue about SIP.
> 
> Also, I have never heard about interoperability problems with 
> INFO. One reason people are using INFO for certain things IS 
> in order to interop with other implementations.
> 
> I am also confused that people seem to think that INFOs will 
> start flying around for no reason, without the sender having 
> any clue about whether the receiver will understand them or 
> not. As we have discussed, there ARE mechanisms in SIP to 
> negotiate what content types etc entities support. Yes, MAYBE 
> we need to extend that (e.g. being able to indicate which 
> methods can be used to carry a specific content type), if 
> what we have is not enough. But, to me that is not the same 
> thing has having "tons of problem".
> 
> Having said that, if there are issues with INFO, I have 
> nothing against discussing them. But, if you are going to 
> talk about alternative solutions, you also need to look at 
> possible issues with those (having to set up multiple dialogs 
> just in order to send some DTMFs associated with another dialog etc). 
> 
> We can sit in our <insert-your-favorite-Hilton-hotel> meeting 
> rooms and write whatever 
> you-must-to-this-and-you-must-not-do-that documents, but if 
> we don't care about the feedback we get from the real world 
> OUTSIDE the meeting room it won't help much. In the long run 
> it will cause more harm than good.
> 
> Regards,
> 
> Christer
> 
> 
> 
>  
> 
> > (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.
> > 
> > 
> 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
> Alternatives to 
> > INFO
> > - Prescriptions for deciding which method is appropriate under what 
> > circumstances Update to RFC 2976
> > 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.
> > 
> >