I find the following process very ineffective:
1. IESG charters IPP WG in 3/97 after a well attended BOF 12/96. =20
2. The WG has always been well staffed and work has progressed within the =
working group at a very good rate. We were essentially done at the end of =
97.
3. The working group has reached consensus and produced a set of drafts =
that meet the objectives of the charter.
4. The decision to reuse HTTP/1.1 has been on the table (IPP WG email =
discussion list, IPP drafts) for over a year now. There was NEVER any =
discussion in the working group meetings in Munich, DC, and/or LA that IPP =
should not be layered on top of HTTP/1.1. The only question was POST vs =
PRINT. Both of which implied layering on top of HTTP/1.1 For a year we =
have said that IPP opertions would be use the "http:" scheme.
5. The working group had final call in 12/97. All comments were addressed.=
6. The IESG held IEFT wide final call. There were virtually NO comments =
on the mailing list. All comments were addressed.
Now, here is the real killer step:
7. 5 months after the end of the IESG final call on the IPP documents, we =
start to hear that "You MUST do it this way or else it will not be =
approved." Such comments were REQUIRED a year ago - they seem disruptive =
now.
I don't buy the arguments about "layering is bad". Although not optimal, =
the argument is that re-using HTTP was a good thing becuase of the =
leveraging and growth path of HTTP. HTTP is already being used for =
network attached printers and for print servers in a big way - it is =
already deployed where it needs to be. I do understand that IPP needs to =
be distinguishable, therefore the default port is a great idea along with =
an obvious content-type. If every protocol did its own infrastructure, =
security, naming, identity, distribution model, header definitions, etc., =
the world would be a mess. In my mind, it is either HTTP/1.1 for =
leveraging exiting protocol stack rather than requiring new ones, or not. =
I would hate to have all of the disadvantages of using HTTP with none of =
the advantages. At least with re-use, you get some or all of the =
advantages.
Scott
************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121=20
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: sisaacson@novell.com
web: http://www.novell.com
************************************************************