Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry@us.ibm.com
phone: 1-303-924-4080
owner-ipp@pwg.org on 06/12/98 06:13:28 PM
Please respond to owner-ipp@pwg.org
To: ipp@pwg.org, Roger K Debry/Boulder/IBM@ibmus
cc: cmanros@cp10.es.xerox.com
Subject: RE: IPP> Minutes of 6/10 IPP conference call
Well i dont recall the agreement that we should abandon the new method =
path.
As far as I could see we were arguing over facts (would it break proxie=
s or
not). Until the answer to this is known I dont see how we can decide.
> -----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 apologie=
s 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, an=
d
> what to
> do about TLS. Carl-Uno asked Keith Moore to being the discussion by g=
iving
> 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 propos=
al,
> 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 agre=
ed
> with
> the idea of a default IPP Port number (as long as could still use po=
rt
> 80),
> but thought that using IPP as a shorthand notation was nothing more t=
han
> an end
> user convenience, and really had nothing to do with the protocol. Ke=
ith
> 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 difference=
s
> between
> filtering proxies and forwarding proxies. His claim is that forwardin=
g
> proxies
> would all break with definition of a new method. Paul Moore disagreed=
,
> indicating that Microsoft's polling of proxy vendors indicated that m=
ost
> 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-o=
f 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 t=
he
> details
> of using a new port number and using IPP as a naming scheme, per Larr=
y
> Masinter's proposal. We would not pursue the definition of a new met=
hod.
> Randy
> Turner agreed to write up a draft of how this would work. Carl-Uno ag=
reed
> 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, Kei=
th
> agreed
> that he would support the use of SHOULD for IPP client support of TLS=