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

From: "Carl Kugler" <[email-masked]>
Date: Mon, 12 Mar 2001 12:38:05 -0700

Ned wrote:
>
>> 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.
>
>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.
>
Wouldn't it be better than nothing?  Can't we find something between blind
trial-and-error and requiring every client to have a priori knowledge of
every existing printer-make-and-model?

>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.
>
But don't Media feature tags describe physical characteristics, rather than
how those characteristics are described in a PDL?  Couldn't a given Mime
media feature have a different expression in different versions of PS or
PCL?  [I admit I don't know much about media feature tags.  Can you point
me to some references?]

>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.
>
The thing is, these would have to be generally accepted standards in order
to be useful for interop.  It won't do any good for me to define my own new
tags.

>                   Ned

     -Carl

---

From: [email-masked]
Date: Mon, 12 Mar 2001 13:10:24 -0800 (PST)

> > 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
> > anything outside of the subset they implement. So a simple version number just

> Wouldn't it be better than nothing?

It would probably be worse, given the number of partial implementations of
PostScript levels out there, many of which incorrectly claim to support Level 2
or Level 3 or whatever. And you're also assuming that only alternative to the
parameter is "nothing", and that's just not so -- existing software understands
how to read DSC information and dispatch appropriately based on it. There's
ample evidence that the fine grained feature model is practical.

> Can't we find something between blind

Of course we can. We've already designed it. All you have to do is use it.

> how those characteristics are described in a PDL?

Nope. They do a lot more than describe the characteristics of a document. They
can also be used to describe the capabilities of a device.

> Couldn't a given Mime
> PCL?

Some features are generic cross-format stuff but others are specific to a
particular format. For example, it would be entirely reasonable to have a "LZ
compression" feature tag specific to application/postscript. And supposing for
a moment that there's similar functionality in PCL, it would not be reasonable
to use the same feature tag since a given printer might implement this with one
format and not the other.

There's even a "feature calculus" you can use to express more complex
relationships. For example, I believe it would be possible to write a feature
expression that describes a printer that supports B&W PCL and Postscript but
color is only available in PCL.

It seems logical to use generic media feature tags whenever possible, of
course.

> [I admit I don't know much about media feature tags.  Can you point
> me to some references?]

The RFC index lists many RFCs on media features.

> to be useful for interop.  It won't do any good for me to define my own new

That's why there's a registration procedure.

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Mon, 12 Mar 2001 21:35:54 +0000

>every existing printer-make-and-model?

The proposal for fax negotiation does this.  (draft-ietf-fax-negotiation)

>... Couldn't a given Mime

Media feature expressions have precisely this capability to describe 
different combinations of allowable characteristics.

References:  RFC 2506 and 2533

(See also:  RFC 2703, 2879, 2880, 2912, 2913, 2938)

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------