attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Daniel,<div><br></div><div>Thank you for the additional comments. My initial responses are inline below, but as a general comment I think we don't need to mirror every IPP attribute in the SM - some things are a side-effect of the protocol or of targeting specific markets/use cases.</div><div><br></div><div><br><div><div>On Aug 30, 2013, at 12:57 PM, Manchala, Daniel <<a href="mailto:Daniel.Manchala@xerox.com">Daniel.Manchala@xerox.com</a>> wrote:</div><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style id="owaParaStyle" type="text/css">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
P {margin-top:0;margin-bottom:0;}</style>
<div ocsi="0" fpstyle="1">
<div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><br>
<font face="Calibri" size="2">Some additional comments from Xerox:</font><br>
<br><p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">IPP Attributes should be document format independent. Existing semantics should be used when they exist or corrected when additional semantics are required.</span></p><p class="MsoListParagraph" style="margin-left:20.25pt; text-indent:-.25in"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><span style="">1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">“jpeg-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.
</span></p><p class="MsoListParagraph" style="margin-left:56.25pt; text-indent:-.25in"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><span style="">a.<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Note that IPP attribute coloring can be used to obtain document format specific values when required.
</span></p></div></div></blockquote><div><br></div>In actual implementation, the existing attribute (with multiple queries) was too inefficient. This attribute has been widely implemented in IPP printers since 2010.</div><div><br></div><div>My preference is to reject this request.</div><div><br></div><div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><p class="MsoListParagraph" style="margin-left:20.25pt; text-indent:-.25in"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><span style="">2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">“pdf-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.</span></p></div></div></blockquote><div><br></div><div>In actual implementation, the existing attribute (with multiple queries) was too inefficient. This attribute has been widely implemented in IPP printers since 2010.</div><div><br></div><div>My preference is to reject this request.</div><div><br></div><div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"></div></div></blockquote></div><div>(For reference, a Client might need to determine supported file formats and sizes in order to determine which format to send to the Printer. And certain file formats such as PWG Raster generally are streamed on both the Client and Printer so the job-k-octets-supported value is MAX vs. some smaller value for PDF or JPEG)</div><div><br></div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><p class="MsoListParagraph" style="margin-left:20.25pt; text-indent:-.25in"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><span style="">3)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">“pdf-versions-supported” should be dropped in favor of the existing “document-format-details-supported” (“document-format” and “document-format-version” members).</span></p></div></div></blockquote><div><br></div><div>"document-format-version" is localized text, "document-format-details-supported" is a list of member attributes supported by the "document-format-details" attribute, and "document-format-version-supported" is a list of all of the localized version strings that are supported for all formats that is optionally filtered by document-format when you do a Get-Printer-Attributes request.</div><div><br></div><div>Since there is no way to register localized text values, filtering those values with multiple Get-Printer-Attributes requests is inefficient, and this attribute is supported by most IPP+PDF printers since 2010, my preference is to reject this request.</div><div><br></div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><p class="MsoListParagraph" style="margin-left:20.25pt; text-indent:-.25in"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><span style="">4)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">“jpeg-x-dimension-supported” and “jpeg-y-dimension-supported” should apply to any image format. The names should be changed to “max-image-x-dimension-supported”
and “max-image -x-dimension-supported”.</span></p></div></div></blockquote><div><br></div>These attributes have been widely implemented since 2010. And as I've noted before doing multiple Get-Printer-Attributes requests is really inefficient.</div><div><br></div><div><div>My preference is to reject this request.</div><div><br></div><div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"></div></div></blockquote></div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><p class="MsoListParagraph" style="margin-left:20.25pt; text-indent:-.25in"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"><span style="">5)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">“printer-dns-sd-name” should be applicable to any service. The name should be changed to “dns-sd-name”.</span></p></div></div></blockquote><div><br></div><div>With a few exceptions, we prefix all Printer Description attributes that are not associated with Job/Document Template attributes with "printer-". And since DNS-SD is a *service* discovery protocol, not a device discovery protocol, I don't think dropping the "printer-" prefix or using an alternate prefix like "device-" makes sense. And FWIW CUPS has implemented "printer-dns-sd-name" for a very long time (since CUPS 1.2/2005 IIRC).</div><div><br></div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><p class="MsoListParagraph" style="margin-left:20.25pt"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Scaling should not be print specific.</span></p></div></div></blockquote><div><br></div>IPP = Internet Printing Protocol, so we are necessarily focused on printing. And as has been done in the past, SM can (and probably should) map print-scaling to ScalingMode (or whatever), just as print-quality is mapped to Quality, printer-resolution => Resolution, etc.</div><div><br></div><div><blockquote type="cite" dir="auto"><div ocsi="0" fpstyle="1"><div style="direction: ltr; font-family: Tahoma; font-size: 10pt;"><p class="MsoListParagraph" style="margin-left:20.25pt"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">The PWG Semantic Model already defined a collection for scaling (i.e., “scaling”).
Apparently we didn’t quite get it right. The current definition allows for explicit scaling (i.e., “scaling-height” and “scaling-width”) or a boolean for “auto-scaling”. The explicit scaling member should be kept. The Boolean “auto-scaling” should be deprecating
and an attribute with a unique name (e.g., “auto-scale-mode”) should replace it with the semantics defined for “print-scaling”
</span></p></div></div></blockquote><div><br></div>FWIW, CUPS previously supported two other attributes for scaling in the past - "scaling" (scale to a percentage of the media size) and "natural-scaling" (scale to a percentage of the document size). This allowed for "poster" printing over multiple media sheets, among other things, but had a lot of limitations and implementation issues. (BTW, we only ever supported symmetric scaling: scaling-width == scaling-height)</div><div><br></div><div>I *can* see the use case for copy - copy this hardcopy document and enlarge to 200% - but for print the 99% use case is "enlarge this document/image to fit/fill these (media) dimensions". In many cases there are no (reliable) physical dimensions to work with, so saying "enlarge to 200%" has no meaning. However, you can always say "fit/fill the document data on the requested media".</div><div><br></div><div>Also, the current Scaling group in SM is not part of the Print service, just under the Copy, FaxIn, FaxOut, and Scan services (under <service>DocumentProcessing).</div><div><br></div><div><div>My preference is to reject this request.</div><div><br></div></div><div><span style="font-family: 'Andale Mono'; orphans: 2; text-align: -webkit-auto; widows: 2;">_________________________________________________________</span></div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></body></html>