ICAP Trailers
draft-rousskov-icap-trailers-01

Document Type Active Internet-Draft (individual)
Last updated 2016-10-11
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        A. Rousskov
Internet-Draft                                   The Measurement Factory
Updates: 3507 (if approved)                             October 10, 2016
Intended status: Informational
Expires: April 13, 2017

                             ICAP Trailers
                    draft-rousskov-icap-trailers-01

Abstract

   This document defines an ICAP trailer feature which allows ICAP
   agents to reliably send message metadata after the message body.  The
   ICAP trailer is independent from the HTTP trailer that might also be
   encapsulated in an ICAP message.  ICAP changes defined here are
   backward compatible and address a long-standing ICAP specification
   errata entry.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 13, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Rousskov                 Expires April 13, 2017                 [Page 1]
Internet-Draft                ICAP Trailers                 October 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Motivation and Design Choices . . . . . . . . . . . . . . . .   2
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overall Operation . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Notations . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Extended Use of the Allow Header Field  . . . . . . . . . . .   5
   6.  Message Syntax  . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Trailer Field Syntax  . . . . . . . . . . . . . . . . . . . .   6
   8.  Client Requirements . . . . . . . . . . . . . . . . . . . . .   7
   9.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   8
   10. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Motivation and Design Choices

   ICAP [RFC3507] specification says that the Trailer header field is
   "defined in ICAP the same as [...] in HTTP".  Unfortunately, that
   phrase alone is not enough for trailer-related interoperability in
   the ICAP context because of the following conflicting
   interpretations, requirements, and needs:

   o  Both ICAP and HTTP message headers might contain a Trailer field.

   o  HTTP messages might contain HTTP trailers (that ICAP servers could
      be interested in receiving or even sending).  An HTTP trailer can
      be present with or without an HTTP Trailer header field.

   o  ICAP agents need to distinguish an HTTP trailer from an ICAP
      trailer.

   o  HTTP uses Chunked Transfer Coding [RFC7230] to transmit trailers.
      The chunked coding is applied to the entire HTTP message body.
      This choice places an HTTP trailer inside an HTTP message body.

   o  It is possible to interpret the ICAP specification as placing the
      ICAP trailer either inside the HTTP message body or inside the
      ICAP message body.

   o  ICAP does not chunk-encode ICAP message bodies.  Instead, ICAP
      message bodies contain a combination of zero, one, or two HTTP
      headers possibly followed by a chunked-encoded HTTP message body.

Rousskov                 Expires April 13, 2017                 [Page 2]
Internet-Draft                ICAP Trailers                 October 2016

   o  Chunked coding does not support multiple trailers: Chunked HTTP
Show full document text