RFC 3914

Open Pluggable Edge Services (OPES) Treatment of IAB Considerations

📅 published October 2004, from ietf

RFC 3914 🎀 Part 1 of 3

Network Working Group ✨

RFC 3914, Informational, October 2004 🌸

Authors: A. Barbir from Nortel Networks 💅 and A. Rousskov from The Measurement Factory 🫶

Obsoletes and updates: none listed in the header 🙈

Okay bestie, this one is titled Open Pluggable Edge Services (OPES) Treatment of IAB Considerations 🦋 It's an Informational doc, so it's giving "here's some info," not "you must do this" 💅 It came out in October 2004 and it does not list anything it obsoletes or updates 🧚

Status of this Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 💖

Copyright Notice ©️

Abstract ✨

The IETF Internet Architecture Board (IAB) came up with nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework 👑 This document is basically the receipts showing how OPES handles each one 🧾💅

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Consideration (2.1) 'One-party consent'  . . . . . . . . . . .  3
4.  Consideration (2.2) 'IP-layer communications'  . . . . . . . .  4
5.  Notification Considerations  . . . . . . . . . . . . . . . . .  5
    5.1.  Notification versus trace. . . . . . . . . . . . . . . .  6
    5.2.  An example of an OPES trace for HTTP . . . . . . . . . .  8
    5.3.  Consideration (3.1) 'Notification' . . . . . . . . . . .  9
    5.4.  Consideration (3.2) 'Notification' . . . . . . . . . . . 10
6.  Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 10
7.  Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 11
8.  Consideration (4.2) 'Reference validity' . . . . . . . . . . . 11
9.  Consideration (4.3) 'Addressing extensions'  . . . . . . . . . 12
10. Consideration (5.1) 'Privacy'  . . . . . . . . . . . . . . . . 12
11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 12
12. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
    14.1. Normative References . . . . . . . . . . . . . . . . . . 14
    14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16

1. Introduction 🦋

Okay so the Open Pluggable Edge Services (OPES) architecture [RFC3835] is all about cooperative application services, called OPES services 🫶 These run between a data provider, a data consumer, and zero or more OPES processors. The services analyze and possibly transform application-level messages that get swapped between the data provider and the data consumer 💅

So when OPES was getting chartered, the IAB dropped some recommendations on the stuff OPES solutions should be required to address 👀 Those recs got written up in a specific IAB considerations document [RFC3238]. Here's the tea: the IAB stressed that its considerations did NOT recommend specific solutions and did NOT mandate specific functional requirements 🙈 Addressing one can mean showing the right protocol mechanisms, or proving the issue just doesn't apply to you 💖 And addressing a consideration does not necessarily mean supporting whatever technology the wording seems to imply 🧚

The main goal of this doc is to show that every formal IAB recommendation is addressed by OPES, as far as an IETF working group can actually address them 🔥 The doc also spells out, very explicitly, the limits of what the OPES working group can do for certain parts of the IAB considerations 🌈 Honesty era, bestie 🫶

The IAB considerations document [RFC3238] also has a bunch of informal recommendations 📝 For example, the IAB informally wants the OPES architecture to "protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries" 😭 But the IAB went and formalized these into more specific recommendations, like the Notification considerations we'll get to in Section 5.3 and Section 5.4 below 💅 So the OPES framework handles the informal recommendations by addressing the formal considerations that match them 🎀

There are nine formal IAB considerations [RFC3238] that OPES has to address 👑 The core of this document is nine "Consideration" sections, one for each. Each section has general discussion, plus references to the specific OPES mechanisms that matter for that consideration 🧚✨

2. Terminology 📖

This document does not introduce any new terminology 🙅‍♀️ It just borrows terminology from other OPES documents 💜

Here's the IAB consideration, quoted directly 👇

"An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client)." [RFC3238]

Now the OPES architecture says that "OPES processors MUST be consented to by either the data consumer or data provider application" [RFC3835] ✅ That requirement directly satisfies the IAB concern, ngl 💅 BUT here's the catch: no requirement on its own can stop consent-less introduction of OPES processors 💀 In other words, the OPES framework requires one-party consent, but it cannot guarantee it when there are incompliant OPES entities around 🙈

