Hi,
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.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434
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>