> -----Original Message-----
> From: Roger K Debry [SMTP:rdebry@us.ibm.com]
> Sent: Wednesday, June 10, 1998 2:09 PM
> To: ipp@pwg.org
> Cc: cmanros@cp10.es.xerox.com
> Subject: IPP> Minutes of 6/10 IPP conference call
>
> When I agreed to take minutes, I did not agree to spell peoples names
> corrrectly, remember everything that transpired during the discussion, or
> get
> it 1100% correct when transposing to paper. Please accept my apologies in
> advance for such errors. With those caveats, here are the minutes of the
> 6/10
> call. I won't feel bad if you have to correct me. Thanks ...
>
> Participating in the call ( mostly in the order joining the call):
>
> Shevan Albright
> Daniel Manchella
> Keith Moore (area director)
> Patrick ?? (area director)
> Kris Schaff
> Tom Hastings
> Jim Walker
> Ron Bergman
> Harry Lewis
> Larry Masinter
> Don Wright
> Xavier Riley
> Ira MacDonald
> Carl Kugler
> Peter ???
> Steve Gebert
> Randy Turner
> Paul Moore
> Scott Issacson
>
> The call began at approximately 11:00am (Mountain Daylight Time) with
> Carl-Uno
> reviewing the agenda. It was agreed that the two major issues to be
> discussed
> were the issue of how to differentiate IPP for filtering purposes, and
> what to
> do about TLS. Carl-Uno asked Keith Moore to being the discussion by giving
> his
> thoughts on the first issue.
>
> In response, Keith Moore said that the goal was to be able to
> differentiate IPP
> from normal HTTP traffic going through firewalls. By tradition new
> services run
> on different port numbers. Keith's poll of the IESG found general
> agreement
> that IPP should run on a new port number. Larry Masinter reviewed his
> proposal
> for providing a new scheme name for IPP at the client. In this proposal,
> IPP as
> a scheme never appears on the wire.
>
> Randy Turner argued that requiring a new port number for IPP would be a
> hardship on some implementations, specifically where a server is not
> capabale
> of listening to multiple ports, ports other than 80. Paul Moore agreed
> with
> the idea of a default IPP Port number (as long as could still use port
> 80),
> but thought that using IPP as a shorthand notation was nothing more than
> an end
> user convenience, and really had nothing to do with the protocol. Keith
> Moore
> expressed the opinion that there was benefit to using IPP.
>
> Carl-Uno then asked for comments on the proposal to define a new HTTP
> method,
> PRINT. Larry Masinter reviewed his recent communication on differences
> between
> filtering proxies and forwarding proxies. His claim is that forwarding
> proxies
> would all break with definition of a new method. Paul Moore disagreed,
> indicating that Microsoft's polling of proxy vendors indicated that most
> proxies would handle a new method without any problem. Larry said he does
> not
> believe this is the case. There was some debate about what the out-of box
> condition of IPP should be, and what impact our direction would have on
> this.
> Keith Moore too a very strong position that it was up to the System
> Adminsitrator to configure things so they worked, our responsibility was
> to be
> sure the System Administrator was not surprised.
>
> The resulting agreement from this debate was that we would focus on the
> details
> of using a new port number and using IPP as a naming scheme, per Larry
> Masinter's proposal. We would not pursue the definition of a new method.
> Randy
> Turner agreed to write up a draft of how this would work. Carl-Uno agreed
> to
> take a work item to contact IANA about an IPP port number.
>
> We then turned to the TLS discussion. Keith Moore indicated that TLS is
> currenly hung up wating for documents from the PCIKS group, which are
> currently
> in last call. Keith expects the TLS issue to be resolved soon and to have
> TLS
> progress down the standards track. Keith said that there is weak
> agreement in
> the IETF on doing security negotiation in-band. The idea of having a
> reserved
> port for TLS is still under discussion. Keith proposed that IPP use a
> parameter
> in the URL to indicate TLS use. After quite a bit of discussion, Keith
> agreed
> that he would support the use of SHOULD for IPP client support of TLS.
> However,
> he warned that others on the IESG may not approve with that wording. He
> suggested that we articulate client instances where TLS may not be
> appropriate,
> e.g. on a Palm Pilot.
>
>
>
>
> Roger K deBry
> Senior Technical Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry@us.ibm.com
> phone: 1-303-924-4080