idnits 2.17.1 draft-ietf-sip-refer-00.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: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 108: '... A REFER request MAY be placed outside...' RFC 2119 keyword, line 109: '...n INVITE. REFER MAY be Record-Routed,...' RFC 2119 keyword, line 111: '... MUST follow the Route/Record-Route ...' RFC 2119 keyword, line 122: '... A REFER method MUST contain exactly ...' RFC 2119 keyword, line 124: '... Refer-To header MAY be encrypted as p...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 18, 2001) is 8311 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) ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- No information found for draft-sip-events - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft dynamicsoft 4 Expires: January 16, 2002 July 18, 2001 6 The Refer Method 7 draft-ietf-sip-refer-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 16, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This document defines the REFER method. This SIP extension requests 39 that the recipient REFER to a resource provided in the request. This 40 can be used to enable many applications, including Call Transfer. 42 Table of Contents 44 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Changes from draft-sparks-sip-cc-transfer-04 . . . . . . . 3 46 3. The REFER Method . . . . . . . . . . . . . . . . . . . . . 3 47 3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . 3 48 3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . 4 50 3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . 5 51 3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.3 Header Field Support for the REFER Method . . . . . . . . 5 53 3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . 7 54 3.5 Responses within the REFER transaction . . . . . . . . . . 7 55 3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . 7 56 3.6.1 Accessing the referred-to resource . . . . . . . . . . . . 7 57 3.6.2 Reporting on the results of the reference . . . . . . . . 7 58 3.6.2.1 Using NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.6.2.2 The body of the NOTIFY . . . . . . . . . . . . . . . . . . 8 60 3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . 9 61 3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . 9 62 3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . 9 63 3.10 Security Considerations . . . . . . . . . . . . . . . . . 11 64 3.10.1 Circumventing privacy . . . . . . . . . . . . . . . . . . 11 65 3.10.2 Circumventing security . . . . . . . . . . . . . . . . . . 11 66 3.10.3 Limiting the breach . . . . . . . . . . . . . . . . . . . 12 67 4. Historic Material . . . . . . . . . . . . . . . . . . . . 12 68 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1 REFER is now dependent on sip-events . . . . . . . . . . . 12 70 5.2 Registering the refer event with IANA . . . . . . . . . . 13 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 13 72 References . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . 13 74 Full Copyright Statement . . . . . . . . . . . . . . . . . 14 76 1. Overview 78 This document defines the REFER method. This SIP SIP [1] extension 79 requests that the recipient REFER to a resource provided in the 80 request. This can be used to enable many applications, including 81 Call Transfer. 83 Editor's note: Per working group consensus, draft-ietf-sip-cc- 84 transfer-04 was split into two drafts. This draft specifies the 85 REFER method itself. Its companion (name to be determined) details 86 the use of REFER to achieve call transfer. 88 2. Changes from draft-sparks-sip-cc-transfer-04 90 o Split the document 91 o Simplified the expression of the Referred-By grammar 92 o Resolved inconsistency in Referred-By signature normative text and 93 example 95 3. The REFER Method 97 REFER is a SIP method as defined by RFC2543 [1]. The REFER method 98 indicates that the recipient (identified by the Request-URI) should 99 contact a third party using the contact information provided in the 100 method. A success response indicates that the recipient was able to 101 contact the third party. 103 Unless stated otherwise, the protocol for emitting and responding to 104 a REFER request are identical to those for a BYE request in [1]. The 105 behavior of SIP entities not implementing the REFER (or any other 106 unknown) method is explicitly defined in [1]. 108 A REFER request MAY be placed outside the scope of a call-leg created 109 with an INVITE. REFER MAY be Record-Routed, hence MUST contain a 110 single Contact header. REFERs occurring inside an existing call-leg 111 MUST follow the Route/Record-Route logic of that call-leg. REFERs 112 occurring outside an existing call-leg effectively create a new call- 113 leg following the behavior of SUBSCRIBE specified [2]. 115 3.1 The Refer-To Header 117 Refer-To is a request-header as defined by [1]. It may only appear 118 in a REFER request. It provides a URL to reference. 120 Refer-To = ("Refer-To" | "r") ":" URL 122 A REFER method MUST contain exactly one Refer-To header. 124 The Refer-To header MAY be encrypted as part of end-end encryption. 126 The Contact header is an important part of the Route/Record-Route 127 mechanism and is not available to be used to indicate the target of the 128 reference. 130 3.1.1 Examples 132 Refer-To: sip:alice@atlanta.com 134 Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk. 135 biloxi.com&Call-ID=55432@alicepc.atlanta.com 137 Refer-To: 140 Refer-To: sip:carol@cleveland.com;method=SUBSCRIBE 142 Refer-To: http://www.ietf.org 144 Long headers are line-wrapped here for clarity only. 146 3.2 The Referred-By Header 148 Referred-By is a request-header as defined by [1]. It can appear in 149 any request. It conveys the identity of the original REFERrer to the 150 referred-to party, optionally proving the identity and that the 151 REFERrer actually issued this reference. 153 Referred-By = ("Referred-By" | "b") ":" 154 referrer-url [ referenced-url ] 156 referrer-url = ( name-addr | addr-spec ) 158 referenced-url = ";" "ref" "=" "<" URL ">" [ ref-signature ] 160 ref-signature = ";" signature-scheme *( sig-scheme-params ) 162 signature-scheme = "scheme" "=" token 164 sig-scheme-parms = ";" token "=" ( token | quoted-string ) 166 The referrer-url contains the SIP URL of the party sending the REFER 167 request. The referenced-url contains a copy of the URL placed in the 168 Refer-To: header. Any occurrences of < or > in the referenced-url 169 MUST be escaped. The ref-signature contains a signature over the 170 concatenation of addr-spec portion of the referrer-url and the entire 171 referenced-url. An example signature scheme is given in section 172 Section 3.2.1. 174 A REFER request MUST contain exactly one Referred-By header. 176 The Referred-By header SHOULD be signed to help detection of REFERs 177 from unauthorized third parties. A signed Referred-By header SHOULD 178 include a Date header in the referrer-url to facilitate detection of 179 replay attacks. 181 A UA MAY reject a request containing an unsigned Referred-By header. 182 A UA SHOULD verify the signature on any Referred-By header it 183 receives. 185 The Referred-By header MAY be encrypted as part of end-end 186 encryption. 188 3.2.1 A PGP based signature-scheme 190 One signature-scheme for Referred-By headers uses PGP as follows: 192 signature-scheme = "scheme" "=" "pgp" 193 sig-scheme-parms = pgp-version | signed-by | pgp-signature 195 pgp-version, signed-by and pgp-signature are defined in section 15.1 196 of RFC2543, with the modification that the signature is computed 197 across the concatenation of the addr-spec portion of the referrer-url 198 and the entire referenced-url. 200 3.2.2 Examples 202 Referred-By: sip:alice@atlanta.com;ref= 204 Referred-By: "Bob" ; 205 ref=;scheme=pgp; 206 pgp-version="5.0";signature="the signature" 208 (Note that in the last example, the signature would be over the 209 string "sip:bob@biloxi.comsip:alice@atlanta.com") 211 3.3 Header Field Support for the REFER Method 213 This table adds a column to tables 4 and 5 in [1], describing header 214 presence in a REFER method. See [1] for a key for the symbols used. 215 A row for the Refer-To: and Referred-By request-header should be 216 inferred, each mandatory for REFER. Refer-To is not applicable for 217 any other methods. Referred-By is a general Request header. The enc 218 and e-e columns in [1] apply to the REFER method unmodified. 220 Header Where REFER 221 Accept R - 222 Accept-Encoding R - 223 Accept-Language R o 224 Allow R - 225 Allow 405 m 226 Authorization R o 227 Call-ID gc m 228 Contact R m 229 Contact 1xx - 230 Contact 2-6xx o 231 Content-Encoding e - 232 Content-Length e o 233 Content-Type e - 234 CSeq gc m 235 Date g o 236 Encryption g o 237 Expires R o 238 From gc m 239 Hide R o 240 Max-Forwards R o 241 Organization g o 242 Priority R - 243 Proxy-Authenticate 407 o 244 Proxy-Authorization R o 245 Proxy-Require R o 246 Require R o 247 Retry-After R - 248 Retry-After 404,480,486 o 249 Retry-After 503 o 250 Retry-After 600,603 o 251 Response-Key R o 252 Record-Route R o 253 Record-Route 2xx o 254 Route R o 255 Server r o 256 Subject R - 257 Timestamp g o 258 To gc(1) m 259 Unsupported 420 o 260 User-Agent g o 261 Via gc(2) m 262 Warning r o 263 WWW-Authenticate 401 o 265 3.4 Message Body Inclusion 267 A REFER method MAY contain a body. This specification assigns no 268 meaning to such a body. A receiving agent may choose to process the 269 body according to its Content-Type. 271 3.5 Responses within the REFER transaction 273 An agent responding to a REFER Method MUST return a 400 Bad Request 274 if the request contained zero or more than one Refer-To headers. An 275 agent responding to a REFER Method MUST return a 400 Bad Request if 276 the request contained zero or more than one Referred-By headers. An 277 agent (including proxies generating local responses) MAY return a 100 278 Trying or any appropriate 400-600 class response as prescribed by 279 [1]. If the recipient's agent decides to contact the resource in the 280 Refer-To header, a 202 Accepted response MUST be returned before the 281 REFER transaction expires. 283 3.6 Behavior of SIP User Agents 285 3.6.1 Accessing the referred-to resource 287 A UA receiving a well-formed REFER request SHOULD request approval 288 from the user to proceed (this request could be interactive or 289 through configuration). Upon receiving approval from the user, the 290 UA MUST contact the resource identified by the URL in the Refer-To: 291 header. Note that if the URL is a SIP URL, it could contain header 292 fields such as Call-Id that may be used to form the resulting 293 request. If the URL is a SIP URL, the Referred-By header in the 294 REFER request should be copied into the request sent to the referred- 295 to resource. 297 The resource identified by the Refer-To: URL is contacted using the 298 normal mechanisms for that URL type. For example, if the URL is a 299 SIP INVITE URL, the UA would issue a new INVITE using all of the 300 normal rules for sending an INVITE defined in [1]. 302 3.6.2 Reporting on the results of the reference 304 3.6.2.1 Using NOTIFY 306 Once it is known whether the reference succeeded or failed, the UA 307 receiving the REFER SHOULD notify the agent sending the refer using 308 the NOTIFY mechanism defined in Event Notification in SIP [2] as if 309 the REFER had established a subscription. In particular: 311 o Each NOTIFY should reflect the To:, From:, and Call-ID headers 312 from the REFER as if they had arrived in a SUBSCRIBE. 314 o Each NOTIFY MUST contain an event header of Event: refer 316 o Each NOTIFY MUST contain a body of type "application/sip". The 317 contents of this body are detailed in Section 3.6.2.2 319 o Analogous to the case for SUBSCRIBE described in [2], the agent 320 that issued the REFER MUST be prepared to receive a NOTIFY before 321 the REFER transaction completes. 323 3.6.2.2 The body of the NOTIFY 325 Each NOTIFY MUST contain a body of type "application/sip". This body 326 MUST begin with a SIP Response Status-Line as defined in [1]. The 327 response class in this status line indicates the success of the 328 referred action. The body MAY contain other SIP headers to provide 329 information about the outcome of the referenced action. 331 A minimal, but complete, implementation can respond with a single 332 NOTIFY containing either the body: 334 SIP/2.0 200 OK 336 if the reference was successful or the body: 338 SIP/2.0 503 Service Unavailable 340 if the reference failed. 342 An implementation MAY include more of a SIP message in that body to 343 convey more information. Warning headers received in responses to 344 the referred action are good candidates. In fact, if the reference 345 was to a SIP URL, the entire response to the referenced action could 346 be returned (perhaps to assist with debugging). However, doing so 347 could have grave security repercussions (see Section 3.10). 348 Implementers must carefully consider what they choose to include. 350 Note that if the reference was to a non-SIP URL, status in any 351 NOTIFYs to the referrer must still be in the form of SIP Response 352 Status-Lines. The minimal implementation discussed above is 353 sufficient to provide a basic indication of success or failure. For 354 example, if a client receives a REFER to a HTTP URL, and is 355 successful in accessing the resource, its NOTIFY to the referrer can 356 contain the application/sip body of "SIP/2.0 200 OK" 358 3.7 Behavior of SIP Registrars/Redirect Servers 360 Registrars and Redirect Servers SHOULD return a 603 to a REFER 361 request, unless they are also playing some other SIP role. 363 3.8 Behavior of SIP Proxies 365 SIP Proxies do not require modification to support the REFER method. 366 Specifically, as required by [1], a proxy should process a REFER 367 request the same way it processes an OPTIONS request. 369 3.9 Prototypical REFER callflow 371 Agent A Agent B 372 | | 373 | REFER | 374 |----------------------->| 375 | 202 Accepted | 376 |<-----------------------| 377 | | 378 | |-------> 379 | | (whatever) 380 | |<------ 381 | | 382 | NOTIFY | 383 |<-----------------------| 384 | 200 OK | 385 |----------------------->| 386 | | 387 | | 389 Here are examples of what the four messages between Agent A and Agent 390 B might look like if the reference to (whatever) that Agent B makes 391 is successful. The details of this flow indicate this particular 392 REFER occurs outside a session (there is no To: tag in the REFER 393 request). If the REFER occurs inside a session, there would be a 394 non-empty To: tag in the request. 395 Message One 396 REFER sip:b@agentland SIP/2.0 397 Via: SIP/2.0/UDP agenta.agentland 398 To: 399 From: ;tag=193402342 400 Call-ID: 898234234@agenta.agentland 401 CSeq: 93809823 REFER 402 Refer-To: (whatever URL) 403 Referred-By: ;ref=; 404 scheme=pgp;pgp-version="5.0";signature="signature goes here" 405 Contact: sip:a@agentland 406 Content-Length: 0 408 Message Two 410 SIP/2.0 202 Accepted 411 Via: SIP/2.0/UDP agenta.agentland 412 To: ;tag=4992881234 413 From: ;tag=193402342 414 Call-ID: 898234234@agenta.agentland 415 CSeq: 93809823 REFER 416 Contact: sip:b@agentland 417 Content-Length: 0 419 Message Three 421 NOTIFY sip:a@agentland SIP/2.0 422 Via: SIP/2.0/UDP agentb.agentland 423 To: ;tag=193402342 424 From: ;tag=4992881234 425 Call-ID: 898234234@agenta.agentland 426 CSeq: 1993402 NOTIFY 427 Event: refer 428 Contact: sip:b@agentland 429 Content-Type: application/sip 430 Content-Length: 16 432 SIP/2.0 200 OK 434 Message Four 435 SIP/2.0 200 OK 436 Via: SIP/2.0/UDP agentb.agentland 437 To: ;tag=193402342 438 From: ;tag=4992881234 439 Call-ID: 898234234@agenta.agentland 440 CSeq: 1993402 NOTIFY 441 Contact: sip:a@agentland 442 Content-Length: 0 444 3.10 Security Considerations 446 The security requirements of [1] apply to the REFER method. 448 This mechanism relies on providing contact information for the 449 referred-to resource to the party being referred. Care should be 450 taken to provide a suitably restricted URI if the referred to 451 resource should be protected. 453 Care should be taken when implementing the logic that determines 454 whether or not to accept the REFER request. A UA not capable of 455 accessing non-SIP URLs SHOULD NOT accept REFER requests to them. 457 Using application/sip bodies to return the progress and results of a 458 REFER request is extremely powerful. Careless use of that capability 459 will compromise security and privacy. Here are a couple of simple, 460 somewhat contrived, examples to demonstrate the potential for harm. 462 3.10.1 Circumventing privacy 464 Suppose Alice has a user-agent that accepts REFER requests to SIP 465 INVITE URLs, and NOTIFYs the referrer of the progress of the INVITE 466 by copying each response to the INVITE into the body of a NOTIFY. 468 Suppose further that Carol has a reason to avoid Mallory and has 469 configured her system at her proxy to only accept calls from a 470 certain set of people she trusts (including Alice), so that Mallory 471 doesn't learn when she's around, or what user agent she's actually 472 using. 474 Mallory can send a REFER to Alice, with a Refer-To: indicating Carol. 475 If Alice can reach Carol, the 200 OK Carol sends gets returned to 476 Mallory in a NOTIFY, letting him know not only that Carol is around, 477 but also the IP address of the agent she's using. 479 3.10.2 Circumventing security 481 Suppose Alice, with the same user agent as above, is working at a 482 company that is working on the greatest SIP device ever invented - 483 the SIP FOO. The company has been working for months building the 484 device and the marketing materials, carefully keeping the idea, even 485 the name of the idea secret (since a FOO is one of those things that 486 anybody could do if they'd just had the idea first). FOO is up and 487 running, and anyone at the company can use it, but it's not available 488 outside the company firewall. 490 Mallory has heard rumor that Alice's company is onto something big, 491 and has even managed to get his hands on a URL that he suspects might 492 have something to do with it. He sends a REFER to ALICE with the 493 mysterious URL and as Alice connects to the FOO, Mallory gets NOTIFYs 494 with bodies containing 496 Server: FOO/v0.9.7 498 3.10.3 Limiting the breach 500 For each of these cases, and in general, returning a carefully 501 selected subset of the information available about the progress of 502 the reference through the NOTIFYs mitigates risk. The minimal 503 implementation described in Section 3.6.2.2 exposes the least 504 information about what the agent operating on the REFER request has 505 done, and is least likely to be a useful tool for malicious users. 507 4. Historic Material 509 This method was initially motivated by the call-transfer application. 510 Starting as TRANSFER, and later generalizing to REFER, this method 511 improved on the BYE/Also concept of the now expired draft-ietf-sip- 512 cc-01 by disassociating transfers from the processing of BYE. These 513 changes facilitate recovery of failed transfers and clarify state 514 management in the participating entities. 516 Earlier versions of this work required the agent responding to REFER 517 to wait until the referred action completed before sending a final 518 response to the REFER. That final response reflected the success or 519 failure of the referred action. This was infeasible due to the 520 transaction timeout rules defined for non-INVITE requests in [1]. A 521 REFER must always receive an immediate (within the lifetime of a non- 522 INVITE transaction) final response. 524 5. Open Issues 526 5.1 REFER is now dependent on sip-events 528 This work is prevented from moving to RFC until the sip-events draft 529 moves to that level. 531 5.2 Registering the refer event with IANA 533 When we near the end of the process, the refer event will need to be 534 registered with IANA per [2]. 536 6. Acknowledgments 538 This draft is a collaborative product of the SIP working group. 540 References 542 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 543 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 545 [2] Roach, A., "SIP-Specific Event Notification", draft-sip-events- 546 00 (work in progress), July 2001. 548 Author's Address 550 Robert J. Sparks 551 dynamicsoft 552 5100 Tennyson Parkway 553 Suite 1200 554 Plano, TX 75024 556 EMail: rsparks@dynamicsoft.com 558 Full Copyright Statement 560 Copyright (C) The Internet Society (2001). All Rights Reserved. 562 This document and translations of it may be copied and furnished to 563 others, and derivative works that comment on or otherwise explain it 564 or assist in its implementation may be prepared, copied, published 565 and distributed, in whole or in part, without restriction of any 566 kind, provided that the above copyright notice and this paragraph are 567 included on all such copies and derivative works. However, this 568 document itself may not be modified in any way, such as by removing 569 the copyright notice or references to the Internet Society or other 570 Internet organizations, except as needed for the purpose of 571 developing Internet standards in which case the procedures for 572 copyrights defined in the Internet Standards process must be 573 followed, or as required to translate it into languages other than 574 English. 576 The limited permissions granted above are perpetual and will not be 577 revoked by the Internet Society or its successors or assigns. 579 This document and the information contained herein is provided on an 580 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 581 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 582 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 583 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 584 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 586 Acknowledgement 588 Funding for the RFC Editor function is currently provided by the 589 Internet Society.