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.

All this menas that it is just an accident of history and so we have
to just grin and bear it and live with all the bad fallout effects.

I am looking for some way to provide published expanations for the
roots of all the confusion and so educate peple on two fronts:

1.  How to cope wth the existing confustion.

2.  How and why to avoid this kind of thing in the future.

I see no reason to leave this kind of knowledge hidden to as to invite
more fo the same.  Do we need some kind of IETF/IAB purblicatron that
explains why one protocol should not use the same verbs as other
differnet protocols use for different meanings?

Is this a higher meta level issue for our Architecture Board to work
on?

Cheers...\Stef

>From your message Mon, 26 Jan 1998 11:08:23 -0800:
}
}
}
}>  Sender: stef@nma.com
}>  From: Einar Stefferud <Stef@nma.com>
}>  Date: Sun, 25 Jan 1998 00:13:37 -0800
}>  To: IETF working group on HTML in e-mail <mhtml@segate.sunet.se>,
}>          http-wg@cuckoo.hpl.hp.com
}>  Subject: Re: MHTML/HTTP 1.1 Conflicts 
}>  
}>  I am fast losing confidence that we can ever resolve our MHTML/HTTP
}>  interworking problems, as long as the IETF allows HTTP to claim to
}>  only be MIME-like, while using MIME headers, but with differences from
}>  the MIME standard?  
}>  
}>  Without the surrounding HTTP wrapper, how are we supposed to know
}>  which kind of MIME object we are dealing with? 
}
}By its MIME type.  HTTP has adopted the HTTP type registry, lock stock and 
}barrel.  There is one place, where HTTP has relaxed this: text types, 
}reflecting the reality of the Web, where you don't (necessarily) get CRLF's 
}for line delimiters, and don't have line length restrictions. This is 
}acknowleging existing practice, not something we believe is necessarily 
}desirable (though it is pretty clear that one of the reasons the Web succeeded 
}was that pretty well arbitrary plaintext documents could be served up without 
}modification, early in the Web).  This reflects the reality of the text 
}content on the Web, and how it was prepared, and that HTTP servers treat 
}all datatypes the same, as bags of bits (possibly with some metadata).
}
}Note that any fully conformant (i.e. email) text body and/or message is, 
}however, a valid HTTP text entity.  This is one saving grace for interoperability.
}
}> Are we supposed to
}>  sniff it to see if there is any trace of HTTP smell to it?
}>  
}>  I raise this issue now because we need a reading on this situation
}>  from our APP Area Directors, and perhaps from the APP Area
}>  Directorate.
}>  
}>  I do not see how we can ever sort things out when any IETF standard
}>  claims to be MIME, but not quite, while it references the MIME
}>  standard, and uses MIME standard headers that do not conform to the
}>  MIME standard.
}>  
}
}I don't think HTTP claims to be MIME.  It certainly borrows both
}syntax and lots of usage, and the type registry from MIME.
}
}>  This is a sure recipe for a long term (like continuing forever) series
}>  of interworking problems.
}>  
}
}Yup.  Best we can do is try to avoid new ones.
}
}>  It seems to me that if any standard claims to be MIME-like, that it
}>  should have been required to choose new names for its headers and to
}>  strcitly conform to the MIME standard in its use of any MIME headers.
}
}You won't get any argument out of us; we certainly agree.  But it is water under
}the dam, in some cases.
}
}>  
}>  I have no idea what to do about this situation, but I am having great
}>  difficulty trying to figure out how we are ever going to be able to
}>  close on our MHTML standard and hope for consistent interworking with
}>  MIME objects created for HTTP tansport, without our adopting the HTTP
}>  MIME-like standard for our MIME standard.
}>  
}>  Are we supposed to just give up because of some serious mistakes made
}>  by HTTP in the distant past?
}>
}
}I don't think things are quite a bad as you make out.
}
}You are still trying to think of HTTP as MIME; it isn't...
}
}Note that the HTTP standard has been trying as best it can to mitigate the
}damage for a long time.
} 
}>  Will someone please explain how this is supposed to work?
}>  
}>  
}
}Think of HTTP as a generic "bag of bits transport" protocol, using
}MIME types to type the bags of bits, and you'll get the general idea.
}(FTP with types on steroids).
}
}MHTML and MIME as far as HTTP is concerned is just one more datatype, one that
}happens to strongly resemble HTTP in syntax.
}
}That it looks like MIME is pretty much an accident of history, in my
}humble opinion; the confusion this has caused has haunted HTTP and now will
}haunt MIME and MHTML for years.
}
}HTTP is enough like MIME to confuse even the non-innocent (or maybe
}particularly the non-innocent) into believing it is MIME.  So people who
}don't know MIME, just find HTTP a baroque and wierd transport protocol, while
}those who come to HTTP from MIME get all confused.  So, in our experience,
}it is the MIME experts who have the biggest trouble getting their
}heads around HTTP.
}
}I wish there were a magic wand to "fix" this, and the resulting confusion; 
}there isn't one I can find.  If I had been the one to design HTTP, it wouldn't 
}have looked like RFC 822...
}
}					- 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 14:11:05 UTC