RE: [Printing-architecture] PAPI status report [IPP System Admin issue]

RE: [Printing-architecture] PAPI status report [IPP System Admin issue]

[McDonald, Ira]

Hi Norm,

We have a problem looming on the horizon for PAPI.

Here's an excerpt from your PAPI monthly status:

"Moving forward

	* Take feedback on v0.91 of PAPI spec and incorporate it into a new
	  draft.

	* Work on draft interface additions for Administration and Document
	  interfaces for next draft. (review via email through
printing-spool
	  list)"

After recent discussions with Carl-Uno Manros (IETF IPP WG chair)
and Tom Hastings (primary IPP editor), we've decided to abandon
the IPP System Admin spec (draft-ietf-ipp-ops-set2-03.txt) as
an IETF 'standards track' RFC.

Rationale:  If IPP System Admin spec is published as an IETF
Proposed Standard, it's implied that it will be implemented
and interop tested.  But (except for CUPS??) there are no
announced implementations.

Background:  The IESG is again closing down older WGs.  Carl-Uno
wants to move any remaining IPP specs to IEEE/ISTO PWG if possible.
The IPP notifications specs have been abandoned in the IETF.  
PWG WBMM is designing a simpler subset over SOAP in XML schema.  
PWG WBMM is also designing a SOAP-based set of system admin
operations equivalent to former IPP System Admin in XML schema.


Michael Sweet - has CUPS implemented some/all of the IPP System
Admin extension operations?


Comments?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: Norm Jacobs [mailto:Norm.Jacobs@Sun.COM]
Sent: Monday, February 16, 2004 11:41 PM
To: printing-architecture@freestandards.org;
printing-spool@freestandards.org
Subject: [Printing-architecture] PAPI status report



PAPI status can be found at

ftp://ftp.pwg.org/pub/pwg/fsg/status_reports/PAPI_WG_Status_13Feb2004.txt


		-Norm

_______________________________________________
Printing-architecture mailing list
Printing-architecture@freestandards.org
http://freestandards.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] PAPI status report [IPP System Admin issue]

[Michael Sweet]

McDonald, Ira wrote:
> ...
> Michael Sweet - has CUPS implemented some/all of the IPP System
> Admin extension operations?

CUPS has implemented some of the operations (in most cases using
our own extension operations, since the CUPS ops came first) since
v1.0; here is a quick table:

      Admin Spec Op                        CUPS Op
      -----------------------------------  -----------------------
      Enable-Printer                       CUPS-Accept-Jobs
      Disable-Printer                      CUPS-Reject-Jobs
      Pause-Printer-After-Current-Job      N/A *
      Hold-New-Jobs                        N/A *
      Release-Held-New-Jobs                N/A *
      Deactivate-Printer                   N/A
      Activate-Printer                     N/A
      Restart-Printer                      N/A
      Shutdown-Printer                     N/A
      Startup-Printer                      N/A
      Reprocess-Job                        N/A **
      Cancel-Current-Job                   Cancel-Job with job-id=0
      Suspend-Current-Job                  N/A
      Resume-Job                           N/A
      Promote-Job                          N/A *
      Schedule-Job-After                   N/A *

      * = planned for future CUPS releases
      ** = planned for future CUPS releases, similar to Restart-Job

FWIW, the Hold-New-Jobs and Release-Held-New-Jobs operations are
somewhat problematic in the current definitions, since there is
no "job-admin-held" job-state-reasons value or "admin"
job-hold-until value to differentiate between a user-held job and
a job that is held via Hold-New-Jobs.  That makes implementation
of Release-Held-New-Jobs somewhat challenging and makes it
impossible for an admin to know which jobs will be released.

In any case, the current spec covers both admin and operator
operations for both printers and jobs, so it might be useful
to break it up into functional documents published by the PWG
instead...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com

RE: [Printing-architecture] PAPI status report [IPP System Admin issue]

[McDonald, Ira]

Hi,

I've just spoken with Harry Lewis (IBM) and Tom Hastings (Xerox)
about this IPP System Admin spec (they are co-authors, along with
Carl Kugler, IBM).

We think we should do a PWG IPP System Admin spec as _one_ spec,
but delete or fix any 'broken' operations (see below).

If we leave this spec on the IETF 'standards track', it will be 
late 2005 at the earliest before it's published as an RFC (the
typical delay for a no-issues spec is 18 months at present).

If we move it to IEEE/ISTO PWG, it can be taken to 'last call'
within a month or two (it already _passed_ an IETF IPP WG 'last
call').  Tom has already made the (trivial) security changes
requested by Ned Free (our IETF Applications Area Director)
in summer 2001.  I've found other minor typos (and sent them
to Tom).

We need a volunteer to be principal editor of the PWG conversion
of the spec (into IEEE/ISTO format in MS Word).  I would volunteer
to be co-editor.  Because of issues such as Michael raises below, 
a few operations must be deleted or fixed (new parameters or new
state reasons).

If this spec rapidly advanced, then PWG WBMM (which has XML
schema for most of these operations) could continue to have
Normative references to the IPP operation semantics.

Cheers,
- Ira 


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com


-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Tuesday, February 17, 2004 11:34 AM
To: McDonald, Ira
Cc: 'Norm Jacobs'; printing-architecture@freestandards.org;
printing-spool@freestandards.org; Hastings, Tom N; 'carl@manros.com';
Zehler, Peter; 'Harry Lewis'
Subject: Re: [Printing-architecture] PAPI status report [IPP System
Admin issue]


McDonald, Ira wrote:
> ...
> Michael Sweet - has CUPS implemented some/all of the IPP System
> Admin extension operations?

CUPS has implemented some of the operations (in most cases using
our own extension operations, since the CUPS ops came first) since
v1.0; here is a quick table:

      Admin Spec Op                        CUPS Op
      -----------------------------------  -----------------------
      Enable-Printer                       CUPS-Accept-Jobs
      Disable-Printer                      CUPS-Reject-Jobs
      Pause-Printer-After-Current-Job      N/A *
      Hold-New-Jobs                        N/A *
      Release-Held-New-Jobs                N/A *
      Deactivate-Printer                   N/A
      Activate-Printer                     N/A
      Restart-Printer                      N/A
      Shutdown-Printer                     N/A
      Startup-Printer                      N/A
      Reprocess-Job                        N/A **
      Cancel-Current-Job                   Cancel-Job with job-id=0
      Suspend-Current-Job                  N/A
      Resume-Job                           N/A
      Promote-Job                          N/A *
      Schedule-Job-After                   N/A *

      * = planned for future CUPS releases
      ** = planned for future CUPS releases, similar to Restart-Job

FWIW, the Hold-New-Jobs and Release-Held-New-Jobs operations are
somewhat problematic in the current definitions, since there is
no "job-admin-held" job-state-reasons value or "admin"
job-hold-until value to differentiate between a user-held job and
a job that is held via Hold-New-Jobs.  That makes implementation
of Release-Held-New-Jobs somewhat challenging and makes it
impossible for an admin to know which jobs will be released.

In any case, the current spec covers both admin and operator
operations for both printers and jobs, so it might be useful
to break it up into functional documents published by the PWG
instead...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com