Brian Stucker Says: I'm not really sure what your point was here unless you are against people writing down a common way of using a protocol amongst themselves
Actually, I have no problem with "people writing down a common way of using a protocol". One would offer that is the work of the IETF. However, the key phrase I have a problem with is, "amongst themselves." The IETF makes protocols for everybody, not just members of the garden club. The garden club can do whatever they want inside their garden. The IETF has no right nor interest in mandating what goes on inside their garden. Some gardeners ask the IETF for advice. Some do not. Sometimes, when the IETF sees a gardener about to spray a known, highly toxic poison, that is likely to spray outside the garden and harm innocent children, then the IETF does have the obligation to step up. In my mind, INFO for DTMF falls into the, "it is not an Internet protocol, but you can do whatever you want in your playground, so long as your fences are good and you will still play with me. P.S., do not claim you are using Internet protocols, because you are not." P-Preferred-Service is an example of something that falls into "the toxic substance that will bleed through, so do not even think of using it" category. -- 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: Brian Stucker <[EMAIL PROTECTED]> To: Eric Burger; Peili Xu <[EMAIL PROTECTED]> Cc: sip <[email protected]> Sent: Sun Sep 09 21:43:18 2007 Subject: RE: [Sip] INFO > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 30, 2007 5:03 PM > 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. ...or all of your UAs come from the same vendor or set of vendors that have agreed previously to support said mechanism, or you buy one of Hadriel's magic boxes to fix it for you. I realize the same could be said for any protocol scheme, but it's a very real fact in the case of how INFO works today, especially for DTMF. There's really only a few widely deployed schemes running around out there for DTMF via INFO. If we're complaining about using INFO for DTMF because of negotiation issues, I think that's a very solvable problem without deprecating INFO. > > Said in a different manner, INFO works fine for > non-inter-network use. It works fine for inter-network use as well depending upon what you are trying to use it for. Take for instance trying to figure out if a session is still alive by periodically sending an INFO to the other endpoint. I know we have a session timer mechanism defined, but many endpoints don't support it (yet). Even getting back an error response, depending upon the response code, may mean that the session is still alive (success). The point of the usage wasn't to convey anything, and so no negotiation was necessary. SIP was all you needed. > 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... > > You could say this for a lot of things. For instance, point me to the IETF use of SIP to do call forwarding. You can't use SIP between manufacturers unless you get them to agree to implement it correctly either. I'm not really sure what your point was here unless you are against people writing down a common way of using a protocol amongst themselves. :) Regards, Brian 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