Next, [RFC3897] says the OPES architecture lets concerned parties detect unwanted OPES processors by looking at OPES traces 🔍 Still, a tracing mechanism alone can't catch processors that violate OPES specifications 😤 Stealth mode processors are one example of that 🥷 However, the OPES architecture does allow content signatures to verify that the adaptations performed are authentic 🔐 Content signatures are a strong mechanism, but they're expensive 💸 They can detect any modification of signed content, as long as the content provider is willing to sign the data and the client is willing to either check the signature or relay the received content to the content provider for signature verification 🫶

Also, OPES entities can copy or otherwise access content without modifying it 👀 Content signatures can't detect that kind of access 😭 So "passive" OPES entities can operate on signed content without the consent of the data consumer or provider 💀 If content privacy is a concern, content encryption can be used 🔒 A passive processor is no different from any intermediary operating outside the OPES framework 🧚 And no OPES mechanism, existing or foreseeable, can prevent non-modifying access to content 🙅‍♀️

Okay, the summary: one-party consent is satisfied by including the corresponding requirement in the IAB architecture document 🎀 That requirement alone can't stop incompliant OPES entities from doing consent-less adaptations 😤 But the OPES framework does allow various ways of detecting and/or preventing those adaptations ✨ These ways typically add overhead and need some level of cooperation between producer and consumer 💅

4. Consideration (2.2) 'IP-layer communications' 🌸

Quoted from the IAB 👇

"For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user" [RFC3238].

The OPES architecture says that "OPES processors MUST be addressable at the IP layer by the end user (data consumer application)" [RFC3835] 🦋 The IAB and the architecture docs call out one important exception: addressing the first OPES processor in a chain is enough 🔗 So a chain of OPES processors is viewed as a single OPES "system" sitting at the address of its first chain element 🧚

The IAB doesn't strictly define what a chain is 🤷‍♀️ For the purpose of addressing this consideration, the doc looks at a group of OPES processors working on a given application transaction 💅 That group would necessarily form a single processing chain, with a single "exit" OPES processor, meaning the processor that adapted the given message last 👑 The OPES architecture basically requires that last OPES processor to be explicitly addressable at the IP layer by the data consumer application 🫶 How the chain forms, including its exit point, may depend on the application message and other dynamic factors, like time of day or system load ⏰

Now, if OPES processing is an internal step on the data consumer's or data provider's application side, the last OPES processor might live in a private address space and not be explicitly addressable from outside 🏠 In that case, the processing side has to designate an addressable point on the same processing chain 🎯 That designated point may not be, strictly speaking, an OPES processor, but it will do the job for IAB considerations 💖 The data consumer application will be able to address it explicitly at the IP layer, and it will represent the OPES processing chain to the outside world 🌍

Designating an addressable processing point clears up the conflict between a narrow reading of the IAB consideration and real system designs 🧩 It's honestly irrational to expect a content provider to give access to internal hosts that take part in content generation, whether OPES processors are involved or not 🙄 Giving that access wouldn't even help much, because internal OPES processors probably can't answer any data consumer queries, since they're totally out of the content generation context 🤷‍♀️ For example, an OPES processor that adds customer-specific information to XML pages may not understand or be aware of the final HTML content the data consumer application gets, and it may not be able to map an end user request to any internal user identification 💅 Since OPES requires the end of the message processing chain to be addressable, the conflict just doesn't exist 🙌 OPES puts no requirements on the internal architecture of data producer systems, while requiring the entire OPES-related content production "system" to be addressable at the IP layer 🎀

Here's the diagram 👇

Private Domain    | Public Domain     | Private Domain
                  |                   |
+--------------+  |             +-------------+      +--------+
| Data         |  |             | OPES System |      |Data    |
| Consumer     |<--- network -->| with public |<---->|Provider|
| Application  |  |             | IP address  |      |App     |
+--------------+  |             +-------------+      +--------+
                  |                   |
                  |                   |

