idnits 2.17.1 draft-ietf-opes-protocol-reqs-03.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The OPES callout protocol SHOULD be application protocol-agnostic, i.e. it SHOULD not make any assumptions about the characteristics of the application-layer protocol used on the data path between data provider and data consumer. At a minimum, the callout protocol MUST be compatible with HTTP [5]. -- 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 (December 12, 2002) is 7777 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) ** Downref: Normative reference to an Informational draft: draft-ietf-opes-architecture (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '3') ** Obsolete normative reference: RFC 2616 (ref. '5') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '6') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '7') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '8') (Obsoleted by RFC 3550) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services A. Beck 3 Internet-Draft M. Hofmann 4 Expires: June 12, 2003 Lucent Technologies 5 H. Orman 6 Purple Streak Development 7 R. Penno 8 Nortel Networks 9 A. Terzis 10 Individual Consultant 11 December 12, 2002 13 Requirements for OPES Callout Protocols 14 draft-ietf-opes-protocol-reqs-03 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 12, 2003. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 This document specifies the requirements that the OPES (Open 46 Pluggable Edge Services) callout protocol must satisfy in order to 47 support the remote execution of OPES services. The requirements are 48 intended to help evaluating possible protocol candidates as well as 49 to guide the development of such protocols. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Functional Requirements . . . . . . . . . . . . . . . . . . 5 56 3.1 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2 Congestion Avoidance . . . . . . . . . . . . . . . . . . . . 5 58 3.3 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5 59 3.4 Callout Connections . . . . . . . . . . . . . . . . . . . . 6 60 3.5 Asynchronous Message Exchange . . . . . . . . . . . . . . . 6 61 3.6 Message Segmentation . . . . . . . . . . . . . . . . . . . . 7 62 3.7 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 7 63 3.8 Operation in NAT Environments . . . . . . . . . . . . . . . 8 64 3.9 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 8 65 3.10 Multiple OPES Processors . . . . . . . . . . . . . . . . . . 8 66 3.11 Support for Different Application Protocols . . . . . . . . 8 67 3.12 Capability and Parameter Negotiations . . . . . . . . . . . 8 68 3.13 Meta Data and Instructions . . . . . . . . . . . . . . . . . 9 69 4. Performance Requirements . . . . . . . . . . . . . . . . . . 11 70 4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11 71 5. Security Requirements . . . . . . . . . . . . . . . . . . . 12 72 5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12 73 5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12 74 5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12 75 5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 77 Normative References . . . . . . . . . . . . . . . . . . . . 15 78 Informative References . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 80 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 81 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 Intellectual Property and Copyright Statements . . . . . . . 21 84 1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [2]. 90 2. Introduction 92 The Open Pluggable Edge Services (OPES) architecture [1] enables 93 cooperative application services (OPES services) between a data 94 provider, a data consumer, and zero or more OPES processors. The 95 application services under consideration analyze and possibly 96 transform application-level messages exchanged between the data 97 provider and the data consumer. 99 The execution of such services is governed by a set of rules 100 installed on the OPES processor. The rules enforcement can trigger 101 the execution of service applications local to the OPES processor. 102 Alternatively, the OPES processor can distribute the responsibility 103 of service execution by communicating and collaborating with one or 104 more remote callout servers. As described in [1], an OPES processor 105 communicates with and invokes services on a callout server by using a 106 callout protocol. This document presents the requirements for such a 107 protocol. 109 The requirements in this document are divided into three categories - 110 functional requirements, performance requirements, and security 111 requirements. Each requirement is presented as one or more 112 statements, followed by brief explanatory material as appropriate. 114 3. Functional Requirements 116 3.1 Reliability 118 The OPES callout protocol MUST be able to provide ordered reliability 119 for the communication between OPES processor and callout server. 120 Additionally, the callout protocol SHOULD be able to provide 121 unordered reliability. 123 In order to satisfy the reliability requirements, the callout 124 protocol SHOULD specify that it must be used with a transport 125 protocol which provides ordered/unordered reliability at the 126 transport-layer, for example TCP [6] or SCTP [7]. 128 3.2 Congestion Avoidance 130 The OPES callout protocol MUST ensure that congestion avoidance that 131 matches the standard of RFC 2914 [4] is applied on all communication 132 between OPES processor and callout server. For this purpose, the 133 callout protocol SHOULD use a congestion-controlled transport-layer 134 protocol, presumably either TCP [6] or SCTP [7]. 136 3.3 Callout Transactions 138 The OPES callout protocol MUST enable an OPES processor and a callout 139 server to perform callout transactions with the purpose of exchanging 140 partial or complete application-level protocol messages (or 141 modifications thereof). More specifically, the callout protocol MUST 142 enable an OPES processor to forward a partial or complete application 143 message to a callout server so that one or more OPES services can 144 process the forwarded application message (or parts thereof). The 145 result of the service operation may be a modified application 146 message. The callout protocol MUST therefore enable the callout 147 server to return a modified application message or the modified parts 148 of an application message to the OPES processor. Additionally, the 149 callout protocol MUST enable a callout server to report back to the 150 OPES processor the result of a callout transaction, e.g. in the form 151 of a status code. 153 A callout transaction is defined as a message exchange between an 154 OPES processor and a callout server consisting of a callout request 155 and a callout response. Both, the callout request as well as the 156 callout response, MAY each consist of one or more callout protocol 157 messages, i.e. a series of protocol messages. A callout request 158 MUST always contain a partial or complete application message. A 159 callout response MUST always indicate the result of the callout 160 transaction. A callout response MAY contain a modified application 161 message. 163 Callout transactions are always initiated by a callout request from 164 an OPES processor and typically terminated by a callout response from 165 a callout server. The OPES callout protocol MUST, however, also 166 provide a mechanism that allows either endpoint of a callout 167 transaction to terminate a callout transaction before a callout 168 request or response has been completely received by the corresponding 169 callout endpoint. Such a mechanism MUST ensure that a premature 170 termination of a callout transaction does not result in the loss of 171 application message data. 173 A premature termination of a callout transaction is required to 174 support OPES services which may terminate even before they have 175 processed the entire application message. Content analysis services, 176 for example, may be able to classify a Web object after having 177 processed just the first few bytes of a Web object. 179 3.4 Callout Connections 181 The OPES callout protocol MUST enable an OPES processor and a callout 182 server to perform multiple callout transactions over a callout 183 connection. Additionally, the callout protocol MUST provide a method 184 to associate callout transactions with callout connections. A 185 callout connection is defined as a logical connection at the 186 application-layer between an OPES processor and a callout server. A 187 callout connection MAY have certain parameters associated with it, 188 for example parameters that control the fail-over behavior of 189 connection endpoints. Callout connection-specific parameters MAY be 190 negotiated between OPES processors and callout servers (see Section 191 3.12). 193 The OPES callout protocol MAY choose to multiplex multiple callout 194 connections over a single transport-layer connection so long as a 195 flow control mechanism is applied which guarantees fairness among 196 multiplexed callout connections. 198 Callout connections MUST always be initiated by an OPES processor. A 199 callout connection MAY be closed by either endpoint of the connection 200 provided that doing so does not affect the normal operation of 201 on-going callout transactions associated with the callout connection. 203 3.5 Asynchronous Message Exchange 205 The OPES callout protocol MUST support an asynchronous message 206 exchange over callout connections. 208 In order to allow asynchronous processing on the OPES processor and 209 callout server, it MUST be possible to separate request issuance from 210 response processing. The protocol MUST therefore allow multiple 211 outstanding callout requests and provide a method to correlate 212 callout responses to callout requests. 214 Additionally, the callout protocol MUST enable a callout server to 215 respond to a callout request before it has received the entire 216 request. 218 3.6 Message Segmentation 220 The OPES callout protocol MUST allow an OPES processor to forward an 221 application message to a callout server in a series of smaller 222 message fragments. The callout protocol MUST further enable the 223 receiving callout server to re-assemble the fragmented application 224 message. 226 Likewise, the callout protocol MUST enable a callout server to return 227 an application message to an OPES processor in a series of smaller 228 message fragments. The callout protocol MUST enable the receiving 229 OPES processor to re-assemble the fragmented application message. 231 Depending on the application-layer protocol used on the data path, 232 application messages may be very large in size (for example in the 233 case of audio/video streams) or of unknown size. In both cases, the 234 OPES processor has to initiate a callout transaction before it has 235 received the entire application message to avoid long delays for the 236 data consumer. The OPES processor MUST therefore be able to forward 237 fragments or chunks of an application message to a callout server as 238 it receives them from the data provider or consumer. Likewise, the 239 callout server MUST be able to process and return application message 240 fragments as it receives them from the OPES processor. 242 Application message segmentation is also required if the OPES callout 243 protocol provides a flow control mechanism in order to multiplex 244 multiple callout connections over a single transport-layer connection 245 (see Section 3.4). 247 3.7 Support for Keep-Alive Mechanism 249 The OPES callout protocol MUST provide a keep-alive mechanism which, 250 if used, would allow both endpoints of a callout connection to detect 251 a failure of the other endpoint even in the absence of callout 252 transactions. The callout protocol MAY specify that keep-alive 253 messages be exchanged over existing callout connections or a separate 254 connection between OPES processor and callout server. The callout 255 protocol MAY also specify that the use of the keep-alive mechanism is 256 optional. 258 The detection of a callout server failure may enable an OPES 259 processor to establish a callout connection with a stand-by callout 260 server so that future callout transactions do not result in the loss 261 of application message data. The detection of the failure of an OPES 262 processor may enable a callout server to release resources which 263 would otherwise not be available for callout transactions with other 264 OPES processors. 266 3.8 Operation in NAT Environments 268 The OPES protocol SHOULD be NAT-friendly, i.e. its operation should 269 not be compromised by the presence of one or more NAT devices in the 270 path between an OPES processor and a callout server. 272 3.9 Multiple Callout Servers 274 The OPES callout protocol MUST allow an OPES processor to 275 simultaneously communicate with more than one callout server. 277 In larger networks, OPES services are likely to be hosted by 278 different callout servers. Therefore, an OPES processor will likely 279 have to communicate with multiple callout servers. The protocol 280 design MUST enable an OPES processor to do so. 282 3.10 Multiple OPES Processors 284 The OPES callout protocol MUST allow a callout server to 285 simultaneously communicate with more than one OPES processor. 287 The protocol design MUST support a scenario in which multiple OPES 288 processors use the services of a single callout server. 290 3.11 Support for Different Application Protocols 292 The OPES callout protocol SHOULD be application protocol-agnostic, 293 i.e. it SHOULD not make any assumptions about the characteristics of 294 the application-layer protocol used on the data path between data 295 provider and data consumer. At a minimum, the callout protocol MUST 296 be compatible with HTTP [5]. 298 The OPES entities on the data path may use different 299 application-layer protocols, including, but not limited to, HTTP [5] 300 and RTP [8]. It would be desirable to be able to use the same OPES 301 callout protocol for any such application-layer protocol. 303 3.12 Capability and Parameter Negotiations 305 The OPES callout protocol MUST support the negotiation of 306 capabilities and callout connection parameters between an OPES 307 processor and a callout server. This implies that the OPES processor 308 and the callout server MUST be able to exchange their capabilities 309 and preferences and engage into a deterministic negotiation process 310 at the end of which the two endpoints have either agreed on the 311 capabilities and parameters to be used for future callout 312 connections/transactions or determined that their capabilities are 313 incompatible. 315 Capabilities and parameters that could be negotiated between an OPES 316 processor and a callout server include (but are not limited to): 317 callout protocol version, fail-over behavior, heartbeat rate for 318 keep-alive messages, security-related parameters etc. 320 The callout protocol MUST NOT negotiate the transport protocol to be 321 used for callout connections. The callout protocol MAY, however, 322 specify that a certain application message protocol (e.g. HTTP [5], 323 RTP [8]) requires the use of a certain transport protocol (e.g. TCP 324 [6], SCTP [7]). 326 Callout connection parameters may also pertain to the characteristics 327 of OPES callout services if, for example, callout connections are 328 associated with one or more specific OPES services. An OPES 329 service-specific parameter may, for example, specify which parts of 330 an application message an OPES service requires for its operation. 332 Callout connection parameters MUST be negotiated on a per-callout 333 connection basis and before any callout transactions are performed 334 over the corresponding callout connection. Other parameters and 335 capabilities, such as the fail-over behavior, MAY be negotiated 336 between the two endpoints independently of callout connections. 338 The parties to a callout protocol MAY use callout connections to 339 negotiate all or some of their capabilities and parameters. 340 Alternatively, a separate control connection MAY be used for this 341 purpose. 343 3.13 Meta Data and Instructions 345 The OPES callout protocol MUST provide a mechanism for the endpoints 346 of a particular callout transaction to include in callout requests 347 and responses meta data and instructions for the OPES processor or 348 callout server. 350 Specifically, the callout protocol MUST enable an OPES processor to 351 include information about the forwarded application message in a 352 callout request, e.g. in order to specify the type of the forwarded 353 application message or to specify what part(s) of the application 354 message are forwarded to the callout server. Likewise, the callout 355 server MUST be able to include information about the returned 356 application message. 358 The OPES processor MUST further be able to include an ordered list of 359 one or more uniquely specified OPES services which are to be 360 performed on the forwarded application message in the specified 361 order. However, as the callout protocol MAY also choose to associate 362 callout connections with specific OPES services, there may not be a 363 need to identify OPES services on a per-callout transaction basis. 365 Additionally, the OPES callout protocol MUST allow the callout server 366 to indicate to the OPES processor the cacheability of callout 367 responses. This implies that callout responses may have to carry 368 cache-control instructions for the OPES processor. 370 The OPES callout protocol MUST further enable the OPES processor to 371 indicate to the callout server if it has kept a local copy of the 372 forwarded application message (or parts thereof). This information 373 enables the callout server to determine whether the forwarded 374 application message must be returned to the OPES processor even it 375 has not been modified by an OPES service. 377 The OPES callout protocol MUST also allow OPES processors to comply 378 with the tracing requirements of the OPES architecture as laid out in 379 [1] and [3]. This implies that the callout protocol MUST enable a 380 callout server to convey to the OPES processor information about the 381 OPES service operations performed on the forwarded application 382 message. 384 4. Performance Requirements 386 4.1 Protocol Efficiency 388 The OPES callout protocol SHOULD be efficient in that it minimizes 389 the additionally introduced latency, for example by minimizing the 390 protocol overhead. 392 As OPES callout transactions introduce additional latency to 393 application protocol transactions on the data path, callout protocol 394 efficiency is crucial. 396 5. Security Requirements 398 In the absence of any security mechanisms, sensitive information 399 might be communicated between the OPES processor and the callout 400 server in violation of either endpoint's security and privacy policy 401 through misconfiguration or a deliberate insider attack. By using 402 strong authentication, message encryption, and integrity checks, this 403 threat can be minimized to a smaller set of insiders and/or operator 404 configuration errors. 406 The OPES processor and the callout servers SHOULD have enforceable 407 policies that limit the parties they communicate with, that determine 408 the protections to use based on identities of the endpoints and other 409 data (such as enduser policies). In order to enforce the policies, 410 they MUST be able to authenticate the callout protocol endpoints 411 using cryptographic methods. 413 5.1 Authentication, Confidentiality, and Integrity 415 The parties to the callout protocol MUST have a sound basis for 416 binding authenticated identities to the protocol endpoints, and they 417 MUST verify that these identities are consistent with their security 418 policies. 420 The OPES callout protocol MUST provide for message authentication, 421 confidentiality, and integrity between the OPES processor and the 422 callout server. It MUST provide mutual authentication. For this 423 purpose, the callout protocol SHOULD use existing security 424 mechanisms. The callout protocol specification is not required to 425 specify the security mechanisms, but it MAY instead refer to a 426 lower-level security protocol and discuss how its mechanisms are to 427 be used with the callout protocol. 429 5.2 Hop-by-Hop Confidentiality 431 If end-to-end encryption is a requirement for the content path, then 432 this confidentiality MUST be extended to the communication between 433 the OPES processor and the callout server. While it is recommended 434 that the communication between OPES processor and callout server 435 always be encrypted, encryption MAY be optional if both the OPES 436 processor and the callout server are co-located with each other in a 437 single administrative domain with strong confidentiality guarantees. 439 In order to minimize data exposure, the callout protocol MUST use a 440 different encryption key for each encrypted content stream. 442 5.3 Operation Across Un-trusted Domains 443 The OPES callout protocol MUST operate securely across un-trusted 444 domains between the OPES processor and the callout server. 446 If the communication channels between the OPES processor and callout 447 server cross outside of the organization taking responsibility for 448 the OPES services, then endpoint authentication and message 449 protection (confidentiality and integrity) MUST be used. 451 5.4 Privacy 453 Any communication carrying information relevant to privacy policies 454 MUST protect the data using encryption. 456 6. Security Considerations 458 The security requirements for the OPES callout protocol are discussed 459 in Section 5. 461 Normative References 463 [1] Barbir, A., "An Architecture for Open Pluggable Edge Services 464 (OPES)", draft-ietf-opes-architecture-04 (work in progress), 465 December 2002. 467 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 468 Levels", RFC 2119, March 1997. 470 [3] Floyd, S. and L. Daigle, "IAB Architectural and Policy 471 Considerations for Open Pluggable Edge Services", RFC 3238, 472 January 2002. 474 [4] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, 475 September 2000. 477 [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 478 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 479 HTTP/1.1", RFC 2616, June 1999. 481 Informative References 483 [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 484 September 1981. 486 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 487 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 488 "Stream Control Transmission Protocol", RFC 2960, October 2000. 490 [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 491 "RTP: A Transport Protocol for Real-Time Applications", RFC 492 1889, January 1996. 494 Authors' Addresses 496 Andre Beck 497 Lucent Technologies 498 101 Crawfords Corner Road 499 Holmdel, NJ 07733 500 US 502 EMail: abeck@bell-labs.com 504 Markus Hofmann 505 Lucent Technologies 506 Room 4F-513 507 101 Crawfords Corner Road 508 Holmdel, NJ 07733 509 US 511 Phone: +1 732 332 5983 512 EMail: hofmann@bell-labs.com 514 Hilarie Orman 515 Purple Streak Development 517 EMail: ho@alum.mit.edu 518 URI: http://www.purplestreak.com 519 Reinaldo Penno 520 Nortel Networks 521 2305 Mission College Boulevard 522 San Jose, CA 95134 523 US 525 EMail: rpenno@nortelnetworks.com 527 Andreas Terzis 528 Individual Consultant 529 150 Golf Course Dr. 530 Rohnert Park, CA 94928 531 US 533 Phone: +1 707 586 8864 534 EMail: aterzis@sbcglobal.net 536 Appendix A. Acknowledgments 538 This document is based in parts on previous work by Anca Dracinschi 539 Sailer, Volker Hilt, and Rama R. Menon. 541 The authors would like to thank the participants of the OPES WG for 542 their comments on this draft. 544 Appendix B. Change Log 546 Changes from draft-ietf-opes-protocol-reqs-02.txt 548 o Re-ordered some sections in the functional requirements part of 549 the draft 551 o Clarified in Section 3.3 what callout requests and responses must/ 552 may contain 554 o Removed reference to explicit and implicit mechanism of 555 terminating a callout transaction prematurely in Section 3.3 557 o Added reference to RFC 2914 in congestion avoidance requirement in 558 Section 3.2 560 o Added language that states that existing solutions should be used 561 to achieve congestion avoidance and ordered/unordered reliability 562 in Section 3.2 and Section 3.1 564 o Clarified concept of callout connections (previously referred to 565 as "callout channels") in Section 3.4 567 o Added statement about the possibility of multiplexing multiple 568 callout connections over a transport connection to Section 3.4 570 o Clarified in Section 3.7 that use of a keep-alive mechanism is 571 optional 573 o Replaced "MUST" with "SHOULD" in OCP requirement to be application 574 protocol-agnostic in Section 3.11, added explicit requirement to 575 support HTTP 577 o Removed "transport protocol" from list of callout parameters which 578 may be negotiated, added suggestion to pick transport protocol 579 depending on the application protocol in Section 3.12. 581 o Explained that application message segementation is also necessary 582 for multiplexing callout connections over transport connections in 583 Section 3.6 585 o Added statement to Section 5.2 that encryption between OPES 586 processor and callout server may be optional if they are 587 co-located with each other in a single administrative domain 589 Changes from draft-ietf-opes-protocol-reqs-01.txt 590 o Reworded and clarified several statements of the draft 592 Changes from draft-ietf-opes-protocol-reqs-00.txt 594 o Aligned terminology with [1] 596 o Clarified in Section 3.13 that OCP requests not only have to 597 identify one or more OPES services, but also the order in which 598 the services are to be executed 600 o Removed requirement from Section 4.1 that OCP must satisfy 601 performance requirements of the application-layer protocol used 602 between data consumer and provider 604 Intellectual Property Statement 606 The IETF takes no position regarding the validity or scope of any 607 intellectual property or other rights that might be claimed to 608 pertain to the implementation or use of the technology described in 609 this document or the extent to which any license under such rights 610 might or might not be available; neither does it represent that it 611 has made any effort to identify any such rights. Information on the 612 IETF's procedures with respect to rights in standards-track and 613 standards-related documentation can be found in BCP-11. Copies of 614 claims of rights made available for publication and any assurances of 615 licenses to be made available, or the result of an attempt made to 616 obtain a general license or permission for the use of such 617 proprietary rights by implementors or users of this specification can 618 be obtained from the IETF Secretariat. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights which may cover technology that may be required to practice 623 this standard. Please address the information to the IETF Executive 624 Director. 626 Full Copyright Statement 628 Copyright (C) The Internet Society (2002). All Rights Reserved. 630 This document and translations of it may be copied and furnished to 631 others, and derivative works that comment on or otherwise explain it 632 or assist in its implementation may be prepared, copied, published 633 and distributed, in whole or in part, without restriction of any 634 kind, provided that the above copyright notice and this paragraph are 635 included on all such copies and derivative works. However, this 636 document itself may not be modified in any way, such as by removing 637 the copyright notice or references to the Internet Society or other 638 Internet organizations, except as needed for the purpose of 639 developing Internet standards in which case the procedures for 640 copyrights defined in the Internet Standards process must be 641 followed, or as required to translate it into languages other than 642 English. 644 The limited permissions granted above are perpetual and will not be 645 revoked by the Internet Society or its successors or assignees. 647 This document and the information contained herein is provided on an 648 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 649 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 650 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 651 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 652 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Acknowledgement 656 Funding for the RFC Editor function is currently provided by the 657 Internet Society.