Re: MHTML/HTTP 1.1 Conflicts

Thanks Jim -- I will accept your judgement that I am beating up on the
wrong people with hindsight, and the implication tha doing so is
unfair.  But, I was fishing for an understanding of how we got here
from there and that is what I got.  Thank you very much;-)...

The problem of converting hindsight into foresight has always been
daunting, so merely clarifying hindsight, in and of itself, is not of
much interest if we cannot convert it with some kind of meta process
into a way to visualize, in this case, the architecual meanings in the
future.

>From what I have seen here and elsewhere, it seems very clear that any
new protocol should never ever use the same names for anything that is
not infact the same thing, just in case it somehow gets into that
alternate universe and is there mistaken for what it is not.

I suspect that the ISO/OSI custom of incorporating the protocol names
by abreviation into the protocol element labels was a method for
achieving this precise goal, as it clearly prevnets the use of any
naming label from bearing the same name as some otherwise defined
element.

If this is all there is to be gleaned from the HTTP/RFC822/MIME
escapade, so be it.  Perhaps it does not look like a very big lesson,
but if it can help prevent future accidents, it does not look too
expensive related to the possibly huge payoffs.

Cheers...\Stef

>From Jim Gettys's message Mon, 26 Jan 1998 14:35:11 -0800:
}
}>  From: Einar Stefferud <Stef@nma.com>
}>  Date: Mon, 26 Jan 1998 13:13:40 -0800
}>  Subject: Re: MHTML/HTTP 1.1 Conflicts 
}>  
}>  I understand that we are dealing with a legacy of bad HTTP choices
}>  back when there was no IETF involvement, adn the people developing
}>  ythe "standard" understood tha the way to set standards was to "just
}>  do what you wnat to do" adn get it over with.
}>  
}
}BTW, this is a bit unfair and an overstatement...  The folks who designed 
}HTTP have/had different goals than mail, and different expertise than networks. 
}Part of the Web's success was that it allowed existing and future content 
}to be transported (including MHTML). Demanding all text files be converted 
}before being served by a web server would not likely have helped the Web 
}take off, for example, so it seems to me it was a perfectly pragmatic 
}decision, in that case.
}
}Adopting the MIME type registry was clearly a win.  
}
}You can question whether modelling the HTTP protocol after MIME was a good 
}idea; I think history is showing it wasn't, that the accumulated baggage 
}since 822 is causing serious confusion.  Systems also age, and RFC822's 
}decendents are showing serious signs of senesence. 
}
}But things might have been even worse had they (TimBL, et. al. etc.) gone 
}off completely on their own.  There are relatively few people who've designed 
}even one protocol at all well. I know in my background it took several 
}redesigns to design one (the X protocol) even partially right for long term 
}stability (and I certainly know of many problems with that protocol).  Given 
}the speed with which the Web took off, it is unlikely Tim et. al. would 
}have had the luxury we did of fixing the worst mistakes we made in early
}versions of X.
}
}So you're beating up on people with 20-20 hindsight.  Things might be much 
}worse.  All in all, I think they did a pretty decent job for a first try.
}Where were we when the Web should have been invented (arguably, all the
}pieces to invent it have been around since around 1986).
}				- Jim Gettys
}
}--
}Jim Gettys
}Industry Standards and Consortia
}Digital Equipment Corporation
}Visting Scientist, World Wide Web Consortium, M.I.T.
}http://www.w3.org/People/Gettys/
}jg@w3.org, jg@pa.dec.com

Received on Monday, 26 January 1998 16:34:39 UTC