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
At 03:46 PM 12/7/97 PST, you wrote:
>Copies To: masinter@parc.xerox.com
> imcdonal@eso.mc.xerox.com
> ipp@pwg.org
>
>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: ietf-types@iana.org
> 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: scott_isaacson@novell.com
>
> 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: robert.herriot@eng.sun.com
>
> Intended usage:
>
>| COMMON
>
>------------------------------------------------------------------------
>
>
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: manros@cp10.es.xerox.com