We also rely upon the severity suffixes and make use them in our iPrint
print system as required by RFC 2911. So deprecating them would be bad
for us and our installed base. What is wrong with just using the report
suffix on these values?
We currently don't use the printer-state-message attribute, but it was
meant for human readable strings. We would not be inclined to use a
collection mechanism for the prtAlert objects. There must be a better
way to do this.
McDonald, Ira wrote:
> Hi folks, Monday (17 July
>> I've just posted the first draft of the PWG IPP Printer State
> Extensions specification on the PWG FTP server at:
>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm>> This draft is technically complete (to the best of my ability)
> for the summary conformance sections (individual sections already
> detailed conformance requirements).
>> For immediate review, comment on the IPP WG mailing list
(ipp at pwg.org),
> and discussion at an IPP WG Telecon as soon as possible.
WRT section 5.1.1, CUPS implements the severity suffixes as required
by RFC 2911. I don't think we can just do away with them, but
defining a mapping from keyword-suffix to keyword would have the
equivalent effect without requiring an update of RFC 2911... Also,
I know I get "media-tray-empty-error" and other messages from HP
printers via IPP, so we're not the only company implementing it...
Also, overloading printer-state-message with non-localized alert
object data is, IMHO, the wrong approach. Define a printer-alert
1setOf collection that contains all of the prtAlert* objects. CUPS
uses printer-state-message to hold the human-readable state message
(as defined by RFC 2911), and it would be impossible for CUPS to
conform to this spec if you use printer-state-message for this
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
Sr. Software Engineer
ttronson at novell.com
-------------- next part --------------
An HTML attachment was scrubbed...