draft-ietf-sipcore-proxy-feature-reqs-02.txt   draft-ietf-sipcore-proxy-feature-reqs-03.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson 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 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 Abstract
The Session Initiation Protocol (SIP) "Caller Preferences" extension The Session Initiation Protocol (SIP) "Caller Preferences" extension
defined in RFC 3840 provides a mechanism that allows a SIP message to defined in RFC 3840 provides a mechanism that allows a SIP message to
convey information relating to the originator's supported features/ convey information relating to the originator's supported features/
capabilities. This document defines requirements for a mechanism capabilities. This document defines requirements for a mechanism
that would allow SIP proxies to convey information relating to the that would allow SIP proxies to convey information relating to the
proxy's supported features/capabilities. proxy's supported features/capabilities.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 5 1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) "Caller Preferences" extension The Session Initiation Protocol (SIP) "Caller Preferences" extension
defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP
message to convey information relating to the originator's supported message to convey information relating to the originator's supported
features/capabilities. features/capabilities.
It can be useful for SIP proxies to indicate supported feature/ It can be useful for SIP proxies to indicate supported feature/
capabilities, that might trigger actions and enable functions in capabilities, that might trigger actions and enable functions in
skipping to change at page 6, line 32 skipping to change at page 6, line 32
NOTE: This requirement might be fully implemented as part of the NOTE: This requirement might be fully implemented as part of the
protocol mechanism, or parts might be left to be specified in a protocol mechanism, or parts might be left to be specified in a
feature/capability specification, or it might be left to be specified feature/capability specification, or it might be left to be specified
in a feature/capability specification completely. in a feature/capability specification completely.
REQ-7: It MUST be possible to assign additional parameters (either as REQ-7: It MUST be possible to assign additional parameters (either as
a single value, or a list of values) to a feature/capability a single value, or a list of values) to a feature/capability
indicator, in order to provide additional information about the indicator, in order to provide additional information about the
feature/capability. 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 does not understand, it MUST act as if it hadn't received the
indication. indication.
REQ-9: If a SIP entity that does not support the proxy feature/ REQ-9: If a SIP entity that does not support the proxy feature/
capability indication mechanism receives a feature support capability indication mechanism receives a feature support
indication, it MUST act as if it hadn't received the indication. indication, it MUST act as if it hadn't received the indication.
REQ-10: Other SIP entities MUST be able to make routing decisions REQ-10: SIP entities on the path of the SIP message MUST be able to
based on received feature/capability support indications. inspect the feature/capability support indicators introduced by other
entities.
REQ-11: A feature/capability support indicator MUST only be used to 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 support of a feature/capability, and MUST NOT be used to
indicate whether procedures associated with the feature/capability indicate whether procedures associated with the feature/capability
have been applied or not. have been applied or not.
REQ-12: It MUST be possible to determine which features/capabilities 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 REQ-13: A SIP proxy that indicates support of a feature/capability
values with IANA MUST be defined. 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 4. Security Considerations
Feature/capability support indications can provide sensitive Feature/capability support indications can provide sensitive
information about a SIP entity. RFC 3840 cautions against providing information about a SIP entity. RFC 3840 cautions against providing
sensitive information to another party. Once this information is sensitive information to another party. Once this information is
given out, any use may be made of it. given out, any use may be made of it.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 7, line 33 skipping to change at page 7, line 44
Thanks to Hadriel Kaplan for telling us how SBCs mess up the Thanks to Hadriel Kaplan for telling us how SBCs mess up the
mechanisms we try to specify. mechanisms we try to specify.
Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving
working procedure guidance. working procedure guidance.
7. Change Log 7. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [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 Changes from draft-ietf-sipcore-proxy-feature-reqs-01
o New REQ-12 added (old REQ-12 becomes REQ-13). o New REQ-12 added (old REQ-12 becomes REQ-13).
o New use-case added (section 1.2.3). o New use-case added (section 1.2.3).
Changes from draft-ietf-sipcore-proxy-feature-reqs-00 Changes from draft-ietf-sipcore-proxy-feature-reqs-00
o New REQ-5 added (IETF#81). o New REQ-5 added (IETF#81).
o New REQ-9 added (Dale Worley). o New REQ-9 added (Dale Worley).
o Text added to REQ-4 and REQ-5, indicating that the requirement o Text added to REQ-4 and REQ-5, indicating that the requirement
applies also in cases where an entity does not support the applies also in cases where an entity does not support the
mechanism as a whole (Dale Worley). mechanism as a whole (Dale Worley).
o Usage of "session establishment transactions" terminology in o Usage of "session establishment transactions" terminology in
 End of changes. 9 change blocks. 
10 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/