Subject: IPP> Minutes from PWG IPP Meeting in Portland, OR - April 8-9, 1998

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 14 Apr 1998 13:48:52 PDT

Here are the "raw" minutes from last week. Thanks to Jay and Harry for
taking notes. None seems to have captured the list of attendents. Has
anybody got that list somewhere?

Carl-Uno

Minutes from PWG IPP Meeting in Portland, OR - April 8-9, 1998
===============================================================

Minutes taken by Jay Martin on April 8.

The meeting started at approximately 8:30 am.

Job openings

Need a permanent, full-time secretary (not Jay!)
Scott will chair the next PWG IPP meeting as Carl-Uno will be unable to
attend.

IETF

Editing and maintenance
Keith Moore wants to see a short document describing the minimal mandatory
aspects and components of IPP, from the perspective of the server side
implementation.
No commitment made by any PWG participant to write such a document.
Carl-Uno requested a volunteer to write the document. Peter reminded the
group that the IPP testing document provides much of that kind of info. Tom
suggested that he, Carl-Uno & Peter will review the testing document and
perhaps deriving a document for Keith Moore’s use. Carl-Uno stated that IPP
V1.0 will formally wrap up its effort by the August 98 IETF plenary.
Carl-Uno announced that Steve Zilles will be asking to be relieved of his
IETF WG co-chairperson position due to other commitments with the W3C.
Scott brought up the fact that the WG has had several proposals for
changes, yet no action has been taken to officially incorporate (or reject)
those proposals into the formal documents, including:
- Charset and natural language should always be the first and second
attribute in every message in the operations group (affects the Model
document)
- All attributes should be lowercase only, including the values for
language keywords; the document examples need to be updated
- Tom raised the issue of mapping uppercase to lowercase to provide a more
"forgiving" implementation;  the group decided that this was not necessary,
that specifying "always lowercase" is sufficient
- Need to explain the table of attributes with respect to MANDATORY vs.
"required" (section 15 of the Model document)
- Changing URI to URL with respect to references to external IETF
documents, since there is no IETF standards document for URI
Decision: leave it as is (URI). Scott will look into adding some simple
clarifying text in the Model document.

IPP Notifications

What can the IPP group do to satisfy its charter requirements wrt
notifications?
Randy reminded Roger that one of the published requirements was supposed to
be removed: the ability for a client to specify which attributes should be
returned in a notification.  Rabid discussion followed, resulting in a
decision to make this specific requirement optional rather mandatory.  What
will be mandatory is support for a fixed list of attributes in a
notification message.

Dictionary proposal

Tom reviewed the recent proposal (v0.92, 3/31/98)
Several people mentioned they have a problem with the term "dictionary", so
the term was officially changed to "collection".
The group did not wholeheartedly buy into this data typing and structuring
approach due to its complexity and the lack of understanding of the
requirements
Review of "Notifications for the IPP print protocol" (ipp-job-proposal.doc
by Hastings/Lewis)
Consensus was to not provide "ala carte" specification for job event
registrations; instead, events will be gathered into groups, and the client
registers for one or more groups.
As a result, job-notify-additional-attributes was removed.

Accessing MIB data through  IPP

How to map and access Printer and Job MIB objects using IPP attributes
Scott lead the discussion
Rabid discussion followed resulting in the consensus that the concept and
discussion should be deferred until we conduct more discussion on the
host-to-device issue.

Testing

Peter will draw up and publish a list of the "Top 25" (or so) list of test
scenarios. 
Harry pointed out that unless the group schedules a date for a bake-off,
testing will languish.
Carl-Uno is attempting to emancipate a test case generator/analyzer from
the Xerox effort for public use.

The meeting ended at approximately 5:30pm.

--

Notes from April 9 taken by Harry Lewis

The meeting started saty 8:30 am
     
Host-to-Device protocol

Carl-Uno tries to set the stage. Trying to get decision on general
direction. Concerns. What’s happening with IPP? Not using HTTP? Drop IPP
into TIPSI? Funny to run this discussion of Host-to-Device protocol on the
IPP list. Worried about sabotaging peoples confidence in IPPv1.

Change the name of this to Server to printer
Review issues - from Paul.

