I should have known better not to waste my time answering your questions when you obviously don't care about the answers.
I won't make that mistake again. > -----Original Message----- > From: Srivastava, Samir (SC100:8826) > Sent: Wednesday, April 25, 2007 15:25 > To: Audet, Francois (SC100:3055) > Cc: '[email protected]' > Subject: RE: Interaction of SIPS with old implementations > that weren't really using SIPS (was Re: [Sip] > draft-ietf-sip-sips-03.txt) > > > > >On your first question: If I send you a request using a SIPS > URI, and > >you accept it even if you don't support SIPS (because you > are a buggy > >implemenation), you will nevertheless put SIP in the various URIs in > >your response, e.g., in the Contact header. You may even muck-up the > >From or To. If you send me mid-call requests later, you will most > >probably use SIP URIs in From. If I detect something like > that, I can > >probably figure out something is wrong. Some of this is > already covered > >in the draft and in RFC 3261. > > If it just doesn't support SIPS, It should just return "416 > Unsupported URI scheme". > Very pointed question, why do we want to develop standards > for the BUGGY implementation. At the _most_, we can just say > in BCP/INFORMATIONAL document that if it behaves like this, > then it is buggy implementation. And we don't attempt to fix > it in the specification. If we take this route, we might find > numerous others BUGGY implementations of other parts of SIP > specifications also. I just call them BUGS. And bugs are > fixed by their owners during the upgrades/patches etc. > > > >On your second question. It's not the protocol that is > broken but the > >implementation. > > > We should not even attempt to fix the broken implementation > via another add-on standards. I don't want to say now as Dean > yesterday said season is over for hunting. Keep trying to fix > it. Good luck. > > Thx > Samir > _______________________________________________ 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
