Subject: IPP> MOD - Proposed application/ipp registration text

From: [email-masked] (Ira Mcdonald x10962)
Date: Wed, 8 Oct 1997 17:54:16 PDT

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

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: [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 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: [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: Larry Masinter <[email-masked]>
Date: Thu, 9 Oct 1997 23:59:09 PDT

I think that the IANA registration for application/ipp should
just be part of the protocol suite, and that you shouldn't try to register it
before the draft(s) get approved.

I think the definition of the charset paramter you've given
is pretty confusing.

A parameter definition just says what the parameter means and what
the allowable range of values are. But the definition you give is
full of stuff about the IPP protocol and rules contained in it. If
you can't define a media type independent of the protocol by which
it is transported, then it's pretty suspect as a MIME media type;
the whole point of 'media type' is to make the information objects
independent of their transport.

>       US-English.

You mean 'Keywords within application/ipp bodies'?

>                 IPP/1.0 string attributes of syntax "text" or "name"

Well, while this is interesting, why is it important to repeat this
little bit of the application/ipp media type rules inside the registration
of the charset parameter?

>       "charset" of a "charset/language" prefix is empty (ie, a single

I think it's odd to make "what something is used for" to be mandatory.
You just mean it the other way around. The default is from the charset
parameter. The parameter is mandatory. All of this MUST-ing and SHOULD-ing
really just gets in the way.

>                        IPP/1.0 protocol requests and responses MUST

This is very confusing in a media type registration. It's not just
'IPP/1.0 protocol requests and responses', is it? It's any mechanism
used to transport this media type MUST specify a default language, too.

>       using Content-Transfer-Encoding: binary.

You're saying 'IPP/1.0 protocol requests' rather than 'application/ipp bodies'
again. And "COntent-Transfer-Encoding" is appropriate for mail and not for
HTTP transport. I think you mean 'must be transfered using an encoding
appropriate for the protocol and binary data'.

At some point in the earlier life of IPP, it made sense to think about
mailing an application/ipp print request to a printer, as a way of initiating
a print job.

>       transport layer security protocol (below HTTP/1.1).

No, 'security considerations' doesn't mean 'encryption used'. What it is used
for is "what risks are entailed by accepting one of these bodies and trying
to interpret it?". For example, application/postscript has a security
consideration that some postscript programs could maliciously delete files
on your print system or tie up your printer or otherwise do harm unless
you're careful. What attacks could be mounted by a print client onto a print
server, and what have you done to protect against them?

>       facilitate interoperability with IPP/1.0 clients.

Is there an interoperability considerations section in a media type
registration?
Is this new? What are you trying to say here?

>       COMMON

Actually, no, the intended use of application/ipp is with a very narrow
domain: within an implementation of IPP that tries to bundle a request/response
protocol inside a MIME object body and tunnel it through using HTTP.

So, it's a narrow intended use, and you probably should say so.

Regards,

Larry
--
http://www.parc.xerox.com/masinter