idnits 2.17.1 draft-ietf-conneg-feature-sets-at-urls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-ietf-conneg-feature-syntax-04', but the file name used is 'draft-ietf-conneg-feature-sets-at-urls-00' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([SYNTAX], [FEATURES]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 February 1999) is 9188 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 143 ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'FEATURES' ** Obsolete normative reference: RFC 2068 (ref. 'HTTP1POINT1') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'SYNTAX' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Nortel Networks W. Newman 2 Internet Draft Nortel Networks 3 Updates: 26 February 1999 4 Expires: 26 August 1999 6 Syntax extensions for abbreviating media feature sets with URLs 8 10 Status of this document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 [INTENDED STATUS: This document specifies an Internet standards track 32 protocol for the Internet community, and requests discussion and 33 suggestions for improvements. Please refer to the current edition of 34 the "Internet Official Protocol Standards" (STD 1) for the 35 standardization state and status of this protocol. Distribution of 36 this document is unlimited.] 38 Copyright Notice 40 Copyright (C) The Internet Society 26 February 1999. All Rights 41 Reserved. 43 Abstract 45 Other Internet Drafts from the CONNEG working group describe a 46 syntax[SYNTAX] and vocabulary[FEATURES] for negotiating media feature 47 sets which can be used for transmission of a message. For example, a 48 feature set may specify that full color output up to 800x600 pixels 49 is supported, or that output can have up to 300 dots per inch. These 50 feature sets can be arbitrarily complex, and typical feature set 51 expressions may be hundreds of bytes in length. It would be 52 relatively costly to transmit such long feature set expressions, and 53 this cost could be a significant obstacle to the use of the CONNEG 54 standard to negotiate capabilities for Internet transactions. The 55 problem is likely to particularly severe for low-bandwidth wireless 56 connections to the Internet. 58 This document describes an extension to the CONNEG syntax[SYNTAX] 59 which allows a feature set expression to be represented as an 60 absolute URL, which can then be looked up over another channel, which 61 is not necessarily the channel between the negotiating parties. By 62 using this extension, content negotiation between two parties can 63 proceed with a relatively small exchange of data over the channel 64 between them. Of course, the contents of the URL must still be found 65 through some channel. However, the channel used to find the contents 66 of the URL may have greater bandwidth than the channel between the 67 negotiating parties, and may further benefit from HTTP or other 68 caching mechanisms. 70 This extended syntax is only applicable when the receiver of the 71 feature set has the capability to fetch the contents of absolute 72 URLs. In contrast, the base, unextended syntax[SYNTAX] is applicable 73 to any transmission channel, without requiring any external resources 74 for the feature set transmitter or the feature set receiver. 76 Discussion of this document 78 Discussion of this document should take place on the content 79 negotiation and media feature registration mailing list hosted by the 80 Internet Mail Consortium (IMC): 82 Please send comments regarding this document to: 84 ietf-medfree@imc.org 86 To subscribe to this list, send a message with the body 'subscribe' 87 to "ietf-medfree-request@imc.org". 89 To see what has gone on before you subscribed, please see the mailing 90 list archive at: 92 http://www.imc.org/ietf-medfree/ 94 Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 99 The syntax notation used in this document is the same RFC 2234[ABNF] 100 notation as used in the syntax document[SYNTAX]. 102 Syntax changes 104 In section 4.1 of the syntax document[SYNTAX], "Textual 105 representation of predicates", the definition of "filter" is to be 106 amended so that it reads 108 filter = "(" filtercomp ")" *( ";" parameter ) 109 / "<" absoluteURL ">" *1( ";" "md5" "=" md5value ) 110 md5value = 16*HEX 112 absoluteURL is an absolute URL, with the same syntax as absoluteURI 113 in RFC2068[HTTP1POINT1]: 115 absoluteURL = scheme ":" *( uchar / reserved ) 116 scheme = 1*( ALPHA / DIGIT / "+" / "_" / "." ) 117 uchar = unreserved / escape 118 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" 119 unreserved = ALPHA / DIGIT / safe / extra / national 120 escape = "%" HEX HEX 121 safe = "$" / "-" / "_" / "." 122 extra = "!" / "*" / "'" | "(" | ")" | "," 123 CTL = 125 SP = 126 unsafe = CTL / SP / <"> / "#" / "%" / "<" / ">" 127 national = 129 HEX = "a" / "b" / "c" / "d" / "e" / "f" 130 / "A" / "B" / "C" / "D" / "E" / "F" 131 / DIGIT 133 ALPHA and DIGIT are alphabetic characters and decimal digits 134 respectively, as defined in both RFC 2068[HTTP1POINT1] and RFC 135 2234[ABNF] (using equivalent definitions but different notation). 136 Using the RFC2234 notation: 138 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 139 DIGIT = %x30-39 ; 0-9 141 The extension described in this document does not change the 142 auxiliary predicates extension described in section 6.1.3 of the 143 syntax document[1]. Thus, it is possible for an implementation to 144 support both this extension and the extension described in 6.1.3, in 145 which case a filter will be described by 147 filter = "(" filtercomp ")" *( ";" parameter ) 148 / "<" absoluteURL ">" *1( ";md5=" md5value ) 149 / "(" filtercomp *( ";" parameter ) ")" 150 "where" named-pred-sequence "end" 152 The absoluteURL field holds a URL where a filter description may be 153 found. The md5value field, if present, holds a hexidecimal 154 representation of an MD5 digest[MD5] of the contents of the URL. 156 Interpretation of URLs 158 Any implementation of this extension MUST be able to process URLs 159 with an "http" scheme. Other forms of URL MAY be supported. 161 Any implementation of this extension MUST be able to process data 162 returned with the MIME type "text". Other types MAY be supported. 164 If the MD5 digest of the URL contents is specified, then the 165 implementation MUST compute the MD5 digest of the contents of the URL 166 and compare it with the value specified in md5value. If the two 167 values do not match, the negotiation MUST fail at least as thoroughly 168 as though the capability sets had not matched. 170 The resource retrieved from the URL is parsed as a filter. The 171 implementation MUST return an error if the resource does not contain 172 a filter, or if the resource contains extra non-whitespace text after 173 the filter. 175 The implementation SHOULD provide sufficient information on failure 176 to allow the client to detect failure when reading from the delegated 177 feature set server, and to distinguish this error from other possible 178 error conditions, such as failure to connect to the server which the 179 user is trying to negotiate with. A conforming implementation SHOULD 180 provide distinguished error returns which allow the caller to 181 distinguish between (1) failure to fetch the requested URL contents, 182 (2) failure to match the secure hash function checksum, and (3) 183 failure to parse the feature set in the URL contents. 185 Security Considerations 187 This extension causes new communication channels and new servers to 188 be brought into a content negotiation session. The new servers 189 potentially include both the server specified in the URL and any 190 intermediate systems which cache the contents of the URL. Therefore, 191 this extension increases the number of ways that an adversary could 192 interfere with content negotiation. 194 So long as MD5 is cryptographically secure, the device requesting 195 content negotiation can reduce all these new attacks to denial of 196 service (causing the content negotiation to fail with a checksum 197 error) by specifying the MD5 hash of the desired resource, 199 Further, by specifying the MD5 hash, storing a literal copy of the 200 desired feature set locally, and being able to repeat a failed 201 request without URL abbreviation, the device requesting content 202 negotiation can reduce all these new attacks to degradation of 203 service. When the adversary doesn't interfere, negotiation would 204 require a single round trip over the primary communications link, 205 carrying roughly 40 bytes of compressible URL and 16 bytes of 206 uncompressible MD5 hash. When the adversary does interfere, 207 negotiation requires the first round trip (which fails), followed by 208 retransmissing of the entire literal feature set over the primary 209 link. Thus, the effect of interference is merely to slow the 210 negotiation, not to change its result. 212 It is expected that only a small minority of content negotation 213 applications will be sufficiently critical that such interference 214 will be a significant concern. After all, given that you have an 215 adversary with the capable of tampering with communications between 216 your servers, you are likely to have a long list of problems, and 217 interference with content negotiation may be far from the most 218 serious problem on that list. For this reason, and because the 219 primary motivation for this extension is to allow content negotiation 220 to proceed with minimal bandwidth usage on the primary channel, the 221 MD5 checksum is optional. 223 Acknowledgements 225 The need for this extension was originally pointed out to me by Ted 226 Hardie, the chairman of the CONNEG working group. Graham Klyne was 227 particularly helpful with clarifications and suggestions. An earlier 228 version of this proposal circulated on the CONNEG mailing list 229 received feedback from Al Gilman, Ted Hardie, Koen Holtman, Larry 230 Masinter, and Franklin Reynolds, and a later version circulated 231 within Nortel received additional feedback from Spencer Dawkins and 232 Tim Schweitzer. 234 Author's Address 236 William H. Newman 237 Nortel Networks 238 Enterprise Networks Division 239 1460 Glenville Dr. 240 Richardson TX 75083-3805 241 USA 243 1-972-380-9172 245 billnewn@nortelnetworks.com 247 References 249 [ABNF] 250 Crocker, D. (ed) and P. Overell, "Augmented BNF for Syntax 251 Specifications: ABNF", RFC 2234, November 1997. 253 [FEATURES] 254 Masinter, L., K. Holtman, A. Mutz, and D. Wing, "Media 255 Features for Display, Print, and Fax", Internet Draft 256 , January 1999. 258 [HTTP1POINT1] 259 Fielding, R., J. Gettys, J. Mogul, H. Frystyk, and T. 260 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 261 RFC2068, January 1997. 263 [KEYWORDS] 264 Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [MD5] 268 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 269 April 1992. 271 [SYNTAX] 272 Klyne, G., "A syntax for describing media feature sets", 273 Internet Draft , 274 December 1998. 276 Full Copyright Statement 278 Copyright (C) The Internet Society 26 February 1999. All Rights 279 Reserved. 281 This document and translations of it may be copied and furnished to 282 others, and derivative works that comment on or otherwise explain it 283 or assist in its implementation may be prepared, copied, published 284 and distributed, in whole or in part, without restriction of any 285 kind, provided that the above copyright notice and this paragraph are 286 included on all such copies and derivative works. However, this 287 document itself may not be modified in any way, such as by removing 288 the copyright notice or references to the Internet Society or other 289 Internet organizations, except as needed for the purpose of 290 developing Internet standards in which case the procedures for 291 copyrights defined in the Internet Standards process must be 292 followed, or as required to translate it into languages other than 293 English. 295 The limited permissions granted above are perpetual and will not be 296 revoked by the Internet Society or its successors or assigns. 298 This document and the information contained herein is provided on an 299 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 300 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 301 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 302 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 303 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 305 Expiration Date 307 26 August 1999