rfc2910.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,598 行 · 第 1/5 页

  boolean               SIGNED-BYTE  where 0x00 is 'false' and 0x01 is
                        'true'.

  integer and enum      a SIGNED-INTEGER.

  dateTime              OCTET-STRING consisting of eleven octets whose
                        contents are defined by "DateAndTime" in RFC
                        1903 [RFC1903].

  resolution            OCTET-STRING consisting of nine octets of  2
                        SIGNED-INTEGERs followed by a SIGNED-BYTE. The
                        first SIGNED-INTEGER contains the value of
                        cross feed direction resolution. The second
                        SIGNED-INTEGER contains the value of feed
                        direction resolution. The SIGNED-BYTE contains
                        the units

  rangeOfInteger        Eight octets consisting of 2 SIGNED-INTEGERs.
                        The first SIGNED-INTEGER contains the lower
                        bound and the second SIGNED-INTEGER contains
                        the upper bound.

  1setOf  X             Encoding according to the rules for an
                        attribute with more than 1 value.  Each value
                        X is encoded according to the rules for
                        encoding its type.

  octetString           OCTET-STRING


   The attribute syntax type of the value determines its encoding and
   the value of its "value-tag".

3.10 Data

   The "data" field MUST include any data required by the operation

4. Encoding of Transport Layer

   HTTP/1.1 [RFC2616] is the transport layer for this protocol.

   The operation layer has been designed with the assumption that the
   transport layer contains the following information:





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


      -  the URI of the target job or printer operation
      -  the total length of the data in the operation layer, either as
         a single length or as a sequence of chunks each with a length.

   It is REQUIRED that a printer implementation support HTTP over the
   IANA assigned Well Known Port 631 (the IPP default port), though a
   printer implementation may support HTTP over some other port as well.

   Each HTTP operation MUST use the POST method where the request-URI is
   the object target of the operation, and where the "Content-Type" of
   the message-body in each request and response MUST be
   "application/ipp". The message-body MUST contain the operation layer
   and MUST have the syntax described in section 3.2 "Syntax of
   Encoding". A client implementation MUST adhere to the rules for a
   client described for HTTP1.1 [RFC2616].  A printer (server)
   implementation MUST adhere the rules for an origin server described
   for HTTP1.1 [RFC2616].

   An IPP server sends a response for each request that it receives.  If
   an IPP server detects an error, it MAY send a response before it has
   read the entire request.  If the HTTP layer of the IPP server
   completes processing the HTTP headers successfully, it MAY send an
   intermediate response, such as "100 Continue", with no IPP data
   before sending the IPP response.  A client MUST expect such a variety
   of responses from an IPP server. For further information on HTTP/1.1,
   consult the HTTP documents [RFC2616].

   An HTTP server MUST support chunking for IPP requests, and an IPP
   client MUST support chunking for IPP responses according to  HTTP/1.1
   [RFC2616].  Note: this rule causes a conflict with non-compliant
   implementations of HTTP/1.1 that don't support chunking for POST
   methods, and this rule may cause a conflict with non-compliant
   implementations of HTTP/1.1 that don't support chunking for CGI
   scripts.

4.1 Printer-uri and job-uri

   All Printer and Job objects are identified by a Uniform Resource
   Identifier (URI) [RFC2396] so that they can be persistently and
   unambiguously referenced.  Since every URL is a specialized form of a
   URI, even though the more generic term URI is used throughout the
   rest of this document, its usage is intended to cover the more
   specific notion of URL as well.








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


   Some operation elements are encoded twice, once as the request-URI on
   the HTTP Request-Line and a second time as a REQUIRED operation
   attribute in the application/ipp entity.  These attributes are the
   target URI for the operation and are called printer-uri and job-uri.
   Note: The target URI is included twice in an operation referencing
   the same IPP object, but the two URIs NEED NOT be literally
   identical. One can be a relative URI and the other can be an absolute
   URI.  HTTP/1.1 allows clients to generate and send a relative URI
   rather than an absolute URI.  A relative URI identifies a resource
   with the scope of the HTTP server, but does not include scheme, host
   or port.  The following statements characterize how URLs should be
   used in the mapping of IPP onto HTTP/1.1:

      1. Although potentially redundant, a client MUST supply the target
         of the operation both as an operation attribute and as a URI at
         the HTTP layer.  The rationale for this decision is to maintain
         a consistent set of rules for mapping application/ipp to
         possibly many communication layers, even where URLs are not
         used as the addressing mechanism in the transport layer.
      2. Even though these two URLs might not be literally identical
         (one being relative and the other being absolute), they MUST
         both reference the same IPP object. However, a Printer NEED NOT
         verify that the two URLs reference the same IPP object, and
         NEED NOT take any action if it determines the two URLs to be
         different.
      3. The URI in the HTTP layer is either relative or absolute and is
         used by the HTTP server to route the HTTP request to the
         correct resource relative to that HTTP server.  The HTTP server
         need not be aware of the URI within the operation request.
      4. Once the HTTP server resource begins to process the HTTP
         request, it might get the reference to the appropriate IPP
         Printer object from either the HTTP URI (using to the context
         of the HTTP server for relative URLs) or from the URI within
         the operation request; the choice is up to the implementation.
      5. HTTP URIs can be relative or absolute, but the target URI in
         the operation MUST be an absolute URI.

