Nortel Networks W. Newman Internet Draft Nortel Networks Updates: 26 February 1999 Expires: 26 August 1999 Syntax extensions for abbreviating media feature sets with URLs Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. [INTENDED STATUS: This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this document is unlimited.] Copyright Notice Copyright (C) The Internet Society 26 February 1999. All Rights Reserved. Abstract Other Internet Drafts from the CONNEG working group describe a syntax[SYNTAX] and vocabulary[FEATURES] for negotiating media feature Newman [Page 1] INTERNET-DRAFT Abbreviating media feature sets 26 February 1999 sets which can be used for transmission of a message. For example, a feature set may specify that full color output up to 800x600 pixels is supported, or that output can have up to 300 dots per inch. These feature sets can be arbitrarily complex, and typical feature set expressions may be hundreds of bytes in length. It would be relatively costly to transmit such long feature set expressions, and this cost could be a significant obstacle to the use of the CONNEG standard to negotiate capabilities for Internet transactions. The problem is likely to particularly severe for low-bandwidth wireless connections to the Internet. This document describes an extension to the CONNEG syntax[SYNTAX] which allows a feature set expression to be represented as an absolute URL, which can then be looked up over another channel, which is not necessarily the channel between the negotiating parties. By using this extension, content negotiation between two parties can proceed with a relatively small exchange of data over the channel between them. Of course, the contents of the URL must still be found through some channel. However, the channel used to find the contents of the URL may have greater bandwidth than the channel between the negotiating parties, and may further benefit from HTTP or other caching mechanisms. This extended syntax is only applicable when the receiver of the feature set has the capability to fetch the contents of absolute URLs. In contrast, the base, unextended syntax[SYNTAX] is applicable to any transmission channel, without requiring any external resources for the feature set transmitter or the feature set receiver. Discussion of this document Discussion of this document should take place on the content negotiation and media feature registration mailing list hosted by the Internet Mail Consortium (IMC): Please send comments regarding this document to: ietf-medfree@imc.org To subscribe to this list, send a message with the body 'subscribe' to "ietf-medfree-request@imc.org". To see what has gone on before you subscribed, please see the mailing list archive at: http://www.imc.org/ietf-medfree/ Conventions used in this document Newman [Page 2] INTERNET-DRAFT Abbreviating media feature sets 26 February 1999 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. The syntax notation used in this document is the same RFC 2234[ABNF] notation as used in the syntax document[SYNTAX]. Syntax changes In section 4.1 of the syntax document[SYNTAX], "Textual representation of predicates", the definition of "filter" is to be amended so that it reads filter = "(" filtercomp ")" *( ";" parameter ) / "<" absoluteURL ">" *1( ";" "md5" "=" md5value ) md5value = 16*HEX absoluteURL is an absolute URL, with the same syntax as absoluteURI in RFC2068[HTTP1POINT1]: absoluteURL = scheme ":" *( uchar / reserved ) scheme = 1*( ALPHA / DIGIT / "+" / "_" / "." ) uchar = unreserved / escape reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" unreserved = ALPHA / DIGIT / safe / extra / national escape = "%" HEX HEX safe = "$" / "-" / "_" / "." extra = "!" / "*" / "'" | "(" | ")" | "," CTL = SP = unsafe = CTL / SP / <"> / "#" / "%" / "<" / ">" national = HEX = "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F" / DIGIT ALPHA and DIGIT are alphabetic characters and decimal digits respectively, as defined in both RFC 2068[HTTP1POINT1] and RFC 2234[ABNF] (using equivalent definitions but different notation). Using the RFC2234 notation: ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 The extension described in this document does not change the auxiliary predicates extension described in section 6.1.3 of the Newman [Page 3] INTERNET-DRAFT Abbreviating media feature sets 26 February 1999 syntax document[1]. Thus, it is possible for an implementation to support both this extension and the extension described in 6.1.3, in which case a filter will be described by filter = "(" filtercomp ")" *( ";" parameter ) / "<" absoluteURL ">" *1( ";md5=" md5value ) / "(" filtercomp *( ";" parameter ) ")" "where" named-pred-sequence "end" The absoluteURL field holds a URL where a filter description may be found. The md5value field, if present, holds a hexidecimal representation of an MD5 digest[MD5] of the contents of the URL. Interpretation of URLs Any implementation of this extension MUST be able to process URLs with an "http" scheme. Other forms of URL MAY be supported. Any implementation of this extension MUST be able to process data returned with the MIME type "text". Other types MAY be supported. If the MD5 digest of the URL contents is specified, then the implementation MUST compute the MD5 digest of the contents of the URL and compare it with the value specified in md5value. If the two values do not match, the negotiation MUST fail at least as thoroughly as though the capability sets had not matched. The resource retrieved from the URL is parsed as a filter. The implementation MUST return an error if the resource does not contain a filter, or if the resource contains extra non-whitespace text after the filter. The implementation SHOULD provide sufficient information on failure to allow the client to detect failure when reading from the delegated feature set server, and to distinguish this error from other possible error conditions, such as failure to connect to the server which the user is trying to negotiate with. A conforming implementation SHOULD provide distinguished error returns which allow the caller to distinguish between (1) failure to fetch the requested URL contents, (2) failure to match the secure hash function checksum, and (3) failure to parse the feature set in the URL contents. Security Considerations This extension causes new communication channels and new servers to be brought into a content negotiation session. The new servers potentially include both the server specified in the URL and any intermediate systems which cache the contents of the URL. Therefore, Newman [Page 4] INTERNET-DRAFT Abbreviating media feature sets 26 February 1999 this extension increases the number of ways that an adversary could interfere with content negotiation. So long as MD5 is cryptographically secure, the device requesting content negotiation can reduce all these new attacks to denial of service (causing the content negotiation to fail with a checksum error) by specifying the MD5 hash of the desired resource, Further, by specifying the MD5 hash, storing a literal copy of the desired feature set locally, and being able to repeat a failed request without URL abbreviation, the device requesting content negotiation can reduce all these new attacks to degradation of service. When the adversary doesn't interfere, negotiation would require a single round trip over the primary communications link, carrying roughly 40 bytes of compressible URL and 16 bytes of uncompressible MD5 hash. When the adversary does interfere, negotiation requires the first round trip (which fails), followed by retransmissing of the entire literal feature set over the primary link. Thus, the effect of interference is merely to slow the negotiation, not to change its result. It is expected that only a small minority of content negotation applications will be sufficiently critical that such interference will be a significant concern. After all, given that you have an adversary with the capable of tampering with communications between your servers, you are likely to have a long list of problems, and interference with content negotiation may be far from the most serious problem on that list. For this reason, and because the primary motivation for this extension is to allow content negotiation to proceed with minimal bandwidth usage on the primary channel, the MD5 checksum is optional. Acknowledgements The need for this extension was originally pointed out to me by Ted Hardie, the chairman of the CONNEG working group. Graham Klyne was particularly helpful with clarifications and suggestions. An earlier version of this proposal circulated on the CONNEG mailing list received feedback from Al Gilman, Ted Hardie, Koen Holtman, Larry Masinter, and Franklin Reynolds, and a later version circulated within Nortel received additional feedback from Spencer Dawkins and Tim Schweitzer. Author's Address William H. Newman Nortel Networks Enterprise Networks Division Newman [Page 5] INTERNET-DRAFT Abbreviating media feature sets 26 February 1999 1460 Glenville Dr. Richardson TX 75083-3805 USA 1-972-380-9172 billnewn@nortelnetworks.com References [ABNF] Crocker, D. (ed) and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [FEATURES] Masinter, L., K. Holtman, A. Mutz, and D. Wing, "Media Features for Display, Print, and Fax", Internet Draft , January 1999. [HTTP1POINT1] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2068, January 1997. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [SYNTAX] Klyne, G., "A syntax for describing media feature sets", Internet Draft , December 1998. Full Copyright Statement Copyright (C) The Internet Society 26 February 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 Newman [Page 6] INTERNET-DRAFT Abbreviating media feature sets 26 February 1999 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. Expiration Date 26 August 1999 Newman [Page 7]