Nortel Networks W. Newman
Internet Draft Nortel Networks
Updates: <draft-ietf-conneg-feature-syntax-04.txt> 26 February 1999
Expires: 26 August 1999
Syntax extensions for abbreviating media feature sets with URLs
<draft-ietf-conneg-feature-sets-at-urls-00.txt>
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 = <any US-ASCII control character, octets
0-31 and 127>
SP = <US-ASCII SP, space, octet 32>
unsafe = CTL / SP / <"> / "#" / "%" / "<" / ">"
national = <any octet excluding ALPHA, DIGIT, reserved,
extra, safe, and unsafe>
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
<draft-ietf-conneg-media-features-04.txt>, 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 <draft-ietf-conneg-feature-syntax-04.txt>,
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]
