Hi Larry Masinter, Wednesday (8 October 1997)
At our IPP Telecon this afternoon, I got the action item to write up a
MIME registration for the MIME media type "application/ipp". I'm hoping
you'll take a minute to look my attempt below and tell me where I've
gone wrong. Based on a note from Keith Moore (one of our two IETF Area
Directors), we are trying to finish up the IPP specs for submission to
the IESG by the beginning of November, so our schedule is very tight.
I got the template from RFC 2048.
Thanks for your help in advance,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434
------------------------------------------------------------------------
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 request or response. Currently there is one version:
IPP/1.0, described in [IPP-MOD] and [IPP-PRO], transported via the
HTTP/1.1 (RFC 2068) POST method, using single-valued Content-Type
and Content-Language headers (both headers MUST be specified).
Required parameters: charset
IPP/1.0 keywords (eg, attribute names) are encoded in US-ASCII and
US-English. IPP/1.0 string attributes of syntax "text" or "name"
MAY have values in ANY character set and language, and MUST use
"charset/language" prefixes, via the method specified in RFC 2184.
The required "charset" parameter of the "application/ipp" MIME
media type MUST be used to specify the default to use when the
"charset" of a "charset/language" prefix is empty (ie, a single
quote character). IPP/1.0 protocol requests and responses MUST
use a Content-Language header to specify a default to use when the
"language" of a "charset/language" prefix is empty (ie, a single
quote character).
Optional parameters:
None
Encoding considerations:
IPP/1.0 protocol requests and responses MAY contain long lines and
MUST always contain binary data and therefore MUST be encoded
using Content-Transfer-Encoding: binary.
Security considerations:
IPP/1.0 requests and responses MAY be secured via the use of a
transport layer security protocol (below HTTP/1.1).
Interoperability considerations:
IPP/1.0 Printer objects (ie, servers) MUST support the attributes
"printer-charset-supported" (MAY be multi-valued) and
"printer-natural-language-supported" (MAY be multi-valued), to
facilitate interoperability with IPP/1.0 clients.
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-06.txt>, September 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-02.txt>, September 1997.
Applications which use this media type:
Internet Printing Protocol (IPP)
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
------------------------------------------------------------------------