[IPP] Updated JPS3 draft posted

[IPP] Updated JPS3 draft posted

[IPP] Updated JPS3 draft posted

Ira McDonald blueroofmusic at gmail.com
Sat Mar 5 08:06:42 UTC 2011


I suggest that this new attribute be explicitly named
"media-size-name" (rather than the sadly ambiguous
"media-name") and constrained to ONLY take size
name values from the PWG Standard for Standardized
Media Names (PWG 5101.1-2002) - which is BTW
certainly the most circular and meaningless PWG
Candidate Standard document title that we've ever
come up with...

Note that our DMTF CIM_PrintInputTray class has the
element "MediaSizeName" which we used to map from
the Printer MIB's "prtInputMediaDimFeedDirDeclared"
and "prtInputMediaDimFeedDirDeclared" objects.

Also note that either "job-uri" or "job-id" can be used in
job operations, but either MUST be accompanied by the
enclosing "printer-uri" that specifies the over-the-wire
protocol target of the IPP over HTTP request.

- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
mailto:blueroofmusic at gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
May to Christmas:
  PO Box 221  Grand Marais, MI 49839

On Fri, Mar 4, 2011 at 7:59 PM, Michael Sweet <msweet at apple.com> wrote:

> 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.
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20110305/40cdbe43/attachment-0001.html>

More information about the ipp mailing list