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

Michael Sweet via ipp <ipp@pwg.org> Wed, 10 March 2021 15:01 UTC

Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7453A0ED1 for <ietfarch-ipp-archive@ietfa.amsl.com>; Wed, 10 Mar 2021 07:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFPzpZRpeTjB for <ietfarch-ipp-archive@ietfa.amsl.com>; Wed, 10 Mar 2021 07:01:10 -0800 (PST)
Received: from mail.pwg.org (mail.pwg.org [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id E60C53A0EB8 for <ipp-archive2@ietf.org>; Wed, 10 Mar 2021 07:01:10 -0800 (PST)
Received: by mail.pwg.org (Postfix, from userid 1002) id A5623F575; Wed, 10 Mar 2021 15:01:09 +0000 (UTC)
Received: from mail.pwg.org (localhost [IPv6:::1]) by mail.pwg.org (Postfix) with ESMTP id A677AF55E; Wed, 10 Mar 2021 15:01:07 +0000 (UTC)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: by mail.pwg.org (Postfix, from userid 1002) id 286B8F536; Wed, 10 Mar 2021 15:01:06 +0000 (UTC)
Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by mail.pwg.org (Postfix) with ESMTP id 96580F50F for <ipp@pwg.org>; Wed, 10 Mar 2021 15:01:05 +0000 (UTC)
Received: from mbp16.localdomain (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id 7B0E2809AF; Wed, 10 Mar 2021 15:01:04 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
In-Reply-To: <F92A5194-0A3F-4DB3-ADE7-E10C6C4BDAAC@hp.com>
Date: Wed, 10 Mar 2021 10:01:02 -0500
Message-Id: <C3616DB9-8E39-4CCC-B7E4-94761589F65B@msweet.org>
References: <CS1PR8401MB0518CB6CDAFD39B2A6C751FE9E999@CS1PR8401MB0518.NAMPRD84.PROD.OUTLOOK.COM> <427EB790-2E49-4138-9623-FE62066CB7F5@msweet.org> <CS1PR8401MB0518EB189D8D586DFD43BF6A9E989@CS1PR8401MB0518.NAMPRD84.PROD.OUTLOOK.COM> <1D6881FA-25CE-448F-9133-6E1121E035A3@msweet.org> <CS1PR8401MB051864102AA2F22A74128DF99E989@CS1PR8401MB0518.NAMPRD84.PROD.OUTLOOK.COM> <66391665-903F-4926-BCA6-15B862D80759@msweet.org> <F92A5194-0A3F-4DB3-ADE7-E10C6C4BDAAC@hp.com>
To: Smith Kennedy <smith.kennedy@hp.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Cc: PWG IPP Workgroup <ipp@pwg.org>
Subject: Re: [IPP] IPP Registration Request for Addition: New keywords for the "media" attribute
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ISTO-PWG Internet Printing Protocol workgroup discussion forum <ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>, <mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>, <mailto:ipp-request@pwg.org?subject=subscribe>
From: Michael Sweet via ipp <ipp@pwg.org>
Reply-To: Michael Sweet <msweet@msweet.org>
Content-Type: multipart/mixed; boundary="===============2168763119796190372=="
Errors-To: ipp-bounces@pwg.org
Sender: ipp <ipp-bounces@pwg.org>

Smith,

> On Mar 9, 2021, at 9:25 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy@hp.com> wrote:
>> ...
>> 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).
> 
> Agreed. So "media-family" (name(MAX)) or "media-group" (name(MAX))?

I think "media-group" (or "media-category") since "family" would imply the sizes are marketed together (like a family or series of printers) vs. the desired grouping of sizes.  But I'd only want to add this if we had some idea that it would be supported by IPP Clients - otherwise why bother?

> ...
> But let's say that a Printer supports a number of standard media sizes, and the Printer's manufacturer wanted to support some vendor-unique media sizes, and provide localized labels / names for these. If the Printer only provided "media-size", like the example from page 43 of 5100.7-2019, what value from the media-col collection would a Client be expected to use as the key to locate the appropriate string in the message catalog?

You would localize the equivalent "media" keyword value, either from a "media-size-name" value or by looking up the printer's self-describing media size name (in media-supported) that corresponds to the dimensions of "media-size".

But like I said, no client that I am aware of uses the printer's strings file to lookup localized media names.

> ...
> It seems that the Printer would need to provide "media-size-name" or "media-key" if the string were to be acquired from the IPP Message Catalog, and could provide both.

media-key would allow for the combinations ("US Letter Borderless, Glossy Photo"), which a Client could lookup using the "media-key.value" string.

> But which member would the Client be expected to use as its key? Should the Printer provide the same strings for both keys? It seems like 5100.7 needs some guidance on this.

I didn't bother because Clients don't use the printer's strings file to localize media sizes.   This is because we've defined all of the common names that can be consistently localized for all printers by the client, have a common syntax that provides the dimensions, and because dimensional names provide the best user experience for uncommon sizes.  Common photo sizes are a case in point - who knows that 8R refers to an 8x10" photo size?

> The "finishing-template" member of "finishings-col" is the obvious (and required) member for finishings, but we don't seem to have this for "media-col".

Because for finishing-template there is no standard for how the keywords are formed (beyond the simple enum keyword values), making localization with the printer's strings file desirable/the easy way out (otherwise you need to parse out the member attributes and their values to determine what the template does...)

________________________
Michael Sweet



_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp