RFC 2703

Protocol-independent Content Negotiation Framework

📅 published September 1999, from ietf

RFC 2703: Protocol-independent Content Negotiation Framework 💖

Okay bestie, this one is RFC 2703, written by G. Klyne from 5GM/Content Technologies, dated September 1999, and filed as Category: Informational 🎀 So it's a "here's some info for the community" doc, not an official standard.

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 (C) The Internet Society (1999). All Rights Reserved.

Abstract ✨

Lots of Internet application protocols need content negotiation for the resources they deal with. MIME media types [1,2] give us a standard way to handle one big axis of variation, but resources can also vary in ways that current MIME headers just can't express 😭

So this memo lays out terminology, an abstract framework, and goals for protocol-independent content negotiation, and it flags some technical issues that might need sorting out 🧚

The abstract framework doesn't try to specify the negotiation process itself. It just gives a sense of the scope and shape any such spec might have. The goals describe the properties a content negotiation mechanism should have ✅

Table of Contents 🗂️

   1. Introduction.............................................2
     1.1 Structure of this document ...........................3
     1.2 Discussion of this document ..........................3
   2. Terminology and definitions..............................3
   3. Framework................................................7
     3.1 Abstract framework for content negotiation ...........8
        3.1.1 The negotiation process..........................9
     3.2 Abstract model for negotiation metadata .............10
     3.3 Text representation for negotiation metadata ........11
     3.4 ASN.1 description of negotiation metadata ...........11
     3.5 Protocol binding guidelines .........................11
   4. Goals...................................................12

     4.1 Generic framework and metadata goals ................12
     4.2 Protocol-specific deployment goals ..................12
   5. Technical issues........................................14
     5.1 Non-message resource transfers ......................14
     5.2 End-to-end vs hop-by-hop negotiations ...............14
     5.3 Third-party negotiation .............................15
     5.4 Use of generic directory and resolution services ....15
     5.5 Billing issues ......................................15
     5.6 Performance considerations ..........................15
     5.7 Confidence levels in negotiated options .............16
   6. Security Considerations.................................16
     6.1 Privacy .............................................16
     6.2 Denial of service attacks ...........................17
     6.3 Mailing list interactions ...........................17
     6.4 Use of security services ............................17
     6.5 Disclosure of security weaknesses ...................18
        6.5.1 User agent identification.......................18
        6.5.2 Macro viruses...................................18
        6.5.3 Personal vulnerability..........................18
     6.6 Problems of negotiating security ....................18
   7. Acknowledgements........................................18
   8. References..............................................19
   9. Author's Address........................................19
   10. Full Copyright Statement...............................20

1. Introduction 🌸

Same vibe as the abstract, but the intro is where the setup happens 💅 Lots of Internet application protocols need content negotiation for the resources they interact with. MIME media types [1, 2] handle one major axis of variation really well, but resources also vary in ways that currently available MIME headers can't express. Iykyk 🙈

This memo lays out terminology, a framework, and some goals for a protocol-independent content negotiation framework, and it identifies some technical issues that may need to be addressed 🦋

The framework doesn't try to specify the content negotiation process. Instead, it gives a sense of the scope and form that any such specifications might take 👑

The goals section is meant to lay out the properties a content negotiation framework should have, without assuming what shape that framework will end up taking 🫶

1.1 Structure of this document 🗺️

The main part of this memo covers four big areas:

Section 2 defines some of the terms that get used with a special meaning. 📖

Section 3 outlines a proposed framework for describing protocol-independent content negotiation. 🧩

Section 4 describes various goals for content negotiation. 🎯

Section 5 discusses some of the technical issues raised by this document, with cross-references to other work where it makes sense. 🔗

1.2 Discussion of this document 💬

Discussion of this document should happen on the content negotiation and media feature registration mailing list, which is hosted by the Internet Mail Consortium (IMC) 💌

Send your comments about this document to:

ietf-medfree@imc.org

To subscribe to the list, send a message with the body 'subscribe' to "ietf-medfree-request@imc.org" 🍓

To see what's been discussed before you joined, check out the mailing list archive at:

http://www.imc.org/ietf-medfree/

2. Terminology and definitions ✨

okay bestie, this section is the glossary 📖 It's got a bunch of terms that the content negotiation docs use with a very specific meaning, and a lot of them were borrowed and tweaked from [5]. The list is in alphabetical order, so you can scroll like it's a playlist 🎀

Capability An attribute of a sender or receiver (usually the receiver) that shows it can generate or process a certain type of message content. 💪

Characteristic A description of a sender or receiver that hints at a possible capability or preference. 🔍

Choice message A choice message sends back a representation of some selected variant (or variants), along with the variant list of the negotiable resource. It can show up when the sender knows enough to pick a variant for the receiver, and it also needs to tell the receiver about the other variants that are around. 🦋

Connected mode A mode where sender and receiver are directly connected, so nothing stops them from working out each other's capabilities for sure. (See also: Session mode) 🔗

Content feature (see Feature) 💅

Content negotiation An exchange of information (negotiation metadata) that leads to picking the right representation (variant) when a data resource gets transferred. 🤝

Data resource A network data object that can be transferred. Data resources can come in multiple representations (like different languages, data formats, sizes, or resolutions) or differ in other ways too. (See also: Message, Resource) 🌈

Feature A piece of information about the media handling properties of a message passing system component or of a data resource. ✨

Feature tag A name that identifies a "feature". 🏷️

Feature set Information about a sender, recipient, data file, or other participant in a message transfer that describes the set of features it can handle. 🧩

Basically, a 'feature' is one identified attribute of a resource, while a 'feature set' is the full set of possible attributes. Think of it like one lipstick shade vs. the whole makeup bag 💄

List message A list message sends the variant list of a negotiable resource, but no variant data. It can show up when the sender doesn't want to send a particular variant, or isn't allowed to. 📋

Media feature Information that says what facilities are expected to be available so the message content can be rendered or presented properly. Media features aren't meant to include anything that affects message transmission. 🎬

Message Data that gets transmitted from a sender to a receiver, along with any encapsulation that might be applied. A data resource is the original data (which might be available in a bunch of representations), while a message holds the representation(s) that actually get sent. Negotiation metadata isn't usually counted as part of a message. 💌

Message data is different from other transmitted data because its content is completely fixed before transmission starts. 🔒

Negotiated content Message content that content negotiation has selected. 🎯

Negotiation (See: content negotiation) 🔁

Negotiable resource A data resource that has multiple representations (variants) attached to it. Picking the right variant to send in a message happens through content negotiation between the sender and recipient. 💫

Negotiation metadata Information that the sender and receiver of a message swap during content negotiation so they can work out which variant should be transferred. 📨

Neighbouring variant A particular representation (variant) of a variant resource that can safely be assumed to be under the same access controls as the variant resource itself. Not every variant of a variant resource is necessarily a neighbouring variant. Whether a variant is one or not matters a LOT for security considerations, especially when deciding if that variant can be sent to a receiver instead of the matching variant resource. It can also matter when deciding if a sender is authorized to send a particular variant. 🚨🔐

Preference An attribute of a sender or receiver (usually the receiver) that shows a preference to generate or process one particular type of message content over another, even when both are possible. 💖

Receiver A system component (device or program) that receives a message. 📥

Receiver-initiated transmission A message transmission that's requested by the eventual receiver of the message. It's sometimes called 'pull' messaging. For example, an HTTP GET operation. 🙋‍♀️

Resource A document, data file, or facility that gets accessed or transmitted across a network. (See also: Data resource) 🌐

Sender A system component (device or program) that transmits a message. 📤

Sender-initiated transmission A message transmission that's kicked off by the sender of the message. It's sometimes called 'push' messaging. For example, sending an e-mail. 📬

Session mode A mode of message transmission where the sender gets confirmation of delivery in the same application session (usually the same transport connection) that was used to send the message. (See also: connected mode, store and forward mode) 🤳

Store and forward mode A mode of message transmission where the message gets held in storage for an unknown amount of time on message transfer agents before it's delivered. ⏳

Syntax The form used to express some value, especially the format used to express a media feature value or a feature set. (See also: feature value, feature set, type.) 📐

Transmission The process of moving a message from a sender to a receiver. This can include content negotiation. 🚚

Type The range of values that some identifier of a variable can indicate, especially the range of values a feature tag can indicate. (See also: feature, syntax.) 🎨

NOTE: this is different from how the LDAP/X.500 directory community uses the term. They use "attribute type" to mean an identifier for a value in a directory entry, and "attribute syntax" to mean the range of allowed attribute values. Don't mix these up, bestie! 🙈

User agent A system component that prepares and transmits a message, or receives a message and displays, prints, or otherwise processes its contents. 🖥️

Variant One of several possible representations of a data resource. 🧁

Variant list A list containing variant descriptions, which can be bound to a negotiable resource. 🗂️

Variant description A machine-readable description of a variant resource, usually found in a variant list. A variant description holds a variant resource identifier and various attributes that describe the properties of the variant. 🪪

Variant resource A data resource for which multiple representations (variants) are available. 🌸

3. Framework 🏗️

okay so for this document, message transmission protocol capabilities are completely ignored. The assumption is that some separate, orthogonal mechanism deals with them. 🙅‍♀️

Content negotiation covers three things:

  1. expressing the capabilities of the sender and the data resource to be transmitted (as far as a particular message is concerned),
  2. expressing the capabilities of a receiver (before the message is transmitted), and
  3. a protocol that the capabilities get exchanged through.

These negotiation elements are handled by a negotiation framework made up of several design elements, with their dependencies shown in the diagram below. 🗺️

          [ Abstract  ]               [   Abstract   ]
          [negotiation]               [ negotiation  ]
          [  process  ]               [   metadata   ]
                |                            |
                V                            V
          [Negotiation]               [ Negotiation  ]
          [ protocol  ]               [   metadata   ]
          [  binding  ]               [representation]
                |                            |
                 -------              -------
                        |            |
                        V            V
                    [Application protocol]
                    [   incorporating    ]
                    [content negotiation ]

Inside this overall framework, expressing the capabilities of the sender and receiver is covered by negotiation metadata. The protocol for exchanging capabilities is covered by the abstract negotiation framework and how it gets bound to a specific application protocol. 🤓

Application protocol independence comes from separating the abstract negotiation process and metadata from the concrete representations and protocol bindings. That's the glow-up that keeps things flexible 🦋✨

3.1 Abstract framework for content negotiation 💭

The negotiation framework lets the sender and receiver of a message exchange negotiation metadata, and that leads to finding a data format that the sender can provide and the recipient can process. So there are three main elements that the negotiation process is about, and whose capabilities the negotiation metadata describes: the sender, the transmitted data file format, and the receiver. 🎀

The life of a data resource can be viewed like this:

         (C)     (T)     (F)
     [A]-->--[S]-->--[R]-->--[U]

where:

  • [A] = author of document
  • (C) = original document content
  • [S] = message sending system
  • (T) = transmitted data file (representation of (C))
  • [R] = receiving system
  • (F) = formatted (rendered) document data (presentation of (C))
  • [U] = user or consumer of a document

Here, it's [S] and [R] that swap negotiation metadata to decide the form of (T), so those are the elements we're focusing on. 👀

Negotiation metadata provided by [S] takes account of the available document content (C) (for example, which resource variants exist) as well as the sender's own ability to offer that content in a variety of formats. 📦

Negotiation metadata provided by [R] similarly takes account of the needs and preferences of its user [U], as well as the receiver's own capabilities to process and render the received data. 🥰

3.1.1 The negotiation process ✨

okay so negotiation between the sender [S] and the receiver [R] is basically a back-and-forth of negotiation metadata exchanges 💬 that keeps going until either party decides on a specific data file (T) to send. if the sender makes the final call, it can just send the file directly 📨. otherwise the receiver has to tell the sender what it picked, and then the sender sends that one 🎀

this process means there's an open-ended exchange of info between sender and receiver 🦋 not every implementation is expected to do it with the full generality that implies. instead, every concrete negotiation can be seen as a subset of this process 🌸

for example, Transparent Content Negotiation (TCN) [5] uses a model where one of these things happens:

  • the recipient requests a resource with no variants, so the sender just sends what's available 📦
  • a variant resource is requested, so the server replies with a list of the available variants, and the client picks one from that list 📝
  • the recipient requests a variant resource and also sends negotiation metadata (in the form of 'Accept' headers) so the server can make the choice on the client's behalf 🧚

another, simpler example is fax negotiation 📠 here the intended recipient declares its capabilities, and the sender picks a message variant that matches 💅

each of these is a particular case of the general negotiation process we just described 💖 similar vibes show up with directory services, or with MIME 'Multipart/alternative' used alongside e-mail message transmission 📧

3.2 Abstract model for negotiation metadata 🫶

so a simple but general negotiation framework has been described, based on exchanging negotiation metadata between sender and recipient ✨ how the data actually gets exchanged isn't important to the abstract framework, but we do need to say something about the general form of the metadata 🤓

the terminology and definitions section of this document puts constraints on the form of negotiation metadata, so the descriptions that follow should be read alongside the definitions they refer to 📖

negotiation metadata needs to cover these elements:

  • Media feature: a way to describe attributes of a data resource 🎨
  • Feature set: a description of a range of possible media feature combinations, which can be offered by a sender, represented by a data file format, or processed by a receiver 🍓
  • One or more naming schemes for labelling media features and feature sets. these should be backed up by some kind of registration process to make sure names are unique and to encourage a common vocabulary for commonly used features 🏷️
  • A framework of data types for media features, showing the range and properties of value types that can be represented 🔢
  • A way to combine media features into feature sets, able to express feature dependencies within a feature set (e.g. 640x480 pixel size and 256 colours, or 800x600 pixel size and 16 colours) 🌈
  • Some way to rank feature sets based on sender and receiver preferences for different feature values 👑

3.3 Text representation for negotiation metadata 🌸

a concrete textual representation for media feature values and feature set descriptions would give us a common vocabulary for feature data in text-based protocols like HTTP and SMTP 💜

when you define a textual representation, you have to figure out which character sets are allowed 🔤 whether negotiation metadata needs full international character support depends on the framework of data types adopted for media features. negotiation metadata gets used as a protocol element (not something the user directly sees) rather than part of the message content, so support for extended character sets may be not required 🙈

a textual representation for negotiation metadata would also imply a textual representation for media feature names, and for expressions of the media feature combining algebra 🧮

3.4 ASN.1 description of negotiation metadata 🧚

for non-text-based protocols, an ASN.1 description and encoding designation for negotiation metadata could be helpful 🙌 it would let the common negotiation framework fit into ASN.1-derived protocols like X.400, X.500, LDAP and SNMP 🛠️

an ASN.1 description of negotiation metadata formats also suggests that a separate media feature naming scheme based on ISO object identifiers would be valuable 🔥

3.5 Protocol binding guidelines 🎀

specific protocol bindings are going to be needed to use the abstract framework for negotiation 🔗

details of protocol bindings would be beyond the scope of this work, but guidelines maybe not. (SASL might provide a useful model here.) 👀

4. Goals 🎯

these goals come in two categories:

  1. Negotiation framework and metadata goals, which address the broad goals of negotiation in a protocol-independent way 🌍
  2. Specific goals about deploying negotiation in the context of a specific protocol (e.g. relation to HTTP protocol operations, cache interactions, security issues, existing HTTP negotiation mechanisms, application to variant selection, etc.). these would be addressed by a specific protocol binding for the negotiation framework 💅

4.1 Generic framework and metadata goals 🌷

  • A common vocabulary for designating features and feature sets 🗣️
  • A stable reference for commonly used features 📌
  • An extensible framework, so new features can be adopted quickly and easily 🚀
  • Permit an indication of quality or preference ⭐
  • Capture dependencies between feature values 🔗
  • A uniform framework mechanism for exchanging negotiation metadata should be defined. it should be able to cover existing negotiable features and be extensible to future (unanticipated) features 🦄
  • Efficient negotiation should be possible in both receiver initiated ('pull') and sender initiated ('push') message transfers 🫸🫷
  • The structure of the negotiation procedure framework should stand independently of any particular message transfer protocol 🧩
  • Be capable of addressing the role of content negotiation in meeting the communication needs of less able computer users 💛

4.2 Protocol-specific deployment goals 💻

  • A negotiation should generally result in identifying a mutually acceptable form of message data to be transferred 🤝
  • If capabilities are sent at times other than when a message is transmitted, they should include enough information to be verified and authenticated 🔐
  • A capability assertion should clearly identify the party the capabilities apply to, the party they're being sent to, and some indication of their date/time or range of validity 📅 to be secure, capability assertions should be protected against interception and against valid data being swapped out for invalid data 🛡️
  • A request for capability information, if sent other than in response to delivery of a message, should clearly identify the requester, the party whose capabilities are being requested, and the time of the request. it should include enough information to let the request be authenticated 🪪
  • In the context of a given application, content negotiation may use one or several methods for transmitting, storing, or distributing capabilities 📬
  • The negotiation mechanism should include a standardized method for associating features with resource variants 🔖
  • Negotiation should provide a way to indicate provider and recipient preferences for specific features 🎚️
  • Negotiation should have the least possible impact on network resource consumption, particularly bandwidth and the number of protocol round-trips required 🏃‍♀️
  • Systems should protect the privacy of users' profiles and providers' inventories of variants 🔒
  • Protocol specifications should identify, and permit, mechanisms to verify the reasonable accuracy of any capability data provided 🔍
  • Negotiation must not significantly jeopardize the overall operation or integrity of any system in the face of erroneous capability data, whether it was provided accidentally or maliciously 🚨
  • Intelligent gateways, proxies, or caches should be allowed to take part in the negotiation 🧠
  • Negotiation metadata should be regarded as cacheable, and explicit cache control mechanisms should be provided, so people don't reach for ad-hoc cache-busting techniques 🗄️
  • Automatic negotiation should not pre-empt a user's ability to choose a document format from those available 🙋‍♀️

