Glen,
Thanks for the comments; we can discuss these at the F2F in some detail, but some quick comments are inline...
On Feb 2, 2012, at 3:24 PM, Petrie, Glen wrote:
> 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.
We've never used tables in IPP specifications; will bring this up for discussion at the F2F.
> 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.
"Coloring" comes from RFC 2911, so I'd prefer not to omit or change it at this point.
> 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.
These come from the common use case document at the cost of many weeks worth of discussions...
> 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.
This refers to auto-configuration of host drivers, not auto-configuration of the imaging device itself.
> 9. Line 229 --- HTTP 1.1 already supports message chunking; did you have some specific reason for stating “with chunking” in this rationale?
13 year of bad IPP implementations layered on top of HTTP/1.0 masquerading as HTTP/1.1.
(similar language is in IPP/2.0)
> 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.
I could go with "minimal document format"; as for the file vs. stream argument, let's not go there (that is an implementation detail)
> 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.
We need to say something about the fact that it supports different kinds of color; "color and grayscale" gets the point across without being overly technical here.
> 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.
I assume you mean PDF supports more color formats, but my point above stands.
> 13. Line 244 --- I suggest changing “photographic” to “bitmap”
JPEG = Joint Photographic Experts Group. JPEG is used for photos. Image is usually == 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.
We don't want to rewrite everything for IPP Everywhere 2.0, and this was changed based on feedback during the last review at the August 2011 F2F...
> 15. Line 260 --- How can a “Logical Printer” be a “Scan Service”; perhaps you meant a “Print Service”
This change was specifically requested; let's talk about this at the F2F.
> 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.”
This is the wording we agreed to at the last Common Use Case BOF...
> 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.
It highlights the need for geo-location and organizational information, among other conditions that might be used to select the last used printer.
> 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!!!
All desktop operating systems provide a way to add/select a printer by manually providing a name or address.
> 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).
The use cases do not differentiate between a user application and a management application, but (for example) you can add a printer from the print dialog in OS X.
> 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.
IPP Printer == logical printer (service) or physical printer (device).
> 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).
Somebody turned the embedded solution on. And this all comes from the common use case BOF text...
> 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.
This is not a design document for the client UI. This is a list of use cases for a protocol specification - what does the protocol need to be capable of? Whether a client chooses to implement some aspect of a protocol is up to the client.
> 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.
Such interfaces exist today.
> 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.
Geo-location *may* be a filter, but this was called out specifically in the Use Case BOF since not all directory services may provide filtering; we need the info in the protocol to support the use case.
> 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”).
No, the Client and Printer each maintain their own knowledge of location.
> 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 !!!!
Bar codes can convey a bunch of info, including things like network address and printer URI.
> 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.
As in, which service is providing the printer ("show me all the printers available via Google Cloud Print")
> 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.
The use case does not define how it is implemented, again we just want the capability...
....
Stopping here, but keep in mind that ALL of these use cases came directly from the Use Case BOFs; I am hesitant to start back down the road of making major changes to them, but I will make sure to incorporate your editorial changes in future revisions of the document. We can debate the use cases themselves in the F2F sessions...
_________________________________________________________
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/ipp/attachments/20120202/24168459/attachment-0001.html>