UPD Mail Archive: UPD> [Fwd: RE: IPP> MED - Media Standar

UPD> [Fwd: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded]

From: Michael Sweet (mike@easysw.com)
Date: Mon Mar 26 2001 - 10:20:34 EST

  • Next message: Norbert Schade: "UPD> PDL per UPDF"

    -------- 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
    any mime-media type, defined by RFC, or an arbitrary string? That would
    you the base level of standardization that everyone could count on
    that there's an equivalent for media formats like there was for document
    data formats), without limiting proprietary extensions that may be
    in some cases.

    I'm not sure that just having a single "custom" value is good
    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
    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
    with that name" or something. If there was a "media-types-supported"
    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
    I want to be able to extend the media type names that are available,
    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,
    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
    overrules when there's a printer attribute that the client has received
    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.
    trying to offer a suggestion in case it wasn't already ruled out for
    reason. Like I said, I haven't followed the entire discussion on this
    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
    then just ignore me. :^)

    -- Mike Bartman

    This archive was generated by hypermail 2b29 : Mon Mar 26 2001 - 10:20:50 EST