Attached are the minutes of the Phone conference on July 23. Would someone
please post them to the correct place on the FTP/Web sites.
Steve
--============_-1342333354==_============
Content-Type: text/plain; name="phone.mtg.97.07.23.minutes.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="phone.mtg.97.07.23.minutes.txt"
Minutes of IPP Phone Meeting, July 23, 1997
by S. Zilles
Meeting commenced at 1PM PDT
Attendees
Carl-Uno Manros
Tom Hastings
Lee Farrell
Jim Walker
Jay Martin
Steve Zilles
Stan McConnell
Bob Herriott
Roger deBry (late)
Don Wright (late)
Revised drafts should be sent to
Internet-Drafts@ietf.org
All document authors should extract all the issues related
to their document and post this collection in Word format
(.doc) in the relevant section of the IPP FTP site; that is,
in the same section that the version of the document sent to
the IETF is put. Please do this by Wednesday, July 30 and
Tom Hastings will then combine the issue list and post it to
the working group so people will have time to review it
before the Seattle meeting.
All documents should refer to the "requirements document"
as:
"Requirements for an Internet Printing Protocol"
Requirements document
It was observed that some of the scenarios in the
current I-D are out of date (w.r.t. the model); it was
agreed that updating this document was not critical for
Munich so that such updates would be delayed until an
informational RFC can be prepared.
LPD Mapping Document
Bob Herriot is re-editing the document to fix errors,
to shift the focus from how to what (exp w.r.t. Short
and Long LPQ forms). Bob will provide this draft to Tom
no later than July 29.
Tom Hastings will prepare the .01 draft and send it to
the IETF for publication for Munich.
Architecture Doc
Steve Zilles will produce a new draft and submit it by
Tuesday, July 29.
Protocol Doc
Validate
Agreed that agreement with Sylvan was that
PrintJob, and Validate had the same syntax (and
semantics) except for including the print data.
Agreed that Validate only checks the parameters
and attributes and not the content.
Agreed that Validate is mainly there to allow
checking of the parameters and attributes prior to
doing a PrintJob.
Because the PrintURI does not send any print data,
a separate validate is not necessary for PrintURI
Client Closing connection before data transfer is
completed
because processing of the print data can begin
before all the data has arrived, it is necessary
to specify what the printer does if the connection
drops during data transmission. This is treated as
if the job were cancel at the time the connection
dropped.
Handling a CreateJob for which data does not arrive
Because the client may never receive the response
or may fail to send documents, there should be a
time out on resource reserving operations. This
time out needs to be configurable (and probably
the model should have a value to say what this
time out is.
Extending Tag values
Agreed that no tag values were allocated for
private extensions, in part because the tag value
space is small and that providing extension values
has often been abused in the past; e.g., there are
plenty of MIME types that being "x-" and are in
common usage.
Issue: Should adding a new data type be a Type 1
or a Type 2 extension? (Some people on call were
leaning toward it being Type 2.) It was agreed
that if they were Type 2 the review process should
have greater scrutiny than adding a new attribute.
Inclusion of Appendix B
Agreed that this appendix would be removed from
the I-D, but the information would be retained in
case it might be needed in the future.
A possible reason for not using POST in IPP
It has been pointed out that today POST is most
often used for forms processing and that such
processing is often done without doing
authentication. If IPP uses POST and the same
server is used to service both forms and print
operations, then putting in authentication for one
would require authentication for all POSTs (at
least in some server architectures). This could
add extra processing time for all POST and could
in some case increase the processing of Forms.
(Note that this only for HTTP authentication and
not TLS authentication.)
Model and Directory
Status unknown, Scott believed to be working on getting
an updated I-D to the IETF by July 30.
Issue: how should the format of the content to be
printed be identified: Printer MIB enum or MIME type.
The current spec uses Printer MIB enum to insure that
querying via the Printer MIB and via the IPP Model will
give the same answers. Alternatively, identifying the
content by the a MIME type means that any applications
other than printing can also identify the format; for
example an application that picked up already formatted
print data and printed it would not have to translate
from a MIME type description into a Printer MIB enum
description. Issue was left open, but current model
specifies that the Printer MIB enum shoud be used.
Security Document
Roger will update the security document and send off to
the IETF by Tuesday,
Drums has changed the handling of ranges, but has left an
ambiguity as to whether a hyphen or a colon is used for
range specs.
Status of presentation of IPP to consultants in August
This is an activity of either the PWG or the
participating companies.
targetted consultants: Gartner, IDC, Lyra, DataPro and
MetaGroup
planning to do it in Boston:
there was a slight preference for the last week of
August; Roger will test both the 20th and 27th of
August.
This meeting would be completely separate from any IBM
announcements.
Meeting adjourned at 3PM PDT.
--============_-1342333354==_============--