LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Re: Glue RFC
From: lilley <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Mon, 18 Sep 95 15:14:28 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (345 lines)



Sorry it took a while to get back on this.  I had trouble getting into
lanl.gov and gummo while the transatlantic link was being fixed.

Dan and I were disagreeing on the specifics of content negiotiation for
HTML files containing post-2.0 material. Having read over what was
said, both in this thread and in previous archived threads, it has
become clear that there are actually two problems being conflated here,
and it becomes cleaner once they are separated.

 1) Post-standardisation
 -----------------------

How to do content negotiation in the future, once there is a post-2.0
HTML standard (whatever that may be called) and the files being served
are alleged to comply with that standard.

 2) Pre-standardisation
 ----------------------

How to do content negotiation for any new features which have been
proposed and are being implemented to gain experience and refine the
proposed specification.  In this case, there is no standard and there
may be no firm specification.

Taking these one at a time, 

1) I thought Dan was saying that there would not be any intermediate 2.n
version numbers and thus that it would not be possible to label content
conforming to post-2.0 standards:

> >> I'm not exactly sure at this point what numbers/names/parameters will
> >> be assigned to which features. I believe that having this working
> >> group decide the bindings prescriptively is not a formula for sucess.

> >You seem to be saying that even after a Glue RFC 
> >is published there will still be no direction on how to label content. 

> I didn't mean to say that. Eventually, there will be standards.

OK, so that is problem one sorted out and a misunderstanding cleared up.

At some point there will be an HTML standard which includes 2.0, tables,
and other stuff.  This will have a DTD so folks can author or validate
content, and the text/html Internet Media type registration will be
updated to include the level/version/whatever number so that clients can
do classic content-negotiation based on whether they accept the new HTML
standard or only HTML 2.0.

Fine.

2) That leaves the second problem - what to do in the
experience-gathering phase of pre-standardisation deployment.  Dan said:

> We're not ducking out. I've made a propsal. Your options are (1) take
> it and try it out, or (2) propose something else. I don't think (3)
> standardize something unproven will work. 

Firstly, I have tried out Dan's proposal [01], as the archives show.  He
announced it to this list on Mon, 13 Mar 1995 [02].  The very next day I
posted [03] to this list giving my experience with his proposal and
detailed description of browser behaviour with all table-accepting
browsers I then had access to - Arena 0.94y and 0.96p plus Netscape
1.1b1 - and I concluded:

| a) Arena 0.96p works correctly, iff the MIME type is text/x-html3

But not if it is text/html; level=3 as per Dan's suggestion

| b) Netscape 1.1b1 works correctly, in that it does not claim to be 
|    an HTML 3 browser and offers to save unknown MIME typed objects 
|    to disk. This does mean that some documents it could infact handle 
|    are not displayed.

That also means that Netscape 1.1b1 (and 1.1) would refuse to display
any documents with tables, using Dan's strategy.  We hardly need a
crystal ball to predict that Netscape - indeed, any browser supplier -
would not be happy with this.

| c) The CERN server has problems serving up parameterised MIME types.

That last one turned out to be wrong; Dan and I then discussed these
findings in some detail, sorting out the practicalities of serving up
parameterised Internet Media types with the CERN server.  I also
reported problems with various browsers [04] including Arena 0.94y
(fixed in 0.96s) and Netscape 1.1b1 (not fixed)

In addition, I made available the same validated HTML 3.0 file at three
different URLs which would be served up as three different Internet
Media types

 text/html 
 text/x-html3
 text/html; level=3.0  (actually it might have been version=3.0)

for folks to conduct their own tests on browsers I didn't have.  So I
think I can honestly say I gave Dan's proposal a fair test.

Secondly, I was not calling for premature *standardisation*, in the IETF 
sense of standardisation. What I said was:

> >Then people would at least be able to *all do the same thing*. A consensus 
> >on what to do is the minimum requirement for interoperability.

I stand by this statement.  We are talking about an automated content
negotiation process; no client can do anything sensible with totally
free-form labelling where one document is text/x-html-with-tables,
another is text/html; tables=yes and a third has text/html;
options=x-tables

In this instance, tables are the new feature; however it could as well
be fig, or div, or something else.  I suggest that we need a way to
advertise content that uses new features that have been proposed for
standardisation; this is distinct from browser-specific features, or
individual research projects, or other extensions which are not being
proposed for inclusion in an HTML standard specification.

