Re: IPP Registration Request for Addition: New keywords for the "media" attribute

Michael Sweet via ipp <[email protected]> Wed, 3 Mar 2021 18:08:46 -0500
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Smith,

> On Mar 3, 2021, at 5:51 PM, Kennedy, Smith (Wireless & IPP Standards) <[email protected]> wrote:
> ...
> So three notes:
> 
> 1. CUPS-based systems (including Linux, macOS, and iOS) never use any localized media size names from the Printer
> 2. Windows 10's IPP class driver only supports well-known media sizes at present (where "well known" seems to be limited to standard office printer sizes) - yes, I've filed a bug report on it...
> 3. macOS (at least) groups media sizes by dimension, for example "US Letter" and "US Letter (Borderless)" while iOS and CUPS clients do no grouping.
> 
> [Smith K.] Understood. And it is up to the Client implementor to take advantage of message catalog provided strings or family information (or not). But there are other clients that do use the behavior I described, including HP vendor drivers for Windows and Android. We can do it with a vendor extension but I would prefer to not do that.

If we are using media-col-database, I would rather have another member attribute that provides the grouping information because modern clients use media-col-database/ready and *not* media-supported/media-ready (in order to get supported media types, sources, and margins).

> If the Client were implemented to use “media-col-database” rather than “media-supported”, the “media-key” value for the two variants could both use “na_arch-c_18x24in”
> 
> "media-key" is a *unique* keyword for a combination of media-size, media-type, etc.  "media-name" (the localized name) might be the same but I don't see any Client using it since (as I've noted previously) current Clients use the dimensions to lookup the corresponding localized name (even if it is a dimensional name like "4 x 6")
> 
> [Smith K.] I think we are talking about two different things: how the PWG has defined the members of the “media-col” collections to be used along with other facilities of IPP such as printer-resident message catalogs, and how some clients have been implemented to use those members and other IPP facilities. I don’t doubt your assertion that CUPS-based systems have been implemented to choose non-printer-resident strings based on “media-size” or “media-size-name” and ignore “media-key”. But is that how we in the PWG are intending “media-col-ready” and “media-col-database” to be used?

Yes.

The "media-size" member attribute is REQUIRED while "media-size-name" and "media-key" are just RECOMMENDED.  The whole purpose of MSN size names was to formalize the syntax of keyword names so they were self-describing with "natural" dimensions, so that the "media" attribute would only specify the desired media size (and not the type or source).  All legacy media values were deprecated with STD92, making media-col the only way to specify media size, type and source (via member attributes).

> (I don’t see a “media-name” member registered with IANA or in 5100.7…)

Sorry, "media-info" (RECOMMENDED).

________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 874 B)