Subject: RE: IFX> RE: Fax processing confirmation; document-formats

From: "Carl Kugler" <[email-masked]>
Date: Mon, 12 Mar 2001 09:10:48 -0700

My point is that if the purpose of the attribute exchange is to avoid
incompatibilities between sender and receiver, the current design isn't
going to work reliably.  For example, there is the scenario of a client
sending a PS3 file to a PS2 IPP Printer.

Bill wrote:
> For the specific example, IPP includes
> the attribute "document-format" (mimeMediaType).
> Getting all current
> printer languages mime-typed is still in progress, but different document
formats
> will be distinguishable.

However, this doesn't solve the problem in the example scenario.  To solve
the problem we need to be able to distinguish versions of PS.

     -Carl

[email-masked]@pwg.org on 03/11/2001 12:45:16 AM

Sent by:  [email-masked]

To:   Carl Kugler/Boulder/IBM@IBMUS
cc:   "Wagner,William" <[email-masked]>, "'MAEDA toru'"
      <[email-masked]>, [email-masked], [email-masked]
Subject:  RE: IFX> RE: Fax processing confirmation; document-formats

> In general, I think it would be a good idea to register some standard
MIME
> Media Type "version" parameters.  (Parameters are modifiers of the media
> subtype.)

This has to be done as part of the registration of the media type itself.
You cannot register a parameter separately; there is no process for it.

>  Some RFCs mention this possibility;  for example, in RFC 2045:

>    In particular, some formats (such as application/postscript) have
>    version numbering conventions that are internal to the media format.
>    Where such conventions exist, MIME does nothing to supersede them.
Where
>    no such conventions exist, a MIME media type might use a "version"
>    parameter in the content-type field if necessary.

Correct, and several media types have been registered that have such
parameters.

> I'm thinking of all the versions of PCL, for example:  a particular
Printer
> may support some subset of existing PCL versions.

The current registration of PCL, application/vnd.hp-pcl, doesn't have such
a
parameter. The current change controller for this media type is HP; I
suggest
contacting someone there if you want to amend the registration and add
such a parameter.

> Here is a made-up example of a MIME content  type field using the version
> paramater:

>      Content-type: text/line-data; charset=ibm500 (EBCDIC 500V1);
> version=ibm3800

Of course if you're registering such a media type yourself you can simply
have
such a parameter as part of your registration. Make sure you completely
specify
the syntax of the parameter value.

                    Ned

---

From: [email-masked]
Date: Mon, 12 Mar 2001 09:55:39 -0800 (PST)

> sending a PS3 file to a PS2 IPP Printer.

You're making the very big assumption that PostScript breaks down cleanly by
simple version numbers. But it never has been this way, and hasn't been since
Level 2 was defined. Devices are free to implement subsets of level 2 or level
3 and can check the declarations in a document to see if the document uses
anything outside of the subset they implement. So a simple version number just
doesn't work very well for PostScript.

However, the earlier example I saw was PCL. I don't know enough about PCL to
say whether a simple version number is useful. If it is then defining a MIME
version parameter for PCL might be appropriate.

But while simple versioning through the use of MIME parameters is OK, anything
more than that isn't something MIME parameters were designed to do.  Nor are
MIME content type parameters all that good at negotiating feature sets or
anything similar.

We have a mechanism for complex version and feature declaration and
negotiation: Media feature tags. 

If attribute exchange is your goal you should be using media feature tags. MIME
content type parameter information is only a small subset of the information
available in this context. And if you need additional feature tags for
PostScript or PCL, by all means define them.

				Ned