IPP> ADM - Minutes from PWG IPP Phone Conference on 970924

IPP> ADM - Minutes from PWG IPP Phone Conference on 970924

IPP> ADM - Minutes from PWG IPP Phone Conference on 970924

Carl-Uno Manros cmanros at cp10.es.xerox.com
Wed Sep 24 18:43:02 EDT 1997

Minutes from PWG IPP Phone Conference on 970924


	Tom Hastings
	Bob Herriot
	Carl-Uno Manros
	Ira Mcdonald
	Steve Zilles
	Dale Wick

A number of the usual participants were busy doing other things this week,
but here are the subjects discussed and recommendations given.

1) Consequences of Atlanta proposal to take out document level attributes.

Of Bob Herriot's earlier listed 3 alternatives, alternative 2) seems to get
most support both from the DL and the participants in the call.

The general proposal for resolution include the following:
a) Keep the Print-URI and Send-URI operations.
b) The actual URIs are operational attributes. They are not stored on the
job object and cannot come back in a Get-Attributes operation.
c) Add back document-name as an operational attribute on Print-Job,
Print-URI, and Send-Document operation requests.  It is not stored on the
job or document objects and cannot come back in a Get-Attributes operation. 
d) Describe algorithm of how to populate job-name from first document-name
in the job, if not supplied by requestor.

Bob Herriot to write draft text and send to the DL.

e) It was also suggested to revive the attribute number-of-documents as a
job-level attribute, which can be returned in a Get-Attributes operation
for a job object. This functionality was previously provided through
looking at a list of document names, but since document level attributes
are now gone we need to re-introduce this.  This was not considered as
extension, but rather as a fix to remedy a consequence of removing document
level attributes.

Tom Hastings to write up the draft text and send to the DL.

2) Other comments resulting from the Atlanta meeting minutes that had been
raised on the DL.

a) Suggestion to define separate port # for IPP.
As HTTP requires that port 80 is always supported and that security
protocols also require that special ports be supported, it is still not
clear what added value a separate port number for IPP would bring. The
Protocol document will reflect that other port numbers can be used, by
inclusion in the URI.
It was suggested that implementation experience can determine if we want to
add a rule for a special IPP port at some later stage.

b) Proposal to add FILE as a mandatory "protocol" to support for
print-by-reference.  Although some implementation may want to support this,
it was considered to be a option to support it, not mandatory.

3)  Security

The progress of TLS has become questionable.  We will take the advice from
Keith Moore to describe the potential (non-standard) use of SSL3 for now,
and indicate that the intension is to add a separate RFC document on how to
use IPP in combination with TLS, once the latter spec is finalized.

Carl-Uno will check which changes need to be done in the Model and Protocol
documents to reflect this.

4) Other comments on the latest Model draft

a) Terminology section still rather thin. Need to add further terms and

Everybody to come in with proposals.

b) Section 6.2 talks about mime-Types.  Should be media-Types.

c) Directory Annex is missing info about the security attribute.

d) Carl-Uno asked everybody to start proof reading and giving feedback on
the latest Model draft to get it is as clean as possible before the next
I-D version and WG last call at the end of September.

5) How are we doing on the drafts?

a) Model is progressing, but there is still work to be done from Scott and
other contributors. This now includes Security and Directory Schema.

b) Bob ready to release new version of the Protocol document as soon as
latest security changes have been made available from Carl-Uno.

c) The Rationale document not yet updated.  Steve will hopefully get it
done later this week.

d) The Requirements document. Don is still hoping to have it updated by the
end of the month, but somewhat unclear.

6) Should we reserve an IPP session in the next IETF meeting?

Suggested that we reserve one slot, which can be canceled if it turns out
that we do not need it.  Possible subjects are any remaining issues
resulting from the IESG review (but hopefully we are past that by that
time), and the LPR Mapping document (which may or may not be finished by

7) Next Phone Conference

We will hold the next phone conference on October 1.




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: manros at cp10.es.xerox.com

More information about the Ipp mailing list