Re: Looking toward the IETF meeting

Daniel W. Connolly (connolly@hal.com)
Tue, 29 Nov 94 14:45:55 EST

In message <ab0130080a0210041170@[192.246.238.160]>, 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