5. Technical issues 🧪

5.1 Non-message resource transfers 🌊

the ideas for generic content negotiation were conceived and developed with message-oriented data transmissions in mind 📨

message data is defined elsewhere as data whose entire content is decided before data transmission starts. the following are examples of non-message data transfers:

  • streamed data,
  • interactive computations,
  • real-time data acquisition,

so here's the big question 🤔 does a proposed approach to negotiation based on message data reasonably extend to streamed data (e.g. data whose content isn't fully determined by the time the first data items are transmitted)?

it may be that the metadata will still apply, but the abstract negotiation process framework might be insufficient for these more demanding circumstances 🥲

5.2 End-to-end vs hop-by-hop negotiations 🔁

could this distinction place any special demands or constraints on a generic negotiation framework, or is it simply a protocol issue? 🧐

  • End-to-end negotiation gives the greatest confidence in the outcome 💯
  • Hop-by-hop may have advantages in a network of occasionally-connected systems, but it will place additional demands on intervening message transmission agents 🛰️

hop-by-hop negotiation means negotiation responses aren't necessarily a definitive indication of an endpoint system's capabilities 👀 this in turn implies a possible need for time-to-live and re-verification mechanisms to flush out stale negotiation data 🗑️

note: one of the stated goals is to let proxies and caches take part in the negotiation process, as appropriate ✨

5.3 Third-party negotiation 🕵️‍♀️

an extension of the hop-by-hop vs. end-to-end theme is to think about what happens when any system other than an endpoint participant in the message transmission is allowed to supply negotiation metadata 🤷‍♀️

any use of a third party in the negotiation process inevitably increases the chances of errors creeping into the negotiation metadata 😬

one example of a third-party participant that gets suggested a lot is a directory service using LDAP or similar protocols 📇 what extra steps need to be taken to make sure negotiation metadata supplied this way is reasonably reliable? 🤔

5.4 Use of generic directory and resolution services 📚

it's clearly helpful to use existing protocols such as LDAP to exchange content negotiation metadata 💖

to make this happen, it would be necessary to define directory or other schema elements that are specific to content negotiation 🧩 for example, an LDAP attribute type for a media feature set 🎀

5.5 Billing issues 💸

Okay so negotiation can get messy with billing 🙈 because it can mean a two-way exchange of data that doesn't always finish in one connection. Who pays for the return messages?? It's a real question in non-connected places like e-mail or fax 📠.

5.6 Performance considerations 🚀

Negotiation can hit performance in both good and bad ways, bestie ✨

The obvious downside is that swapping extra data eats some extra bandwidth 📉. There's also the round-trip or third-party query delay while the negotiation metadata gets exchanged before the message itself even starts moving 😩.

Over the Internet there are some bandwidth/latency trade-offs you can make 🦋. In Internet e-mail, for example, the MIME type multipart/alternative can send multiple versions of a resource. That keeps latency low by spending more bandwidth on a bigger pile of data 💜. HTTP [7] goes the other way. It suggests a negotiation mechanism that saves bandwidth but adds a round-trip delay (section 12.2, Agent-driven negotiation) 🐢.

To balance out the performance hit of content negotiation, we hope overall network efficiency improves when the most useful data format gets delivered to its intended recipient first time, almost every time 🌈.

5.7 Confidence levels in negotiated options 🎯

Sometimes, like when there's been a direct exchange of info with the remote system, the parties are super confident about how the negotiation turned out 😌. Then they can just send the data without checking whether those options were okay 💅.

Other times the options are basically a best guess. In those cases the parties might need a way to reject the options actually used in favour of some other set 🙅.

This is probably tied up with performance considerations 🔗.

A pattern that TCN [5] uses is to define a negotiation procedure that guarantees a correct outcome 🔐. That becomes the foundation for a faster procedure that grabs easy-but-less-reliable info to optimize things. It has checks built in so the final result matches what the full negotiation would have given 🧠. Those faster procedures can fall back to the original "full cycle" negotiation procedure sometimes, but most of the time they're expected to finish by the optimized route 🏁.

6. Security Considerations 🔒

Bestie, this part is serious and I'm not gonna water it down 🫶. The purpose of this section is to identify and catalogue some security issues that feature negotiation protocols should consider.

6.1 Privacy 🙈

Privacy may be adversely affected by:

  • Unintended disclosure of personal information.
  • Spoofed requests for negotiation data simply for the purposes of gathering information, and not as part of a bona fide message transmission.

6.2 Denial of service attacks 💀

Service denial may be caused by:

  • Injection of false negotiation data.
  • Excessive requests for negotiation data

6.3 Mailing list interactions 📬

Content negotiation with final recipients is kinda at odds with normal practice for maintaining lists for redistribution of Internet mail 😬.

It may be appropriate for a sender to negotiate data formats with a list manager, and for a list manager to negotiate with message recipients ✨. But the common practice of keeping the identities and addresses of mailing list subscribers confidential suggests that end-to-end negotiation through a mailing list is not consistent with good security practice 🔐.

6.4 Use of security services 🛡️

Protocols that employ security services for message transfer should also apply those services to content negotiation:

  • Authenticated requests for negotiation metadata give a potential recipient a way to moderate the distribution of media capability information 👑.
  • Authentication of negotiation metadata lets potential message senders avoid using incorrect information injected by some other party 🙅.
  • Encryption of negotiation data may help prevent disclosure of sensitive capability-related information to snoopers 🕵️.
  • Conducting a negotiation exchange over an authenticated or encrypted protocol session (e.g. SASL), transport connection or network path (e.g. TLS, IPSEC) can provide for mutual authentication of both parties in an exchange of negotiation data 🤝.

6.5 Disclosure of security weaknesses 🫣

6.5.1 User agent identification

Disclosure of capability information may allow a potential attacker to deduce which message handling agent is used. That can lead to exploiting known security weaknesses in that agent 😱.

6.5.2 Macro viruses

Macro viruses are a widespread problem among apps like word processors and spreadsheets 🦠. Knowing which applications a recipient uses (e.g. by file format) may assist a malicious attack. But such viruses can spread easily without that knowledge, by sending multiple messages where each one infects a specific application version 💥.

6.5.3 Personal vulnerability

One application of content negotiation is enabling delivery of message content that meets the specific requirements of less able people 🫶. Disclosing this information may make those people potential targets for attacks that play on their personal vulnerabilities 💔.

6.6 Problems of negotiating security 🔐

If feature negotiation is used to decide on security-related features, some special problems can pop up if the negotiation procedure can be subverted to prevent effective security procedures from being selected 🚨.

The security considerations section of GSS-API negotiation [8] discusses the use of integrity protecting mechanisms with security negotiation 🧐.

7. Acknowledgements 🌸

Some material in this memo has been derived from earlier memos by Koen Holtman, Andrew Mutz, Ted Hardie, Larry Masinter, Dan Wing, Neil Joffe. Matters relating to the importance and relevance of content negotiation to less-able users were raised by Al Gilman 🎀.

This memo has also been informed by the debates of the IETF "conneg" working group 🧚.

8. References 📚

[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 1: Format of Internet message bodies", RFC 2045, November 1996.

[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 2: Media Types", RFC 2046, November 1996.

[3] Holtman, K., et al., "The Alternates Header Field", Work in Progress.

[4] Hardie, T., "Scenarios for the Delivery of Negotiated Content", Work in Progress.

[5] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

[6] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.

[7] Fielding, R., Gettys, J., Mogul, J., Frytyk, H. and T. Berners-Lee, "Hyptertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[8] Blaize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.

9. Author's Address 📍

Graham Klyne
5th Generation Messaging Ltd.  Content Technologies Ltd.
5 Watlington Street            1220 Parkview, Arlington Business Park
Nettlebed                      Theale
Henley-on-Thames, RG9 5AB      Reading, RG7 4SA
United Kingdom                 United Kingdom.

Phone: +44 1491 641 641        +44 118 930 1300
Fax:   +44 1491 641 611        +44 118 930 1301
EMail: GK@ACM.ORG

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 🌷

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

📦 where this page comes from