I've posted the minutes from today's telecon:
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/
-rw-r--r-- 1 pwg pwg 12800 Sep 11 01:58
970910-ipp-conference-call.doc
-rw-r--r-- 1 pwg pwg 6706 Sep 11 01:58
970910-ipp-conference-call.pdf
-rw-r--r-- 1 pwg pwg 5271 Sep 11 01:56
970910-ipp-conference-call.txt
Tom
Here is the text version:
Subj: Minutes of the IPP telecon, Wed, 9/10/97
From: Tom Hastings and Carl-Uno Manros
Date: 9/10/97
File: tc970910.doc
Attendees: Scott Isaacson, Roger deBry, Jim Walker, Lee Farrell, Ira
McDonald, Bob Herriot, Ron Bergman, Peter Zehler, Steve Zilles, Jay Martin,
Don Wright, Carl-Uno Manros, Tom Hastings
We wrote these minutes up after the fact, so please comment if any of them
are not correct.
1. Functionality freeze
We agreed to freeze the functionality of IPP V1.0 in order to get the Model,
Protocol, Directory, Requirements, and Rationale specs ready by the end of
September to forward to the IESG. We agreed to limit changes to fixing
errors and plugging holes in the existing functionality.
2. Making more Job Template attributes document attributes
We decided not to make any Job Template attributes document attributes,
thereby changing the current draft by making the "document-format",
"compression", "document-k-octets", "document-impressions", and
"document-media-sheets" Job Template attributes only be job level
attributes. Also the semantics that multi-valued Job Template attributes
would apply to each document was agreed to be removed from IPP V1.0.
It was felt that the Job Template attributes could be made document
attributes in IPP V2.0, but that it would take too long to decide now how to
do it. We do not want to delay getting IPP V1.0 agreed and forwarded as a
standard. As existence proofs, there are at least two proposals for upwards
compatible extension to do so, one from Tom and one from Bob.
3. Don't add 'dictionary' attribute syntax at this time
We decided that the proposal was good, but that we wouldn't add the
functionality at this time, since IPP V1.0 will have no attributes that use
it and we want to freeze the functionality. We will reserve an attribute
syntax code for it and can then register the attribute syntax using the
registration procedures for type 2 enums, after we finish IPP V1.0, so that
the 'dictionary' attribute syntax need not wait for IPP V2.0.
4. Job-uri versus a 32-bit job-identifier
Since neither Paul Moore nor Randy Turner were participating, we felt it
best to postpone the discussion until the IPP meeting next Wednesday and
Thursday, 9/17 and 9/18.
ACTION ITEM (Carl-Uno): Call Paul and Randy to find out whether they will be
attending the IPP meeting on 9/17 and 9/18 in Atlanta or have them attend by
teleconference.
ACTION ITEM (Don Wright): Set up a conference call for the afternoon of 9/17
for any participants that are not attending for discussion of this issue.
We agreed that this issue is the biggest issue remaining in the
specification. It is holding up prototyping and implementation. We also
agreed that we must agree on a proposal next week and verify it on the
mailing list next week.
We also wanted to understand the problems of implementing IPP under the
existing Windows/NT Print API that returns a 32-bit integer to the
application. We didn't know whether the 32-bit integer was the address of a
control block which existing for the life of the job (so that a job-uri
could be added to the control block), or was a 32-bit integer that was
contained in the control block. In the latter case, the control block could
go way immediately after the job was created, so that the 32-bit integer was
all that the application had to make future references to the job, to query
it or cancel it.
There is also the issue as to when the 32-bit job-identifier is generated:
before contacting the Printer or after.
Would a more robust notification mechanism from the IPP Printer when the job
completes help with removing stale job-identifier to job-uri map entries
from the client, if the IPP Printer returned a job-uri, instead of a 32-bit
job-identifier?
ACTION ITEM (Paul Moore): Please explain the problems again.
5. Registering MIME-types for document formats
We agreed that it would be better for the PWG to register most of the
Printer Interpreter Language Family (IANA printer language) enums with IANA
as MIME-types.
We also agreed that those Printer enums that already have registered
MIME-types: 'application/postscript', 'application/pdf', and vnd.hp-PCL
should use those MIME-types.
ISSUE: Should the PWG register the rest as 'application/xxx' because IPP is
on standards track or should the PWG register the rest as 'vnd.vv-xx'?
'application/xxx' requires a document specifying the semantics of each
MIME-type.
ACTION ITEM (Steve Zilles): Ask our Area Directors which they recommend
before the IPP meeting next week.
ACTION ITEM (Tom Hastings): Prepare a strawman mapping from Printer enums to
MIME-types for discussion at the meeting next week.
6. Security sub-group
A phone conference call is scheduled for Thursday, 9/11/97, 1:00 PDT.
7. Prototyping and Testing sub-group
The group is looking for a solution for security for Internet testing.
One proposal is to have private agreements between clients and Printers on
the times to run tests, until security has been resolved.
8. Requirements document
ACTION ITEM (Don Wright): Don will try to find time to update the
Requirements document by the end of September to agree with the Model document.