rfc2565.txt

RFC 的详细文档！

   The type of the value in the model document determines the encoding
   in the value and the value of the value-tag.

3.12 Data

   The data part MUST include any data required by the operation

4. Encoding of Transport Layer

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

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

      - 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.
   In addition, a printer may have to support another port for privacy
   (See Section 5 "Security Considerations").

   Note: even though port 631 is the IPP default, port 80 remains the
   default for an HTTP URI.  Thus a URI for a printer using port 631
   MUST contain an explicit port, e.g. "http://forest:631/pinetree".  An
   HTTP URI for IPP with no explicit port implicitly reference port 80,
   which is consistent with the rules for HTTP/1.1. 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 [RFC2068]. A
   printer (server) implementation MUST adhere the rules for an origin
   server described for HTTP1.1 [RFC2068].

   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



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


   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 [RFC2068].

5. Security Considerations

   The IPP Model document defines an IPP implementation with "privacy"
   as one that implements Secure Socket Layer Version 3 (SSL3).  Note:
   SSL3 is not an IETF standards track specification. SSL3 meets the
   requirements for IPP security with regards to features such as mutual
   authentication and privacy (via encryption). The IPP Model document
   also outlines IPP-specific security considerations and should be the
   primary reference for security implications with regards to the IPP
   protocol itself.

   The IPP Model document defines an IPP implementation with
   "authentication" as one that implements the standard way for
   transporting IPP messages within HTTP 1.1. These include the security
   considerations outlined in the HTTP 1.1 standard document [RFC2068]
   and Digest Access Authentication extension [RFC2069].

   The current HTTP infrastructure supports HTTP over TCP port 80. IPP
   server implementations MUST offer IPP services using HTTP over the
   IANA assigned Well Known Port 631 (the IPP default port). IPP server
   implementations may support other ports, in addition to this port.

   See further discussion of IPP security concepts in the model document
   [RFC2566].

5.1 Using IPP with SSL3

   An assumption is that the URI for a secure IPP Printer object has
   been found by means outside the IPP printing protocol, via a
   directory service, web site or other means.

   IPP provides a transparent connection to SSL by calling the
   corresponding URL (a https URI connects by default to port 443).
   However, the following functions can be provided to ease the
   integration of IPP with SSL during implementation:

      connect (URI), returns a status

         "connect" makes an https call and returns the immediate status
         of the connection as returned by SSL to the user. The status
         values are explained in section 5.4.2 of the SSL document
         [ssl].




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


         A session-id may also be retained to later resume a session.
         The SSL handshake protocol may also require the cipher
         specifications supported by the client, key length of the
         ciphers, compression methods, certificates, etc. These should
         be sent to the server and hence should be available to the IPP
         client (although as part of administration features).

      disconnect (session)

         to disconnect a particular session.

         The session-id available from the "connect" could be used.

      resume (session)

         to reconnect using a previous session-id.

   The availability of this information as administration features are
   left for implementers, and need not be specified at this time.

6. References

   [RFC2278] Freed, N. and J. Postel, "IANA Charset Registration
             Procedures", BCP 19, RFC 2278, January 1998.

   [dpa]     ISO/IEC 10175 Document Printing Application (DPA), June
             1996.

   [iana]    IANA Registry of Coded Character Sets:
             ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.

   [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.0:
             Implementer's Guide", Work in Progress.

   [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
             "Mapping between LPD and IPP Protocols", RFC 2569, April
             1999.

   [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
             Powell, "Internet Printing Protocol/1.0: Model and
             Semantics", RFC 2566, April 1999.

   [RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
             April 1999.






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


   [RFC2568] Zilles, S., "Rationale for the Structure and Model and
             Protocol for the Internet Printing Protocol", RFC 2568,
             April 1999.

   [RFC2567] Wright, D., "Design Goals for an Internet Printing
             Protocol", RFC 2567, April 1999.

   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text
             Messages", STD 11, RFC 822, August 1982.

   [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
             and Support", STD 3, RFC 1123, October 1989.

   [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon
             Protocol" RFC 1179, August 1990.

   [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
             RFC 2223, October 1997.

   [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
             Resource Locators (URL)", RFC 1738, December 1994.

   [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
             Gyllenskog, "Printer MIB", RFC 1759, March 1995.

   [RFC1766] Alvestrand, H., " Tags for the Identification of
             Languages", RFC 1766, March 1995.

   [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
             1808, June 1995.

   [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
             Conventions for SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail
             Extensions (MIME) Part Two: Media Types", RFC 2046,
             November 1996.

   [RFC2048] Freed, N., Klensin J. and J. Postel.  Multipurpose Internet
             Mail Extension (MIME) Part Four: Registration Procedures",
             BCP 13, RFC 2048, November 1996.

   [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
             2068, January 1997.






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


   [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
             Luotonen, A., Sink, E. and L. Stewart, "An Extension to
             HTTP: Digest Access Authentication", RFC 2069, January
             1997.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
             Word Extensions: Character Sets, Languages, and
             Continuations", RFC 2184, August 1997.

   [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234. November 1997.

   [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.

7. Authors' Addresses

   Robert Herriot (Editor)
   Xerox Corporation
   3400 Hillview Ave., Bldg #1
   Palo Alto, CA 94304

   Phone: [phone]
   Fax:  [phone]
   EMail: [e-mail]


   Sylvan Butler
   Hewlett-Packard
   11311 Chinden Blvd.
   Boise, ID 83714

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]












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


   Paul Moore
   Microsoft
   One Microsoft Way
   Redmond, WA 98053

   Phone: [phone]
   Fax: 425-93MS-FAX
   EMail: [e-mail]


   Randy Turner
   Sharp Laboratories
   5750 NW Pacific Rim Blvd
   Camas, WA 98607

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   IPP Mailing List:  [e-mail]
   IPP Mailing List Subscription:  [e-mail]
   IPP Web Page:  http://www.pwg.org/ipp/