[IPP] Updated JPS3 draft posted

[IPP] Updated JPS3 draft posted

Yousey, Marc marc.yousey at hp.com
Mon Mar 7 21:55:14 UTC 2011

Client-error-document-format-error works for me I just wasn't sure if we had a policy on whether job-state-reasons should have a matching status-code or not.  There seems to be a rough but not perfect correlation between them.

I'm not asking for new stutus-codes just clarification.


-----Original Message-----
From: Michael Sweet [mailto:msweet at apple.com] 
Sent: Friday, March 04, 2011 4:59 PM
To: Yousey, Marc
Cc: ipp at pwg.org
Subject: Re: [IPP] Updated JPS3 draft posted

On Mar 4, 2011, at 3:53 PM, Yousey, Marc wrote:
> One thing that would be nice to add to the media-col is the pwg-standard-name.  With rounding going on on both sides of the wire it can be difficult to associate the standard sizes in media-supported to the media-size elements in the media-col-database.  If the media-size collection had a pwg-standard-name (or similar) attribute we could be sure which size everyone was talking about rather than trying to guess.

I have no objection to adding a media-name member attribute that contains the PWG media name that corresponds to the given dimensions and margins. While size matching is not usually an issue for CUPS, margin matching often can be...

> Also, a few questions:
> 1) job-uri is just an informational object correct?  I.e. it is not a new way to specify which job you are operating on in say a get-job-attributes or cancel-job request.

I assume you mean job-uuid? In the current definition it is only used as an informational object. The local job-id  or job-uri is used to actually specify the job object in job operations. If all you had was a job-uuid, you would need to use the Get-Jobs operation to get a list of all jobs and their job-uuid attributes and then find the job you are interested in.

> 2) On the new job-state-reasons, is there a corresponding status code to return with job requests?  There seems to be a pairing between many but not all of the job-state-reasons and status-codes.

Currently I have not added any new status-code values, although we can do so if a need is seen. Both document-security-error and document-unprintable-error checking could be done as part of job/document creation, although I think it is more likely that they will be discovered while processing the job.

Is the existing client-error-document-format-error status code sufficient, or would you prefer to see new status codes for each?

Michael Sweet, Senior Printing System Engineer, PWG Chair

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the ipp mailing list