IPP> Delay of IPP ratification

IPP> Delay of IPP ratification

Scott Isaacson SISAACSON at novell.com
Fri Jan 9 19:08:16 EST 1998


Paul,


There has to be some process in any standards body working group.   We had
final call for the working group close about a month ago and since then we
have been working issues raised during final call - not new issues. 
Granted, the IESG has not had final call and really any issues are still
open as long as we follow that process, it is just that this should have
come up ealier.  Keith has commented that he expected some comments during
the larger final call time frame.


Having said that, I am an technologist at heart and so I am always
interested in the best technical solution.  Best technologies to not always
a standard make.   The current protocol document is in the form that it is
in because of the valid Microsoft and HP proposals that were made 9 months
ago.  As I recall the problem wasn't structured data in an ascii protocol,
it was using a binary protocol rather than an ascii one for lower overhead
in processing and performance reasons.  I am convinced that the current
protocol spec is not broken and that what we have will work (since many of
us have already been doing prototyping).  There would have to be a
compelling reason to change now.  Just becuase there are other working
groups doing it, it not compelling to me.  Just becuase it is a "new wave"
is not compelling to me.


Here is my major point:  You do, however, raise vaild points about XML.  It
is a growing thing.  It is a valid candidate.  The WebDAV WG has found it be
useful.  But, one of our early goals for IPP was "speed to market" (so to
speak) so that we could come to consensus before some new technology came
over us an swallowed us up and we had to start over with the new technology.
 We are just on the verge here - we have a gold-master candidate and we are
about ready to ship product.  Do we "ship the product" with what we have
fought for a year over and finally come to consensus on (paying the price
with people's and company's time and resources) or to we hold up the product
and wait to integrate in the next new feature?  The classic question that we
all face every day.  


I personally feel is that it is too late in the process for infusion of new
things. This protocol mapping issue was discussed in Memphis (4/97) and
Munich(8/97) with full understanding and consensus on the mailing list
throughout the whole period.  There were NO issues raised about this on the
mailing list during final call.  There were NO issues raised in Washington. 
It is too late.  We need to ship.  We are not broken.  We do not NEED to
integrate with the up and coming wave of anything or we will never ship, we
will always be chasing.


Having said all that, I would be willing to consider the following:


Take the time to review a FULL proposal on an XML mapping for IPP on top of
HTTP POSTs as new encoding rules for version 1.0 of the new
"application/ipp" MIME media type if the following conditions are true:


1. That you (or someone) can contribute resources to deliver a full
proposal, distributed to the working group (via the DL) prior to the
face-to-face meeting on 1/21-22/98.


2. The proposal is limited to a data representation and encoding of the
current Model and Semantics.  We are not touching the model and semantics. 
There will be no revisiting the proposed use of new HTTP domain-specific
methods.  We SHALL NOT (can you tell I have been an editor too long!) not
revisit the issue of POST vs new HTTP methods.


3. The working group can reach consensus (at the meeting, via a toll free
phone call, on the DL)  that there is a way to proceed with the XML mapping
that will yield closure to all issues (given the limited scope of #2) in a
matter of weeks, not months.


4. The area directors comment and approve of the proposed direction before
the 1/21 meeting.


I hope that these assumptions were in the intent of your email in the first
place.  I am a little worried about the use of the parenthetical phrase you
added "(and protocol specific HTTP commands)".


Scott




************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121 
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: sisaacson at novell.com
web: http://www.novell.com
************************************************************




>>> Paul Moore <paulmo at microsoft.com> 01/09 11:21 AM >>>
This is a formal request that we delay the finalization of the IPP spec
until we have looked at the possibility of using XML as the protocol format.


I know this is revisiting an old issue but we need to make sure we do the
right thing. When the current format was proposed there was no good method
for representing structured data in an ASCII data stream. XML is now
available and seem to be the coming wave. I also know that most of the new
standards that will come out over the next year will be based around XML
(and protocol specific HTTP commands). By ensuring that we are in the centre
of these standards we will be able to leverage many common tools that will
emerge to support and manage these protocols.


There will definitely be down-sides so we need to debate this issue - not
least the investment that some of us have already made in building using the
current spec.


I think that somebody from MS will be in Hawaii.


Paul Moore
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                              



More information about the Ipp mailing list