Re: IPP> regarding "ipp:" (I spoke too soon...)

["Scott Isaacson" <[e-mail]>]

Keith,

I find the following process very ineffective:

1. IESG charters IPP WG in 3/97 after a well attended BOF 12/96.  
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 
122 E 1700 S, Provo, UT 84606
voice: [phone], [phone] x17366
fax: [phone]
email: [e-mail]
web: http://www.novell.com
************************************************************