The IESG has approved the following document: - 'The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) ' <draft-ietf-sip-sips-09.txt> as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-09.txt Technical Summary: This document updates RFC 3261 to provide clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). This document also provides a discussion of possible future steps in specification. The SIPS URI scheme was originally documented in RFC 3261, but experience has shown that the specification therein is incomplete, and that at least one use case that increased the complexity of the specification (the "last hop exception") can be eliminated. Several possible error conditions relating to mismatch of sips vs. sip on sending and receiving ends exist. This documents adds new SIP error codes to provide for the detection and correction of these error conditions. Working Group Summary: There were several topics of significance that are worth noting. The foremost is the deprecation of the "last hop exception" from RFC 3261. This exception allowed a proxy/registrar supporting SIPS to relay requests received using SIPS on to user agent servers that did not indicate support for SIPS. This increases the complexity of implementations and weakens the end-to-end assurance of signaling security provided by SIPS. After extensive debate, the working group resolved to eliminate this exception and make SIPS fully end-to-end. Doing so required extensive discussion and annotation on what "end to end" means in the context of gateways to non-SIP protocols. Detection and correction of error conditions resulting where a UAC has specified a SIPS request and the terminating UAS has not registered a SIP contact, or where the UAC has specified a SIP request and the terminating UAS has registered only a SIP contact was another problem requiring extensive discussion. The "obvious" approach of using 400 class responses created problems when interacting with forking proxies. The WG concluded on using two new 300-class SIP response codes to enable request resolution in these scenarios. During the process of developing this specification, the working group began to converge on a new process for incrementally updating RFC 3261. As a precursor to this process, this specification contains an appendix that provides explicit in-context changes to RFC 3261 as required by this specification. The intent here is to reduce the complexity of discussions at interoperability events. Document Quality There are several notable implementations of the specification at varying levels of maturity. The SIPIt interop events have included SIPS for some time, and the changes in this specification were in-part driven by experiences at those interop events. The document' Acknowledgements section cites numerous active participants for providing detailed review. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
