Exactly. > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, October 02, 2007 4:50 PM > To: Dean Willis; Stucker, Brian (RICH1:AR00) > Cc: [email protected]; Adam Roach; Barnes, Mary (RICH2:AR00) > Subject: RE: [Sip] INFO > > I'm still completely baffled by why are we having this thread. > > INFO is used by ISUP tunnelling. It's there, we can leave it > alone. As far as I know, nobody is trying to improve it. > Legacy stuff. No RFC required here. > > DTMF transport is a null issue since the last remaining > laggars that didn't support RFC 2833 now support it. So it is > going away and I really can't imagine that anybody would > bring a draft to resurect it. No RFC required here. > > IETF is certainly not going to come up with new INFO usages. > Everytime somebody shows up with an INFO idea, he's promptly > turned away. > > So, what is the "problem" that we are trying to solve? Why > are we wasting time on this? > > Can't we just declare victory and move on? > > > > > -----Original Message----- > > From: Dean Willis [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 02, 2007 09:47 > > To: Stucker, Brian (RICH1:AR00) > > Cc: [email protected]; Adam Roach; Barnes, Mary (RICH2:AR00) > > Subject: Re: [Sip] INFO > > > > > > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: > > > > > > > > So if we're allowing SIP-T, which builds off of a baseline SIP > > > requirement that if you get a MIME type or method (INFO) that you > > > don't understand, that you gracefully handle this: send a > > 415/488 or > > > send a 405, respectively, then why are we disallowing > other uses of > > > INFO that do not introduce ANY requirements beyond those of SIP-T > > > which we are allowing? > > > > > > > This raises the argument that SIP-T should be revisited to more > > clearly negotiate support for the material being tunneled, > including > > the context in which it is being tunneled. My UA might, for > example, > > know how to render an ISUP message using a pretty-printer. That > > doesn't mean it knows how to do SIP-T for gateways. > > > > So, SIP-T is broken and likely to give surprising results. > > That is not a hearty argument for endorsing the technique > of SIP-T for > > other functions. > > > > > > > Here's another question for the readers: let's say Eric's draft > > > becomes an RFC as written for sake of argument. What > > happens when a UA > > > that does not support SIP-T gets a call from an ISUP > > gateway and gets > > > an INFO with encapsulated ISUP in the message body? How does this > > > processing differ from an endpoint getting encapsulated DTMF in a > > > format it may not understand? It doesn't differ because it > > can't: the > > > UA cannot differentiate between two different MIME types > > when it does > > > not recognize either of them. > > > > But assume the UA DOES recognize the MIME type. How does it > know what > > to do with it? Is content-disposition adequate? > > > > If it were, why would we have the higher-level negotiation of event > > contexts? > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > 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
