rfc2565.txt

RFC 的详细文档！

Network Working Group                                    R. Herriot, Ed.
Request for Comments: 2565                             Xerox Corporation
Category: Experimental                                         S. Butler
                                                         Hewlett-Packard
                                                                P. Moore
                                                               Microsoft
                                                               R. Turner
                                                              Sharp Labs
                                                              April 1999


         Internet Printing Protocol/1.0: Encoding and Transport

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

IESG Note

   This document defines an Experimental protocol for the Internet
   community.  The IESG expects that a revised version of this protocol
   will be published as Proposed Standard protocol.  The Proposed
   Standard, when published, is expected to change from the protocol
   defined in this memo.  In particular, it is expected that the
   standards-track version of the protocol will incorporate strong
   authentication and privacy features, and that an "ipp:" URL type will
   be defined which supports those security measures.  Other changes to
   the protocol are also possible.  Implementors are warned that future
   versions of this protocol may not interoperate with the version of
   IPP defined in this document, or if they do interoperate, that some
   protocol features may not be available.

   The IESG encourages experimentation with this protocol, especially in
   combination with Transport Layer Security (TLS) [RFC 2246], to help
   determine how TLS may effectively be used as a security layer for
   IPP.








Herriot, et al.               Experimental                      [Page 1]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


Abstract

   This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP). IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies. This document defines the
   rules for encoding IPP operations and IPP attributes into a new
   Internet mime media type called "application/ipp".  This document
   also defines the rules for transporting over HTTP a message body
   whose Content-Type is "application/ipp".

   The full set of IPP documents includes:

      Design Goals for an Internet Printing Protocol [RFC2567]
      Rationale for the Structure and Model and Protocol for the
      Internet Printing Protocol [RFC2568]
      Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
      Internet Printing Protocol/1.0: Encoding and Transport (this
      document)
      Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
      Mapping between LPD and IPP Protocols [RFC2569]

   The document, "Design Goals for an Internet Printing Protocol", takes
   a broad look at distributed printing functionality, and it enumerates
   real-life scenarios that help to clarify the features that need to be
   included in a printing protocol for the Internet. It identifies
   requirements for three types of users: end users, operators, and
   administrators. It calls out a subset of end user requirements that
   are satisfied in IPP/1.0. Operator and administrator requirements are
   out of scope for version 1.0.

   The document, "Rationale for the Structure and Model and Protocol for
   the Internet Printing Protocol", describes IPP from a high level
   view, defines a roadmap for the various documents that form the suite
   of IPP specifications, and gives background and rationale for the
   IETF working group's major decisions.

   The document, "Internet Printing Protocol/1.0: Model and Semantics",
   describes a simplified model with abstract objects, their attributes,
   and their operations that are independent of encoding and transport.
   It introduces a Printer and a Job object. The Job object optionally
   supports multiple documents per Job. It also addresses security,
   internationalization, and directory issues.

   This document "Internet Printing Protocol/1.0: Implementer's Guide",
   gives advice to implementers of IPP clients and IPP objects.





Herriot, et al.               Experimental                      [Page 2]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   The document "Mapping between LPD and IPP Protocols" gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon) implementations.

Table of Contents

   1. Introduction.....................................................4
   2. Conformance Terminology..........................................4
   3. Encoding of  the Operation Layer.................................4
      3.1  Picture of the Encoding.....................................5
      3.2  Syntax of Encoding..........................................7
      3.3  Version-number..............................................9
      3.4  Operation-id................................................9
      3.5  Status-code.................................................9
      3.6  Request-id..................................................9
      3.7  Tags.......................................................10
         3.7.1 Delimiter Tags.........................................10
         3.7.2 Value Tags.............................................11
      3.8  Name-Length................................................13
      3.9  (Attribute) Name...........................................13
      3.10 Value Length...............................................16
      3.11 (Attribute) Value..........................................16
      3.12 Data.......................................................18
   4. Encoding of Transport Layer.....................................18
   5. Security Considerations.........................................19
      5.1  Using IPP with SSL3........................................19
   6. References......................................................20
   7. Authors' Addresses..............................................22
   8. Other Participants:.............................................24
   9. Appendix A: Protocol Examples...................................25
      9.1  Print-Job Request..........................................25
      9.2  Print-Job Response (successful)............................26
      9.3  Print-Job Response (failure)...............................27
      9.4  Print-Job Response (success with attributes ignored).......28
      9.5  Print-URI Request..........................................30
      9.6  Create-Job Request.........................................31
      9.7  Get-Jobs Request...........................................31
      9.8  Get-Jobs Response..........................................32
   10. Appendix C: Registration of MIME Media Type Information for
       "application/ipp"..............................................35
   11. Full Copyright Statement.......................................37










Herriot, et al.               Experimental                      [Page 3]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


1. Introduction

   This document contains the rules for encoding IPP operations and
   describes two layers: the transport layer and the operation layer.

   The transport layer consists of an  HTTP/1.1 request or response. RFC
   2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP
   headers that an IPP implementation supports.

   The operation layer consists of  a message body in an HTTP request or
   response.  The document "Internet Printing Protocol/1.0: Model and
   Semantics" [RFC2566] defines the semantics of such a message body and
   the supported values. This document specifies the encoding of an IPP
   operation. The aforementioned document [RFC2566] is henceforth
   referred to as the "IPP model document"

2. Conformance Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and  "OPTIONAL" in this document are to be
   interpreted as described in RFC 2119 [RFC2119].

3. Encoding of  the Operation Layer

   The operation layer MUST contain a single operation request or
   operation response.  Each request or response consists of a sequence
   of values and attribute groups. Attribute groups consist of a
   sequence of attributes each of which is a name and value.  Names and
   values are ultimately sequences of octets

   The encoding consists of octets as the most primitive type. There are
   several types built from octets, but three important types are
   integers, character strings and octet strings, on which most other
   data types are built. Every character string in this encoding MUST be
   a sequence of characters where the characters are associated with
   some charset and some natural language. A character string MUST be in
   "reading order" with the first character in the value (according to
   reading order) being the first character in the encoding. A character
   string whose associated charset is US-ASCII whose associated natural
   language is US English is henceforth called a US-ASCII-STRING. A
   character string whose associated charset and natural language are
   specified in a request or response as described in the model document
   is henceforth called a LOCALIZED-STRING. An octet string MUST be in
   "IPP model document order" with the first octet in the value
   (according to the IPP model document order) being the first octet in
   the encoding Every integer in this encoding MUST be encoded as a
   signed integer using two's-complement binary encoding with big-endian
   format (also known as "network order" and "most significant byte



Herriot, et al.               Experimental                      [Page 4]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   first"). The number of octets for an integer MUST be 1, 2 or 4,
   depending on usage in the protocol.  Such one-octet integers,
   henceforth called SIGNED-BYTE, are used for the version-number and
   tag fields. Such two-byte integers, henceforth called SIGNED-SHORT
   are used for the operation-id, status-code and length fields. Four
   byte integers, henceforth called SIGNED-INTEGER, are used for values
   fields and the sequence number.

   The following two sections present the operation layer in two ways

      - informally through pictures and description
      - formally through Augmented Backus-Naur Form (ABNF), as specified
        by RFC 2234 [RFC2234]

3.1 Picture of the Encoding

   The encoding for an operation request or response consists of:

  -----------------------------------------------
  |                  version-number             |   2 bytes  - required
  -----------------------------------------------
  |               operation-id (request)        |
  |                      or                     |   2 bytes  - required
  |               status-code (response)        |
  -----------------------------------------------
  |                   request-id                |   4 bytes  - required
  -----------------------------------------------------------
  |               xxx-attributes-tag            |   1 byte  |
  -----------------------------------------------           |-0 or more
  |             xxx-attribute-sequence          |   n bytes |
  -----------------------------------------------------------
  |              end-of-attributes-tag          |   1 byte   - required
  -----------------------------------------------
  |                     data                    |   q bytes  - optional
  -----------------------------------------------

   The xxx-attributes-tag and xxx-attribute-sequence represents four
   different values of "xxx", namely, operation, job, printer and
   unsupported. The xxx-attributes-tag and an xxx-attribute-sequence
   represent attribute groups in the model document. The xxx-
   attributes-tag identifies the attribute group and the xxx-attribute-
   sequence contains the attributes.

   The expected sequence of  xxx-attributes-tag and xxx-attribute-
   sequence is specified in the IPP model document for each operation
   request and operation response.





Herriot, et al.               Experimental                      [Page 5]

RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   A request or response SHOULD contain each xxx-attributes-tag defined
   for that request or response even if there are no attributes except
   for the unsupported-attributes-tag which SHOULD be present only if
   the unsupported-attribute-sequence is non-empty. A receiver of a
   request MUST be able to process as equivalent empty attribute groups:

     a) an xxx-attributes-tag with an empty xxx-attribute-sequence,
     b) an expected but missing xxx-attributes-tag.

   The data is omitted from some operations, but the end-of-attributes-
   tag is present even when the data is omitted. Note, the xxx-
   attributes-tags and end-of-attributes-tag are called 'delimiter-
   tags'. Note: the xxx-attribute-sequence, shown above may consist of 0
   bytes, according to the rule below.

   An xxx-attributes-sequence consists of zero or more compound-
   attributes.

  -----------------------------------------------
  |              compound-attribute             |   s bytes - 0 or more
  -----------------------------------------------

   A compound-attribute consists of an attribute with a single value
   followed by zero or more additional values.

   Note: a 'compound-attribute' represents a single attribute in the
   model document.  The 'additional value' syntax is for attributes with
   2 or more values.

   Each attribute consists of:

  -----------------------------------------------
  |                   value-tag                 |   1 byte
  -----------------------------------------------
  |               name-length  (value is u)     |   2 bytes