[IPP] Several questions about "finishings-col-default" and "finishings-default"

[IPP] Several questions about "finishings-col-default" and "finishings-default"

Michael Sweet msweet at apple.com
Fri Dec 5 19:03:31 UTC 2014


Smith,

> On Dec 5, 2014, at 12:42 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
> 
> Greetings,
> 
> In the process of doing final evaluation of FIN2 leading up to voting, some questions have arisen about the “finishings-col-default” attribute that I wanted to discuss on the reflector.
> 
> 
> 1. How would “finishings-col-default” provide an equivalent to “finishings” == ‘none’?  PWG 5100.3 makes no restriction on what can be in “finishings-col-default”, so from a 5100.3 perspective this would be legitimate:
> 
> finishings-col-default = { finishing-template = ’none’ }
> 
> FIN2 section 6.9 doesn’t seem to disallow including an entry in “finishings-col-database” like the one above, but for some reason ’none’ not included in the following statement in 6.9 lines 1079-1081:
> 
> Printers SHOULD report "finishings-col-database" values for each "finishings-supported" value other than 'none', and MAY report multiple instances with the same "finishing- template" value but different "media-size" or "media-size-name" values.

Because 'none' is always supported/ready, there is no point in including it in finishings-col-database or finishings-col-ready.

It can show up in finishing-template-supported, but then you can also use 'no-value' for the whole collection in finishings-col-default.

> I don’t get why “other than ‘none’” was included here.  Presumably a Client would never need to even consult such an entry since the meaning of ‘none’ should be well-understood by a client that properly implements 5100.3 and FIN2, that knows to start with finishings-XXX and then go to finishings-col-XXX if more details are needed?  If so that should be called out more clearly (maybe in the IPP Implementor’s Guide v2 but better if it is in the FIN2 spec itself).

'none' (or more specifically the enum value 3) has an explicit semantic of performing no finishing processes.  I could add a Note: for this to make sure there is no confusion about this.  (just include this as a comment in your vote...)

> 2. I don’t quite understand why “finishings-col-default” would ever be needed or need to have sub-attributes other than “finishing-template”?  I guess it is conceivable that the default may be custom settings not described in any entry in “finishings-col-database”, but is that kind of flexibility really a good thing?  It adds complexity to a Client for that corner case.

"finishings-col-default" contains the default finishings-col value(s) that is (are) used for job processing, so it is desirable for the value(s) to tell the Client what processes are applied and with what locations/offsets/etc.  Otherwise the Client needs to consult both finishings-col-default and finishings-col-database in order to determine the specific finishing values that will be used.

> 3. There seems to be no requirement that “finishings-default” and “finishings-col-default” need to be synchronized - is this an oversight?

Yes, please include this as a comment.  This was also not addressed in 5100.3 (production printing) where finishings-col first appeared... :/

> 4. Related to #3, it may be that “finishings-col-default” has its “finishing-template” value set to a “name(MAX) value, which isn’t allowable in “finishings-default”.  In this case, what should the value be set to in “finishings-default”?

It might very well be a vendor enum value (0x40000000 and up).  We can address this along with the wording for #3 (so please include this in your comments as well...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141205/bcf40522/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141205/bcf40522/attachment.p7s>


More information about the ipp mailing list