[SM3] [IPP] IPP Transaction-Based Printing Extensions specification ...comments.

[SM3] [IPP] IPP Transaction-Based Printing Extensions specification ...comments.

Michael Sweet msweet at apple.com
Mon Sep 16 17:56:03 UTC 2013


Daniel,

Thank you for the response.

My own personal experience with various IPP implementations from consumer inkjet's through high-end light production office equipment shows that performance with multiple requests (in serial or parallel) introduces delays on the order of seconds with some printers.  A delay of even 1 second can seem like an eternity in an interactive UI.

In some cases the overhead is with the implementation (low-end hardware with non-optimized IPP stack) and in other cases with the configuration (TLS, authentication, etc.) which introduces a lot of round trips and retransmissions.  And many low-end printers limit the number of simultaneous client requests making a parallel request strategy cause more delays than simply issuing multiple requests over a single connection.  Add IPP USB to the mix and you are *really* constrained in the number of parallel requests you can make.

Perhaps things like HTTP/2.0 and future TLS specifications will address many of the performance issues inherent in a parallel request strategy, but those are not yet available or implemented in production printers.

(FWIW, I don't regret defining these PDL-specific attributes: it has made printing an enjoyable experience for hundreds of millions of users.)

WRT the Semantic Model, there are already differences in what is defined in IPP and the SM, from operations (Get-Jobs + which-jobs vs. GetXxxJobs) to attributes (MediaType top-level element in SM that is not in IPP, various IPP operation attributes like "compression" that are not in the SM, etc.)  IMHO the important thing is for the core semantics to remain the same, not to provide a directly-accessible SM element for every IPP attribute.

So I might not add xxx-k-octets-supported to the SM, but something like pdf-versions-supported would be a candidate since you can't get it from DocumentFormatDetails.


On Sep 13, 2013, at 7:33 PM, Manchala, Daniel <Daniel.Manchala at xerox.com> wrote:

> Michael,
>  
> Thanks for the response to earlier comments from Xerox. Just a few additional comments on the same topic.
>  
> Given your explanation to Justin, and other “industry efforts”, Xerox will accept your rejection of 1 through 5 (copied below for reference), although we believe IPP should have avoided PDL specific attributes.  We have two ways to obtain the same information.  The network overhead of attribute coloring is minimal and can be mitigated through parallel requests or technologies such as “Volley.
>  
> It is best the PWG mirror every IPP attribute in the PWG Semantic Model even if they are a side-effect of the protocol or of targeting specific markets/use cases. 
>  
> Thanks,
> /Daniel.
>  
> Here are the five comments (copied from an earlier email note):
>  
> IPP Attributes should be document format independent.  Existing semantics should be used when they exist or corrected when additional semantics are required.
> 1)      “jpeg-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”. 
> a.       Note that IPP attribute coloring can be used to obtain document format specific values when required.
>  
> In actual implementation, the existing attribute (with multiple queries) was too inefficient.  This attribute has been widely implemented in IPP printers since 2010.
>  
> My preference is to reject this request.
>  
> 2)      “pdf-k-octets-supported” should be dropped in favor of the existing “k-octets-supported”.
>  
> In actual implementation, the existing attribute (with multiple queries) was too inefficient.  This attribute has been widely implemented in IPP printers since 2010.
>  
> My preference is to reject this request.
>  
> (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)
>  
> 3)      “pdf-versions-supported” should be dropped in favor of the existing “document-format-details-supported” (“document-format” and “document-format-version” members).
>  
> "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.
>  
> 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.
>  
> 4)      “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”.
>  
> These attributes have been widely implemented since 2010.  And as I've noted before doing multiple Get-Printer-Attributes requests is really inefficient.
>  
> My preference is to reject this request.
>  
> 5)      “printer-dns-sd-name” should be applicable to any service.  The name should be changed to “dns-sd-name”.
>  
> 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).
>  
> Scaling should not be print specific.
>  
> 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.
>  
> 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”
>  
> 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)
>  
> 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".
>  
> 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).
>  
> My preference is to reject this request.
>  
>  
>  
> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: Friday, September 06, 2013 10:05 AM
> To: Justin Hutchings
> Cc: ipp at pwg.org
> Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments
>  
> Justin,
>  
> Fair enough, we do have use cases but will highlight for each of the attributes.
>  
>  
> On Sep 6, 2013, at 12:53 PM, Justin Hutchings <justhu at microsoft.com> wrote:
> 
> 
> Thanks for your quick response, Mike. It might be worthwhile to articulate the rationale as to why these are required in the spec. I didn’t pick up on all that during my read through.
>  
> Thanks!
> Justin
>  
> From: Michael Sweet [mailto:msweet at apple.com] 
> Sent: Friday, September 6, 2013 7:00 AM
> To: Justin Hutchings
> Cc: ipp at pwg.org; Ira McDonald; Paul Tykodi
> Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments
>  
> Justin,
>  
> Thank you for your feedback!  Quick comments inline...
>  
> On Sep 5, 2013, at 6:06 PM, Justin Hutchings <justhu at microsoft.com> wrote:
> -          OpenXPS has a MIME type of application/oxps, not application/OpenXPS (http://www.iana.org/assignments/media-types/application/oxps)
>  
> Oops, will fix.
> 
> 
> 
> -          This spec appears to have a bunch of content which is completely unrelated to the transaction based printing. Why are we throwing these into what would otherwise be a very straightforward, to-the-point spec?
>  
> These have particular application to commercial print services and service discovery.
>  
> o   Print-scaling-supported
> o   Print-scaling-default
>  
> These provide control over the final imposition/scaling of the document data on the output media - important particularly for commercial print services.
> 
> 
> 
> o   Printer-dns-sd-name
>  
> This is used for service discovery; we need to have a way to configure the service name.
> 
> 
> 
> o   Printer-kind
>  
> This is used for service selection/filtering - again, if you are looking for a print service that supports the kind of document you are printing, you need this information.
>  
> (this is also part of the DNS-SD TXT record, but DNS-SD is not the only way to do discovery)
> 
> 
> 
> o   Jpeg-*
> o   Pdf-*
>  
> These are used to inform the Client of limits for direct photo and PDF printing - having dealt with a lot of commercial print shops over the years, it is VERY important for the Client to be able to know whether they support a particular flavor of PDF or have limits in the maximum size/dimensions of print files.
>  
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>  
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>  
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>  
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




More information about the sm3 mailing list