A consensus on what to do is not the same thing as standardisation.  The
file upload proposal [05] says for example:

 "Add a FILE option for the TYPE attribute of INPUT"
 
I don't hear anyone complaining that this is premature standardisation
and that we should be free to say UPLOAD or FILE_UPLOAD or WIBBLE as the
whim takes us!

What I suggest is that when proposed HTML extensions are put forward,
the internet draft should include proposed deployment information, which
is every bit as important as the proposed syntax of HTML tags.  [The
file upload proposal, used as an example, does of course consider some
backward compatibility issues, although not the Internet Media type]

For example, suppose that the forthcoming FIG internet draft not only
proposes the syntax of the FIG element but also proposes that clients
which understand FIG advertise this fact by sending

Accept: text/html; x-fig=yes

New releases of browsers which understand FIG could then advertise the
fact in a consistent way, to allow it to be tested in practice; content
providers could label FIG-containing material in a consistent way, and
this consistency would allow automation, and thus permit the proposal to
be actually tested out in practice. 

I see M. Hedlund saying something similar [06]:

| (Quoting Dan)
| > Accept: text/html; level=3

| Can this be stated more strongly? Without a strong advisory that clients
| designate acceptance of tables, and without uniform implementation,
                                              ^^^^^^^^^^^^^^^^^^^^^^
| globbing in the Accept header will make partial implementation next to
| useless. The HTTP protocol encourages the use of "Accept: */*" to allow
| clients to download unknown types.

| > not the rest of the 3.0 spec should specify level=2.5 in their 
| > Accept: headers?

| I would definitely prefer this to nothing at all. Again, if this could be
| strongly suggested and widely implemented, the Accept header would be more
| useful.

Dan appeared to be suggesting something similar  when he said, quoted in [04]:

| > I suspect the installed base of Netscape 1.1beta is already significant,
| > though Netscape should be able to spin another release if we figure out
| > some easy fix that would be a big win. Does that sound reasonable,
| > anybody from Netscape?

Netscape did not reply, but then I am not sure they were offered an easy fix.

This consistent proposed labelling is not the same as standardisation;
after standardisation, browsers might well say they understand FIG (and
other things) by sending, for example,

Accept: text/html; level=2.2

depending on the number given to the Glue RFC that included FIG.

Getting back to Dan's recent email, he says:

> I disagree. There is a clear direction on how to proceed: clients that
> grok tables MUST differentiate themselves in the Accept headers somehow.

Somehow is a bit vague, and Dan suggests:

> They should use the syntax given in the tables-deployment draft, unless
> they've got a better idea.

Now we get back to problems with the table deployment draft, some of
which were identified as early as March this year. Problems being that

A) the tables deployment draft gives four possible syntaxes rather 
than one:

| Accept: text/html; level=3
| Accept: text/x-html; level=3 
| Accept: text/x-html; level=2.5
| Accept: text/html; level=2.5

These are all post-standardisation labels; they do not scale to other
proposed features.  What happens if there was a browser which understood
some other part of HTML 3.0, say FIG, but not tables?  What happens with
a browswer that implements some other feature, proposed for
standardisation, that is not in HTML 3.0?

B) It has been shown [04] that the installed base of Netscape 1.1 does
not display content labelled x-html and ignores any parameters to
text/html and thus the tables deployment draft, as it stands, will not
work with a widely deployed browser.

So, any proposal for deployment of tables, FIG, or whatever has to take
into account how to reliably label the content and how to reliably
advertise acceptance of such content from day one, so the tens of
thousands of people who will use the new feature, many of whom will have
little technical skill, can all inter-operate.  And any proposals for
standardisation have to take account of the fact that the proposed
extension will be in daily use by millions by the time it gets
standardised; thus, any such deployment draft must not break the
existing installed base.

C) Regarding the suggested "2.5" Paul Burchard said: [07]

| I think there was broad agreement here to work toward a level 2.1 
| having tables as its main enhancement. So, I believe we should use 
| "Accept: text/html; level=2.1" to detect table capability.

| (Why 2.5? HTML 3.0 is a reasonably big chunk to bite off -- even 
| Dave hasn't fully implemented it in his own browser -- so I forsee 
| the need for a couple more intermediate levels. Can we start arguing 
| about what those should be?)

However, Dan's graceful deployment paper still says 2.5.  It does not
clearly distinguish pre-standardisation deployment from
post-standardisation deployment.

