Subject: [IPP] A few Comments on IPP-Everywhere 1.0

From: "Petrie, Glen" <[email-masked]>
Date: Thu, 2 Feb 2012 15:24:46 -0800

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.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Thu, 02 Feb 2012 16:49:42 -0800

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:

> 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

---

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 3 Feb 2012 07:21:32 -0800

Mike,

I hope we will not go through all of my comments at the F2F or even in
phone meetings.  They are my opinion on what would improve the document
or make it clearer.   Of course, if you or others find some comments
that need to be explored by the group, then we should discuss them.  I
can't remember any of comments that were "critical".

Glen

________________________________

From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, February 02, 2012 4:50 PM
To: Petrie, Glen
Cc: [email-masked]
Subject: Re: [IPP] A few Comments on IPP-Everywhere 1.0

Glen,

Thanks for the comments; we can discuss these at the F2F in some detail,
but some quick comments are inline...