< draft-ietf-sip-serverfeatures-04.txt   draft-ietf-sip-serverfeatures-05.txt >
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg,H.Schulzrinne Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-sip-serverfeatures-04.txt dynamicsoft,Columbia U. draft-ietf-sip-serverfeatures-05.txt dynamicsoft,Columbia U.
February 25, 2001 July 20, 2001
Expires: August 2001 Expires: February, 2002
The SIP Supported Header The SIP Supported Header
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Session Initiation Protocol (SIP) provides a mechanism that The Session Initiation Protocol (SIP) provides a mechanism that
allows a client to request that a particular protocol extension be allows a client to request that a particular protocol extension be
used to process the request. The server declines the request if it used to process the request. The server declines the request if it
does not support the extension. However, there is currently no way does not support the extension. However, there is currently no way
for a server to determine which extensions are supported by the for a server to determine which extensions are supported by the
client. Knowing about client-supported extensions allows the server client. Knowing about client-supported extensions allows the server
skipping to change at page 4, line 31 skipping to change at page 4, line 31
All requests, excepting ACK, generated by UACs conformant to this All requests, excepting ACK, generated by UACs conformant to this
specification SHOULD include the Supported header. This header MUST specification SHOULD include the Supported header. This header MUST
list all those extensions supported by the UAC which the UAC is list all those extensions supported by the UAC which the UAC is
willing to apply to the transaction. willing to apply to the transaction.
Any server (UAS, proxy, redirect or registrar) that wishes to apply Any server (UAS, proxy, redirect or registrar) that wishes to apply
some extension to the response, MUST only do so if support for that some extension to the response, MUST only do so if support for that
extension is indicated in the Supported header. If the desired extension is indicated in the Supported header. If the desired
extension is not supported, the server SHOULD rely only on baseline extension is not supported, the server SHOULD rely only on baseline
SIP and any other extensions supported by the client. In rare SIP and any other extensions supported by the client. To ensure that
circumstances, where the server cannot process the request without the SHOULD can be fulfilled, any specification of a new extension
the extension, the server MAY send a 421 (Extension Required) MUST include discussion of how to gracefully return to baseline SIP
response. This response indicates that the proper response cannot be when the extension is not present. In rare circumstances, where the
generated without support of a specific extension. The needed server cannot process the request without the extension, the server
extension(s) MUST be included in a Require header in the response. MAY send a 421 (Extension Required) response. This response indicates
This behavior is NOT RECOMMENDED, as it will generally break that the proper response cannot be generated without support of a
interoperability. specific extension. The needed extension(s) MUST be included in a
Require header in the response. This behavior is NOT RECOMMENDED, as
it will generally break interoperability.
Any extensions applied to a non-421 response MUST be listed in a Any extensions applied to a non-421 response MUST be listed in a
Require header included in the response. Of course, the server MUST Require header included in the response. Of course, the server MUST
NOT apply extensions not listed in the Supported header in the NOT apply extensions not listed in the Supported header in the
request. As a result of this, the Require header in a response will request. As a result of this, the Require header in a response will
only ever contain option tags defined in standards track RFCs. only ever contain option tags defined in standards track RFCs.
4 Usage with OPTIONS 4 Usage with OPTIONS
User agent servers compliant to this specification MUST include a User agent servers compliant to this specification MUST include a
 End of changes. 4 change blocks. 
14 lines changed or deleted 16 lines changed or added

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