IPP> ADM - Minutes from 7/23/97 Phone Conference

IPP> ADM - Minutes from 7/23/97 Phone Conference

IPP> ADM - Minutes from 7/23/97 Phone Conference

Steve Zilles szilles at Adobe.COM
Thu Jul 24 20:05:30 EDT 1997


--============_-1342333354==_============
Content-Type: text/plain; charset="us-ascii"


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 at 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==_============--



More information about the Ipp mailing list