Roger DeBry (IBM)
Harry Lewis (IBM)
Carl Kugler (IBM)
Carl-Uno Manros (Xerox)
Peter Zehler (Xerox)
Scott Barnes (Xerox)
Tom Hastings (Xerox)
Swen Johnson (Xerox?)
Jim Walker (DAZEL)
Jay Martin (Underscore)
The primary topic of the day was "Asynchronous Notifications".
Carl-Uno proposed that a BOF be held at the upcoming IETF meetings as
a way of starting the IPP v2.0 effort, in which async notifications
would be part of that effort. The group believed there was no need to
startup an following WG for IPP in order to advance the definitions
for async notifications; instead, Internet Drafts (I-D's) could be
published for such purposes.
One fundamental goal of the group was that support of async
notifications within IPP should NOT necessarily mandate the
development of a new protocol. Instead, every effort will be made to
leverage existing protocols and practices whenever and wherever
possible.
The group then walked through Roger's proposal submitted to the IPP
DL.
* The focus is on End-User only; no administrative nor operator
requirements are to be considered, at least at this point.
* A new pair of terms is needed to denote "Reliable" and
"Unreliable" types of notifications, much in the same manner as
the "Immediate"/"Delayed" types.
* An additional term is needed to denote a notification comprising
both "Human Consumable" and "Machine Consumable".
* Requirement 6: The IPP Printer should be able to notify the client
when the delivery of an Event to a target Event Recipient fails;
no specific details were proposed, but the discussion revolved
around the idea of having the client optionally supply an email
address to be used by the IPP Printer to send such event delivery
failure messages.
* Need to show an additional scenario having multiple Event
Recipients.
Roger volunteered to be the Requirements document Editor, and
committed to publishing the first official draft to the IPP list no
later than Tuesday, February 17.
The topic then changed over to the recent DL thread concerning the
need for a more robust "host-to-device" printing protocol. It was
pointed out that this discussion really transcends the IPP WG, and
that in no way should the IPP Chairman feel compelled to manage this
discussion. It was suggested that perhaps a new PWG project (or at
least a new DL) be formed for this topic; in the meantime, the IPP DL
will be used for convenience.
Roger suggested that people raising issues with IPP for use in host to
printer scenarios should indicate whether the problem is with the
current IPP Model document or the current IPP protocol document.
For the problems with the Model document, they may be resolvable by
extending the Model, by, say, adding more Printer attributes and maybe
a Set-Printer-Attributes operation?
For problems that were with the protocol (mapping) document, the PWG
might develop a second IPP protocol document for use in the host to
printer connection whose semantics would be the same (extended) IPP
Model document. This second IPP protocol mapping document would be a
PWG standard, not an IETF standard, since the document deals with the
host to printer connection only (and not the Internet).
It was suggested that some printers might implement both IPP protocol
mappings, if they wanted to be used across the Internet and in the
host to printer connection. But with the same semantic model, such a
dual implementation would not be a big burden.
The teleconference ended at approximately 2:50pm PDT.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------