At 4:20 AM 4/28/95, Gavin Nicol wrote:
>...
>> (2) use "filename.html" ("filename.htm" on Windows and CDROMS) for
>> "ASCII-tag-character-superset encodings" and use
>> "filename.uhtml"
>> ("filename.uht" for Windows and CDROMS).
>
>I do not think this to be reasonable either.
>
>How about defining a new MIME type for filesystem-based documents (or
>perhaps just storing such documents with the MIME headers)? Why is it
>absolutely vital to store the documents as HTML when this is obviously
>insufficient?
It wouldn't have to be for filesystem-based docs ONLY. Browsers could be
made aware of this new extension and type being sent by HTTP servers.
>One could assume that documents which use the .htm(l) extension use
>ISO-8859-1 (default, same as HTTP), and documents with a .www (or
>whatever) extension have HTTP headers.
My Netscape colleague was suggesting the same thing, except he was using
filename.mim(e). Although, I'd suggest using filename.htt(p) -- I think
that better describes the file contents.
Like in Larry's proposal, the HTTP headers would be in ASCII, but the
actual HTML data could be in any encoding. Essentially, this file date
would look like what an HTTP server would send over the wire. It's general
enough that the data could be other than HTML (e.g., GIF).
Just as with the <META> tag the HTTP headers could be handled by either the
server or the client.
This proposal (1) doesn't violate SGML,
(2) allows for UCS-2 and
(3) puts the tag in the data.
I like it.
-Bob
-- Bob Jung bobj@netscape.com +1 415 528-2688, fax +1 415 528-4122 Netscape Communications Corp. 501 E. Middlefield Mtn View, CA 94041