Subject: IPP> IPP Phone Calls and MIME-type

From: Steve Zilles <[email-masked]>
Date: Fri, 22 Aug 1997 18:32:11 -0800

ACTION REQR'd by 9/3

There was a relative small turn-out on the August 20 IPP Phone call. The
primary topics of discussion were MIME-types and prtInterpreterLangFamily
and Job-ID. Because so many of the regular participants will be at the
briefing in Boston and may be leaving for airplanes, the August 27th phone
call has been cancelled. You are asked, however, to participate in the
September 3 phone call if you care about how the resolution of either of
the above to issues. We hope to close all outstanding issues during that
phone call.

With respect to MIME-types and prtInterpreterLangFamily,
There was a useful discussion of this topic both on the mailing list
(digest of which is attached) and on the Weekly Phone meeting on Aug
20. I would summarize the current position as follows

For IPP:

IPP is strongly encouraged (read, the draft will have GREAT difficulty
getting throught the IESG without it) to use MIME-types to identify the
document format.

The main reason for this request is that using a MIME-type solves more
problems than does using the prtInterpreterLangFamily enum. For example,

1. Many protocols, including HTTP, use the MIME-type to identify the
format of a "file." (Here "file" can be a file or a segment of a
multipart message, etc.).

2. Some text based file formats, e.g., PCL, require that the character
set used to represent the text be identified. Using MIME-types allows a
character set parameter to be attached to the MIME-type.

As an example of the utility of 1. consider an application that is
generating a PostScript file. This file may or may not be printed; for
example, it may be intended for input into a PDF distiller. The
application (which may not know the intended use of the file) would not
be able to label the file if Printers use a different label from other
applications. (Yes, of course, the label does not necessarily go on the
file, but, more often, on/in the message by which the file is
transmitted. But, with a "standard" labelling scheme, the type label may
work its way into file system directory information.)

The reasons for using the prtInterpreterLangFamily enum seem to be:

1. The printer MIB uses it and we wish to align IPP with the Printer MIB so
that no matter which path you get information from the Printer, it comes
out the same where the same question can be asked (e.g., what languages
does this Printer support, right now).

2. The prtInterpreterLangFamily enum has already been populated with the
relevant languages, why is is necessary to do this work all over again?

These reasons are relevant, but not strictly compelling, IMHO. Consider
the following proposal:

The Printer MIB retains the prtInterpreterLangFamily object and adds a
new object prtInterpreterLangFamilyMIMEtype. The use of the first
object is Deprecated, but not Obsoleted. The MIME-type registry is
updated to have all the types that are in the prtInterpreterLangFamily
enum registry. A new value is added to the prtInterpreterLangFamily enum
registry. This value stands for "There is no prtInterpreterLangFamily
enum assigned so use the prtInterpreterLangFamilyMIMEtype value
instead". (Note this could be a new value or it could be an action taken
when the "Unknown" value of the prtInterpreterLangFamily enum is seen.)
This allows future formats to be registered only in the MIME-type list
and to provide a way to tell a MIB client that it should use the
prtInterpreterLangFamilyMIMEtype value instead of the
prtInterpreterLangFamily value.

Since it is not the function of the IPP maillist to design the Printer
MIB, the above is provided as a suggestion for a way to keep IPP and the
Printer MIB aligned. With this proposal, the Printer MIB grows by one
object (and a somewhat bulky table of character strings for the
MIME-types), but preserves interoperability with the existing MIB
clients and agents. This seems like a small price to pay for
interoperability both between the Printer MIB and IPP and IPP and the
other application protocols.

Note there was some (useless) noise in the message log that appeared to
be disparaging the reality of the Printer MIB. When the smoke cleared, I
believe the only assertion being made was that it appeared that
MIME-types had a wider (current) deployment than
prtInterpreterLangFamily enum values. Therefore, if we were to
*standardize on only one of these*, the use of MIME-type would affect the
smaller number of "affectees". Those of us doing printers make up most
of those "affectees", however. I do not believe that people would
disagree with the above conclusion, but I do believe that people might
not agree that we need to have *only one standard*.

