Yeah, sorry, I missed that thread. The current draft basically says that it is NOT legal for a proxy to "upgrade" or "downgrade" from sip to sips or vice versa. It MUST keep the same scheme.
So, it is "not true" and therefore not badly broken. In fact, that's the whole point of making that change in the draft: fixing sips so it is not broken. The Double Record-Route procedures are nevertheless described in the draft because people wanted to see "what would happen with theoretical legacy 3261 implementations that supported sips as per 3261, but not according to the new draft". So: to summarize, with the current draft, the double record-route procedures are never used. > -----Original Message----- > From: Juha Heinanen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 23:00 > To: Audet, Francois (SC100:3055) > Cc: [email protected]; Alan Johnston; Keith Drage; Peterson, Jon; > Dean Willis > Subject: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues > > Francois Audet writes: > > > I looks like we are about ready to close on the 2 > remaining opened > issues in Appendix C of draft-ietf-sip-sips-03. > > how about the r-r tls transport issue that was raised a > couple of days ago? someone said that according to your i-d, > my proxy that uses tls with then next proxy, has to upgrade > sip: to sips: over that link. > > if that is true, your draft is badly broken, because my proxy > cannot have any knowledge that sips: is supported on the > following hops. if that is not true, tell me what kind of > r-r(s) my proxy needs to in that case insert. > > -- juha > _______________________________________________ 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
