Subject: new Internet Draft on feature sets at URLs

From: Bill Newman <[email-masked]>
Date: Fri, 26 Feb 1999 11:18:40 -0800 (PST)

I've just submitted my feature-sets-at-URLs proposal as an Internet
Draft. I was less prompt than Graham: it was only yesterday that I
sent in my request for an official filename. The I-D office is
probably a little bit busy right now, and I haven't received a reply.
Since today is the deadline, I just sent in the draft
itself under my chosen filename,

  <draft-ietf-conneg-feature-sets-at-urls-00.txt>.

I've attached a copy of the draft after my signature so that people
can read it even if there's some delay or even if it is eventually
assigned some other filename.

Note that [email-masked] is currently a better e-mail address than
the one in the draft if you want quick turnaround, but both will work.

  Bill Newman
  [email-masked]

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:

      [email-masked]

   To subscribe to this list, send a message with the body 'subscribe'
   to "[email-masked]".

   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

      [email-masked]

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]