Mike, a few comments for consideration
1. Line 190+ --- Section 2.3 on terminology is a table in other PWG
specification. A table format makes it easy to read.
2. Line 191 --- I thought that "coloring" as adding or assigning
attributes values; typically by "discovery" of attributes from a
document-format. In fact the term in only used on line 484 and could
easily be dropped and remove any confusion.
3. Line 192 --- The term "direct imaging" is not used in the
document and it also seems we are inventing new terminology.
4. Line 201 --- The term "indirect imaging" is not used in the
document and it also seems we are inventing new terminology.
5. Line 206 --- Service seems to be ambiguous. For this
specification, isn't Service a Print Service? If the definition is
trying to define "Service" in a totally generic sense then any use of
the term Service needs an adjective to name the Service. I.e. Print
Service, Print Client Service, Print Transform Service; but Service
alone not descriptive.
6. Line 209 --- The term "Visible Device" is not used in the
document and it also seems we are inventing new terminology.
7. Line 210 --- "Visible/Visibility" is "access/accessibility"
and should not depend upon "direct/indirect" communication, How would
the Client even know or care. Again, we seem to be inventing new terms.
8. Line 219 --- How does existing protocols or schema do any kind
"... auto-configuration of imaging devices". It might configure an
imaging device but not auto-configure.
9. Line 229 --- HTTP 1.1 already supports message chunking; did
you have some specific reason for stating "with chunking" in this
rationale?
10. Line 235 --- The "minimal file format" should be the "minimal
print format" or "minimal print-content format" since a PWG Raster may
never be a file.
11. Line 236 --- There seems to be no value to the words "color and
grayscale" since PWG raster support more color format that just color
and grayscale. I suggest removing the words.
12. Line 239 --- There seems to be no value to the words "color and
grayscale" since PWG raster support more color format that just color
and grayscale. I suggest removing the words.
13. Line 244 --- I suggest changing "photographic" to "bitmap"
14. Line 258 --- I believe in the sentence "Printer selection is part
of most Service use cases", the word "Service" should be removed or
replaced with "printing". The word "Service" is ambiguous and
confusing.
15. Line 260 --- How can a "Logical Printer" be a "Scan Service";
perhaps you meant a "Print Service"
16. Line 261 --- I recommend putting quotes around "Selection Using a
Directory Service" and "Selection Using Properties" to denote they are
title of sections.
17. Line 265 --- I suggest changing the line to read "For all of the
following use-cases, a Printer or Print Service must be accessible to
the Client to be selectable."
18. Line 267 --- Section 3.2.1.1 --- This use-case should be
removed. Why is this section a use-case for IPP? It does imply or
infer any requirement for IPP-Everywhere. It attempts to define the
requirement and operations of a Print Client(!!!) and this specification
does not define this type Client operations that are not IPP related.
19. Line 275 --- I am confused about how this line is written. I
don't see the situation where the Client asks the User for a printer
name or address. I do see the case where the Client presents a list of
Printer/Print-Service by name or address. If the user (and now the
Client, perhaps) is at a new location; exactly how to they obtain the
printer name - ask someone!!!
20. Line 282 --- same comment as for Line 275. When was the last
time you saw a Client interface asked-for the URI of the printer (may be
in setup but no by the Client).
21. Through out the document, it only discusses the "Printer". I
very strong recommend this be change to "Printer or Print Service". The
new print paradigm is service and printer.
22. Line 298 --- Change "Visible" to "accessible".
23. Line 302 --- The words "on behalf of the user" should be removed.
There may no always be a user (example an embedded solution).
24. Line 302 --- I do not see why there is a requirement that the
Client "maintains a dynamic list of "accessible" Printers, during
selection. I believe this should read, the Client "present a list of
the currently accessible Printers or Print Services during selection".
The original statement put a burden on the Client to continuously
initiate discovery or updating a list or drop-down menu if a new printer
just happens to come up during the printer selection action.
25. Line 304 --- Suggest removing ", updating those Printers as they
come and go." Have you ever tried selecting something from a list as
the list continues to change; it ain't fun.
26. Line 309 --- Shouldn't geo-location be a filter on Printer and
Print Service found by Discovery; where the Printer and Print Services
report geo-location? The Client, via the user, may have to specify
what "a range" (proximity) to use.
27. Line 313 --- Is the implication of this statement that the
Printer or Print Service will somehow maintain the geo-loc list of
Client !!!! I understand the Printer or Print Service has a geo-loc
and the Client knows its own geo-loc; so the Client can do "proximity"
sorting (I don't about the word "detection").
28. line 315 --- Section 3.2.18 If the Client can use Discovery to
find the Printer or Print Service; then you are suggesting the reading a
bar-code will somehow establish communication and an IPP protocol;
interesting !!!!
29. line 323 --- What does "properties such as Service" mean? If
"Service" is dropped and line 324 changes "Printer" to "Printer or Print
Service" then it makes sense.
30. Line 324 --- Again, "Service properties include ...." makes more
sense if it read "Printer or Print Service properties include....". I
can not see a User selecting an XYZ - protocol using an ABC-security
model; if so, that's one sophisticated user. If you are attempting to
encompass a Cloud Print Service, I believe that protocol and security
issues with the Client are done behind the scene based on some global
Client host system settings.
31. line 330 --- I believe a better wording is something like. "The
User sets selection filters and/or conditions in the Client User
Interface which are used to obtain a list of candidate Printers or Print
Services. The Client filters the Printer and Print Service list using
the user chosen filters and conditions along with site and/or
administrative policies and restrictions. The User selects a printer
from the filtered list provided by the Client User Interface."
32. line 336 --- I would suggest removing the first sentence; I
really think the primary function of most Printers is to print!
33. line 338 --- I suggest this wording. "the Printer or Print
Service status and capabilities information. " There should be no need
to display status information unless it does not allow the user to
print. If, by status, you mean number of existing job on the printer;
so the user can determine if another, less busy, printer should be used;
then ok; but lets make it "Existing Job Status". If you mean ink/toner
levels; this may or not be a returnable value to all user. For a
managed at Star Bucks, only the administrator may get an indicator of
ink/toner levels. This specification, in the intro section, discussion
the use for mobile devices; so if I have a 7 inch display; not problem;
if I have a cell phone; screen space if very limited. Thus, displaying
any status information is implementation specific with the exception of
status that prevents actual printing (which would likely be a pop up
dialog).
34. Line 347 --- Add the word "A" to beginning of sentence.
35. Line 348 --- Need to fix "user User". At the end of the
sentence, I believe the word "processing" should be replaced with
"print".
36. Line 349 --- in the first part of the sentence you use "Job" but
in the next sentence you use "print job"; I suggest using "print job" in
both places.
37. line 349 --- suggest changing "print action" to "print intent"
38. line 350 --- would it be clearer to change "Job Ticket" to
"Print Job Ticket" (everywhere in the document)
39. Line 353 --- same as for line 347
40. line 355 --- suggest changing "processing" to "print"
41. line 356 --- same as for line 349; both comments
42. line 357 --- same as for line 350
43. line 360 --- same as for line 347
44. line 360 --- to match the next paragraph; I would suggest
changing "viewing a photo" to "viewing a photo on her phone"
45. line 361 --- the word "her" could be replaced with "her
selected"
46. line 363 --- I suggest this wording; "automatically sets the
media selection to the largest ..."
47. line 364 --- change "processing" to "print"
48. line 365 --- same as for line 349; both comments
49. line 378-379 --- to make this use-case work out as defined
the Client must be part of the accounting program. No problem with
this and, in fact, it is a good idea. To make this clear, some
rewording is needed. For example "The User initiates check printing
using the accounting program's print Client. The User selects the
Printer with the check blanks loaded and selects checks as the print
intent. The accounting program's Client User Interface ..."
50. line 381 --- change second sentence to "The accounting program's
Client set the media-source to the tray containing the blank checks."
51. Line 385 --- should the User de-configure the Printer for the
"check" media or should the Printer do that (how and when).
52. after line 385 --- The same precondition for this use-case as
was in the last use-case
53. line 387 --- while the use of the words "factotum and general
gofer" is interesting; it sounds demeaning; can we use something else.
Maybe, "resort, a resort associate" and change Gofer in other places
to Associate.
54. line 389 --- modify "Costs ...." To "Costs of printing ..."
Also change "Gofer" to "The Associate"
55. line 390 --- change "Resort" to "The resort" Also change
"available to users" to "available for use" since users is ambiguous and
it will be an employee that will actually do the printing in this
use-case.
56. line 392 --- It is not clear that a the printed material will be
"removed from the premises". So change to "sheets for quest use".
57. Line 394 --- change "processing" to "print" and change "action"
to "intent" (no action has taken place yet only an intent of action)
58. Line 395 --- The client does not "produce document data"!!!! I
think something else is meant here, but needs to be made clearer in the
paragraph. That is, the user created a document-page with the ten
keywords/phrases and, then, used the number-up layout feature of the
Client to duplicate the document-page on the print-page" with the
correct 2" x 1" sizing.
59. Line 399 --- I believe this use case is about "only physically
print the job when I am at the printer and entry a code". So the title
should be something like "Print when authorized at Printer".
60. Line 400 --- this line needs to be replaced with something like.
"The account manager needs to print the monthly statements on the high
speed, general use Printer in the hallway. After he sets up his print
intent and identifies the document to be printed; he selects the option
for "Print When Present" which will hold the Print Job until he enters
his access code. The Client then sends the Print Job to the Printer to
be held until the manager present. The manager goes to the hallway
Printer and after noting the Printer is not in use, he selects his job,
enters his access code and printing begins."
61. Line 403 --- This paragraph would have to make the general use
case from the new paragraph above.
62. Line 407 --- Interesting point: Does the Client only send a
"Hold Until Present" request to the printer; then, after authorization
send the actual print job. Or, does the Client send the actual Print
Job with the "Hold Until Present" flag set. This would require that
Printer be able to hold the Job at the Printer. Either or both
scenarios are interesting and valid.
63. line 410 --- where are the document. Did he upload them to his
phone or are they in a repository. Let's just say at an accessible URI
64. Line 412 --- change to " .... provider web pages. Using the
provider web based Client, he specifies his job intent of 10 color
copies, printed duplex and stapled on the left side. He also specifies
the covers to be 80lb. stock, and the internal pages to be 24lb. stock.
After review is his print intent, he enters the URI for the document and
submits the Print Job."
65. Line 417 --- This is not different from the use-case 3.2.2.6
66. line 425 --- Title could be "Print with Proof Print"
67. Line 426 --- change "processing" to "print"
68. Line 427 --- change "selects ..." to "set the option for a proof
print using page 17 of the full document and confirms the print intent.
69. line 429 --- change "prints a ..." to "prints a proof print
using page 17 of the document."
70. line 434 --- Interesting. When the Client was invoked and the
Client created a list of discovered printer or print service, it
displayed the list to the user; by default the Client User Interface
would have to have some printer selected (the first in the list most
likely). So if the cancels or does not select a different printer then
the one that was set in Client user Interface list would become the
default. This would be true even if a pop-up were used for the printer
selection. So the print request does not have to cancel.
71. line 436 --- change "Visible" to "accessible"
72. Line 441 --- suggest changing "print the document" to "print the
Print Job"
73. line 449 --- Does "cancels the print request" imply that the
Client terminated or could the Client inform the user to wait.
74. line 483 --- capitalize the first word "list"
75. Line 484 --- change "coloring" to "capabilities"
Out of time and the rest looks pretty good.
Glen
--
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/20120202/a0a11b1e/attachment-0001.html>