Re: Looking toward the IETF meeting

Murray Maloney (murray@sco.COM)
Tue, 29 Nov 94 15:36:02 EST

While I am not from one of the "major vendors" that Dan mentions,
I agree with Dan that option (see below) is the way to go.
That is, I don't care one way or another whether HTML 2.0
becomes and Internet RFC or not. What is (was) important
to me is to get the HTML 2.0 spec published and sanctioned
by an appropriate body or group. I think that we have done that,
simply by virtue of being accepted as an Internet Draft whose
contributors include most of the "major vendors".

I'd like to see us move on with the HTML 2.* series and HTML 3.0.
I really think that that's what the market needs too.


> In message <ab0130080a0210041170@[]>, Eric W. Sink writes:
> >I was under the impression
> >that what we sent as an Internet Draft was a "draft", and changes will be
> >made before we actually call it HTML 2.0. It is still not clear to me when
> >that time arrives, but I assumed it was tied to the time when this document
> >reaches RFC status.
> >
> >To put it another way: We want HTML 2.0 to be an RFC, whichever track it
> >ends up in. Surely there will be opportunity for a few more changes
> >between the Internet Draft and the RFC, right?
> The HTML 2.0 document has missed its marked window, in my
> opinion. When I started this effort, I had hoped that HTML 2.0 is what
> all the vendors would use in their marketing stuff and documentation.
> It would be the common feature set among the commercial
> implementations.
> But the first round of commercial browsers are already released.
> I see two options:
> 1. Continue to edit the 2.0 document until all the little nits are
> hammered out. Sort through the boat-load of documents resulting from
> the Internet Draft released in San Jose, looking for those few
> comments actually in the 2.0 scope among the zillions of enhancement
> requests.
> We end up with a nice, neat specification of a language that some
> browsers sort of supported about six months ago.
> 2. Let the 2.0 document go. Publish it as an informational RFC. Let it
> be known that we tried real hard, but we were after a moving target,
> and we never got all the editorial kinks out. But the DTD is
> available: you can validate your documents against the official,
> released, published, blessed, 2.0 DTD.
> Start fresh with 2.1 -- the spec that the _next_ release of commercial
> browsers will support. Add the ICADD stuff. Add &nbsp; and
> &shy;. Maybe add <super> and <sub>. Maybe even add tables.
> Maybe trim some of the fluff out of the document. Maybe split the HTTP
> interactions and such off into a "browser spec" ("WWW User Agent
> Spec," more precisely.)
> I'd like to go with option 2.
> But the critical thing about this document is endorsement of the major
> vendors. How do the folks from SoftQuad, NetScape, Spyglass, Spry,
> EIT, MCC (the consortium in Austin, not Mosaic Comm Corp) etc. feel
> about this? Which way should we go?
> Dan