HTTP-EQUIV (was Re: minutes from the IETF INDEX BOF
At 8:48 AM 6/26/96, Mike Schwartz wrote:
>Also, I got a good suggestion after the BOF from Paul Leach (Microsoft): to
>keep the tagging people suggested at the workshop data-type independent
>(i.e., so it works with more than just HTML), it would be a good idea to
>work in the HTTP entity header space rather than in HTML META tags. You can
>still do the tagging in HTML for the (current) common case by using
>HTTP-EQUIV tags, and that way other data types can also take advantage of
>any tagging standards that get defined.
A few observations. Doing it in http entity header space:
- raises the issue of namespace conflicts,
although they can be avoided with some care.
- limits the design of the name space to the requirements
of the field-name syntax in the HTTP RFC, which may be acceptable.
- doesn't limit the possible character sets, because HTTP field-values
specifies an encoding scheme.
- means that in the common case of GET, servers that do server-side
parsing for HTTP-EQUIV and generate the HTTP header duplicate this
information during transmission, which is wastefull.
- means that as the size of the meta-content grows, the protocol
overhead in parsing the request increases.
- there is no precedent fo other things in HTML, such as the <TITLE>,
to move into the HTTP protocol.
> 4. There was a question about the extent to which multiple
> character sets and languages was addressed at the workshop.
> The response was that it did not come up much in the discussion
Well, in the case where the data originates from the contents of an
HTML document, I would expect the meta data followed the character
set and language of the document, unless the meta specification in use
specifies any different.
You can attempt to address multiple character sets and languages
inside a meta information specification, but it's an enourmeous hassle
which may be avoided; Simply separate the meta information from
both HTML _and_ protocol. I think this can most easily be done by keeping
the meta information in a URL-addressable object, and just define ways of
associating this URL with the object in question. In HTML, you can use
a LINK tag, in HTTP you can define a header. Providing the protocol
supports it you can then negotiate and/or report character sets and/or
languages. Bummer if you use "file://" of course...