- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 19 Oct 1998 18:16:17 +0200 (MET DST)
- To: manuel.carrasco@emea.eudra.org (Carrasco Benitez Manuel)
- Cc: www-international@w3.org, tc46sc2@elot.gr, Harald.Alvestrand@maxware.no
Carrasco Benitez Manuel: [...] > 3) The reason for proposing the extension > of RFC-1766 is because: > > 3.1) It does *not* break RFC-1766. > > 3.2) It "feels" like a natural extension > and the "right" place to do it. > > 3.3) It is an easy to implement. > > 3.4) No need to change HTTP, HTML, etc. This is incorrect, see my previous message. > > 3.5) It could be available soon. > > 4) It could be that this is the "wrong" place > to put it and that one has to look at RDF > or similar places. > > By the same argument, one would not need the > "content-language". The client (one he > know the "charset") could look itself in > the document for the language and other > metadata. But HTTP has a "fat-ish" header. > > RFC-1766 is use for the header in the > transmission and for the metadata of the > document. My proposal tries to follow the > same doctrine. The existing content-* headers in HTTP are not a generic metadata transfer mechanism. They are a specialised mechanism, the shape of which was mainly determined by historical coincidences. If you have some new form of metadata, you should not try to shoehorn it into these existing headers, as there is historical code which depends on their current specification. Use a generic extensible mechanism instead. You can define a new HTTP header for example, that won't break existing implementations. >Regards >Tomas Koen.
Received on Monday, 19 October 1998 12:16:50 UTC