Assuming that the WG agrees to use MIME-types for Document Format in IPP
(and, separately, the Printer MIB group adds the
prtInterpreterLangFamilyMIMEtype object) then the following work items
arise:

1. The MIME-type registration must be updated to add all the
prtInterpreterLangFamily values that are currently not in the MIME
registry. Note that the MIME registry has at least two sub-trees: the
IETF subtree and the Vendor sub-tree. Types may be registered in the
IETF only via a standards track RFC (IPP is one of these, Printer MIB is
another). Types may be registered in the Vendor sub-tree by any
vendor. Besides requiring an RFC to register, registration in the IETF
sub-tree also requires "a precise and openly available specification of
the format." No specification is required for the Vendor sub-tree, but a
specification is "encouraged".  Therefore, a decision must be made for
the unregistered prtInterpreterLangFamily enums. This memo suggests that
they be registered in the Vendor sub-tree using the information
currently in the prtInterpreterLangFamily enum registry. This
registration is best done by the company owning the format so that a
request to this effect will be sent to the contact point in the
prtInterpreterLangFamily registry; if this fails to produce a
registration, then the the IPP RFC will force the registratration.

2. The prtInterpreterLangFamily enum registry should be updated to
include a new line for the MIME-type. This would be the already
registered MIME-type where there is one already and would be the one
registered by step 1. above where it was not registered.

---

From: JK Martin <[email-masked]>
Date: Fri, 22 Aug 1997 23:19:33 -0400 (EDT)

Thanks for doing a great job of summarizing the current state of affairs,
Steve.  You've covered the essence of the issues, IMHO.

As a vendor of software currently utilizing the Printer MIB, maintaining
two registries--one for enums, the other for MIME types--is not that big
a problem.  We can go either way.  I would suspect many other server-based
software developers might say the same thing.

The folks with the biggest problems with using MIME types in the MIB
are probably the printer manufacturers.  Printer vendors are inclined
to provide consistent services up and down their product lines, and
while mid- to high-end systems can afford the added space required for
comprehensive MIME definitions, memory continues to be a precious
resource for for low-end units.

MIME types come at a bit of expense, but the simple elegance for extensions
is quite compelling, IMHO.  I support the move to incorporate MIME types
in the Printer MIB.  Whether the existing enums are deprecated or not
does not really matter to us at this time, although I would suspect that
others may not be very enthusiastic.

	...jay

PS: Probably the biggest reason for the low turnout for the last IPP
    telecon was the fact that no "reminder/info" message was posted on
    the IPP list within a day or two of the telecon.  As I recall, this
    was the first time no reminder message was posted since we started
    the telecon series.  I completely forgot about the telecon
    date...then realized that I had been subconsciously hooked on being
    electronically reminded from the list.  Perhaps we can make it a
    point to post such reminders before all future telecons.

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 23 Aug 1997 16:43:09 -0400

I see no reason to add MIME types to the MIB.  If we do our
job right, all the MIME types should map to a printer ENUM.
Since host system have infinite resources for all this trash ;>)
it shouldn't be any problem to correlate them there rather than
down in the printer agent.

Don

**********************************************
* Don Wright                 [email-masked] *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

... stuff deleted ...

... more stuff deleted ...

---

From: Harry Lewis <[email-masked]>
Date: Mon, 25 Aug 1997 18:03:59 -0400

I agree with Don. The host is the appropriate place to map
prtInterpreterLangFamilyTC enums and MIME types.

Harry Lewis

----------- Forwarded by Harry Lewis/Boulder/IBM on 08/25/97 03:51 PM ----------

[email-masked] on 08/23/97 03:02:54 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet
Subject: Re: IPP> IPP Phone Calls and MIME-type

Don

... stuff deleted ...