Figure 1 🖼️

5. Notification Considerations 🔔

This section talks about how the OPES framework addresses IAB Notification considerations 3.1 and 3.2 🫶

5.1. Notification versus trace 🦋

Okay bestie, before we get into the specific considerations we need to untangle IAB notifications from OPES tracing. OPES is all about tracing rather than notification 💅. The OPES Communications spec [RFC3897] defines an "OPES trace" as application message information about the OPES entities that adapted the message. So the trace follows the application message around, and it's meant for the recipient of that message. Traces get built as extensions of the application protocols being adapted and traced 🧚.

Provider notification (the thing the IAB had in mind) is different. It tells the sender of the application message, not the recipient, so notifications travel in the opposite direction from traces 🔄. Supporting notifications directly would need a brand-new protocol. Figure 2 shows the difference between a trace and a notification from one application message's point of view:

sender --[message A]--> OPES --[message A']--> recipient
   ^                       V                             [with trace]
   |                       |
   +-<-- [notification] ---+

                             Figure 2

Here's the vibe check 😭. Notifications can't be piggy-backed onto application messages, so they create new messages and might double how many messages the sender has to process. It gets worse if several intermediaries on the message path each generate notifications. Tying notifications to application messages might mean copying application message info into the notifications, and maybe keeping sender state around until the notification arrives. All of that adds performance overhead, and nobody wants that 🙈.

Then there's the question of how much detail goes into notifications versus how interested providers are in getting them at all. Experience shows content providers often want really detailed info about user actions before they care about notifications. The Hit Metering protocol [RFC2227] is a good example. It was designed to give content providers proxy cache hit counts, which was supposed to cut down on the cache busting that happened because providers wanted accurate "access counts" 🍓. Even so, Hit Metering isn't widely deployed, because it doesn't give providers stuff like client IP addresses, browser versions, or cookies.

Hit Metering is relevant here because it was designed to do for HTTP caching intermediaries what OPES notifications are meant to do for OPES intermediaries 👑. Performance needs push for reducing state by aggregating notifications, while provider preferences push for preserving or duplicating state. When the two sides belong to different organizations and have different optimization priorities, finding the right balance might be impossible 💀.

So instead of building notifications into the protocol level, OPES focuses on tracing facilities. Basically, OPES supports notifications indirectly, through tracing 🌸. The IAB's "Notification" label gets read as "Notification assistance" (making notifications meaningful), not as a "Notification protocol" ✨.

All of these concerns mean notification should be optional 🎀. The OPES architecture still leaves room for an efficient and meaningful notification protocol in certain OPES environments. For example, an OPES callout server attached to a gateway or firewall might scan outgoing traffic for signs of worm or virus activity, then notify a local Intrusion Detection System (IDS) about potentially compromised hosts (servers or client PCs) inside the network. Those notifications can use OPES tracing info to pinpoint the infected host, which could itself be another OPES entity. In this case the notifications basically go back to the content producer (the local network) and use OPES tracing to supply the details 🔥.

Content Delivery Networks (CDNs) are another place where efficient, meaningful notification with OPES tracing works 🌈. A CDN node might use several content adaptation services to customize generic content from the content producer (a web site). For example, a callout service might insert advertisements for client-local events. The CDN node itself might not understand the specifics of the ad insertion algorithm running on those callout servers. It can still use info in the OPES trace (for example, from the callout service) to notify the content producer. Those notifications could be about how many ads were inserted (the number of "impressions" delivered to the customer), or even how many ad "clicks" the customer made (say, if the node hosts content linked from the ads) 🛍️. Callout services doing ad insertion might not have the details, like a customer ID/address or a web server authentication token, needed to contact the content producer directly. So the OPES trace made by an OPES service becomes essential for the meaningful notifications the CDN node sends to the content producer 💖.

5.2. An example of an OPES trace for HTTP 🎀

Let's look at an example of adaptations to an HTTP request at an OPES processor run by the client ISP 🧁. We show both the original request (as sent by an end user) and the adapted one (as received by the origin web server). The main adaptation is changing the HTTP "Accept" header. The secondary one is adding an OPES-System HTTP extension header [I-D.ietf-opes-http].

Here's the original request:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain

Figure 3

... and it may get adapted by an ISP OPES system into this:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8
OPES-System: http://www.isp-example.com/opes/?client-hash=1234567

Figure 4

Next up is an adaptation to an HTTP response at an OPES intermediary run by a Content Distribution Network (CDN) 🌷. Again we see both the original response (as sent by the origin web server) and the adapted one (as received by the end user). The main adaptation converts HTML markup to plain text, and the secondary one adds an OPES-System HTTP extension header.

Original response:

HTTP/1.1 200 OK
Content-Length: 12345
Content-Encoding: text/html

<html><head><h1>Available Documenta...

Figure 5

... which may get adapted by a CDN OPES system into:

HTTP/1.1 200 OK
Content-Length: 2345
Content-Encoding: text/plain
OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t

AVAILABLE DOCUMENTA...

Figure 6

In these examples, the OPES-System header values are URIs that can point to OPES-specific documents, like a description of the OPES operator and its privacy policy 📜. Those documents can be parameterized for customizations specific to the transaction being traced. For instance, a client or even a transaction identifier can be used to give more info about the adaptations performed 🔍. An OPES-Via header can be used to give a more detailed trace of the specific OPES entities inside an OPES System that adapted the message. Traced OPES URIs may later be used to request OPES bypass [RFC3897] 🦋.

5.3. Consideration (3.1) 'Notification' 💅

"The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider" [RFC3238].

OPES tracing mechanisms help content providers detect client-centric actions by OPES intermediaries 🕵️‍♀️. Specifically, a compliant OPES intermediary or system lets a content provider know it's there by including its tracing info in the application protocol requests. An OPES system MUST leave its trace [RFC3897] 🫶. Detection help does have limits, though. Some OPES intermediaries only work on responses, so they might never get a chance to trace the request. Also, some application protocols don't have explicit requests at all (for example, a content push service) 😬.

OPES tracing mechanisms also help content providers respond to client-centric actions by OPES intermediaries 🔥. Specifically, OPES traces MUST include identification of OPES systems, and they SHOULD include a list of the adaptation actions performed on the provider's content 📋. This tracing info may be included in the application request. Usually, though, it ends up in the application response, and an adapted version of that response never reaches the content provider 😭. If OPES end points cooperate, notification can be assisted with traces. Content providers who suspect or run into difficulties can do any of the following:

Check whether the requests they receive pass through OPES intermediaries. If OPES tracing info is present, that tells them. This check only works for request/response protocols. For other protocols (like broadcast or push), the provider would have to assume OPES intermediaries are involved until proven otherwise 🔎.
If OPES intermediaries are suspected, request OPES traces from the potentially affected user(s). The trace will be part of the application message the user's software receives. If the involved parties cooperate, the provider(s) may get access to all the info they need. Of course, a lack of cooperation can make it harder to get tracing info. To encourage cooperation, data providers might be able to deny service to uncooperative users 🙅‍♀️.
Some traces may indicate that more information is available by accessing certain resources on the specified OPES intermediary or somewhere else. In that case, content providers may query for more information 📚.
If everything else fails, providers can enforce a no-adaptation policy using appropriate OPES bypass mechanisms and/or end-to-end encryption mechanisms 🔐.

OPES detection and response assistance is limited to application protocols that support tracing extensions. For example, HTTP [RFC2616] has that support, while DNS over UDP doesn't 🙃.

5.4. Consideration (3.2) 'Notification' 🫶

"The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries" [RFC3238].

OPES tracing mechanisms help end users detect OPES intermediaries 🌟. Specifically, a compliant OPES intermediary or system lets an end user know it's present by including its tracing info in the application protocol messages sent to the client. An OPES system MUST leave its trace [RFC3897]. Detection help has limits too, though. Some OPES systems may only work on requests and never get a chance to trace the response. Some application protocols also don't have explicit responses (for example, an event logging service) 🪵.

OPES detection assistance is limited to application protocols that support tracing extensions. For example, HTTP [RFC2616] has that support, while DNS over UDP doesn't 💜.

6. Consideration (3.3) 'Non-blocking' 🫶

Okay bestie, this one's about not blocking people from the original stuff ✨. Here's the quote from [RFC3238]: "If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider".

Then there's the bypass rule from [RFC3897]: "OPES entities MUST support a bypass feature". So if an application message has bypass instructions and an OPES intermediary isn't set up to ignore them, that intermediary will not process the message. An OPES intermediary may be configured to ignore bypass instructions only if no non-OPES version of content is available 💅.

Real talk though, bypass can cause content errors 😭. Some OPES services are essential but may not be configured as essential, so skipping them can break things.

Bypass support has limitations similar to the two notification-related considerations above 🌸.

7. Consideration (4.1) 'URI resolution' 🧚

Here's the vibe from [RFC3238]: "OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself". So OPES services are about what happens after a URI is resolved, not the resolving itself 🎀.

The "OPES Scenarios and Use Cases" spec [RFC3752] lists the content adaptations that are in scope for the OPES framework. Those include adapting requests and responses. None of the documented adaptations include URI resolution. Technically, though, some environments could use documented OPES mechanisms to resolve URIs (and other kinds of identifiers or addresses) ✨. The OPES framework can't effectively stop any specific kind of adaptation, so it's not gonna police everything 🙈.

For example, a CDN node could swap domain names in URLs for CDN-chosen IP addresses. That's basically resolving a URI for the content producer (the website owner) 🍓. An OPES callout service running on a user's PC could rewrite every HTML-embedded ad URL to point at a local image the user picked. That's basically a URI redirection for the content consumer (the end user) 💜. These URI manipulations are outside the OPES framework scope, but the real world can't effectively get rid of them 🌈.

8. Consideration (4.2) 'Reference validity' 💖

From [RFC3238]: "All proposed services must define their impact on inter- and intra-document reference validity".

The OPES framework doesn't propose adaptation services itself 🦋. But OPES tracing requirements include identifying OPES intermediaries and services (more details in the "Notification" consideration sections of this doc). The identification has to be usable to locate info about the OPES intermediaries, including how they affect reference validity [RFC3897] ✨.

9. Consideration (4.3) 'Addressing extensions' 👑

From [RFC3238]: "Any services that cannot be achieved while respecting the above two considerations may be reviewed as potential requirements for Internet application addressing architecture extensions, but must not be undertaken as ad hoc fixes".

No ad hoc fixes in the OPES framework, periodt 💅. This document, together with the other OPES documents, should be enough to inform service creators about IAB considerations. If a service does URI resolution or quietly affects document reference validity, the authors are asked to review the service's impact on the Internet application addressing architecture and work within the IETF on potential extension requirements 🧐. Those actions would be outside the current OPES framework 🌸.

10. Consideration (5.1) 'Privacy' 🎀

From [RFC3238]: "The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries".

OPES tracing mechanisms let end users identify OPES intermediaries (more in the "Notification" consideration sections here) ✨. The identification has to be usable to locate info about those intermediaries, including their privacy policies 🔐.

Quick caveat, though 🙈: the term "privacy policy" isn't defined in this context, by the IAB or the OPES working group. OPES tracing mechanisms let end users and content providers identify an OPES system and/or its intermediaries. The belief is that once an OPES system is identified, you could find relevant info about it, including info relevant to what the requester perceives as privacy policy or reference validity 💀.

11. Consideration 'Encryption' 🔒

From [RFC3238]: "If OPES is chartered, the OPES working group will also have to explicitly decide and document whether the OPES architecture must be compatible with the use of end-to-end encryption by one or more ends of an OPES-involved session. If OPES was compatible with end-to-end encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends".

This requirement wasn't explicitly listed as one of the IAB considerations, but it still needs to be addressed 🥺. From the context, "end-to-end encryption" means encryption along every link of the end-to-end path, with the OPES intermediaries acting as encrypting/decrypting participants or hops. For example, encryption between the provider and the OPES intermediaries, and between the OPES intermediaries and the client 💜.

OPES processors are regular hops on the application protocol path, so the OPES architecture allows this kind of encryption, as long as the application protocol being adapted supports it ✨. Hop-by-hop encryption wouldn't do much for the overall protection of the application message path if callout services have to receive unencrypted content 😭. So, for full link encryption coverage, the OPES callout protocol (OCP) supports encrypting OCP connections between an OPES processor and a callout server, through optional (negotiated) transport encryption mechanisms [I-D.ietf-opes-ocp-core] 🫶.

For example, TLS encryption [RFC2817] can be used among HTTP hops (some of which could be OPES processors) and between each OPES processor and a callout server 🌈.

12. Security Considerations 🛡️

This document doesn't define any mechanisms that may be subject to security considerations, so there's no new attack surface here, but the security of OPES mechanisms is discussed in the Security Considerations sections of the corresponding OPES framework documents. Read them, bestie 💀.

This document's scope is just to address specific IAB considerations ✨. The security of OPES mechanisms is covered in the Security Considerations sections of the matching OPES framework documents.

For example, OPES tracing mechanisms help content providers and consumers protect content integrity and confidentiality by requiring OPES intermediaries to disclose their presence 🔥. The security of the tracing mechanism is discussed in the Security Considerations section of [RFC3897] 🕵️.

13. Compliance 💅

This document might look like proof of OPES compliance with IAB implied recommendations 👀. But it doesn't introduce any compliance subjects 🙅. Compliance of OPES implementations is defined in the other OPES documents discussed above ✨.

14. References 📚

14.1. Normative References

[RFC3238]                     Floyd, S. and L. Daigle, "IAB
                              Architectural and Policy Considerations
                              for Open Pluggable Edge Services", RFC
                              3238, January 2002.

[RFC3752]                     Barbir, A., Burger, E., Chen, R.,
                              McHenry, S., Orman, H. and R. Penno,
                              "Open Pluggable Edge Services (OPES)
                              Use Cases and Deployment Scenarios",
                              RFC 3752, April 2004.

[RFC3835]                     Barbir, A., Penno, R., Chen, R.,
                              Hofmann, M., and H. Orman, "An
                              Architecture for Open Pluggable Edge
                              Services (OPES)", RFC 3835, August
                              2004.

[RFC3897]                     Barbir, A., "Open Pluggable Edge
                              Services (OPES) Entities and End Points
                              Communication", RFC 3897, September
                              2004.

14.2. Informative References

[RFC2227]                     Mogul, J. and P. Leach, "Simple
                              Hit-Metering and Usage-Limiting for
                              HTTP", RFC 2227, October 1997.

[RFC2616]                     Fielding, R., Gettys, J., Mogul, J.,
                              Frystyk, H., Masinter, L., Leach, P.
                              and T. Berners-Lee, "Hypertext Transfer
                              Protocol -- HTTP/1.1", RFC 2616, June
                              1999.

[RFC2817]                     Khare, R. and S. Lawrence, "Upgrading
                              to TLS Within HTTP/1.1", RFC 2817, May
                              2000.

[I-D.ietf-opes-http]          Rousskov, A. and M. Stecher, "HTTP
                              adaptation with OPES", Work in
                              Progress, October 2003.

[I-D.ietf-opes-ocp-core]      Rousskov, A., "OPES Callout Protocol
                              Core", Work in Progress, November 2003.

Authors' Addresses 🏡

Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario
CA

Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com


Alex Rousskov
The Measurement Factory

EMail: rousskov@measurement-factory.com
URI:   http://www.measurement-factory.com/

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Info on the IETF's procedures for rights in IETF Documents can be found in BCP 78 and BCP 79 ✨.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🌐.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 🫶.

📦 where this page comes from

ietf: rfc3914 2004-10
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms