RFC 3930

Part 1 of 3 💖

The Protocol versus Document Points of View in Computer Protocols 🦋

• RFC number: 3930
• Stream: Network Working Group
• Author: D. Eastlake 3rd, Motorola Laboratories
• Category: Informational
• Date: October 2004
• Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates

---

Status of this Memo 📜

okay so this memo is here to give info to the Internet community 🫶 it does not specify an Internet standard of any kind, so don't go treating it like one. distribution of this memo is unlimited, so share it with your whole group chat 💌

Copyright Notice ©

Copyright (C) The Internet Society (2004). ✨

Abstract 🌸

this doc puts two vibes side by side: the "document" point of view, where digital stuff is like a piece of paper that people write and read, and the "protocol" point of view, where the things we care about are composite, dynamic network messages 🧚 both have their place, but treating a protocol like a document can seriously hurt protocol design 💀 once you understand both, the clashes between them get way easier to spot and smooth out 💅

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Points of View . . . . . . . . . . . . . . . . . . . . . . . .  2
    2.1.  The Basic Points of View . . . . . . . . . . . . . . . .  3
    2.2.  Questions of Meaning . . . . . . . . . . . . . . . . . .  3
          2.2.1.  Core Meaning . . . . . . . . . . . . . . . . . .  3
          2.2.2.  Adjunct Meaning. . . . . . . . . . . . . . . . .  4
    2.3.  Processing Models. . . . . . . . . . . . . . . . . . . .  5
          2.3.1.  Amount of Processing . . . . . . . . . . . . . .  5
          2.3.2.  Granularity of Processing. . . . . . . . . . . .  5
          2.3.3.  Extensibility of Processing. . . . . . . . . . .  6
    2.4.  Security and Canonicalization. . . . . . . . . . . . . .  6
          2.4.1.  Canonicalization . . . . . . . . . . . . . . . .  6
          2.4.2.  Digital Authentication . . . . . . . . . . . . .  8
          2.4.3.  Canonicalization and Digital Authentication. . .  8
          2.4.4.  Encryption . . . . . . . . . . . . . . . . . . .  9
    2.5.  Unique Internal Labels . . . . . . . . . . . . . . . . . 10
3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.  Resolution of the Points of View . . . . . . . . . . . . . . . 11
5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.  Security Considerations. . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15

---

1. Introduction 🎀

okay so this doc is literally about two ways of looking at the same thing: the "document" view, where digital objects are basically paper that people write and read 📄, and the "protocol" view, where the objects are composite, dynamic network messages 🛰️ the tea is that people who grew up in one view have a really hard time getting the other one. even after they get it, they start from their usual view, assume their view works for everything, and keep sliding back into it 🙈 like, both views have a place, but sticking to the document view can seriously damage protocol design 💀 once you understand both, the conflicts between them can be clarified and reduced ✨

the IETF's traditional work has mostly been about low level binary protocol stuff 🤖 that stuff is almost always seen from the protocol point of view. but once higher level application constructs and syntaxes show up in IETF and other standards processes, things get messy because some people come in with the document point of view 😭 section 2 defines and explores these two points of view in detail.

section 3 gives some examples 🍓 and section 4 tries to blend the two views together and offer general design advice for areas where it could reasonably go either way 🫶

2. Points of View 🦋

the subsections below contrast the document and protocol points of view. each viewpoint is EXAGGERATED for effect, so don't take it as the whole truth 💅

the document point of view shows up in paragraphs labeled "DOCUM", and the protocol point of view shows up in paragraphs labeled "PROTO" 🏷️

2.1. The Basic Points of View 🌈

DOCUM: the important stuff is complete digital documents, kinda like pieces of paper, and people are the ones viewing them 👀 a big worry is being able to show these documents as directly as possible to a court or some other third party ⚖️ since what the person sees is the only thing that matters, anything that can affect that, like a "style sheet" [CSS], MUST be considered part of the document 💖 it gets forgotten that the "document" starts out on a computer, can travel over and get processed and stored in computer systems, and gets viewed on a computer 💻 and all of those steps can involve transcoding, enveloping, or data reconstruction 🫠

PROTO: the important stuff is the bits on the wire, generated and consumed by well-defined computer protocol processes 🤖 no person ever actually sees the full messages as such. only geeks look at them as a whole, and only when debugging, and even then they're looking at some translated visible form 🤓 if you ever have to prove something about one of these messages in court or to a third party, there's no way around having computer experts interpret it 🧑‍⚖️ it also gets forgotten that pieces of these messages can end up in, or influence, the data shown to a person 👑

2.2. Questions of Meaning 💭

the document and protocol points of view have totally different ideas of what "meaning" means for data 🥹 document people tend to think "meaning" to a human reader is super important, while protocol people almost never think about it at all 💀

this difference goes past the core meaning and into the meaning of addenda to data. both core and addenda meaning get talked about below ✨

2.2.1. Core Meaning 🧠

DOCUM: the "meaning" of a document is a deep, interesting human question tied to volition 🙃 the document probably needs to include or reference human language policy and/or warranty/disclaimer info 📜 at the very least, some kind of semantic labelling is required 🏷️ the assumed situation is always a person reading the whole "document" with no other context 👓 so it's reasonable to consult attorneys during message design, and to require that human-readable statements be "within the four corners" of the document, and so on ⚖️

PROTO: the "meaning" of a protocol message should be clear and unambiguous from the protocol specification 📐 it's often defined in terms of the state machines of the sender and recipient processes, and it may have only the most remote connection to human volition 🤷‍♀️ these processes have extra context, and the message is usually only meaningful with that extra context 🔑 adding any human-readable text that isn't functionally required is honestly silly 🙄 and consulting attorneys during design is a bad idea, since it complicates the protocol and could tie a design effort in knots 🪢

2.2.2. Adjunct Meaning 🎁

adjunct items can be added to a message, or they're logical addenda to it ✨

DOCUM: from a document point of view, at the top level there's a person looking at a document 👀 so adjunct items like digital signatures, people's names, dates, and so on must be carefully labeled as to meaning 🏷️ so a digital signature needs to include, in more or less human-readable form, what the signature means (is the signer a witness, author, guarantor, authorizer, or what?) ✍️ similarly, a person's name needs to come with that person's role, like editor, author, subject, or contributor 🎭 and a date needs to come with its significance, like date of creation, modification, distribution, or some other event 📅 given how unrestricted the scope of documentation is, there's a risk of trying to list and standardize every possible "semantic tag" for each kind of adjunct data during the design process 😵‍💫 that can be a difficult, complex, and essentially infinite task (i.e., a rat hole) 🐀🕳️

PROTO: from a protocol point of view, the semantics of the message and of every adjunct in it are defined in the protocol specification 📐 so if there's a slot for a digital signature, a person's name, a date, or whatever, the party who fills in that data, the party or parties who read it, and its meaning are all predefined 🔒 even if there are several possible meanings, the specific one that applies can be set by a separate enumerated type field 🔢 there's no reason for that field to be directly human readable 🤖 only the "meanings" relevant to the particular protocol need to be considered 🎯 another way to think about it: the "meaning" of each adjunct, instead of being pushed into and coupled with the adjunct itself, as the document point of view encourages, is usually promoted up to the protocol specification, which makes the adjuncts simpler 🧩✨

2.3. Processing Models ⚙️

the document oriented and protocol oriented people have really different views on what's likely to happen to an object 👯

2.3.1. Amount of Processing 📦

DOCUM: the model is a quasi-static object, like a piece of paper 📄 about all you do to pieces of paper is move them as a whole from one storage area to another, or add signatures, date stamps, or similar adjuncts ✍️ (you might sometimes want an extract from a document, or to combine several documents into a summary, but that's not the common case 🙅‍♀️)

PROTO: the standard model of a protocol message is an ephemeral, composite, multi-level object 🫧 it's created by a source process and consumed by a destination process 🔁 it's built from information in previously received messages, locally stored info, local calculations, and so on 🧮 quite complex processing is totally normal here 🤯

2.3.2. Granularity of Processing 🔍

DOCUM: the document view is usually uniform processing or evaluation of the object being specified 🟰 there might be room for attachments or addenda, but if so, they'd probably be simple, one level, self documenting ones 📎 (separate processing of an attachment or addenda is possible, but it isn't usual 🙂)

PROTO: processing is complex and almost always affects different pieces of the message differently 🌀 some pieces may be meant only for the destination process and get heavily processed there 🔐 others may just be there so the destination process can do minimal processing at some point and forward them in other messages to even more processes 📬 the object's structure can be really rich, with multilevel or recursive aspects 🪆 and because messages get processed in a local context, parts of a message might include something like a signature that covers multiple data elements, some in this message, some from earlier messages, and some calculated locally 🫶🔥

2.3.3. Extensibility of Processing 🧚

Okay so the DOCUM crew (document-oriented folks) usually don't think extensibility is a major problem 💅. They assume their design, maybe with some simple version scheme, will meet every requirement. Or, coming from an SGML/DTD world of closed systems, they might assume that news about new versions or extensions can be spread easily and all at once to every participating site 🙈.

PROTO (protocol-oriented) people are lowkey more realistic 😭. They assume protocols will always need to be extended, and that it won't be possible to update every implementation as those extensions get deployed and/or retired. It's a difficult problem, but they try to hand us the tools 🛠️. For example, they specify carefully defined versioning and extension/feature labelling, including the ability to negotiate versions and features where possible, and at least a specification of how parties running different levels should interact. They also provide length/delimiting information for all data so it can be skipped if not understood, and destination labelling so that a process can tell it should ignore data except for passing it through to a later player. It's giving main character energy 👑✨

2.4. Security and Canonicalization 🔐

Security is a subtle area 🌸. Sometimes problems can be solved in a way that works across many applications. Those solutions are typically built into standard security syntaxes, such as those for ASN.1 [RFC3852] and XML [RFC3275, XMLENC]. But there are almost always application-specific questions, especially the question of exactly what information needs to be authenticated or encrypted 🤔.

Questions about exactly what needs to be secured and how to do it robustly are deeply entwined with canonicalization 🧶. They are also somewhat different for authentication and encryption, as discussed below.

2.4.1. Canonicalization 🍓

Canonicalization is the transformation of the "significant" information in a message into a "standard" form, discarding "insignificant" information. For example, that could mean encoding into a standard character set, or changing line endings into a standard encoding, and discarding the information about the original character set or line ending encodings 📝. Obviously, what counts as "significant" and what counts as "insignificant" varies with the application or protocol, and it can be tricky to figure out 😵‍💫. However, it's common that for each particular syntax, such as ASCII [ASCII], ASN.1 [ASN.1], or XML [XML], a standard canonicalization (or canonicalizations) gets specified or developed through practice. This leads to applications that assume one of those standard canonicalizations, which reduces the need for per-application canonicalization 💅. (See also [RFC3076, RFC3741].)

DOCUM folks think canonicalization is suspect, if not outright evil 😤. Picture a piece of paper with writing on it. Any change to "standardize" its format could be an unauthorized change to the original message as created by the "author", who is always pictured as a person 🧍‍♀️. Digital signatures are like signing, sealing, or time-stamping the bottom of that paper. They don't justify changes to the message appearing above them, and they shouldn't depend on those changes. Encryption is similar: it's just putting the paper in a vault that only certain people can open, and it doesn't justify any standardization or canonicalization of the message 🔒.

PROTO folks see canonicalization as a straight-up necessity 🫶. It's just a question of exactly which canonicalization or canonicalizations to apply to a pattern of bits that gets calculated, processed, stored, communicated, and finally parsed and acted on. Most of these bits have never been seen, and never will be seen, by a person 👀. In fact, many parts of the message will be artifacts of encoding, protocol structure, and computer representation, rather than anything meant for a person to read 🤖.

Perhaps in theory, the "original", idiosyncratic form of any digitally signed part could be conveyed unchanged through the computer processing, storage, and communication channels that implement the protocol, and could be usefully signed in that form. But in practical systems of any complexity, this is unreasonably difficult, at least for most parts of messages. And even if it were possible, it would be virtually useless, because to authenticate messages you would still have to determine their equivalence with the preserved original form 🙃.

So signed data must be canonicalized as part of signing and verification, to compensate for insignificant changes made in processing, storage, and communication 🧹. Even if, miraculously, an initial system design avoids every case of signed message reconstruction based on processed data, or re-encoding based on character set, line ending, capitalization, numeric representation, time zones, or whatever else, later protocol revisions and extensions are certain to require that reconstruction and/or re-encoding eventually 📆. If those "insignificant" changes aren't taken care of by canonicalization, signatures won't work, as discussed in more detail in 2.4.3 below 💀.

2.4.2. Digital Authentication 🪪

The DOCUM view of authentication tends to be a "digital signature" and "forms" point of view 🖋️. (The "forms" point of view is a subset of the document point of view, and believes that a principal activity is presenting forms to human beings so that they can fill out and sign portions of those forms [XForms].) Since the worry is always about human third parties and viewing the document in isolation, document-oriented folks always want "digital signature" (asymmetric key) authentication, with its characteristics of "non-repudiability", etc. As a result, they reject secret-key-based message authentication codes as useless, because those give the verifier the capability of forging an authentication code 🙅‍♀️. (See any standard reference on the subject for the usual meaning of these terms.)

From their point of view, you have a piece of paper or form that a person signs 🖊️. Sometimes a signature covers only part of a form, but that's usually because a signature can only cover data that is already there. And normally at least one signature covers the "whole" document/form. So document-oriented folks want to be able to insert digital signatures into documents without changing the document type, and even "inside" the data being signed. That requires a mechanism to skip the signature, so it doesn't try to sign itself 🌀.

PROTO folks think the right kind of authentication, whether "digital signature" or symmetric keyed authentication code (or biometric, or whatever), is just another engineering decision 🧠. It's affected by questions of efficiency, the desired security model, and so on. Furthermore, the idea of signing a "whole" message seems very peculiar 🤨, unless it's a copy being saved for archival purposes, in which case you might be signing a whole archive at once anyway 🗄️. Typical messages are made up of various pieces, with various destinations, sources, and security requirements 🧩. And there are common fields that are rarely useful to sign, because they change as the message is communicated and processed. Examples include hop counts, routing history, and local forwarding tags 🔁.

2.4.3. Canonicalization and Digital Authentication 🧐

For authenticating protocol system messages of practical complexity, you're faced with a choice between:

• (1) "too little canonicalization", which gives you brittle authentication, useless due to verification failures caused by surface representation changes without significance
• (2) the sometimes difficult and tricky work of selecting or designing an appropriate canonicalization or canonicalizations to be used as part of authentication generation and verification, producing robust and useful authentication, or
• (3) "too much canonicalization", which gives you insecure authentication, useless because it still verifies even when significant changes are made in the signed data

The only useful option above is number 2 💖✨.

2.4.4. Encryption 🔑

In terms of processing, transmission, and storage, encryption turns out to be way easier to get working than signatures 🥳. Why? Because the output of encryption is essentially random bits. It's clear from the beginning that those bits need to reach the destination in some absolutely clean way that doesn't change even one bit 🧼. Because encrypted bits are meaningless to a human being, there's no temptation among the document-oriented to try to make them more "readable" 🙌. So appropriate encoding techniques at the source, such as Base64 [RFC2045], and decoding at the destination, are always incorporated to protect, or "armor", the encrypted data 🛡️.

Although applying canonicalization is more obvious with digital signatures, it may also apply to encryption, particularly encryption of parts of a message 🔍. Sometimes elements of the environment where the plain text data is found may affect its interpretation. For example, interpretation can be affected by the character encoding or the bindings of dummy symbols. When the data is decrypted, it may end up in an environment with a different character encoding or different dummy symbol bindings 🌍. With a plain text message part, it's usually clear which of these environmental elements need to be incorporated in or conveyed with the message. But an encrypted message part is opaque, so some canonical representation that incorporates such environmental factors may be needed 🫣.

DOCUM folks usually consider encryption of the entire document 📜. Because signatures are always thought of as human assent, people with a document point of view tend to vehemently insist that encrypted data should never be signed unless the plain text of it is known 🚫✍️.

PROTO folks point out that messages are complex, composite, multi-level structures, and some pieces of them are forwarded across multiple hops 🛤️. So the design question is what fields should be encrypted, by what techniques, to what destination or destinations, and with what canonicalization 🧠💭.

It sometimes makes perfect sense to sign encrypted data you don't understand. For example, the signature could just be for integrity protection, or for use as a time stamp, as specified in the protocol ⏰🦋.

2.5. Unique Internal Labels 🏷️

okay so sometimes you want to point at one specific piece of a message or object, like "that part right there," and you need a label, id, or tag for it 🎀 the idea is it's a fixed anchor you can use "globally," or at least across one application domain, to reference the tagged bit 💖

DOCUM: from the document point of view, it's giving simple, just provide a text tag 📄 users or apps could totally come up with short, readable tags. if a human makes them, they'd probably be meaningful, like "Susan," and if a machine makes them, they should be fairly short and systematic, like "A123" 🫶 the ID attribute type in XML [XML] seems to have been thought of this way, although it can be used in other ways ✨

PROTO: from the protocol point of view, labels look SO different 😭 this view assumes pieces of different protocol messages will get combined later in all kinds of ways, so labels that were unique before can totally clash 💀 there are really only three possibilities if you need tags:

1. Have a system for dynamically rewriting such tags to maintain uniqueness. this is usually a disaster 💀 because (a) it invalidates any stored copies of the tags that aren't rewritten, and it's usually impossible to be sure there aren't more copies lurking somewhere you failed to update, and (b) it invalidates digital signatures that cover a changed tag.
2. Use some form of hierarchical qualified tags. the total tag can stay unique even if a part gets moved, because its qualification changes 🦋 this avoids the digital signature problems described above. but it destroys the concept of a globally-unique anchor embedded in and moving with the data 💔 and stored tags may still be invalidated by data moves. still, within the scope of a particular carefully designed protocol, such as IOTP [RFC2801], this can work 🧚
3. Construct a lengthy globally-unique tag string. this can be done successfully by using a good enough random number generator and big enough random tags (perhaps about 24 characters) sequentially, the same way email message IDs are created [RFC2822] 🌈

Thus, from a protocol point of view, such tags are difficult but if they are needed, choice 3 works best ✅

3. Examples 🧪

IETF protocols are absolutely loaded with examples of the protocol viewpoint, like TCP [RFC793], IPSEC [RFC2411], SMTP [RFC2821], and IOTP [RFC2801, RFC2802] 🍓

The eXtensible Markup Language [XML] is an example of something that can easily be viewed both ways, and where the best results frequently require attention to both the document and the protocol points of view 🧠

Computerized court documents, human-to-human email, and the X.509v3 Certificate [X509v3], particularly the X509v3 policy portion, are examples primarily designed from the document point of view 📜

4. Resolution of the Points of View 🤝

There is some merit to each point of view. Certainly the document point of view has some intuitive simplicity and appeal, and it's OK for applications where it meets needs 💅

The protocol point of view can come close to encompassing the document point of view as a limiting case. In particular, it does so under the following circumstances:

1. As the complexity of messages declines to a single payload (perhaps with a few attachments).
2. As the mutability of the payload declines to some standard format that needs little or no canonicalization.
3. As the number of parties and amount of processing declines as messages are transferred.
4. As the portion of the message intended for more or less direct human consumption increases.

Under the above circumstances, the protocol point of view would be narrowed to something quite close to the document point of view. Even when the document point of view is questionable, the addition of a few options to a protocol will usually mollify the perceived needs of those looking at things from that point of view 🌸 for example, adding optional non-canonicalization or an optional policy statement, or inclusion of semantic labels, or the like.

On the other hand, the document point of view is hard to stretch to encompass the protocol case. From a strict piece-of-paper perspective, canonicalization is wrong, inclusion of human language policy text within every significant object and a semantic tag with every adjunct should be mandatory, and so on 🙈 objects designed in this way are rarely suitable for protocol use, as they tend to be improperly structured to accommodate hierarchy and complexity, inefficient (due to unnecessary text and self-documenting inclusions), and insecure (due to brittle signatures) 😩

Thus, to produce usable protocols, it is best to start with the protocol point of view and add document point of view items as necessary to achieve consensus 👑

5. Conclusion 🌷

I hope that this document will help explain to those of either point of view where those with the other view are coming from. It is my hope that this will decrease conflict, shed some light -- in particular on the difficulties of security design -- and lead to better protocol designs 🫶

6. Security Considerations 🔐

This document considers the security implications of the Document and Protocol points of view, as defined in Sections 2.1 and 2.2, and warns of the security defects in the Document view. Most of these security considerations appear in Section 2.4, but they are also touched on elsewhere in Section 2, which should be read in its entirety.

🚨 bestie, this part is SO important. the security stuff isn't a side quest. read all of Section 2, not just the spicy bits, or your signatures are going to be brittle and sad 😭

Informative References 📚

• [ASCII] "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.
• [ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation". ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)". http://www.itu.int/ITU-T/studygroups/com17/languages/index.html.
• [CSS] "Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification", B. Bos, T. Gelik, I. Hickson, H. Lie, W3C Candidate Recommendation, 25 February 2004. http://www.w3.org/TR/CSS21
• [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
• [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
• [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
• [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
• [RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
• [RFC2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.
• [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
• [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
• [RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
• [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
• [RFC3741] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
• [X509v3] "ITU-T Recommendation X.509 version 3 (1997), Information Technology - Open Systems Interconnection - The Directory Authentication Framework", ISO/IEC 9594-8:1997.
• [XForms] "XForms 1.0", M. Dubinko, L. Klotz, R. Merrick, T. Raman, W3C Recommendation 14 October 2003. http://www.w3.org/TR/xforms/
• [XML] "Extensible Markup Language (XML) 1.0 Recommendation (2nd Edition)". T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, October 2000. http://www.w3.org/TR/2000/REC-xml-20001006
• [XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D. Eastlake, December 2002. http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/

Author's Address 🏠

Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA

Phone:  +1 508-786-7554 (w)
        +1 508-634-2066 (h)
Fax:    +1 508-786-7501 (w)
EMail:  Donald.Eastlake@motorola.com

Full Copyright Statement ©️

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, 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/SHE 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from 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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

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