5. IPP URL Scheme

   The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL
   that identifies either an IPP printer object or an IPP job object.
   The IPP attributes using the 'ipp' scheme are specified below.
   Because the HTTP layer does not support the 'ipp' scheme, a client
   MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP
   [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP
   headers.  The mapping is simple because the 'ipp' scheme implies all
   of the same protocol semantics as that of the 'http' scheme




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


   [RFC2616], except that it represents a print service and the implicit
   (default) port number that clients use to connect to a server is port
   631.

   In the remainder of this section the term 'ipp-URL' means a URL whose
   scheme is 'ipp' and whose implicit (default) port is 631. The term
   'http-URL' means a URL whose scheme is 'http', and the term 'https-
   URL' means a URL whose scheme is 'https',

   A client and an IPP object (i.e. the server) MUST support the ipp-URL
   value in the following IPP attributes.
       job attributes:
           job-uri
           job-printer-uri
       printer attributes:
           printer-uri-supported
       operation attributes:
           job-uri
           printer-uri
   Each of the above attributes identifies a printer or job object. The
   ipp-URL is intended as the value of the attributes in this list, and
   for no other attributes. All of these attributes have a syntax type
   of 'uri', but there are attributes with a syntax type of 'uri' that
   do not use the 'ipp' scheme, e.g. 'job-more-info'.

   If a printer registers its URL with a directory service, the printer
   MUST register an ipp-URL.

   User interfaces are beyond the scope of this document. But if
   software exposes the ipp-URL values of any of the above five
   attributes to a human user, it is REQUIRED that the human see the
   ipp-URL as is.

   When a client sends a request, it MUST convert a target ipp-URL to a
   target http-URL for the HTTP layer according to the following rules:

      1. change the 'ipp' scheme to 'http'
      2. add an explicit port 631 if the URL does not contain an
         explicit port. Note: port 631 is the IANA assigned Well Known
         Port for the 'ipp' scheme.

   The client  MUST use the target http-URL in both the HTTP Request-
   Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] .
   However, the client MUST use the target ipp-URL for the value of the
   "printer-uri" or "job-uri" operation attribute within the
   application/ipp body of the request. The server MUST use the ipp-URL





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


   for the value of the "printer-uri", "job-uri" or "printer-uri-
   supported" attributes within the application/ipp body of the
   response.

   For example, when an IPP client sends a request directly (i.e. no
   proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a
   TCP connection to port 631 (the ipp implicit port) on the host
   "myhost.com" and sends the following data:

    POST /myprinter/myqueue HTTP/1.1
    Host: myhost.com:631
    Content-type: application/ipp
    Transfer-Encoding: chunked
    ...
    "printer-uri" "ipp://myhost.com/myprinter/myqueue"
              (encoded in application/ipp message body)
    ...

   As another example, when an IPP client sends the same request as
   above via a proxy "myproxy.com", it opens a TCP connection to the
   proxy port 8080 on the proxy host "myproxy.com" and sends the
   following data:

    POST http://myhost.com:631/myprinter/myqueue   HTTP/1.1
    Host: myhost.com:631
    Content-type: application/ipp
    Transfer-Encoding: chunked
    ...
    "printer-uri" "ipp://myhost.com/myprinter/myqueue"
              (encoded in application/ipp message body)
    ...

   The proxy then connects to the IPP origin server with headers that
   are the same as the "no-proxy" example above.

6. IANA Considerations

   This section describes the procedures for allocating encoding for the
   following IETF standards track extensions and vendor extensions to
   the IPP/1.1 Encoding and Transport document:

      1. attribute syntaxes - see [RFC2911] section 6.3
      2. attribute groups - see [RFC2911] section 6.5
      3. out-of-band attribute values - see [RFC2911] section 6.7







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


   These extensions follow the "type2" registration procedures defined
   in [RFC2911] section 6.  Extensions registered for use with IPP/1.1
   are OPTIONAL for client and IPP object conformance to the IPP/1.1
   Encoding and Transport document.

   These extension procedures are aligned with the guidelines as set
   forth by the IESG [IANA-CON].  The [RFC2911] Section 11 describes how
   to propose new registrations for consideration.  IANA will reject
   registration proposals that leave out required information or do not
   follow the appropriate format described in [RFC2911] Section 11.  The
   IPP/1.1 Encoding and Transport document may also be extended by an
   appropriate RFC that specifies any of the above extensions.

7. Internationalization Considerations

   See the section on "Internationalization Considerations" in the
   document "Internet Printing Protocol/1.1: Model and Semantics"
   [RFC2911] for information on internationalization. This document adds
   no additional issues.

8. Security Considerations

   The IPP Model and Semantics document [RFC2911] discusses high level
   security requirements (Client Authentication, Server Authentication
   and Operation Privacy). Client Authentication is the mechanism by
   which the client proves its identity to the server in a secure
   manner. Server Authentication is the mechanism by which the server
   proves its identity to the client in a secure manner. Operation
   Privacy is defined as a mechanism for protecting operations from
   eavesdropping.

8.1 Security Conformance Requirements

   This section defines the security requirements for IPP clients and
   IPP objects.

8.1.1 Digest Authentication

   IPP clients MUST support:

      Digest Authentication [RFC2617].