- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Thu, 20 Mar 1997 11:59:38 -0800
- To: advax@triumf.ca
- Cc: http-wg@cuckoo.hpl.hp.com
>In HTML, <META HTTP-EQUIV="Blah" is supposed to be equivalent to an
>HTTP header "Blah:", yes ?
Not quite. It means that the content given has semantics equivalent
to the HTTP semantics for the header field "Blah".
>What is the position on creating new HTTP-EQUIV types (and presumeably
>equivalent HTTP headers) ?
That's backwards. The only possibility is to create new HTTP headers,
which then could be used in HTTP-EQUIV. Otherwise, use <META NAME="Blah">.
>In the Dublin Core metadata work a form <registry>.<name>[.<type>]
>seems to be accepted, e.g.
><META NAME="DC.Author" CONTENT="Joe Fish">
>and perhaps
><META HTTP-EQUIV="DC.Author.email" CONTENT="jfish@pisces.org">
>and the equivalent
>DC.Author.email: jfish@pisces.org
>as an HTTP header
>
>which might imply that the "DC" portion should be reserved
>for the DC crowd, and registry-less names be reserved for the HTTP group.
That wouldn't make sense. The DC. prefix is supposed to associate
semantics of the name with Dublin Core semantics, and for the exact same
reason that HTTP-EQUIV associates the name with HTTP semantics.
If we were to reinvent HTML, then we would probably use
<META NAME="HTTP.Expires" content="Wed, 19 Mar 1997 13:15:31 GMT">
instead of HTTP-EQUIV (or just skip the whole thing and just use LINK).
>What I don't want to see, obviously, is people generating headers like
>Expires: 4/5/99
>Location: Bournemouth
The server is fully capable of controlling what it sends.
.....Roy
Received on Thursday, 20 March 1997 12:35:10 UTC