Also, Eric Sink announced in September that this WG has decided to
progress from HTML 2.0 in small steps, by publishing RFCs which document
each extension.  [08] So neither 3.0 nor 2.5 is really suitable.  The
post-standardisation Internet Media type is likely to be labelled
something like

text/html; level=2.1

The question is, what should the pre-standardisation labelling be? Back in
June, responding to a post from Brian Behlendorf I said: [09]

|[quotong Brian]
| > What we *could* do is give each incremental advance its own temporary 
| > mime type, like text/x-html-tables, text/x-html-maths, etc. 
|
| Hmm how many different permulations by HTML 2.8? What about
| 
| text/x-html3; tables=no; maths=yes; figure=yes; style=yes; applets=no;
| 
| Then every so often the whole standard gets an overhall and there is a 
| new standard equivalent to the previous one with all add-ons set to yes?
| (Plus making html.reccomended stricter each time etc). At which point
| it goes up a major version number, or level, or both, or whatever the 
| number is being called ;-) at which point we have
| 
| text/html; level=3
| 
| Just a suggestion. Of couse,in the real world, documents with tables 
| are being served up as plain text/html and browsers ignore parameters 
| to media types. Oh well. Click here if your browser supports maths 
| but not tables ;-( barf.

That sounds enough like the current Glue RFC proposal that I still stand
by the idea ;-)  But taking into account the need to not break the
installed base I would now suggest:

text/html                            means 2.0, always 
                                     (installed base unaffected)
text/html; level=2.0                 redundantly means HTML 2.0
text/html; x-tables=yes              means HTML 2.0 plus the proposed tables 
text/html; x-foo=yes                 means HTML 2.0 plus the proposed  foo
text/html; x-tables=yes; x-foo=yes   means HTML 2.0 plus tables plus foo

Once a checkpoint Glue RFC is issued, we then go up a minor version number
and have

text/html; level=2.1               means HTML 2.1 which includes tables 
                                   and other stuff

Dan points out:

> We're at stage 2. During stage 2, it's healthy to have multiple
> proposals on the table. That's what I mean by a market-based
> solution.

Fine.  Now I understand your terminology better.  Take client side
imagemaps; there is the HTML 3.0 proposal from Dave Raggett, and there
is the Seidman internet draft.[10] We could have

text/html; x-csi=raggett

This is not prematurely standardising unproven technology, and it is not
the "ISO mentality of prescriptive standards".  It is not standardising
anything.  It is suggesting a way of deploying multiple independent
proposed new features such that they can be easily tested out by people
and will inter-operate.  It is suggesting that labelling issues be
addressed as part of each new internet draft to ease smooth deployment.

It is encouraging to note that Dan suggests something similar:

> Sure, using HTML spec version numbers in HTTP format negociation is
> handy. I'm just saying that there's nothing handed down from the
> gods that says we've got to do it that way. Something like:
> 	Content-Type: text/html; options=tables
> or
> 	Content-Type: text/html; profile=netscape-1.1
> could work too.

So finally, we seem to be in broad agreement.


[01] <url:http://www.w3.org/hypertext/WWW/MarkUp/table-deployment.html>
[02] <url:http://www.acl.lanl.gov/HTML-WG/html-wg-95q1.messages/0620.html>
[03] <url:http://www.acl.lanl.gov/HTML-WG/html-wg-95q1.messages/0626.html>
[04] <url:http://www.acl.lanl.gov/HTML-WG/html-wg-95q1.messages/0627.html>
[05] draft-ietf-html-fileupload-03.txt
[06] <url:http://www.acl.lanl.gov/HTML-WG/html-wg-95q1.messages/0638.html>
[07] <url:http://www.acl.lanl.gov/HTML-WG/html-wg-95q1.messages/0621.html>
[08] <url:http://www.acl.lanl.gov/HTML-WG/html-wg-95q3.messages/1008.html>
[09] <url:http://www.acl.lanl.gov/HTML-WG/html-wg-95q2.messages/1367.html>
[10] draft-ietf-html-clientsideimagemap-01.txt

-- 
Chris Lilley, Technical Author
+-------------------------------------------------------------------+
|       Manchester and North HPC Training & Education Centre        |
+-------------------------------------------------------------------+
| Computer Graphics Unit,             Email: [log in to unmask] |
| Manchester Computing Centre,        Voice: +44 161 275 6045       |
| Oxford Road, Manchester, UK.          Fax: +44 161 275 6040       |
| M13 9PL                            BioMOO: ChrisL                 |
|     URI: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html       | 
+-------------------------------------------------------------------+





Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager