Subject: IPP> MOD - Updated 'application/ipp' MIME type - 7 Dec 1997

From: [email-masked] (Ira Mcdonald x10962)
Date: Sun, 7 Dec 1997 15:46:09 PST

Copies To:  [email-masked]
            [email-masked]
            [email-masked]

Hi folks,                                       Sunday (7 December 1997)

At our IPP Telecon on Wednesday (3 December), I got the action item to
REVISE the text for registration of MIME media type "application/ipp".
I used revision bars ('|') in the first column, to flag all changes.

The following template came from the IETF MIME Part Four: Registration
Procedures (RFC 2048, November 1996).

We can apply for registration of this media-type when the IESG accepts
our IPP/1.0 specs for entry onto the Internet 'standards track'.  The
application is normally made by mail (see below) and does NOT need to be
supported by a separate Informational RFC.

The 'Intended usage' of 'COMMON' (rather than the former 'LIMITED USE')
is based on two of our decisions on Wednesday (3 December):

a)  All IPP Model attributes conveyed (eg, in the IPP/1.0 over HTTP/1.1
    mapping) in header fields of the underlying transport protocol, MAY
    be specified in the body of the 'application/ipp' message;
b)  All 'application/ipp' messages MUST contain a 'transaction ID'
    (positive 32-bit integer), supplied by the operation requestor for
    later operation response correlations (and possibly notification
    correlations in a future version of IPP).

Therefore, use of 'application/ipp' as a MIME type in email is now
straightforward.

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  716-425-6141 (office at Xerox until April 1998)
  716-442-0609 (home in Rochester, NY until April 1998)

------------------------------------------------------------------------

    To: [email-masked]
    Subject: Registration of MIME media type "application/ipp"

    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, described in [IPP-MOD] and [IPP-PRO].

    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 [IPP-MOD] as well as
|     protocol encoding rules in [IPP-PRO] 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 [IPP-MOD] and [IPP-PRO].  Protocol
|     encoding rules specified in [IPP-PRO] 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 of syntax "text" or "name" are explicit within IPP protocol
      requests/responses (without recourse to any external information
|     in HTTP, SMTP, or other message transport headers).

    Published specification:

      [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson,
      P. Powell, "Internet Printing Protocol/1.0: Model and Semantics",
|     work in progress <draft-ietf-ipp-model-08.txt>, December 1997.

      [IPP-PRO] S. Butler, R. Herriot, P. Moore, R. Turner,
      "Internet Printing Protocol/1.0: Protocol Specification",
|     work in progress <draft-ietf-ipp-protocol-04.txt>, December 1997.

    Applications which use this media type:

      Internet Printing Protocol (IPP) print clients and print servers,
|     communicating using HTTP/1.1 (see [IPP-PRO]), 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 "text" or "name" attributes.

    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: [email-masked]

    or

      Robert Herriot
      Sun Microsystems Inc.
      901 San Antonio Road, MPK-17
      Palo Alto, CA  94303

      Phone: 650-786-8995
      Fax:   650-786-7077
      Email: [email-masked]

    Intended usage:

|     COMMON

------------------------------------------------------------------------

---

From: Carl-Uno Manros <[email-masked]>
Date: Sun, 7 Dec 1997 19:42:46 PST

Ira,

Thanks for taking care of your homework assignment so rapidly and reliably.
Just so we do not confuse people, it should be noted that your text
anticipates a new set of I-Ds, which are still in progress by the editors.

Carl-Uno

>  716-442-0609 (home in Rochester, NY until April 1998)
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]