--- 1/draft-ietf-sipcore-proxy-feature-reqs-02.txt 2011-12-05 18:13:49.434671311 +0100 +++ 2/draft-ietf-sipcore-proxy-feature-reqs-03.txt 2011-12-05 18:13:49.450671870 +0100 @@ -1,18 +1,18 @@ SIPCORE Working Group C. Holmberg Internet-Draft I. Sedlacek Intended status: Standards Track Ericsson -Expires: April 23, 2012 October 21, 2011 +Expires: June 7, 2012 December 5, 2011 Requirements for indication of features supported by a SIP proxy - draft-ietf-sipcore-proxy-feature-reqs-02.txt + draft-ietf-sipcore-proxy-feature-reqs-03.txt Abstract The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 23, 2012. + This Internet-Draft will expire on June 7, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,21 +63,21 @@ 1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/capabilities. It can be useful for SIP proxies to indicate supported feature/ capabilities, that might trigger actions and enable functions in @@ -234,41 +234,51 @@ NOTE: This requirement might be fully implemented as part of the protocol mechanism, or parts might be left to be specified in a feature/capability specification, or it might be left to be specified in a feature/capability specification completely. REQ-7: It MUST be possible to assign additional parameters (either as a single value, or a list of values) to a feature/capability indicator, in order to provide additional information about the feature/capability. - REQ-8: If a SIP entity receives a feature support indication that it + REQ-8: If a SIP entity that supports the proxy feature/capability + indication mechanism receives a feature support indication that it does not understand, it MUST act as if it hadn't received the indication. REQ-9: If a SIP entity that does not support the proxy feature/ capability indication mechanism receives a feature support indication, it MUST act as if it hadn't received the indication. - REQ-10: Other SIP entities MUST be able to make routing decisions - based on received feature/capability support indications. + REQ-10: SIP entities on the path of the SIP message MUST be able to + inspect the feature/capability support indicators introduced by other + entities. REQ-11: A feature/capability support indicator MUST only be used to indicate support of a feature/capability, and MUST NOT be used to indicate whether procedures associated with the feature/capability have been applied or not. REQ-12: It MUST be possible to determine which features/capabilities - are supported by the same proxy + are supported by the same proxy. - REQ-13: A procedure for registering feature/capability indication - values with IANA MUST be defined. + REQ-13: A SIP proxy that indicates support of a feature/capability + associated with a dialog MUST take the necessary steps to ensure it + is part of the signaling path of the remainder that dialog, by + indicating the support of the feature/capability as part of a dialog + forming transaction, or as part of a target refresh request within a + dialog. + + REQ-14: A procedure for registering feature/capability indication + values, which prevents name collisions of indicators, with IANA MUST + be defined. 4. Security Considerations Feature/capability support indications can provide sensitive information about a SIP entity. RFC 3840 cautions against providing sensitive information to another party. Once this information is given out, any use may be made of it. 5. IANA Considerations @@ -284,20 +294,31 @@ Thanks to Hadriel Kaplan for telling us how SBCs mess up the mechanisms we try to specify. Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving working procedure guidance. 7. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] + Changes from draft-ietf-sipcore-proxy-feature-reqs-02 + o Changes based on comments from Robert Sparks at IETF#82 (http:// + www.ietf.org/mail-archive/web/sipcore/current/msg04473.html). + + o REQ-10: now talks about having access to the information, rather + than talking specifically about making routing decisions. + o REQ-8: editorial modification, to better distinguish it from + REQ-9. + o New REQ-13 (old REQ-13 becomes REQ-14) added. + o REQ-14: indication that the IANA registration procedure will + prevent name collision between feature indications. Changes from draft-ietf-sipcore-proxy-feature-reqs-01 o New REQ-12 added (old REQ-12 becomes REQ-13). o New use-case added (section 1.2.3). Changes from draft-ietf-sipcore-proxy-feature-reqs-00 o New REQ-5 added (IETF#81). o New REQ-9 added (Dale Worley). o Text added to REQ-4 and REQ-5, indicating that the requirement applies also in cases where an entity does not support the mechanism as a whole (Dale Worley). o Usage of "session establishment transactions" terminology in