IPP> NOT - Simple IPP Notifications / Subscriptions - no collections

IPP> NOT - Simple IPP Notifications / Subscriptions - no collections

McDonald, Ira imcdonald at sharplabs.com
Wed Apr 19 19:10:02 EDT 2000


Hi folks,	

This is an informal summary of part of the discussion at the IPP Telecon
earlier today (19 April 2000), with the following people attending:

- Carl-Uno Manros (Xerox, chair IETF IPP WG)
- Tom Hastings (Xerox, editor IPP Model)
- Bob Herriot (Xerox, editor IPP Protocol)
- Mike Shepherd (Xerox)
- Harry Lewis (IBM)
- Ron Bergman (Hitachi)
- Ira McDonald (High North)

Discussion of my recent proposed simplified SNMP traps for job monitoring
led to the following tentative conclusions:

1)  Reduce the number of REQUIRED attributes for all IPP Notifications to
    a much smaller list (ACTION - Tom H, Bob H, and Ira McD to propose)

2)  Remove all discussion of all OPTIONAL attributes for IPP Notifications
    and replace with Subscription object and Create-xxx-Subscription
    operation attribute 'requested-attributes' (which may specify any
    Printer, Job, or Subscription object attribute accessible via 
    Get-xxx-Attributes operations).

3)  Remove use of 'collection' syntax for Print-Job/Create-Job and
    Create-xxx-Subscription operations for notification info and
    replace with the simple flat attributes that actually go into
    the Subscription object.

4)  If an IPP Client wants to have more than one subscription for
    a given job, then that IPP Client MUST use Create-Job, followed
    by one or more Create-Job-Subscription operations, followed by
    one or more Send-Document or Send-URI operations - no race
    condition is introduced (like Print-Job) and no dummy Hold-Job
    and Release-Job operations are required.

5)  CONTROVERSIAL - Move 'collection' syntax into production printing
    spec where it offers significant utility - Tom Hastings and Bob
    Herriot would rather keep 'collection' on the IETF 'standards
    track', even if there are no attribute applications immediately -
    the IETF will NOT accept a protocol option which is not implemented
    and will NOT accept a protocol option which has no current usage.

The intent of these simplifications is to foster widespread implementation
of IPP Notifications and to improve interoperability.  The intent is NOT to
abandon 'collection' syntax - just to use it where we get the most bang
for the buck - and to decouple the progress of the IPP Notifications spec
from the finalization of (and acceptance by IETF of) 'collection'.

Comments?

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc



More information about the Ipp mailing list