1. IPP asymmetrical. No way to send asych alerts. We’re working on
notification. 
2. No peer conflict resolution. How does a non-spooling IPP printer resolve
being asked to print by two clients. Like ticket number that tells you
where you are in line.  Randy - there are resources at every level of the
protocol stack so you really can’t solve. Randy added two statuses in his
paper to address this. 
3. No way for printer to solicit data from the client (to throttle data
transfers). 
All transport layers have a flow control mechanism underneath it. One
connection for data and another for control. IPP doesn’t require this.
Maybe we should require this? TCP can do this but IPP is not just TCP
4. Current security too complex? Would security to server and no security
from server to device satisfy? Argued that basic authentication is not too
complex. TLS is optional. 
5. IPP is not transport neutral. Encoding is HTTP independent except for
chinking. From a server standpoint, I want to be able to talk to my
printers in whatever way they are connected using one protocol. 
6. HTTP is heavy duty
7. No way to move data backward (scan, fax...). Embed IPP client in MFP?
8. No separate channel for control. We don’t make any statements right now
but there should be no reason why we couldn’t allow or require two
connections. Open channel for data, another channel for control. Print job
sends status immediately otherwise can’t query. If IPP CREATE JOB was
mandatory, then the job ID would be known early enough to allow queries
over separate channel. Maybe in the v2 thing we’re talking about PrintJob
isn’t even there and createJob is mandatory!
9. Detailed configuration and status not available.  

We kept discussing the scope, purpose etc. Need to start another project.
Decided to start over.  Actual proposals for TIPSI and IPP over TCP not
reviewed in any organized manner.

Implementers Guide.
 
No one volunteered.

Server to Device PWG meeting
Lot’s of discussion about whether or not we need another protocol.

What are the needs for a server to printer protocol? What are the
compelling reasons for doing this. Does it deliver more to the customer?
Does it deliver it cheaper? Is there competitive pressure? 

1. Advantage of single protocol for driver like functions vs. a suite of
protocols.
	- Keeping IP address and URL’s in synch
2. Advantage of multiple protocols.
	-  Asymmetry maps better to actual communications needs. 

NEW LIST OF REQUIREMENTS

1. Need a protocol which delivers unsolicited real time status information
(alerts).
2. Flexible security model
3. Transport independent
4. Need way to send FAX or SCAN data from device to server (for MFPs only)
5. Control channel can’t be blocked by data. Server can query and control
with quick response.
6. Need configuration and status info like what’s provided in the printer MIB.
7. Ability to recover job accounting information 
8. Device can retrieve resources like fonts and forms
9. Server to Device protocol must not significantly limit the function of
any major existing client to server protocols and must accommodate IPP
without any loss. 
10. Must Cover the case of spooling both in the server and the device or
other multiple levels. The user should get the same functionality (CANCEL,
MODIFY etc.).  
11. What layer are we at? -  Application layer.
12. Submit Cancel and list jobs (end-user and administrator)   	 

Naming the new project SDP - Server device protocol. Jay is tentative Chair.

SNMP v3 Traps and Informs

Job MIB traps work is ongoing. Looked like a match with IPP notifications
requirements. Notification MIB and Trap MIB as part of SNMPv3 introduced by
Randy. Utility and applicability of SNMPv3 MIBs to what we are trying to
do. Joe F. and Ira McD. put together proposal for registration.

SNMPv3
128 octet OID string. 
Trap types or groups are given OIDs. 
"TargetSpinLock" keeps one agent from overwriting another agent’s entries. 
Randy recommends use the SNMPv3 target and notification MIBs, augmented, if
necessary with additional function (i.e. Time to Live group indexed to the
target).
JAM MIB supports automatic trap de-registration. Keep alive etc. 
Is there stuff in the v3 MIBs that we don’t need? Should we create a hybrid?
Basically, there is a lot of overlap with Xerox MIB and v3 MIB's so use v3
and augment.
Thru IPP you can register on a per-job basis, but not with SNMP. There,
only per time-out (all jobs). 
No disagreement regarding adoption of this approach. 
We should use Informs... not traps. For v1 it’s a trap. For v2-3 use inform. 
Need proposal to fit this together. Tom, Harry, Ron.
Keep this at tail end of IPP for the next few meetings. 

Administrator register with time to live. Clients register with job. 
Need a way to manage reg table itself. Next highest index. 
Need to define trap informs (informational)
Need to write augments for target and notification MIB's (stds track or
experimental - might ultimately be subsumed by IETF cause they like this
idea).

The meeting closed at 5:30 pm.

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]