Subject: IPP> IPPv2 Consensus Results

From: [email-masked]
Date: Mon, 16 Jun 2008 15:00:02 -0700

The updated document containing the results of today's consensus telecon,
plus the rankings from Novell, can be found at:

   ftp://ftp.pwg.org/pub/pwg/ipp/ippv2-docs/IPPv2-OPS-REQUIRED-2008-06-16.pdf
 (.doc)

SInce some key contributors were not present on the call, there will be
further discussion during next week's face-to-face meeting.

---

From: Michael R Sweet <[email-masked]>
Date: Mon, 16 Jun 2008 16:25:22 -0700

> further discussion during next week's face-to-face meeting.

My apologies for missing the call again.  My meeting reminder didn't
do its job and my brain didn't do any better... :(

Since I won't be at next week's face-to-face, here are my comments
for the items needing further discussion:

     v2.1

     In general, I'd like to avoid making operations that need
     a tight integration with the print device REQUIRED.  My
     vision of the Enterprise Printer Environment is a loosely-
     -managed print-on-demand network environment which provides
     basic spooling and output control.

     - For Pause-Printer-After-Current-Job, Hold-New-Jobs, and
       Release-Held-New-Jobs, there seem to be enough B's to
       justify making them REQUIRED operations, and they are both
       easy to implement and useful for the "Enterprise Printer"
       scenario.
     - For Deactivate-Printer, Activate-Printer, Restart-Printer,
       Shutdown-Printer, and Startup-Printer, there are slightly
       fewer B's and these require a higher level of integration
       with the device than may be available, so I'd argue these
       should be left OPTIONAL.
     - For Cancel-Current-Job, there is only one C and a couple A's.
       It is also a relatively simple operation to implement, so
       I'd vote for making it REQUIRED.
     - For Suspend-Current-Job, Resume-Job, Promote-Job, and
       Schedule-Job-After, there seems to be consensus around "B",
       so I'd vote for leaving them OPTIONAL. In particular,
       Suspend-Current-Job and Resume-Job can be tricky when you
       are not tightly integrated with the device, and Promote-Job
       and Schedule-Job-After can require fairly large resources
       and may need access controls to avoid abuse in this
       environment.

     v2.2

     - For Print-URI and Send-URI, I have my standard objection
       because of the known access control, authentication, and
       error reporting issues.  However, I *can* see them being
       useful in implementing "stored forms" and other template
       documents in a production printing environment.  If we
       make these operations required in any of the three profiles,
       this would be the place to do so.  In short, I'm OK with
       changing these to REQUIRED.

One final note: on page 1 "Cancel-Document" is lumped in with
notifications and subscriptions instead of document object...

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer

---

From: [email-masked]
Date: Tue, 17 Jun 2008 16:10:52 -0700

Mike,

Thank you for the comments.  We plan to do a review of the consensus result
in the Face-to-face meeting next week.  So your comments will be a good
input for that meeting.  There will be a conference phone available during
the meeting and I hope you are able to call in.  The IPPv2 session will be
on Wednesday, June 25 from 4 PM to 6 PM MDT (or 5 PM to 7 PM PDT).  The
call in number will be the PWG standard "1-866-365-4406", pascode =
2635888#.

             Michael R Sweet                                               
             <[email-masked]                                             
             >                                                          To 
                                       [email-masked]           
             06/16/2008 04:25                                           cc 
             PM                        [email-masked]                         
                                                                   Subject 
                                       Re: IPP> IPPv2 Consensus Results    

                                                                           

     v2.1

     v2.2