-------- Original Message --------
Subject: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded
Date: Fri, 23 Mar 2001 12:18:22 -0500
From: Mike Bartman <bartman@process.com>
To: "'Michael Sweet'" <mike@easysw.com>
> From: Michael Sweet [mailto:mike@easysw.com]
> Mike Bartman wrote:
> >
> > I'm just curious...why are you folks trying to name every
> > possibility for media type that might ever have existed, or will
> > exist? Why not just do it like DOCUMENT_FORMAT and make it an
> > arbitrary string to be defined elsewhere, if at all? That would
> > seem to be simplest, most flexible and even easier to implement.
> > Why add complexity that will only limit future utility?
>
> I think the main issue is that *standard* media types need to be
> enumerated (by keyword value) so that you don't end up with 50
> different names for "plain paper"... :)
Ok, I can see that. With document-format isn't the deal that you can
use
any mime-media type, defined by RFC, or an arbitrary string? That would
get
you the base level of standardization that everyone could count on
(assuming
that there's an equivalent for media formats like there was for document
data formats), without limiting proprietary extensions that may be
necessary
in some cases.
I'm not sure that just having a single "custom" value is good
enough...I'd
like to be able to reference my own media type by a name that makes
sense to
me, not by "custom" with a definition each time. "bonus stickers" might
be
a value I want to use for media type...and it might make sense to my
programmable printer, where it's equal to "bin 1" or "make operator
request
with that name" or something. If there was a "media-types-supported"
value
in the get-printer-attributes reply, I could even present such a thing
to a
user for them to select if they want to.
> Without a standard naming convention (whether all the valid values
> are defined or not) there can be no interoperability between
> systems and devices. The goal is to allow a single piece of
> software/hardware to communicate with any presentation device
> without having to be hardcoded/wired for each device.
No problem with that as a base, I just wouldn't like to see it stop
there.
I want to be able to extend the media type names that are available,
either
because the printer knows them, or because it can be told what to call
things that it knows about (alias naming?) to more closely match user
expectations for various forms of media (Purchase Order Forms,
Billboards,
etc.). The client doesn't have to have things hardcoded...they can be
configuration settings, or acquired from the printer through query. My
client will accept anything the user cares to enter for most items, and
only
overrules when there's a printer attribute that the client has received
that
says it isn't going to work (i.e. user asks for 1000 copies on a printer
with a valid copies range of 1:99).
I don't want to waste your time on this if all this has been handled.
Just
trying to offer a suggestion in case it wasn't already ruled out for
some
reason. Like I said, I haven't followed the entire discussion on this
one.
I've been implementing my IPP client... (now in beta test! :^)
Thanks for reading. If it's useful, feel free to pass it on, if it's
not,
then just ignore me. :^)
-- Mike Bartman
This archive was generated by hypermail 2b29 : Mon Mar 26 2001 - 10:23:50 EST