- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Wed, 25 Jan 1995 10:32:49 -0800
- To: Maurizio Codogno <mau@beatles.cselt.stet.it>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> First, is there a mailing list/newsgroup devoted to http *questions*, as > opposed to protocol issues? Yes, it's www-talk@info.cern.ch > At the moment, I am trying to understand what does it mean to have > multiple language versions of a document, as hinted at in section 7.6 > of the draft HTTP document. Hmmm, that sounds to me like an http-wg issue. As it happens, I rewrote that section just last week. 7.6 Content-Language The Content-Language field describes the natural language(s) of the intended audience for the enclosed entity. Note that this may not be equivalent to all the languages used within the entity. Content-Language = "Content-Language" ":" 1#language-tag The primary purpose of Content-Language is to allow a selective consumer to identify and differentiate resources according to the consumer's own preferred language. Thus, if the body content is intended only for a Danish audience, the appropriate field is Content-Language: dk If no Content-Language is specified, the default is that the content is intended for all language audiences. This may mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended. Multiple languages may be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented simultaneously in the original Maori and English versions, would call for Content-Language: mi, en However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English audience. In this case, the Content-Language should only include "en". Content-Language may be applied to any media type -- it should not be considered limited to textual documents. > The question (hopefully) directly related to this group is another, however. > In a distributed environment like WWW it is conceivable that a document is > present in many copies scattered throughout the world; for most of these > documents it is not mandatory that the copies are *always* verbatim the > same, but a slight delay in propagation can be allowed. > Would it be useful to add a Request Header Field to ask for possible > duplicates of the URL, and a corresponding Response Header? This way, the > client could implement some Internet metric and choose the "nearest" > document. That would be the same as returning a URC (or URM) in response to a request instead of the document itself. Yes, that has been under consideration for a while now, but not directly as part of this WG, and independently of HTTP (though I am one of those working on the issues). See the URI WG for more info: <http://www.ics.uci.edu/pub/ietf/uri/> ......Roy Fielding ICS Grad Student, University of California, Irvine USA <fielding@ics.uci.edu> <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
Received on Wednesday, 25 January 1995 10:51:02 UTC