Kelly,
On 2013-03-06, at 10:47 PM, kdLucas <kdlucas at google.com> wrote:
> I've attached a new specification related to Google Cloud Print 2.0: Google Cloud Print Semantic States, and is provided in PDF format. This new specification is designed to complement our Cloud Device Description Specification.
>> Your feedback is welcomed.
Overall this looks like a pretty clean mapping of what you can get from a modern printer. The main issues I see are a lack of computer-readable messages and a very different job state implementation that will cause a lot of headaches for implementation.
My comments:
1. PrinterStateSection: Doesn't have any kind of a "roll up" state indicating that user attention is required. Check out the IETF Printer MIB, IPP, and the Semantic Model for some examples of how this is done - having the roll-up state eliminates the need for the client to look at all of the state information to determine the answer...
2. CloudConnectionStateType: How about a "not configured" value - I believe I made the same suggestion for the Privet protocol as well.
3. VendorState: While I understand wanting to have a human-readable string here, it is equally-important to have something a computer can understand. Consider UI that might show an alert for a warning from the printer - "low ink" is something you probably want to just show and hide automatically, while "out of ink" is something you want to interrupt the user for and give them the option to cancel, restart, or continue the job. And this is something you likely want control over on the client side since UI choices may be different depending on the platform involved. Also, I would avoid providing an example like "System error 404." unless you want to see a lot of those impossible-to-decypher messages... :/
4. InputTrayState: If the level is a percent, then the values should go from 0 to 100. Vendors are going to get this wrong with a name like "level_percent", so either change the range or change the name to "level", "level_proportion", or something other than "level_percent".
5. OutputBinState: See #4.
6. MarkerState: See #4. Also not clear from the document how you get a description or other information about the marker supply that is referenced - using the Marker.ID that is defined elsewhere?
7. MediaPathState: See #3.
8. CoverState: See #3.
9. JobStateType: What state is reported if the user cancels a job? Also, "draft" isn't a state that is exposed in the semantic model - either the job is created or it isn't - there is no in-between. A job that hasn't been closed (received all of its documents/document URIs) is in either the pending (queued) or pending-held states, with a supplemental state string of "job-incoming", meaning that the printer/service is waiting for the document data/URIs to be submitted for the job. We've defined a minimal set of job states (pending, pending-held, processing, processing-stopped, aborted, canceled, completed) in order to reflect the state of the job object itself. The JobStateReasons element in the semantic model gives you additional state information about what the service is doing with the job object, and I encourage you to adopt a notion of "reasons" or "sub-states" for the current job state since it makes things much cleaner.
Also, your job state diagram seems to indicate that all jobs are initially held?!? Held jobs in the Semantic Model are an "equal" state to "pending" (your queued), and either can be the initial state of the job, as well as going from pending to pending-held or vice-versa. See the bottom of page 111 in RFC 2911 for an example of what we use for job states:
The following figure shows the normal job state transitions.
+----> canceled
/
+----> pending --------> processing ---------+------> completed
| ^ ^ \
--->+ | | +----> aborted
| v v /
+----> pending-held processing-stopped ---+
10. PrintJobState: This looks like some sort of mapping of JobStateReasons, but it is very confusing. See my comments on #9 above, but this will be very difficult to map from a printer conforming to the Semantic Model (which is basically all printers).
_________________________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20130317/308d557e/attachment-0002.html>