rfc2910.txt

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

         MD5 and MD5-sess MUST be implemented and supported.

         The Message Integrity feature NEED NOT be used.






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


   IPP Printers SHOULD support:

      Digest Authentication [RFC2617].

         MD5 and MD5-sess MUST be implemented and supported.

         The Message Integrity feature NEED NOT be used.

   The reasons that IPP Printers SHOULD (rather than MUST) support
   Digest Authentication are:

   1. While Client Authentication is important, there is a certain class
      of printer devices where it does not make sense.  Specifically, a
      low-end device with limited ROM space and low paper throughput may
      not need Client Authentication.  This class of device typically
      requires firmware designers to make trade-offs between protocols
      and functionality to arrive at the lowest-cost solution possible.
      Factored into the designer's decisions is not just the size of the
      code, but also the testing, maintenance, usefulness, and time-to-
      market impact for each feature delivered to the customer.  Forcing
      such low-end devices to provide security in order to claim IPP/1.1
      conformance would not make business sense and could potentially
      stall the adoption of the standard.

   2. Print devices that have high-volume throughput and have available
      ROM space have a compelling argument to provide support for Client
      Authentication that safeguards the device from unauthorized
      access.  These devices are prone to a high loss of consumables and
      paper if unauthorized access should occur.

8.1.2 Transport Layer Security (TLS)

   IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]
   for Server Authentication and Operation Privacy. IPP Printers MAY
   also support TLS for Client Authentication.  If an IPP Printer
   supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
   cipher suite as mandated by RFC 2246 [RFC2246].  All other cipher
   suites are OPTIONAL.  An IPP Printer MAY support Basic Authentication
   (described in HTTP/1.1 [RFC2617])  for Client Authentication if the
   channel is secure. TLS with the above mandated cipher suite can
   provide such a secure channel.

   If a IPP client supports TLS, it MUST support the
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC
   2246 [RFC2246].  All other cipher suites are OPTIONAL.






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


   The IPP Model and Semantics document defines two printer attributes
   ("uri-authentication-supported" and "uri-security-supported") that
   the client can use to discover the security policy of a printer. That
   document also outlines IPP-specific security considerations and
   should be the primary reference for security implications with regard
   to the IPP protocol itself.  For backward compatibility with IPP
   version 1.0, IPP clients and printers may also support SSL3 [ssl].
   This is in addition to the security required in this document.

8.2 Using IPP with TLS

   IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism
   [RFC2817].  An initial IPP request never uses TLS.  The client
   requests a secure TLS connection by using the HTTP "Upgrade" header,
   while the server agrees in the HTTP response.  The switch to TLS
   occurs either because the server grants the client's request to
   upgrade to TLS, or a server asks to switch to TLS in its response.
   Secure communication begins with a server's response to switch to
   TLS.

9. Interoperability with IPP/1.0 Implementations

   It is beyond the scope of this specification to mandate conformance
   with previous versions.  IPP/1.1 was deliberately designed, however,
   to make supporting previous versions easy.  It is worth noting that,
   at the time of composing this specification (1999), we would expect
   IPP/1.1 Printer implementations to:

      understand any valid request in the format of IPP/1.0, or 1.1;

      respond appropriately with a response containing the same
      "version-number" parameter value used by the client in the
      request.

   And we would expect IPP/1.1 clients to:

      understand any valid response in the format of IPP/1.0, or 1.1.

9.1 The "version-number" Parameter

   The following are rules regarding the "version-number" parameter (see
   section 3.3):

      1. Clients MUST send requests containing a "version-number"
         parameter with a '1.1' value and SHOULD try supplying alternate
         version numbers if they receive a 'server-error-version-not-
         supported' error return in a response.




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


      2. IPP objects MUST accept requests containing a "version-number"
         parameter with a '1.1' value (or reject the request for reasons
         other than 'server-error-version-not-supported').

      3. It is recommended that IPP objects accept any request with the
         major version '1' (or reject the request for reasons other than
         'server-error-version-not-supported').  See [RFC2911]
         "versions" sub-section.

      4. In any case, security MUST NOT be compromised when a client
         supplies a lower "version-number" parameter in a request.  For
         example, if an IPP/1.1 conforming Printer object accepts
         version '1.0' requests and is configured to enforce Digest
         Authentication, it MUST do the same for a version '1.0'
         request.

9.2 Security and URL Schemes

   The following are rules regarding security, the "version-number"
   parameter, and the URL scheme supplied in target attributes and
   responses:

      1. When a client supplies a request, the "printer-uri" or "job-
         uri" target operation attribute MUST have the same scheme as
         that indicated in one of the values of the "printer-uri-
         supported" Printer attribute.

      2. When the server returns the "job-printer-uri" or "job-uri" Job
         Description attributes, it SHOULD return the same scheme
         ('ipp', 'https', 'http', etc.) that the client supplied in the
         "printer-uri" or "job-uri" target operation attributes in the
         Get-Job-Attributes or Get-Jobs request, rather than the scheme
         used when the job was created.  However, when a client requests
         job attributes using the Get-Job-Attributes or Get-Jobs
         operations, the jobs and job attributes that the server returns
         depends on: (1) the security in effect when the job was
         created, (2) the security in effect in the query request, and
         (3) the security policy in force.

      3. It is recommended that if a server registers a non-secure ipp-
         URL with a directory service (see [RFC2911] "Generic Directory
         Schema" Appendix), then it also register an http-URL for
         interoperability with IPP/1.0 clients (see section 9).

      4. In any case, security MUST NOT be compromised when a client
         supplies an 'http' or other non-secure URL scheme in the target
         "printer-uri" and "job-uri" operation attributes in a request.




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


10. References

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

   [IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

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

   [RFC1123]  Braden, S., "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.

   [RFC1903]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
              "Textual Conventions for Version 2 of the Simple Network
              Management Protocol (SNMPv2)", RFC 1903, January 1996.

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




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


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

   [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. Overall, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246.
              January 1999.

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

   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Turner,
              "Internet Printing Protocol/1.0: Encoding and Transport",
              RFC 2565, 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.

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

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

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A. and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.



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


   [RFC2817]  Khare, R. and S. Lawrence, "Upgrading to TLS Within
              HTTP/1.1", RFC 2817, May 2000.

   [RFC2910]  Herriot, R., Butler, S., Moore, P., Turner, R. and J.
              Wenn, "Internet Printing Protocol/1.1: Encoding and
              Transport", RFC 2910, September 2000.

   [RFC2911]  Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
              Powell, "Internet Printing Protocol/1.1: Model and
              Semantics", RFC 2911, September 2000.

   [SSL]      Netscape, The SSL Protocol, Version 3, (Text version
              3.02), November 1996.

11. Authors' Addresses

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

   Phone: [phone]
   Fax:   [phone]