RFC 3838
Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)
RFC 3838: Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) 🎀
Okay bestie, this is RFC 3838 💖, published by the Network Working Group in August 2004 🍓. It's Informational, so it's giving "here's some info for the Internet community" and not a standard 🧚. The authors are A. Barbir (Nortel Networks), O. Batuner (Consultant), A. Beck (Lucent Technologies), T. Chan (Nokia), and H. Orman (Purple Streak Development) 👑. The title block doesn't 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 💜
Copyright (C) The Internet Society (2004).
Abstract ✨
This doc is all about the policy, authorization, and enforcement requirements for picking which services get applied to a given Open Pluggable Edge Services (OPES) flow 💅.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Policy Architecture . . . . . . . . . . . . . . . . . . . . . 4
3.1. Policy Components and Functions . . . . . . . . . . . . 4
3.2. Requirements for Policy Decision Points. . . . . . . . . 5
3.3. Requirements for Policy Enforcement Points . . . . . . . 5
4. Requirements for Interfaces . . . . . . . . . . . . . . . . . 6
4.1. Service Bindings Requirements . . . . . . . . . . . . . 7
4.1.1. Environment Variables . . . . . . . . . . . . . 7
4.1.2. Requirements for Using State Information . . . . 8
4.1.3. Requirements for Passing Information Between
Services . . . . . . . . . . . . . . . . . . . . 8
4.2. Requirements for Rule and Rules Management . . . . . . . 8
4.2.1. Requirements for Rule Providers . . . . . . . . 8
4.2.2. Requirements for Rule Formats and Protocols . . 9
4.2.3. Requirements for Rule Conditions . . . . . . . . 9
4.2.4. Requirements for Rule Actions . . . . . . . . . 9
4.3. Requirements for Policy Expression . . . . . . . . . . . 10
5. Authentication of Principals and Authorization of Services . . 10
5.1. End users, Publishers and Other Considerations . . . . . 11
5.1.1. Considerations for End Users . . . . . . . . . . 11
5.1.2. Considerations for Publishing Sites. . . . . . . 12
5.1.3. Other Considerations . . . . . . . . . . . . . . 12
5.2. Authentication . . . . . . . . . . . . . . . . . . . . . 12
5.3. Authorization . . . . . . . . . . . . . . . . . . . . . 13
5.4. Integrity and Encryption . . . . . . . . . . . . . . . . 14
5.4.1. Integrity and Confidentiality of Authentication
and Requests/Responses for Service . . . . . . . 14
5.4.2. Integrity and Confidentiality of Application
Content . . . . . . . . . . . . . . . . . . . . 14
5.5. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 171. Introduction ✨
Okay so the Open Pluggable Edge Services (OPES) [1] architecture lets cooperative application services (OPES services) work between a data provider, a data consumer, and zero or more OPES processors 🫶. The application services in question analyze and possibly transform application-level messages exchanged between the data provider and the data consumer 💅. The OPES processor can spread out the job of running services by communicating and collaborating with one or more remote callout servers 🌸.
Running these services is governed by a set of rules installed on the OPES processor 📜. Rule evaluation can trigger a service application that's local to the OPES processor, or one on a remote callout server 🦋.
Policies are basically the goals of an OPES processor, written as a set of rules used to administer, manage, and control access to resources 👑. The requirements in this doc govern how OPES entities decide which of the available services get applied to a given message, if any 🎀.
The OPES policies covered here are limited to ones that describe which services to call and, if it makes sense, with what parameters 💖. They do not include policies that prescribe how the called services behave 🙈. It would be super desirable to have a common management framework for specifying policies for both calling a service and how it behaves ✨. Integrating a function like that is the domain of policy administration user interaction applications 🧚.
Here's the layout: Section 2 considers policy framework. Section 3 discusses requirements for interfaces, while section 4 examines authentication of principals and authorization of services 🍓.
2. Terminology 💅
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. When they're used with the normative meanings, these keywords will be all uppercase 🔥. Lowercase versions of these words are just normal prose, with no normative implications 🫶.
3. Policy Architecture 🌈
This section describes the architectural policy decomposition requirements ⭐. It also describes the requirements for the interfaces between the policy components 🦋. Lots of the rules here were shaped by the influence of RFC 3238 [2] 💜.
3.1. Policy Components and Functions 🎀
So the policy functions are split into three components: a Rule Author, a Policy Decision Point (PDP) [6], and a Policy Enforcement Point (PEP) [6] 🧚. The Rule Author provides the rules an OPES entity uses, and those rules control when services get invoked on the rule author's behalf 🍓. The PDP and the PEP interpret the collected rules and enforce them properly 👑. Here's how the split looks, in Figure 1 🦋:
+--------+ +--------+
| Rule | | Rule |
| Author | ... | Author |
+--------+ +--------+
| |
| |
| +----------+ |
| | Policy | | <- PDP Interface
+--------->| Decision |<----------+
| Point |
+----------+
| ^
| |
| | <- PEP Interface
| |
V |
+--------------+ ...
---> | Policy | --->
| Enforcement | Data Traffic
<--- | Point | <---
+--------------+Figure 1: Policy Components
Splitting policy control into a PDP and a PEP lets some tasks get offloaded to an administrative service 🌸. That service might live on a server separate from the real-time enforcement services of the PEP, which sit on the OPES processor ✨.
The PDP handles authenticating and authorizing rule authors, plus validating and compiling rules 💖.
The PEP lives in the data filter, where data from an OPES flow gets checked against the compiled rules, and the right calls to the requested services get made 🫶.
The interfaces between these architectural components are points of interoperability 💜. The interface between rule authors and the policy decision points (PDP Interface) MUST use the format that may result from the requirements as described in this document 🎀. The interface between the policy decision points and the policy enforcement points (PEP Interface) can be internal to a specific vendor implementation of an OPES processor 🧚. Implementations MUST use a standard interface only if the PDP and the PEP reside on different OPES processors 🔥.
3.2. Requirements for Policy Decision Points 👑
The Policy Decision Point is essentially a policy compiler 💅. The PDP MUST be a service that provides administrative support to the enforcement points 🌈. The PDP service MUST authenticate the rule authors 🦋.
The PDP MUST verify that the specified rules are within the scope of the rule authors' authority 🍓. The PDP MUST be a component of the OPES Administration Authority ⭐.
3.3. Requirements for Policy Enforcement Points ✨
Okay so in the OPES architecture, the data filter is the Policy Enforcement point (PEP) 💅. This is where data from an OPES flow gets checked against the compiled rules, and the requested services get called if they need to be 🔥.
In the PEP, rules MAY chain actions together, so you can specify a series of services to call one after another 🎀. The implementation MUST make sure information gets passed from one called service to the next 💖. It MUST NOT stop a message from being re-evaluated to figure out whether another service or set of services should be called 🦋.
Running an action (aka triggering a rule) can change the values of message properties 🌸. For example, an OPES service that converts JPEG images to GIF images under certain conditions changes the content type of the requested web object 📸.
Those changes to message properties can totally change how later OPES actions behave 😭. The data filter SHOULD act on matched rules before it evaluates the subsequent rules 🧚. Multiple matched rules can be triggered at the same time, but only if the data filter can tell ahead of time that running any specific rule has no side effects ✨.
A data filter MAY evaluate messages several times while handling an OPES flow 🌈. The rule processing points MAY be defined by administratively defined names 🍓. Those names can act as a selector, so policy rules can decide where they apply at each processing point 💜.
Policy roles ([5] and [6]) SHOULD be used where they help with developing the OPES policy model 👑.
Figure 2 shows a typical message data flow between a data consumer application, an OPES processor, and a data provider application 🦋. There are four commonly used processing points, numbered 1 through 4 👀.
+--------+ +-----------+ +---------+
| |<------|4 3|<------| |
| Data | | OPES | | Data |
|Consumer| | Processor | |Provider |
| Appl. |------>|1 2|------>| Appl. |
+--------+ +-----------+ +---------+Figure 2: Processing Execution Points
Any data filter (PEP) or any administrative (PDP) implementation MUST support the four rule processing points 🫶. Here they are:
- Data Consumer Request handling role: This involves request processing when received from a Data Consumer Application.
- OPES Processor Request handling role: This involves request processing before forwarding to Data Provider Application.
- Data Provider Response handling role: This involves response processing when forwarding to Data Consumer Application.
- OPES Processor Response handling role: This involves response processing when forwarding to Data Consumer Application.
4. Requirements for Interfaces 🎀
The interface between the policy system and OPES services needs to include the ability to pass system state information as well as the subject message 🧚.
4.1. Service Bindings Requirements 💅
The invoked OPES services MUST be able to be specified in a location independent fashion 🌸. That means rule authors don't need to know, or specify, which instance of an OPES service gets used in the rules 💖.
The rule author SHOULD be able to identify the required service at whatever detail level suits their needs ✨. They SHOULD be able to specify a type of service, or any service that fits a general category to be applied to their traffic 🦋.
The binding of OPES service names to a specific service MAY be distributed between the PDP and the PEP 🌈. As rules get compiled and validated by the PDP, they MUST be resolved to a specific installation's set of homogeneous OPES service 🔥.
The selection of a specific instance MAY be postponed and left to the PEP, which can choose at either rule installation time or at run time 🍓. For interoperability, the PEP MUST support resolving a generic name to a specific instance 👑. Services such as SLP or UDDI can be used to resolve generic service names to specific OPES service instances 🧚.
The policy system MAY support dynamic discovery of service bindings 💜. A rule author may not know the specific service bindings, such as protocol and parameters, when a rule (as specified on the PDP Interface) is general in nature 😭. The required binding information MUST be provided by the PDP and conveyed on the PEP Interface 🫶. A service description methodology such as WSDL [8] MUST be present in the policy system 💅.
4.1.1. Environment Variables 🌸
There may be a need to define and support a way of maintaining state information that can be used in both condition evaluation and action execution 🎀. Depending on the execution environment, OPES services MAY have the freedom to define the variables they need and use them to further define their service behavior, without data filter support ✨.
4.1.2. Requirements for Using State Information 🧚
Policy rules MAY specify that state information be used as part of evaluating the rules against a given message in an OPES flow 🌈. So the policy system SHOULD support maintaining groups that can be used when evaluating rule conditions 🍓. Membership in those groups can be used as action triggers 💜.
For example, an authorized site blocking service might conclude that a particular user shouldn't be allowed to access a certain web site 🙈. Instead of calling the service for every request that user sends, a rule can check whether the user is a member of blocked users and whether the requested site is a member of blocked-sites, then invoke a local blocking service to return an appropriate message to the user 🔥.
4.1.3. Requirements for Passing Information Between Services 🦋
Environment variables can be used to pass state information between services 💖. For example, analysis of the request, or modifications to the request, may need to be captured as state information that gets passed to other services on the request path, or to services on the response(s) associated with that request 👑.
In the PEP, there SHOULD be provisions for setting up variables when returning from a service call, and for passing variables to other called services based on policy 🫶.
4.2. Requirements for Rule and Rules Management 👑
This section covers the requirements for rule management, and it's giving organized 💅. The rules are split into two groups: some are provided by the data consumer application, and others are provided by the data provider application 🌈.
4.2.1. Requirements for Rule Providers 💜
The requirements for rule providers are:
- Rule providers MUST be authenticated and authorized for rules that apply to their network role.
- Rule providers MUST NOT be able to specify rules that are NOT within their scope of authority.
- Rule providers SHOULD be able to specify only what is needed for their services.
- Compilation of rules from different sources MUST NOT lead to execution of conflicting rules.
- The resolution of such rule conflicts is out of scope.
- Rules are assumed to be static and applied to current network state.
4.2.2. Requirements for Rule Formats and Protocols 🎀
It is desirable to choose standard technologies like XML for the rule language format 🧚.
Rules need to be sent from the rule authors to the OPES administrative server for service authorization, rule validation, and compilation 🌸. The mechanisms for doing that are out of scope of the current work 🙈.
Once the rules are authorized, validated, and compiled by the administrative server, they need to be sent to the OPES processor ✨. The mechanisms for doing that are out of scope of the current work too 💅.
4.2.3. Requirements for Rule Conditions 🦋
Rule conditions MUST be matched against attribute values of the encapsulated protocol as well as environment variable values 💖. Attribute values of the encapsulated protocol include protocol header values and possibly protocol body values 🌈.
Some OPES services may need to be invoked for all user requests or server responses, like services with logging functionality, for example 🍓. The rule system SHOULD allow unconditional rules, so rule authors don't have to write rule conditions that are always true 🫶.
4.2.4. Requirements for Rule Actions 🔥
The rule system MUST allow for the specification of rule actions that are triggered if the conditions of a rule are met 👑. Matched rules typically lead to the invocation of local or remote services 💜. Rule actions MUST identify the OPES service that is to be executed for the current message request or response 😭.
Rule actions MAY contain run-time parameters that can be used to control the behavior of an OPES service 🧚. If specified, these parameters MUST be passed to the executed OPES service 🫶.
4.3. Requirements for Policy Expression 💅
OPES processors MUST enforce policy requirements set by data consumers and/or data publishers, in accordance with the architecture [1] and this document 🌸. They can't do this consistently unless there is unambiguous semantics and representation of the data elements mentioned in the policy 🎀.
Here's the example the document gives 🙈: it mentions protecting user "identity" and "profile" information. If a user specifies that his identity must not be shared with other OPES administrative trust domains, and later discovers that his family name has been shared, he might complain 😭. If he were told that "family names are not considered 'identities' by this site", he would probably feel he had cause for complaint 💀. Or he might be told that when he selected "do not share identity" on a web form offered by the OPES service provider, that only covered his login name, and a different part of the form had to be filled out to protect the family name 🙈. It gets worse if the configuration information from such a web form gets translated into configuration elements given to an OPES processor, and those elements are hard for a software engineer to turn into policy enforcement 🔥. The data elements might have confusing names or be split into groupings that are hard to relate to one another 🌈.
The examples show why the OPES policy MUST have definitions of data elements, their relationships, and how they relate to enforcement 👑. These semantics of essential items don't require a separate protocol, but they MUST be agreed upon by all OPES service providers 💜. Users of OPES services MUST be assured that they can know their settings, change them if the service provider policy allows changes, and have reasonable assurance that they are enforced with reasonable interpretations 🫶.
The requirements for policy data elements in the OPES specification don't have to be all-inclusive, but they MUST cover the minimal set of elements that enable the policies protecting the data of end users and publishers 🦋.
5. Authentication of Principals and Authorization of Services 🧚
This section looks at the authorization and authentication of OPES services 💖.
5.1. End Users, Publishers and Other Considerations 🌸
5.1.1. Considerations for End Users ✨
okay so an OPES rule decides which attributes of traffic set off OPES services 🔥 the service author can write rules, but they can't write the part of the precondition that decides which network users get the services applied for them 🙈 this section is about how users get identified in those preconditions, how they can pick and un-pick services for their traffic, how an OPES service provider SHOULD identify users, and how users decide whether to add their service choice to an OPES enforcement point 💅
an OPES service provider MUST cover these major requirements 🫶:
- Let all users ask for OPES services to be added, deleted, or blocked for their traffic (blocking means "do not use this service for my traffic") 💖
- Stop untrusted users from letting OPES services mess with other users' traffic 🛡️
- Let users see their OPES service profiles and tell them when those change 🔔
- Keep a log of all profile activity for audits 📋
- Follow a privacy policy that guards users' profiles 🔒
the administrator of the PDP is a trusted party and can set policy for individuals or groups using out-of-band communication and configuration files ✨ BUT users MUST always be able to query the PDP so they can find out which rules apply to their traffic 👀 no skipping this part bestie 💅
rules can be deposited in the PDP with no precondition about network users 🧚 this is how rules come packaged with an OPES service when it's delivered for installation 📦 the PDP is responsible for binding identities to the rules and sending them to the PEP 💜 the identity the PDP uses for policy decisions MUST be strictly mapped to the identity the PEP uses 🎀 so if a user goes through an identification and authentication procedure with the PDP and is known as identity "A", and the PEP uses IP addresses for identities, then the PDP MUST give the PEP a binding between "A" and A's current IP address 🌸 that's lowkey the whole mapping thing, iykyk 🤓
5.1.2. Considerations for Publishing Sites 🌈
an OPES service provider working for different publishing sites SHOULD keep all of the above in mind when it's implementing an OPES site 💅 because each publishing site might be represented by just one identity, the authentication and authorization databases may be easier for the PEP to handle 🧠✨
5.1.3. Other Considerations 🦋
authentication may be necessary between PDPs and PEPs, PEPs and callout servers, PEPs and other PEPs, and callout servers and other callout servers, so privacy policies can be validated 🔐 in any case where user data or traffic crosses trust domain boundaries, the originating trust domain SHOULD have a policy describing which other domains are trusted, and it SHOULD authenticate those domains and their policies before forwarding anything 🫶 trust but verify, periodt 💀
5.2. Authentication 🔑
when an individual selects (or deselects) an OPES service, the individual MUST be authenticated by the OPES service provider 🪪 this means a binding between the user's communication channel and an identity the service provider knows gets made in a secure manner 💖 this SHOULD be done using a strong authentication method with a public key certificate for the user, because it'll be super helpful for resolving disputes later 🧾 it is recommended that the service provider keeps a log of all requests for OPES services 📚 and the service provider SHOULD use public key certificates to authenticate its responses to requests 🎀
the service provider may have trusted users who, through explicit or implicit contract, can assign, remove, or block OPES services for particular users 👑 those trusted users MUST be authenticated before they're allowed to take actions that modify the policy base, and therefore the actions of the PEPs 🧚
because user profiles are so sensitive 😭, the PEP Interface between the PEP and the PDP MUST use a secure transport protocol 🔒 and PEPs MUST adhere to the privacy preferences of the users 💅
when an OPES service provider accepts an OPES service, there MUST be a unique name for the service, given by the entity publishing it 🏷️ users MAY refer to that unique name when they request a service 💜 the unique name MUST be used when users are notified about their service profiles 🔔 PEPs MUST be aware of the unique name for each service that can be accessed from their domain 🌍 and there MUST be a cryptographic binding between the unique name and the entity responsible for the service's functional behaviour 🔗 like, if it's a human language translating service, then the name of the company that wrote the software SHOULD be bound to the unique name 🫶
5.3. Authorization 👑
besides requesting or ending specific services, users MAY block particular services, which means those services should not be applied to their traffic 🙅♀️ the "block all OPES" directive MUST be supported on a per user basis 💖
a response to a request for an OPES service can be positive or negative ✨ reasons for a negative response include "service unknown" or "service denied by PDP policy" 💀 positive responses SHOULD include the identity of the requestor, the service, and the type of request 🎀
as described in the OPES Architecture [1], requests for OPES services come from either the end user or the publisher domain 🌐 the PDP bases its authorization decision on the requestor and the domain 🧠 and yes, some cases get messy 😭 here they are:
- the end user has blocked a service, but a trusted user of the PDP wants it applied anyway 🙄 in this case, the end user SHOULD prevail, unless there are security or legal reasons to leave it in place 🫶
- the publisher and the end user are in the same domain 👯♀️ if the publisher and end user are both clients of a PDP, can they make requests that affect each other's processing? in this case, the PDP MUST have policy rules naming the identities that are allowed to set such rules 📜
- the publisher requests a service for an end user 💌 in this case, where the PDP and PEP are in the publisher's administrative domain, the publisher has some way of identifying the end user and his traffic, and the PDP MUST enable the PEP to enforce the policy 🔥 this is allowed, but the PDP MUST use strong methods to identify the user and his traffic 🔐 and the user MUST be able to request and receive information about the service profile that a publisher site keeps about him 👀
- the end user requests a service specific to a publisher's identity (e.g., nfl.com), but the publisher prohibits the service (e.g., through a "NO OPES" application header) 🚫 as in the case above, the publisher MUST be able to request and receive profile information that a user keeps about a publisher 🤝
in general, the PDP SHOULD keep its policy base in a manner that makes the decision procedure for all cases easy to understand 🧩 no confusing vibes allowed 💅
5.4. Integrity and Encryption 🧁
5.4.1. Integrity and Confidentiality of Authentication and Requests/Responses for Service 🔏
the requests and responses SHOULD be cryptographically tied to the identities of the requestor and responder, and the messages SHOULD NOT be alterable without detection 🕵️♀️ a certificate-based digital signature is strongly recommended as part of the authentication process 💜 a binding between the request and response SHOULD be established using a well-founded cryptographic means, so it shows the response was made in reply to a specific request 🎯
5.4.2. Integrity and Confidentiality of Application Content 🌸
as directed by the PEP, content will be transformed in whole or in part by OPES services 🪄 this means end-to-end cryptographic protections cannot be used 😭 this is probably fine for the vast majority of traffic, but where a lesser form of content protection is desirable, hop-by-hop protections can be used instead 🦋 the requirements for those protections are:
- integrity using shared secrets MUST be used between all processing points, end-to-end (i.e., the two ends of a "hop" MUST share a secret, but the secret can be different between "hops") 🔑 the processing points include the callout servers 🧚
- encryption can be requested separately, with the same secret sharing requirement between "hops" 🔐 when requested, encryption applies to all processing points, including callout servers 🫶
- the signal for integrity (and optionally encryption) MUST originate from either the requestor (in which case it is applied to the response as well) or the responder (in which case it covers only the response) 📡
- the shared secrets MUST be unique (to within a very large probabilistic certainty) for each requestor/responder pair 💎 this helps protect the privacy of end user data from insider attacks or configuration errors while it transits the provider's network 🛡️
5.5. Privacy 🙈
the PDP MUST have a privacy policy covering OPES data, such as user profiles for services 📜 users MUST be able to limit the spread of their profile data and their identities 🤫
supported limitations MUST include:
- the ability to prevent Identity from being given to callout servers 🙅♀️
- the ability to prevent Profile information from being shared 🎀
- the ability to prevent Traffic data from being sent to callout servers run by third parties 🚫
- the ability to prevent Traffic from particular sites from being given to OPES callout servers 🌸
when an OPES service is provided by a third party, it MUST have a privacy policy and identify itself to upstream and downstream parties, telling them how to access that policy 🪪 a mechanism is needed to specify these preferences, plus a protocol to distribute them (see section 3.3) 🧠 privacy is literally a whole vibe 💖
6. Security Considerations 🚨
this document discusses the policy, authorization and enforcement requirements of OPES 📋 multiple security and privacy issues related to OPES services are discussed in [3] 💀 go read it, it's serious bestie 😭
7. References 📚
7.1. Normative References
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[3] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
7.2. Informative References
[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[7] 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.
[8] Christensen, et al., Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001, http://www.w3.org/TR/wsdl 🌈
8. Acknowledgements 🙏✨
Big thank-yous to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Condry (Intel), Randy Presuhn (Mindspring), and B. Srinivas (Nokia) 🫶💖 You all made this possible!
9. Authors' Addresses 💌
Here are the lovely humans behind this doc, with their contact deets 🦋
Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Oskar Batuner
Consultant
EMail: batuner@attbi.com
Andre Beck
Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
USA
EMail: abeck@bell-labs.com
Tat Chan
Nokia
5 Wayside Road
Burlington, MA 01803
USA
EMail: Tat.Chan@nokia.com
Hilarie Orman
Purple Streak Development
EMail: ho@alum.mit.edu10. Full Copyright Statement 🎀
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions in BCP 78, and except as stated there, the authors keep all their rights 💜
The document and everything in it is provided "AS IS" 🫠 and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any promise that using the info won't infringe anyone's rights, and any implied warranties of merchantability or fitness for a particular purpose 💀
Intellectual Property 🔍
Okay, the IETF is not taking a side on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this doc are valid or how far they reach 🙈 It also isn't saying whether any licence under those rights might or might not be available, and it hasn't done any independent digging to find such rights. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licences that might be offered, are on the IETF online IPR repository at http://www.ietf.org/ipr 🌸 The same goes for the results of any attempt to get a general licence or permission for implementers or users of this spec to use those proprietary rights.
The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard to let them know. 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 🌈 Thank you, legends!
📦 where this page comes from
- ietf: rfc3838 2004-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms