rfc2910.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,598 行 · 第 1/5 页

Network Working Group                                 R. Herriot, Editor
Request for Comments: 2910                             Xerox Corporation
Obsoletes: 2565                                                S. Butler
Category: Standards Track                                Hewlett-Packard
                                                                P. Moore
                                             Peerless Systems Networking
                                                               R. Turner
                                                               2wire.com
                                                                 J. Wenn
                                                       Xerox Corporation
                                                          September 2000


         Internet Printing Protocol/1.1: Encoding and Transport

Status of this Memo

   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 memo is unlimited.

Copyright Notice

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

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 Hypertext Transfer
   Protocol (HTTP) a message body whose Content-Type is
   "application/ipp". This document defines a new scheme named 'ipp' for
   identifying IPP printers and jobs.












Herriot, et al.             Standards Track                     [Page 1]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


   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.1: Model and Semantics [RFC2911]
   Internet Printing Protocol/1.1: Encoding and Transport (this
   document)
   Internet Printing Protocol/1.1: 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.1. A few OPTIONAL operator operations have
   been added to IPP/1.1.

   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 specification documents, and gives background and rationale
   for the IETF working group's major decisions.

   The document, "Internet Printing Protocol/1.1: 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.

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

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












Herriot, et al.             Standards Track                     [Page 2]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


Table of Contents

   1. Introduction ...................................................4
   2. Conformance Terminology ........................................4
   3. Encoding of  the Operation Layer ...............................4
      3.1  Picture of the Encoding ...................................6
         3.1.1 Request and Response...................................6
         3.1.2 Attribute Group........................................6
         3.1.3 Attribute..............................................7
         3.1.4 Picture of the Encoding of an Attribute-with-one-value.7
         3.1.5 Additional-value.......................................8
         3.1.6 Alternative Picture of the Encoding of a Request Or a
               Response...............................................9
      3.2  Syntax of Encoding ........................................9
      3.3  Attribute-group ..........................................11
      3.4  Required Parameters ......................................12
         3.4.1 Version-number........................................12
         3.4.2 Operation-id..........................................12
         3.4.3 Status-code...........................................12
         3.4.4 Request-id............................................13
      3.5  Tags .....................................................13
         3.5.1 Delimiter Tags........................................13
         3.5.2 Value Tags............................................14
      3.6  Name-Length ..............................................16
      3.7  (Attribute) Name .........................................16
      3.8  Value Length .............................................16
      3.9  (Attribute) Value ........................................17
      3.10 Data .....................................................18
   4. Encoding of Transport Layer ...................................18
      4.1  Printer-uri and job-uri ..................................19
   5. IPP URL Scheme ................................................20
   6. IANA Considerations ...........................................22
   7. Internationalization Considerations ...........................23
   8. Security Considerations .......................................23
      8.1  Security Conformance Requirements ........................23
         8.1.1 Digest Authentication.................................23
         8.1.2 Transport Layer Security (TLS)........................24
      8.2  Using IPP with TLS .......................................25
   9. Interoperability with IPP/1.0 Implementations .................25
      9.1  The "version-number" Parameter ...........................25
      9.2  Security and URL Schemes .................................26
   10. References ...................................................27
   11. Authors' Addresses ...........................................29
   12. Other Participants: ..........................................31
   13. Appendix A: Protocol Examples ................................33
      13.1 Print-Job Request ........................................33
      13.2 Print-Job Response (successful) ..........................34
      13.3 Print-Job Response (failure) .............................35



Herriot, et al.             Standards Track                     [Page 3]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


      13.4 Print-Job Response (success with attributes ignored) .....36
      13.5 Print-URI Request ........................................38
      13.6 Create-Job Request .......................................39
      13.7 Get-Jobs Request .........................................40
      13.8 Get-Jobs Response ........................................41
   14. Appendix B: Registration of MIME Media Type Information for
       "application/ipp".............................................42
   15. Appendix C: Changes from IPP/1.0 .............................44
   16. Full Copyright Statement .....................................45

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
   2616 [RFC2616] 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.1: Model and
   Semantics" [RFC2911] defines the semantics of such a message body and
   the supported values. This document specifies the encoding of an IPP
   operation. The aforementioned document [RFC2911] is henceforth
   referred to as the "IPP model document" or simply "model document".

   Note:  the version number of IPP (1.1) and HTTP (1.1) are not linked.
   They both just happen to be 1.1.

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 is the message body part of the HTTP request or
   response and it MUST contain a single IPP operation request or IPP
   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



Herriot, et al.             Standards Track                     [Page 4]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


   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
   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 value
   fields and the request-id.

   The following two sections present the encoding of the operation
   layer in two ways:

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

   An operation request or response MUST use the encoding described in
   these two sections.




















Herriot, et al.             Standards Track                     [Page 5]

RFC 2910            IPP/1.1: Encoding and Transport       September 2000


3.1 Picture of the Encoding

3.1.1 Request and Response

   An operation request or response is encoded as follows:

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

   The first three fields in the above diagram contain the value of
   attributes described in section 3.1.1 of the Model document.

   The fourth field is the "attribute-group" field, and it occurs 0 or
   more times. Each "attribute-group" field represents a single group of
   attributes, such as an Operation Attributes group or a Job Attributes
   group (see the Model document). The IPP model document specifies the
   required attribute groups and their order for each operation request
   and response.

   The "end-of-attributes-tag" field is always present, even when the
   "data" is not present.  The Model document specifies for each