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 t=
he 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 C=
arl-Uno
reviewing the agenda. It was agreed that the two major issues to be dis=
cussed
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 giv=
ing his
thoughts on the first issue.
In response, Keith Moore said that the goal was to be able to different=
iate IPP
from normal HTTP traffic going through firewalls. By tradition new serv=
ices run
on different port numbers. Keith's poll of the IESG found general agre=
ement
that IPP should run on a new port number. Larry Masinter reviewed his p=
roposal
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 ca=
pabale
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 tha=
n an end
user convenience, and really had nothing to do with the protocol. Keit=
h 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 m=
ethod,
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 mos=
t
proxies would handle a new method without any problem. Larry said he do=
es 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 wa=
s 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 metho=
d. Randy
Turner agreed to write up a draft of how this would work. Carl-Uno agre=
ed 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 c=
urrently
in last call. Keith expects the TLS issue to be resolved soon and to ha=
ve TLS
progress down the standards track. Keith said that there is weak agree=
ment in
the IETF on doing security negotiation in-band. The idea of having a re=
served
port for TLS is still under discussion. Keith proposed that IPP use a p=
arameter
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 appr=
opriate,
e.g. on a Palm Pilot.
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
=