idnits 2.17.1 draft-ietf-sip-serverfeatures-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 93: '...his header field SHOULD be included in...' RFC 2119 keyword, line 95: '...y extensions. It MUST be included in t...' RFC 2119 keyword, line 131: '... specification SHOULD include the Su...' RFC 2119 keyword, line 136: '...to the response, MUST only do so if su...' RFC 2119 keyword, line 139: '... it, the server MAY send a 421 (Featu...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 110 has weird spacing: '... where enc. ...' == Line 112 has weird spacing: '...pported g ...' == Line 126 has weird spacing: '...Require g e...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 2000) is 8824 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 262 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J.Rosenberg,H.Schulzrinne 4 draft-ietf-sip-serverfeatures-01.txt dynamicsoft,Columbia U. 5 February 28, 2000 6 Expires: August, 2000 8 The SIP Supported Header 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Session Initiation Protocol (SIP) defines mechanims that allow a 34 client to mandate that a server support specific extensions in order 35 to process a request. However, there is currently no way for a server 36 to determine what features are supported in a client, in order to use 37 those features to process the request. This capability is needed for 38 numerous extensions currently under development, such as provisional 39 response reliability and the session progress message. We also note 40 that there is currently no way for a client to query a server about 41 the features it supports. This document defines a SIP extension that 42 allows clients to indicate, in a request, the set of features 43 supported. We also define a mechanism that allows clients, through an 44 OPTIONS request, to determine the features supported by a server. 46 1 Introduction 47 The Session Initiation Protocol (SIP) [1] defines mechanims that 48 allow a client to mandate that a server support specific extensions 49 in order to process a request. This is accomplished through the 50 Require and Proxy-Require headers. These headers include option tags. 51 A UAS or proxy, respectively, must understand the option tags in 52 order to process a request. 54 However, SIP provides no support for the reverse case. In this case, 55 a server wants to use a feature to process a request, but must 56 determine if the client supports it. In this scenario, the client 57 does not ask for the given feature, but the server wants to use the 58 feature in the response. As the response cannot be processed without 59 understanding this feature, the server needs a way to determine which 60 features are supported by the client. The server also needs a way to 61 signal to the client which features have been applied in the 62 response. 64 Very much related to this, there is currently no way for a client to 65 query a server to determine which features it supports. OPTIONS 66 allows a client to query a server about capabilities, such as support 67 for various methods and media types. However, the set of supported 68 features is not among the information returned in an OPTIONS 69 response. 71 This document defines an extension to SIP that enables the ability 72 for clients and servers to indicate support for features. This is 73 done through a new header, called Supported. Supported, like the 74 Unsupported header, contains a list of option tags supported by the 75 entity sending the message. This extension also allows the Require 76 header to appear in responses. It is used to indicate what options 77 must be understood by the UAC in order to process the response. 79 It is expected that this extension will be folded into the next 80 revision of the SIP specification. 82 2 Header Syntax 84 2.1 Supported Header 86 This extension defines a new general header, Supported. The syntax 87 for this header is: 89 Supported = ( "Supported" | k ) ":" 0#option-tag 91 The BNF for option-tag is given in RFC 2543 [1]. The Supported 92 general-header field enumerates all the capabilities of the client or 93 server. This header field SHOULD be included in all requests (except 94 ACK) generated by clients conforming to this specification, if those 95 clients support any extensions. It MUST be included in the response 96 to OPTIONS requests, even if the UAS generating the response doesn't 97 support any extensions beyond this one. 99 Note that the BNF for the header explicitly allows for zero option 100 tags to be present. This will occur when a server responds to an 101 OPTIONS request, but it supports no extensions beyond this one 102 itself. This is needed to enable backwards compatibility. If the 103 response to OPTIONS contains no Supported header at all, it means the 104 server may support some extensions, but does not understand the 105 Supported header. 107 The following defines the entry for the Supported in Table 4 of RFC 108 2543. Table 4 lists the places where the Supported may appear: 110 where enc. e-e ACK BYE CAN INV OPT REG 111 ___________________________________________________ 112 Supported g c e - o o o o o 114 A compact form for the Supported header is defined. This is the 115 letter k, for "know". 117 2.2 Require 119 This extension also allows for the Require header to appear in 120 responses. It is used to indicate what options must be understood by 121 the UAC in order to process the response. 123 This implies that the row of Table 4 in RFC 2543 defining usage of 124 the Require header should read: 126 Require g e o o o o o o 128 3 Usage in Requests 130 All requests, excepting ACK, generated by UACs conformant to this 131 specification SHOULD include the Supported header. This header MUST 132 list all those features supported by the UAC which the UAC is willing 133 to apply to the transaction. 135 Any server (UAS, proxy, redirect or registrar) that wishes to apply 136 some extension to the response, MUST only do so if support for that 137 feature is indicated in the Supported header. If the feature is 138 essential, and the server cannot send its desired response without 139 it, the server MAY send a 421 (Feature Required) response. This 140 response indicates that the proper response cannot be generated 141 without support of a specific feature. The needed feature(s) MUST be 142 included in a Require header in the response. 144 If the feature the server wishes to apply to the response is 145 supported, the server MUST include a Require header in the response 146 listing those features it applied to the response. 148 4 Usage with OPTIONS 150 User agent servers compliant to this specification MUST include a 151 Supported header in responses to OPTIONS requests. This header MUST 152 be present even if the server supports no features/extensions beyond 153 the one specificed here. This means that the Supported header may be 154 empty in the response. 156 Clients MUST NOT treat absence of the Supported header in an OPTIONS 157 response to mean no extensions are supported. The presence of an 158 empty Supported header implies no extensions are supported. 160 5 Example Usage 162 This section gives an example call flow using this extension. UAC A 163 sends a request to UAS B. UAS B wishes to apply feature foo to the 164 response. Two cases are shown. In the first, foo is supported by A, 165 and in the second, is not. 167 5.1 A supports foo 169 The initial INVITE from A looks like (SDP omitted for clarity): 171 A->B: INVITE sip:jtoto@dynamicsoft.com SIP/2.0 172 Via: SIP/2.0/UDP bigmachine.dynamicsoft.com 173 Supported: foo 174 From: sip:jdrosen@dynamicsoft.com 175 To: sip:jtoto@dynamicsoft.com 176 Call-ID: 70710@bigmachine.dynamicsoft.com 177 CSeq: 1 INVITE 178 Subject: Venture Capital 180 Since the desired feature is supported, B applies it to the response 181 (in this case, a redirect), and includes a Require header indicating 182 that the feature has been applied. 184 B->A: SIP/2.0 300 Moved 185 Via: SIP/2.0/UDP bigmachine.dynamicsoft.com 186 Require: foo 187 From: sip:jdrosen@dynamicsoft.com 188 To: sip:jtoto@dynamicsoft.com;tag=443322 189 Call-ID: 70710@bigmachine.dynamicsoft.com 190 CSeq: 1 INVITE 191 Foo: 9998h7asdh9 193 and A sends an ACK: 195 C->S: ACK sip:jtoto@dynamicsoft.com SIP/2.0 196 Via: SIP/2.0/UDP bigmachine.dynamicsoft.com 197 From: sip:jdrosen@dynamicsoft.com 198 To: sip:jtoto@dynamicsoft.com;tag=443322 199 Call-ID: 70710@bigmachine.dynamicsoft.com 200 CSeq: 1 ACK 202 Note that the Supported header is not included in the ACK. 204 5.2 A doesn't support foo 206 In this case, A doesn't support foo. It supports some other feature, 207 bar. The server wishes to apply foo, and is not willing to proceed 208 without it. So, it rejects the request. 210 A doesn't support com.dynamicsoft.foo, so it resubmits the request 211 with an Unsupported header included: 213 A->B: INVITE sip:jtoto@dynamicsoft.com SIP/2.0 214 Via: SIP/2.0/UDP bigmachine.dynamicsoft.com 215 Supported: bar 216 From: sip:jdrosen@dynamicsoft.com 217 To: sip:jtoto@dynamicsoft.com 218 Call-ID: 70710@bigmachine.dynamicsoft.com 219 CSeq: 1 INVITE 220 Subject: Venture Capital 222 B->A: SIP/2.0 421 Feature Required 223 Via: SIP/2.0/UDP bigmachine.dynamicsoft.com 224 Require: foo 225 From: sip:jdrosen@dynamicsoft.com 226 To: sip:jtoto@dynamicsoft.com;tag=98765 227 Call-ID: 70710@bigmachine.dynamicsoft.com 228 CSeq: 1 INVITE 230 a sends an ACK: 232 A->B: ACK sip:jtoto@dynamicsoft.com SIP/2.0 233 Via: SIP/2.0/UDP bigmachine.dynamicsoft.com 234 From: sip:jdrosen@dynamicsoft.com 235 To: sip:jtoto@dynamicsoft.com;tag=98765 236 Call-ID: 70710@bigmachine.dynamicsoft.com 237 CSeq: 1 ACK 239 6 Security Considerations 241 This extension introduces no new security considerations beyond those 242 discussed in RFC 2543 [1]. 244 7 Author's Addresses 246 Jonathan Rosenberg 247 dynamicsoft 248 200 Executive Drive 249 Suite 120 250 West Orange, NJ 07052 251 email: jdrosen@dynamicsoft.com 253 Henning Schulzrinne 254 Columbia University 255 M/S 0401 256 1214 Amsterdam Ave. 257 New York, NY 10027-7003 258 email: schulzrinne@cs.columbia.edu 260 8 Bibliography 262 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 263 session initiation protocol," Request for Comments (Proposed 264 Standard) 2543, Internet Engineering Task Force, Mar. 1999.