This document reflects implementation experience with RFC 2109 [RFC2109] and obsoletes it.
Extensible negotiation mechanisms need a vocabulary to identify various things which can be negotiated on. To promote interoperability, a registration process is needed to ensure that that this vocabulary, which can be shared between negotiation mechanisms, is developed in an orderly, well-specified, and public manner.
This document discusses requirements and scenarios the registration of this vocabulary, which is the vocabulary of feature tags. Feature tag registration is foreseen as an ongoing, open process which will keep pace with the introduction of new features by software vendors, and other parties such as standards bodies.
This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates.
This document describes an algebra and syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.
This document also outlines an algorithm for feature set matching.
This is presented as a discussion document, with a view to maybe integrating some of these ideas into ongoing 'conneg' work, and to indicate some areas for ongoing collaboration between the IETF and W3C in the area of content description.
This memo defines a MIME 'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used.
This memo defines a media feature tag whose value is a MIME content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data.
This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite, or the URI of a resource containing the feature expression.
All of this information is missing from HTTP entities [RFC2068]. However, there is nothing that would prevent the use of the Content- Disposition header with this HTTP.
Without being standard, the Content-Disposition header has already been introduced by some software products. [HTTP1.1-REV] documents this practice, based on [RFC1806].
This memo also extends the specification to cover [RFC2183] and corrects the common abuse of the Content-Type header to cover presentation information.
WIRE encourages use of long-lived URIs and at the same time supports protocol evolution without having to change currently deployed URIs or URI schemes. The extension is based on a simple URI resolution model that allows an application to dynamically request metadata describing where and how to access a resource. The model can use any generic metadata description language (e.g. RDF) and as the metadata itself is interpreted as a first class resource, metadata resources are no different than any other resource on the Web.
This document details an extension to the Cache-control header in HTTP/1.1 [HTTP/1.1] to add information about IP or domain based access restrictions. It also stresses that Cache-control should apply to all User-agents which work on behalf on a number of users, and not just to caches.
To provide verification of server privacy practices, we assume the existence of one or more independent Trust Authorities. The authority establishes PICS ratings representing server privacy practices. It then issues trust-labels, in the form of digitally signed PICS labels, to organizations for specific domains and paths based on the server privacy practices. The Trust Authority must be able to audit domains to verify their adherence to a given level. Passing these trust-labels along with cookies allows the user agent to support cookie handling preferences based on trusted privacy practices.
This document describes how PICS-headers are used in conjunction with Set-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labels to communicate the privacy practices of servers regarding cookies.
This applicability statement defines classifications of Web server sub-components and clarifies their responsibilities in implementing HTTP/1.1 protocol features, with a discussion of the motivations for doing so.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as "HTTP/1.0".
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".
Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration.
This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.
This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.
An algorithm for feature set matching is also described here.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.
The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism.
Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.