RFC 2565            IPP/1.0: Encoding and Transport           April 1999


10. Appendix C: Registration of MIME Media Type Information for
    "application/ipp"

   This appendix contains the information that IANA requires for
   registering a MIME media type.  The information following this
   paragraph will be forwarded to IANA to register application/ipp whose
   contents are defined in Section 3 "Encoding of the Operation Layer"
   in this document:

   MIME type name: application

   MIME subtype name: ipp

   A Content-Type of "application/ipp" indicates an Internet Printing
   Protocol message body (request or response). Currently there is one
   version: IPP/1.0, whose syntax is described in Section 3 "Encoding of
   the Operation Layer" of [RFC2565], and whose semantics are described
   in [RFC2566].

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:

   IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS
   contain binary data (for example attribute value lengths).

   Security considerations:

   IPP/1.0 protocol requests/responses do not introduce any security
   risks not already inherent in the underlying transport protocols.
   Protocol mixed-version interworking rules in [RFC2566] as well as
   protocol encoding rules in [RFC2565] are complete and unambiguous.

   Interoperability considerations:

   IPP/1.0 requests (generated by clients) and responses (generated by
   servers) MUST comply with all conformance requirements imposed by the
   normative specifications [RFC2566] and [RFC2565]. Protocol encoding
   rules specified in [RFC2565] are comprehensive, so that
   interoperability between conforming implementations is guaranteed
   (although support for specific optional features is not ensured).
   Both the "charset" and "natural-language" of all IPP/1.0 attribute
   values which are a LOCALIZED-STRING  are explicit within IPP protocol
   requests/responses (without recourse to any external information in
   HTTP, SMTP, or other message transport headers).





 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   Published specification:

   [RFC2566] Isaacson, S., deBry, R., Hastings, T., Herriot, R. 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.

   Applications which use this media type:

   Internet Printing Protocol (IPP) print clients and print servers,
   communicating using HTTP/1.1 (see [RFC2565]), SMTP/ESMTP, FTP, or
   other transport protocol. Messages of type "application/ipp" are
   self-contained and transport-independent, including "charset" and
   "natural-language" context for any LOCALIZED-STRING value.

   Person & email address to contact for further information:

   Scott A. Isaacson
   Novell, Inc.
   122 E 1700 S
   Provo, UT 84606

   Phone: 801-861-7366
   Fax: 801-861-4025
   Email: sisaacson@novell.com

   or

   Robert Herriot (Editor)
   Xerox Corporation
   3400 Hillview Ave., Bldg #1