attachment
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">Hi Mike,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Michael Sweet <msweet@msweet.org> <br>
<b>Sent:</b> Wednesday, March 3, 2021 1:22 PM<br>
<b>To:</b> Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy@hp.com><br>
<b>Cc:</b> PWG IPP Workgroup <ipp@pwg.org><br>
<b>Subject:</b> Re: [IPP] IPP Registration Request for Addition: New keywords for the "media" attribute<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Smith,<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">On Mar 3, 2021, at 1:10 PM, Kennedy, Smith (Wireless & IPP Standards) <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>> wrote:<br>
<br>
Hi Mike,<br>
<br>
From: Michael Sweet <<a href="mailto:msweet@msweet.org">msweet@msweet.org</a>> <br>
Sent: Tuesday, March 2, 2021 1:13 PM<br>
To: Kennedy, Smith (Wireless & IPP Standards) <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>><br>
Cc: PWG IPP Workgroup <<a href="mailto:ipp@pwg.org">ipp@pwg.org</a>><br>
Subject: Re: [IPP] IPP Registration Request for Addition: New keywords for the "media" attribute<br>
<br>
Smith,<br>
<br>
At first blush I see some duplicated sizes from the registry:<br>
<br>
na_arch-c_18x24in<br>
na_arch-d_24x36in<br>
<br>
and the MSN2 spec doesn't allow those...<br>
<br>
[Smith K.] I know we have in the past agreed to not register certain new media keywords because their dimensions were redundant with others already registered. The recent discussion about media “family” grouping has made me question that. (I’m also having a
hard time finding the clauses in PWG 5101.1-2013 that mandates the “no size redundancy” restriction.)<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ugh, it looks like MSN 2 lost this text from MSN 1:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<p class="MsoNormal">5.1.4 For interchange between programs, the dimensions presented in this standard must never be converted to the another system of units, but must remain as defined in this standard. Furthermore, an identical size shall never appear in
this standard with different units. Programs may convert the dimensions to other units when displaying these names to human users and for internal use, both of which are outside the scope of this standard.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">[Smith K.] I filed an errata:
<a href="https://www.pwg.org/dynamo/issues.php?U106">https://www.pwg.org/dynamo/issues.php?U106</a>
<o:p></o:p></span></i></b></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">If a Client were implemented to present supported media using a hierarchical system where families are grouped together (e.g. Architectural, Photo, etc.) and the Printer vendor wanted that Client to offer the user both an “Architectural
C” in the Architectural family and a “Super C” in the Photo family, this would be impossible using only the “media-supported” attribute without the Client knowing a-priori that na_arch-c_18x24in should be shown in two different places and with two different
strings (which the Client presumably provides since the Printer can only provide one localized string in its message catalog for a given keyword).<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">So three notes:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. CUPS-based systems (including Linux, macOS, and iOS) never use any localized media size names from the Printer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">[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.<o:p></o:p></span></i></b></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">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”<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">"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")<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">[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?<o:p></o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><b><i><span style="color:#1F497D">(I don’t see a “media-name” member registered with IANA or in 5100.7…)<o:p></o:p></span></i></b></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">and then I suppose the “Super C” could have some suffix on it (‘na_arch-c_18x24in_photo-super-c’) to make it unique, and that would then provide a unique key in the message catalog so it could have a different label. But we would still
have no standard solution for the family problem, though.<o:p></o:p></p>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><br>
Also, while I appreciate keeping the na_WIDTHxHEIGHT_WIDTHxHEIGHTin form for those dimensional sizes, if they are primarily for photo/art printing I'd like to see a 'photo' prefix in the name portion, e.g.:<br>
<br>
oe_photo-16x20_16x20in<br>
<br>
Similarly, the om_photo sizes should include the dimensions if there is no corresponding well-known name:<br>
<br>
om_photo-300x400_300x400mm<br>
<br>
<br>
[Smith K.] I don’t have a problem with this recommendation in principle, but I’d like to see it codified in an update to MSN2. Seeking information on the “oe_10x12_10x12in” and such – more soon.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">It isn't super clear in MSN2, but section 5.1.5 says:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<p class="MsoNormal">The common usage of some names can represent several physical sizes, e.g., folio, quarto, foolscap, and executive. To avoid naming and sizing conflicts, a hyphenated identifier MUST be used to link the names to a specific size.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">and then we define multiple sizes using the name prefix "photo", "index", "govt", "fanfold", etc. with "-extra" and "-tab" suffixes for many sizes as well.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Like I said, if those dimensional sizes are more widely used then there is precedence (just look at MSN2) for registering purely dimensional names, but if all we cared about was the dimensions we'd just use the media-size collection in
media-col...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">________________________<br>
Michael Sweet<br>
<br>
<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>