That is the point of the draft. All of the uses of INFO today have alternatives that do not have the same problems.
In fact, I am really thinking the draft should point out the use of INFO for SIP-T is also incorrect. SIP-T should use a control channel, not the "SIP" channel, for transporting proprietary signaling. The only thing SIP-T does is re-create TCP over SIP. Not a very useful use of SIP. That said, if this is to be a work group draft, I would sure appreciate the work group's opinion here. Do we: [1] Deprecate SIP-T, indicating the flaw of using INFO for transporting Q.931/Q.sig/DPNSS/telco foobar, as well as writing a new draft to replace SIP-T? Downside is no one will care and it will be ignored. [2] Ignore the issue and hope people do not notice the hypocrisy of saying "do not use INFO, but we have this use that we are afraid to admit we have learned from experience this was a mistake"? [3] Mention the SIP-T issue, point out that it may have been a Best Current Practice in 2002, but that it is no longer the best practice. However, it is what it is. To be clear, the "SIP-T issue" is really the INFO issue: the endpoint has no idea why they are getting an INFO nor what it means. The approach in this draft is to say the INFO means SIP-T and only SIP-T. I am getting less and less enamored with keeping the SIP-T use, as people keep piling on yet one more "kind of like Q.931" signaling on INFO. Before we know it, we get to "UserInputIndication", which is simply DTMF in ASN.1. On 8/31/07 2:31 AM, "Peili Xu" <[EMAIL PROTECTED]> wrote: > > > > I fully understand your concern. But just to forbidden > using INFO does not > solve the "how do the endpoints know they will be able > to communicate?" problem/requirement either. > > I'd suggest we first consider to find solution for the > prolem > then after that we can say "Don't use INFO for this, Use > that solution." > > Do you think this is a more convising way? > > Peili > > > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Friday, August 31, 2007 6:03 AM > To: Peili Xu > Cc: sip > Subject: Re: [Sip] INFO > > Saying, "OK for interworking" does not really say > anything. If I come up with a really broken method for > interworking, saying that it is for interworking does > not make it correct. > > The problem is, how do the endpoints know they will be > able to communicate? > For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know > they will be able to interoperate because they know > a'priori: they are configured to work. > However, this means that the devices must be in the same > administrative domain and configured properly. > > Said in a different manner, INFO works fine for > non-inter-network use. It would be hard for the IETF to > say, "Here is a non-IETF use. We will not use it. You > cannot use it with anyone else. You cannot use it > between manufacturers, unless you get them to agree to > this use." That is a bit more of what we call the toxic > waste warning that accompanies 3GPP specifications... > > > On 8/27/07 8:35 AM, "Peili Xu" <[EMAIL PROTECTED]> > wrote: > >> Hi Eric, >> >> Several cases I encounter to use INFO is for > interworking with PSTN >> signaling, or simulate PSTN services at SIP entities > such as SIP UA or >> SIP GW, which require mid-dialog information change. >> >> For such SIP entities, It's not always possible or > required to support >> encapsulation of ISUP or QSIG package. Just some XML > body with >> application info is enough and light-weight for this > purpose. >> >> >> INFO is not an ideal tool for everything, but is an > ideal tool for some thing. >> >> I'd prpose to at lease allow using INFO for > interworking or simulation >> purpose with legacy system. >> >> Regards. >> Peili >> >> 2007/8/22, Eric Burger <[EMAIL PROTECTED]>: >>> Since list traffic is down, how about something to > spice things up? >>> >>> >>> Any thoughts on >>> >>> > http://www.ietf.org/internet-drafts/draft-burger-sip-inf > o-01.txt >>> >>> ??? >>> >>> If you like it, say so. If you hate it, say so. >>> >>> Text welcome. >>> >>> >>> 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 > > > 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
