Subject: IPP> MOD - Issue on "application/ipp" media type

From: [email-masked] (Ira Mcdonald x10962)
Date: Fri, 21 Nov 1997 10:02:56 PST

Hi folks,                                      Friday (21 November 1997)

At our IPP Telecon on Wednesday (19 November), I got the action item to
address possible objections from MIME experts to registration by the
IPP Working Group of the MIME (Multipurpose Internet Mail Extensions)
media type "application/ipp" (the proposed registration text I posted,
on 24 October 1997, is included below).

ISSUE:  The body of an IPP create request (eg, "Print-URI") is NOT
useful as an email (SMTP/ESMTP) "Content-Type", because some IPP
attributes are conveyed (in the IPP/1.0 transport mapping over HTTP/1.1)
in header fields of the HTTP POST operation and NOT in the HTTP POST
message body.  For example, the HTTP header field "Request-URI" is used
to convey the target "printer-URI" (critical to building an SMTP/IPP
gateway).

PROPOSAL:  The IPP/1.0 specifications should PERMIT the inclusion of any
'orphaned' IPP attributes in the BODY of the "application/ipp" media
type, to make this media type complete and self-contained.  This would
facilitate the use of "Content-Disposition" headers (in HTTP or SMTP) to
request the 'local' storage of the 'job specification' (eg, for later
reuse via a 'file:' scheme URI).  This would also facilitate other
standard IPP transport protocol mappings (eg, directly over TCP/TLS) in
the future.

If no objections are stated on the IPP WG mailing list, then my above
proposal will be our official answer to any possible criticisms from
MIME experts at the IETF meeting on 10 December in Washington, DC.

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  716-442-0609 (home in Rochester, NY until April 1998, w/ voice mail)

========================== Original Message ============================
Copies To:  [email-masked]
            [email-masked]
            [email-masked]

Hi folks,                                       Friday (24 October 1997)

At our IPP Telecon on Wednesday (22 October), I got the action item to
write up new text for registration of MIME media type "application/ipp".

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

Note_1: We need not actually apply for registration of this media-type
until the IPP/1.0 specs are accepted by the IESG onto the 'standards
track'.  The application is made by mail (see below) and need not be
supported by a separate Informational RFC.

Note_2: The 'Intended usage' of 'LIMITED USE' (rather than 'COMMON') is
based on advice earlier this month from Larry Masinter.

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  PO Box 221
  Grand Marais, MI  49839
  906-494-2434

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

    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 underlying transport protocols.

    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 complete and unambiguous
      so interoperability between conforming implementations is ensured
      (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 MIME, HTTP, 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-06.txt>, October 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>, October 1997.

    Applications which use this media type:

      Internet Printing Protocol (IPP) print clients and print servers.

    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:

      LIMITED USE

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