W3C home > Mailing lists > Public > www-international@w3.org > October to December 1998

Re: Transliteration

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 19 Oct 1998 18:16:17 +0200 (MET DST)
Message-Id: <199810191616.SAA07039@wsooti08.win.tue.nl>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:16:53 GMT