> -----Original Message----- > From: Spencer Dawkins [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 27, 2007 10:03 AM > To: [email protected] > Subject: Re: [Sip] INFO > > >> Eric's document basically takes the second approach, > grandfathering > >> all uses of INFO that are currently published in an RFC or > an active > >> internet-draft, and forbidding any others. The list is not > long; I'll > >> replicate it here: > >> > >> 1. RFC 3372 > >> > >> You want more than that, you really need packages. > > > > Expand that list to include application/dtmf and I think you'll > > largely end the debate. > > It would be a lovely thing for this debate to end. Perhaps we > could refocus with that aim in mind. Since I'm Eric's > instigator, I'm asking that we remember how we got here.
Spencer, I'm not debating the problem, I'm trying to figure out what the underlying problem realy *IS* so it's addressed properly. I could care less about application/dtmf or application/vnd.nortelnetworks.digits or any of the other myriad MIME types that may get sent in an INFO. I suggested adding the MIME types as a way to get agreement from others, but it's not what I'm worried about at all. [SNIP] > If we could focus on Eric's draft, which does not deprecate > existing standards-track uses of INFO, that might get us to > publication of a draft that would discourage additional uses > of INFO, and provide the explanation for this, so that random > RAI-area drafts (which aren't even in the SIP working group) > stop including text that explains Why We Aren't Using INFO - > text that may or may not reflect SIP working group consensus. It's the explanation and allowance of SIP-T that (for me) is causing the problem because it makes the document really unclear as to what the actual harm being done here is. It's not clear to me at all why INFO should be deprecated based upon the arugment that sending stuff to someone that they might not understand, when gracefully handling such is a baseline requirement of 3261 and SIP-T itself and is not at all limited to INFO. If this is the real problem that we're trying to address, then write a draft that says that sending things that you're not sure the other side will understand is a bad idea, here's why, and don't make one SIP method the whipping boy for an entirely different problem that can arise in any SIP method. The biggest use of INFO that I see (by volume) contains no message body at all. I tried to point this out earlier so it could be included in the draft but the messenger got shot instead. INFO gets used to detect if the dialog, and therefore the call, is still alive. In this usage it does not differ from sending an OPTIONS as a mid-dialog request which is allowed by RFC-3261. The draft makes no mention of this usage and does not address why this is harmful (as opposed to OPTIONS) as a result. If this is harmful, then sending an OPTIONS in mid-dialog is harmful too, we should deprecate that as well. If sending MIME types that you're not sure the other side understands is harmful, then we should always start out a call by sending an OPTIONS prior to the INVITE so that we can be sure that the MIME types we may include in a multi-part offer are understood. Let's put that in there too if unknown MIME types is the real problem to be solved. Regards, Brian _______________________________________________ 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
