From duerst@it.aoyama.ac.jp Mon Nov 2 01:50:16 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70EF128C180 for ; Mon, 2 Nov 2009 01:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.02 X-Spam-Level: * X-Spam-Status: No, score=1.02 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCsT1kRNMwMm for ; Mon, 2 Nov 2009 01:50:14 -0800 (PST) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 0FB663A66B4 for ; Mon, 2 Nov 2009 01:50:13 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id nA29oMhK023669 for ; Mon, 2 Nov 2009 18:50:22 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2ed0_2334d194_c795_11de_b311_001d096c566a; Mon, 02 Nov 2009 18:50:22 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40057) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Nov 2009 18:46:51 +0900 Message-ID: <4AEEAB47.7060708@it.aoyama.ac.jp> Date: Mon, 02 Nov 2009 18:49:59 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Peter Constable References: <19173.46660.701817.726727@gargle.gargle.HOWL> <49CB1917-6A69-448A-B619-644F8730940C@jfkew.plus.com> <4AEA91E9.4020708@twardoch.com> <4AEAB1E3.50305@it.aoyama.ac.jp> <9d70cb000910301502se5053c5qbfa3562dbcbd850a@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Jonathan Kew , www-font , =?UTF-8?B?SMOla29uIFdpdW0gTGll?= , www-style , Stephen Zilles , LTRU Working Group , "Adam Twardoch \(List\)" Subject: Re: [Ltru] font features in CSS X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 09:50:16 -0000 Hello Peter, others, On 2009/10/31 8:02, Peter Constable wrote: > Btw, Martin: it’s not clear to me what outcomes you have in mind for bringing the CSS thread into the IETF Languages list. See below. > You made statements about HTML lang and xml:lang, and those statements seem to be correct. Yes. Adam's mail seemed to suggest that ISO 639 3-letter codes for well-known languages are or should be used as IETF BCP 47 language tags in HTML lang and xml:lang. Going back and rereading Adam's mail, I'm sure there was no intent for such a suggestion, but I still think it was easy for a third party to read it that way. So I wanted to make sure people understood the difference between ISO codes and IETF BCP 47 language tags. Also, there was a comment that there was no one-to-one correspondence between OpenType "language systems" (put in quotes on purpose) and ISO codes, and I wanted to point out that the correspondence should be better for IETF BCP 47 language tags than for ISO language codes. > You suggested changes to the data in the OT tag registry; that registry is only tangentially relevant for this list, I think, though I have commented on your suggestions. I didn't want to suggest any changes to the OT data, at least not for now. > Sent: Saturday, October 31, 2009 7:54 AM > To: Andrew Cunningham; Martin J. Dürst > Cc: LTRU Working Group; www-font; Håkon Wium Lie; www-style; Jonathan Kew; Stephen Zilles; Adam Twardoch (List) > Subject: Re: [Ltru] font features in CSS > > Indeed, the OT language system tags are about typographic conventions. Yes. In that sense, they are a misnomer, as John Hudson has mentioned. Now I have to say that in the language area, we are used to misnomers, examples being the LANG environment variable on ***ix systems that denotes a locale, or the talk about languages in ICANN settings when mostly or exclusively, they mean script, and so on. The other experience we have made in the work on BCP 47 is that it is often possible, and often desirable, to look some phenomena as not necessarily language-determined but nevertheless language-related. Issues such as sort order, number and monetary formatting, quoting conventions, and so on, at first sight seem to be separate from the question of whether the text is German or French. But then a German reader expects some sort orders and not others, and a French reader expects some quoting conventions and not others. And it becomes feasible to tag different typical German sort orders as variants of 'de'. > Now, many languages have a single conventional writing system and a single set of conventions for typography for that writing system, though conventions may different for other languages with writing systems based on the same script. It is definitely clear that there isn't a one-to-one correspondence. But my observance was that the correspondence got better when moving from ISO tags to IETF BCP 47 language tags. So one question where LTRU could help www-font is whether or to what extent it may make sense to use BCP 47 language tags to identify typographic conventions as expressed by OT "language systems". > A familiar example is Serbian, which has distinctive italic forms for certain letters making its typographic conventions different from, say, Russian. Yes. The question is how to get from HTML lang or xml:lang to the OT "language systems". For cases such as Serbian, I think the common assumption would be that browsers supporting OT would automatically activate the "SRB" (Serbian) "language system" for pieces of text that are tagged with something like lang='sr' (or sr-*). The more interesting question is how to deal with Macedonian, assuming that Macedonian uses the same typographic conventions and variants as Serbian. There are several possibilities: a) Browsers automatically activate the "SRB" "language system" for texts labeled lang='mk' (or mk-*) b) There's a way in CSS to say: use "SRB" for this text. The selector part already exists, the question is just how to create the property part, and where to allow it (@font-face and/or general rules). This could look something like: :lang(mk) { opentype-language-system: 'SRB' } c) Same as b), but without exposing OT tags, essentially saying: Use the same conventions as for Serbian. This could look something like: :lang(mk) { typographic-convention-same-as: 'sr' } (property names are overly long and descriptive on purpose; instead of 'sr' in the above example, 'sr-Cyrl' may be more appropriate) The advantages of c) over b) would be that it is less dependent on a specific font technology, and it may be easier on the users, who don't have to learn yet one more kind of tag. > There may also be cases within a single language and writing system of multiple typographic conventions. For instance, Malayalam is taught today using fewer conjunct forms than were used in the past. Yes. The question here would be whether we can register a variant subtag for this distinction at IANA. (Treating this for the moment as a generic question, not as a particular request.) In my view, this should definitely be possible, as such a distinction may be relevant for libraries tagging books, for movies for tagging subtitling, and so on. For electronic text in Unicode, it may be more a matter of CSS than of language tagging for the text itself, at least if these are simply glyph differences not expressed in Unicode. > In principle, it may be reasonable to say that two or more languages can be described as having a common set of typographic conventions. Yes indeed. There are several examples of this in the OT registry, such as Athapaskan ATH apk, apj, apl, apm, apw, nav, bea, sek, bcr, caf, crx, clc, gwi, haa, chp, dgr, scs, xsl, srs, ing, hoi, koy, hup, ktw, mvb, wlk, coq, ctc, gce, tol, tuu, kkz, tgx, tht, aht, tfn, taa, tau, tcb, kuu, tce, ttm, txc The question here would be whether this can be covered by a collection code, whether the list is an artifact of the fact that Peter wasn't able to reconstruct the original intent (and as Peter said, maybe there never was much of a clear 'original intent' for some of the entries), whether this OT "language system" is actually in use or not, and so on. > For instance, I don’t know of any particular reason why font rendering should differ according to whether the text is English or Spanish. I don't know about English and Spanish. But I know that French likes lots of ligatures, but Italian doesn't like ligatures at all. My understanding is that this could be reflected with an OT "language system" feature. And I seem to remember that in old times (meaning before PostScript printers), the same "Times" font might have been cut slightly differently for English, French, and German, to take into account the frequencies of different letter combinations and to improve readability. (I'm not an expert in typography, and I'm sure many of the participants in this discussion from the www-font list can provide more information or correct me if necessary.) > In practice, though, it would be very difficult to manage a system that organized the data that way: it’s far easier to allow for a default OpenType language system tag for every language, keeping in mind that OpenType fonts have a default language system and that an explicit language system only needs to be incorporated into font data and invoked when rendering if there are distinctive typographic behaviours. Yes. What I'm trying to get at is to what extent we can make use of BCP 47 language tags (which Web developers already should be familiar with) to express the typographic conventions and distinctions that OT "language systems" represent. > Martin suggested that the info Adam Twardoch reported (on some other list than this) should be revised. My mail may read that way, but it wasn't intended that way. > In principle, changes such as Martin suggested to use IETF Language Tags with region or script subtags might make sense, Yes. One reason to include LTRU in this discussion was to see to what extent it makes sense. > but in practice that would be attempting to do something that goes beyond the intent of the OpenType tag registry and that would not be highly feasible: to equate every language system tag with a _specific_ and equivalent IETF language tag. I agree that there are cases of "language systems" where it would be quite difficult. But then some of these may also be cases that may not actually be in use. > The simple explanation is the one Andrew gave: these things are not comparable – unless we want to introduce variant subtags for typographic conventions, and I’m not sure that makes sense. I'm also not sure it makes sense. But we have distinctions such as Fraktur vs. Roman (that one via script subtags rather than variant subtags), which may come very close in usage to "Malayalam with many ligatures" vs. "Malayalam with few ligatures". > My add’l explanation is that it would not be a simple task, and I don’t think it would be worth the effort. Thus, such changes will *not* be made. The page in question is at www.microsoft.com, and so it's Microsoft's business of whether they want to change it or not. But the question of how to get from HTML/XML and CSS to these features involves BCP 47 language tags anyway, so the question of correspondence (whether one-to-one or not) is a separate one from the question of whether the table itself changes or not. > As for “Chinese Phonetic”, I mentioned above that most of the tags were registered years ago without documentation. Thus, it’s not clear what was meant when ZHP was first submitted. It probably was Pinyin, though that’s not certain. Now, I could go and revise the data in the OT tag registry to make the intent explilcit, describing ZHP as being for “Chinese Pinyin”. But I’ve got to ask: are there really different typographic conventions for Pinyin than for any other Latin-based writing system for Chinese? My guess is probably not. I seem to remember that the Chinese for Pinyin rather strongly insist on particular shapes for the lowercase 'a' and 'g', I think they want those that one would in general only see in the Italic style also for the Roman variant. That would explain the need for a separate typographic convention. As for verifying whether it's Pinyin or not, one way would be to examine a wide range of fonts and see if and how it's used. > Peter > > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Andrew Cunningham > Sent: Saturday, October 31, 2009 7:02 AM > To: Martin J. Dürst > Cc: Jonathan Kew; www-font; Håkon Wium Lie; www-style; Stephen Zilles; LTRU Working Group; Adam Twardoch (List) > Subject: Re: [Ltru] font features in CSS > > > 2009/10/30 "Martin J. Dürst"> > > (OT) (ISO) > Chinese Hong Kong ZHH zho > Chinese Phonetic ZHP zho > Chinese Simplified ZHS zho > Chinese Traditional ZHT zho > > > > you are comparing apples and oranges ,as the expression goes. The ISO language codes and BCP47 are about languages. Well, it's more like oranges and mandarines, as far as I understand. > The table from teh OT spec is NOT a language idfentifier. Yes. It's not the same. But it's close, and the question is how close, and whether we can and/or should make good use of that closeness. > It identifies what the OT spec refers to as a language system. According to the spec: > > "Language system tags identify the language systems supported in a OpenType Layout font. What is meant by a “language system” in this context is a set of typographic conventions for how text in a given script should be presented. Such conventions may be associated with particular languages, with particular genres of usage, with different publications, and other such factors." > > The language system tag could map to one language, to multiple languages, and in unexpected ways. Grouping commonalities in orthographic representation and typesetting traditions are the core aspect as far as I can tell, rather than language identification. We definitely have examples of variant tags distinguishing orthographic representations. There's a difference between orthographic variations (many if not most of which are observable in the encoded characters) and typographic variations (many if not most of which are not observable in the encoded characters). Nevertheless, there's a fuzzy boundary, depending among else on personal viewpoint and technology. Also, it should be pointed out that the main original motivation when introducing HTML lang (http://tools.ietf.org/html/rfc2070) and xml:lang was to distinguish typographic variations that were not expressible in Unicode. The first and foremost example that always came up was the distinction between Chinese (simplified and traditional), Japanese, and Korean glyphs of one and the same character. The example second in line, e.g. in talks at the Unicode Conference, is Serbic. So in some sense, we have come full circle: We are looking at whether the tags used in HTML lang and xml:lang, which were mainly introduced to distinguish typographic/glyph variants, can be used to do what OT "language systems" are doing, namely distinguish typographic variants. Of course, language tags have many other uses, too, such as selecting text-to-speech engines, selecting spelling checkers, and so on. And there have been discussions in the past about what to do for cases where one wants a French spell checker, German typographic conventions, and English text-to-speech conversion (to use a simplistic example). These may very well in the future lead so something like the example in c) above (:lang(mk) { typographic-convention-same-as: 'sr' }). In the past, they led to nothing because there was just not enough of a need for such cases. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From julian.reschke@gmx.de Mon Nov 2 10:04:14 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10133A6A51 for ; Mon, 2 Nov 2009 10:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyag4kEbK89T for ; Mon, 2 Nov 2009 10:04:13 -0800 (PST) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id AF25D3A6994 for ; Mon, 2 Nov 2009 10:04:13 -0800 (PST) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009110210042422503 ; Mon, 02 Nov 2009 10:04:24 -0800 Received: from [10.0.62.24] ([10.0.62.24]) by s-utl01-sjpop.stsn.net; Mon, 2 Nov 2009 10:04:23 -0800 Message-ID: <4AEF1F1C.10408@gmx.de> Date: Mon, 02 Nov 2009 19:04:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Phillips, Addison" References: <48037FF9.9030103@gmx.de> <48049274.3090501@gmx.de> <4A61B8B7.7030200@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843B4F@EX-SEA5-D.ant.amazon.com> <4A61F5C2.3050906@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843BEE@EX-SEA5-D.ant.amazon.com> <4A6D9396.5020506@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D45E@EX-SEA5-D.ant.amazon.com> <20090727173222.GF32524@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D6D6@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D6D6@EX-SEA5-D.ant.amazon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group , HTTP Working Group Subject: Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 18:04:14 -0000 Phillips, Addison wrote: >> Phillips, Addison scripsit: >> >>> I tend to think that HTTP's requirements are most like what the >>> Lookup algorithm provides. That is, you can (and must) return >>> exactly one result for a given request. >> Actually, no; that's an oversimplification of HTTP. > > Well... what I was trying to say was "HTTP is most commonly used in a way that I think works better with Lookup". That is, most typically, HTTP is used to return a single resource at the end of a URI. I'm well aware that there are other cases, including the 300 case, which is why I went on to say the rest of what I said :-). > > This is also why I didn't suggest that we merely replace filtering with lookup. I do think that the most common use of HTTP involves returning a single information object for a single request and, in the case where language negotiation is done at all, these typically fit Lookup more closely than Basic Filtering. A significant subset fit Basic Filtering better. And a different significant subset happen to use Basic Filtering (even if Lookup would have been a better choice) simply because 2616 said to. > >> The question is, then, what to do if there is no resource that >> specifies >> those minimum requirements. Apache in this case applies the lookup >> algorithm >> to loosen the client requirement in hopes of finding something >> usable. >> > > Yes, and this is neither "Basic Filtering" nor "Lookup". Similarly, implementations sometimes make use of outside information (Mark Davis's example of Breton falling back to French, for example). And so forth. The problem, as I see it, is that over-specificity in HTTPbis might lead implementers astray and we really need a more comprehensive treatment of language negotiation so that folks can choose wisely. > > Addison Several of us just met at the W3C TPAC, and we produced the following proposal (this is the full text for the Accept-Language definition): -- snip -- 5.4. Accept-Language The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Language tags are defined in Section 2.4. Accept-Language = "Accept-Language" ":" OWS Accept-Language-v Accept-Language-v = 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) language-range = Each language-range can be given an associated quality value which represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example, Accept-Language: da, en-gb;q=0.8, en;q=0.7 would mean: "I prefer Danish, but will accept British English and other types of English." (see also Section 2.3 of [RFC4647]) For matching, Section 3 of [RFC4647] defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. Note: the "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is identical to the matching scheme that was previously defined in Section 14.4 of [RFC2616]. It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic preferences of the user in every request. For a discussion of this issue, see Section 7.1. As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field MUST NOT be given in the request. Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior. -- snip -- The change is that the definition of matching is now delegated to RFC 4647, and we just mention that the "Basic Filtering" scheme is identical to what RFC 2616 used to say. See also for the proposed change as a diff from the text in -08. Feedback appreciated, Julian From julian.reschke@gmx.de Mon Nov 2 10:20:26 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028D828C104 for ; Mon, 2 Nov 2009 10:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOHOGXQ4+n7z for ; Mon, 2 Nov 2009 10:20:25 -0800 (PST) Received: from s-utl02-sjpop.stsn.net (s-utl02-sjpop.stsn.net [72.254.0.202]) by core3.amsl.com (Postfix) with SMTP id 085FF28C0E4 for ; Mon, 2 Nov 2009 10:20:25 -0800 (PST) Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2009110210203603755 ; Mon, 02 Nov 2009 10:20:36 -0800 Received: from [10.0.61.130] ([10.0.61.130]) by s-utl02-sjpop.stsn.net; Mon, 2 Nov 2009 10:20:36 -0800 Message-ID: <4AEF22E9.5060200@gmx.de> Date: Mon, 02 Nov 2009 19:20:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Phillips, Addison" References: <48037FF9.9030103@gmx.de> <48049274.3090501@gmx.de> <4A61B8B7.7030200@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843B4F@EX-SEA5-D.ant.amazon.com> <4A61F5C2.3050906@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843BEE@EX-SEA5-D.ant.amazon.com> <4A6D9396.5020506@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D45E@EX-SEA5-D.ant.amazon.com> <20090727173222.GF32524@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D6D6@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D6D6@EX-SEA5-D.ant.amazon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: LTRU Working Group , HTTP Working Group Subject: Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 18:20:26 -0000 Phillips, Addison wrote: >> Phillips, Addison scripsit: >> >>> I tend to think that HTTP's requirements are most like what the >>> Lookup algorithm provides. That is, you can (and must) return >>> exactly one result for a given request. >> Actually, no; that's an oversimplification of HTTP. > > Well... what I was trying to say was "HTTP is most commonly used in a way that I think works better with Lookup". That is, most typically, HTTP is used to return a single resource at the end of a URI. I'm well aware that there are other cases, including the 300 case, which is why I went on to say the rest of what I said :-). > > This is also why I didn't suggest that we merely replace filtering with lookup. I do think that the most common use of HTTP involves returning a single information object for a single request and, in the case where language negotiation is done at all, these typically fit Lookup more closely than Basic Filtering. A significant subset fit Basic Filtering better. And a different significant subset happen to use Basic Filtering (even if Lookup would have been a better choice) simply because 2616 said to. > >> The question is, then, what to do if there is no resource that >> specifies >> those minimum requirements. Apache in this case applies the lookup >> algorithm >> to loosen the client requirement in hopes of finding something >> usable. >> > > Yes, and this is neither "Basic Filtering" nor "Lookup". Similarly, implementations sometimes make use of outside information (Mark Davis's example of Breton falling back to French, for example). And so forth. The problem, as I see it, is that over-specificity in HTTPbis might lead implementers astray and we really need a more comprehensive treatment of language negotiation so that folks can choose wisely. > > Addison Several of us just met at the W3C TPAC, and we produced the following proposal (this is the full text for the Accept-Language definition): -- snip -- 5.4. Accept-Language The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Language tags are defined in Section 2.4. Accept-Language = "Accept-Language" ":" OWS Accept-Language-v Accept-Language-v = 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) language-range = Each language-range can be given an associated quality value which represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example, Accept-Language: da, en-gb;q=0.8, en;q=0.7 would mean: "I prefer Danish, but will accept British English and other types of English." (see also Section 2.3 of [RFC4647]) For matching, Section 3 of [RFC4647] defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. Note: the "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is identical to the matching scheme that was previously defined in Section 14.4 of [RFC2616]. It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic preferences of the user in every request. For a discussion of this issue, see Section 7.1. As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field MUST NOT be given in the request. Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior. -- snip -- The change is that the definition of matching is now delegated to RFC 4647, and we just mention that the "Basic Filtering" scheme is identical to what RFC 2616 used to say. See also for the proposed change as a diff from the text in -08. Feedback appreciated, Julian From lang.support@gmail.com Tue Nov 3 15:24:02 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE28C3A68F3 for ; Tue, 3 Nov 2009 15:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+rBeeyDhn3G for ; Tue, 3 Nov 2009 15:24:02 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id E6CDF3A6864 for ; Tue, 3 Nov 2009 15:24:01 -0800 (PST) Received: by pxi1 with SMTP id 1so4825748pxi.32 for ; Tue, 03 Nov 2009 15:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jMCJlx/NmlqgVcCOGcodsISzqVx4brQAwY/0mlrXZpU=; b=WAqoQ9yOMIE9eu70Z1aa+OEHhuiGBStcsgMZU60Z6uTOGew6NzfO0HFt0FGDK2SwMX jSvvvrwsSujbu2JqnsEzPZtrsKrMhlxeIjHctTLKehBBzVd9sJ5LtAD/AgZPtkU+7dEO zwMHNT13IGKGThJGQEYUS0TZLbyKcMpNkTdkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kCqSaarx62HJ1hCKOLKCSkNAdL0OARdyVhzkdXSISQQcDNFFhW/DY/zMRhpuR5tPLq WzOTHmm4weqINMMfBpfomZ7MbuWkv9N08Bb3la4UJL0DkIao9CTSXy1bG5fWrUXvZEhv jhs5lUn8VvYveyHSvqF+UnuVbZEuoZ1HkJS8o= MIME-Version: 1.0 Received: by 10.140.126.7 with SMTP id y7mr35739rvc.103.1257290660734; Tue, 03 Nov 2009 15:24:20 -0800 (PST) In-Reply-To: <4AEEAB47.7060708@it.aoyama.ac.jp> References: <19173.46660.701817.726727@gargle.gargle.HOWL> <49CB1917-6A69-448A-B619-644F8730940C@jfkew.plus.com> <4AEA91E9.4020708@twardoch.com> <4AEAB1E3.50305@it.aoyama.ac.jp> <9d70cb000910301502se5053c5qbfa3562dbcbd850a@mail.gmail.com> <4AEEAB47.7060708@it.aoyama.ac.jp> Date: Wed, 4 Nov 2009 10:24:20 +1100 Message-ID: <9d70cb000911031524s4625d144g1b5d00c586778c9f@mail.gmail.com> From: Andrew Cunningham To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=000e0cd28b3c36682004777fcb2b Cc: Jonathan Kew , www-font , =?UTF-8?Q?H=C3=A5kon_Wium_Lie?= , www-style , Stephen Zilles , LTRU Working Group , "Adam Twardoch \(List\)" Subject: Re: [Ltru] font features in CSS X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 23:24:03 -0000 --000e0cd28b3c36682004777fcb2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll start by saying that I tend to work with lesser used languages on the Web, and my comments will reflect what I see as their needs. 2009/11/2 "Martin J. D=C3=BCrst" > > The more interesting question is how to deal with Macedonian, assuming th= at > Macedonian uses the same typographic conventions and variants as Serbian. > There are several possibilities: > > a) Browsers automatically activate the "SRB" "language system" for texts > labeled lang=3D'mk' (or mk-*) > > b) There's a way in CSS to say: use "SRB" for this text. The selector par= t > already exists, the question is just how to create the property part, and > where to allow it (@font-face and/or general rules). This could look > something like: > :lang(mk) { opentype-language-system: 'SRB' } > > c) Same as b), but without exposing OT tags, essentially saying: Use the > same conventions as for Serbian. This could look something like: > :lang(mk) { typographic-convention-same-as: 'sr' } > (property names are overly long and descriptive on purpose; instead of 's= r' > in the above example, 'sr-Cyrl' may be more appropriate) > > I'd argue that b) is a better option. Its easy to see what language systems individual fonts use, whereas c) is dependant on the web browsers implementing very comprehensive data sets. They will need to know about macrolanguages and language collections. The data they'd have to implement would need to be more complete that what is published in the OT spec. For example there is the language system Karen (KRN/kar), and web browsers would need to know that kar is a language collection, and what languages fall into that collection. Assuming that all Karen languages can share an O= T language system. Then there are all the languages that are covered by BCP47 that have no defined OT language system but may be able to use an existing language system instead. I'd even suggest that for a range of languages just indicating a language system in CSS is not enough. For deploying minority language content on the web suing a font like Charis SIL, currently we have to resort to recompilin= g the font with different default features to get it working as we need in we= b browsers. I currently have four versions of the font in use. Being able to specify which OT language system a font should use is critical, but insufficient by itself. There is also a need to be able to specify specific alternative glyphs and be able to control various features in the OT font in order to be adequatel= y able to support minority languages. The advantages of c) over b) would be that it is less dependent on a > specific font technology, and it may be easier on the users, who don't ha= ve > to learn yet one more kind of tag. c) isn't scalable; and b) by itself isn't fully scalable. Personally, I think adding additional connect to the IANA registry to make the system workable would be a huge task. >From the point of scaleability, CSS extensions that would allow 1) to specify the language system and language script AND 2) the ability to control/specify specifc alternatives and features within specific opentype fonts would be crucial to minority language support. Andrew --=20 Andrew Cunningham Vicnet Research and Development Coordinator State Library of Victoria Australia andrewc@vicnet.net.au lang.support@gmail.com --000e0cd28b3c36682004777fcb2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll start by saying that I tend to work with lesser used languages on = the Web, and my comments will reflect what I see as their needs.

2009/11/2 "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac= .jp>

The more interesting question is how to deal with Macedonian, assuming that= Macedonian uses the same typographic conventions and variants as Serbian. = There are several possibilities:

a) Browsers automatically activate the "SRB" "language syste= m" for texts labeled lang=3D'mk' (or mk-*)

b) There's a way in CSS to say: use "SRB" for this text. The = selector part already exists, the question is just how to create the proper= ty part, and where to allow it (@font-face and/or general rules). This coul= d look something like:
:lang(mk) { opentype-language-system: 'SRB' }

c) Same as b), but without exposing OT tags, essentially saying: Use the sa= me conventions as for Serbian. This could look something like:
:lang(mk) { typographic-convention-same-as: 'sr' }
(property names are overly long and descriptive on purpose; instead of '= ;sr' in the above example, 'sr-Cyrl' may be more appropriate)

I'd argue that b) is a better option. Its eas= y to see what language systems individual fonts use, whereas c) is dependan= t on the web browsers implementing very comprehensive data sets. They will = need to know about macrolanguages and language collections. The data they&#= 39;d have to implement would need to be more complete that what is publishe= d in the OT spec.

For example there is the language system Karen (KRN/kar), and web brows= ers would need to know that kar is a language collection, and what language= s fall into that collection. Assuming that all Karen languages can share an= OT language system.

Then there are all the languages that are covered by BCP47 that have no= defined OT language system but may be able to use an existing language sys= tem instead.

I'd even suggest that for a range of languages just indicatin= g a language system in CSS is not enough. For deploying minority language c= ontent on the web suing a font like Charis SIL, currently we have to resort= to recompiling the font with different default features to get it working = as we need in web browsers. I currently have four versions of the font in u= se. Being able to specify which OT language system a font should use is cri= tical, but insufficient by itself.

There is also a need to be able to specify specific alternative glyphs = and be able to control various features in the OT font in order to be adequ= ately able to support minority languages.


The advantages of c) over b) would be that it is less dependent on a specif= ic font technology, and it may be easier on the users, who don't have t= o learn yet one more kind of tag.
=C2=A0
c) isn't s= calable; and b) by itself isn't fully scalable.
=C2=A0
Personally, I think adding additional connect t= o the IANA registry to make the system workable would be a huge task.
From the point of scaleability, CSS extensions that would allow 1) to spe= cify the language system and language script AND 2) the ability to control/= specify specifc alternatives and features within specific opentype fonts wo= uld be crucial to minority language support.


Andrew
--
Andrew Cunningham
Vic= net Research and Development Coordinator
State Library of Victoria
Au= stralia

andrewc@vicnet.net.= au
lang.support@gmail.com
--000e0cd28b3c36682004777fcb2b-- From julian.reschke@gmx.de Sat Nov 7 08:56:51 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5B83A67F2 for ; Sat, 7 Nov 2009 08:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqpCYM+rVkM9 for ; Sat, 7 Nov 2009 08:56:50 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8BFF73A67A6 for ; Sat, 7 Nov 2009 08:56:49 -0800 (PST) Received: (qmail invoked by alias); 07 Nov 2009 16:57:11 -0000 Received: from c-71-202-223-16.hsd1.ca.comcast.net (EHLO [192.168.0.143]) [71.202.223.16] by mail.gmx.net (mp065) with SMTP; 07 Nov 2009 17:57:11 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18PyMQRMs0PDPLlGT1qPqSsALTBBlghAgNftE+WgV jJ0mVBtXN/dC0T Message-ID: <4AF5A6E2.8000300@gmx.de> Date: Sat, 07 Nov 2009 17:57:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: LTRU Working Group , HTTP Working Group References: <48037FF9.9030103@gmx.de> <48049274.3090501@gmx.de> <4A61B8B7.7030200@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843B4F@EX-SEA5-D.ant.amazon.com> <4A61F5C2.3050906@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843BEE@EX-SEA5-D.ant.amazon.com> <4A6D9396.5020506@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D45E@EX-SEA5-D.ant.amazon.com> <20090727173222.GF32524@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D6D6@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D6D6@EX-SEA5-D.ant.amazon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Subject: Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 16:56:51 -0000 (resending a mail I sent last Monday, but apparently got lost on the way to the mailing lists) Phillips, Addison wrote: >> Phillips, Addison scripsit: >> >>> I tend to think that HTTP's requirements are most like what the >>> Lookup algorithm provides. That is, you can (and must) return >>> exactly one result for a given request. >> Actually, no; that's an oversimplification of HTTP. > > Well... what I was trying to say was "HTTP is most commonly used in a way that I think works better with Lookup". That is, most typically, HTTP is used to return a single resource at the end of a URI. I'm well aware that there are other cases, including the 300 case, which is why I went on to say the rest of what I said :-). > > This is also why I didn't suggest that we merely replace filtering with lookup. I do think that the most common use of HTTP involves returning a single information object for a single request and, in the case where language negotiation is done at all, these typically fit Lookup more closely than Basic Filtering. A significant subset fit Basic Filtering better. And a different significant subset happen to use Basic Filtering (even if Lookup would have been a better choice) simply because 2616 said to. > >> The question is, then, what to do if there is no resource that >> specifies >> those minimum requirements. Apache in this case applies the lookup >> algorithm >> to loosen the client requirement in hopes of finding something >> usable. >> > > Yes, and this is neither "Basic Filtering" nor "Lookup". Similarly, implementations sometimes make use of outside information (Mark Davis's example of Breton falling back to French, for example). And so forth. The problem, as I see it, is that over-specificity in HTTPbis might lead implementers astray and we really need a more comprehensive treatment of language negotiation so that folks can choose wisely. > > Addison Several of us just met at the W3C TPAC, and we produced the following proposal (this is the full text for the Accept-Language definition): -- snip -- 5.4. Accept-Language The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Language tags are defined in Section 2.4. Accept-Language = "Accept-Language" ":" OWS Accept-Language-v Accept-Language-v = 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) language-range = Each language-range can be given an associated quality value which represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example, Accept-Language: da, en-gb;q=0.8, en;q=0.7 would mean: "I prefer Danish, but will accept British English and other types of English." (see also Section 2.3 of [RFC4647]) For matching, Section 3 of [RFC4647] defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. Note: the "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is identical to the matching scheme that was previously defined in Section 14.4 of [RFC2616]. It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic preferences of the user in every request. For a discussion of this issue, see Section 7.1. As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field MUST NOT be given in the request. Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior. -- snip -- The change is that the definition of matching is now delegated to RFC 4647, and we just mention that the "Basic Filtering" scheme is identical to what RFC 2616 used to say. See also for the proposed change as a diff from the text in -08. Feedback appreciated, Julian From doug@ewellic.org Sun Nov 8 18:59:59 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3FA3A6A4A for ; Sun, 8 Nov 2009 18:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilsbD2Bj3ArB for ; Sun, 8 Nov 2009 18:59:58 -0800 (PST) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by core3.amsl.com (Postfix) with SMTP id 557683A689A for ; Sun, 8 Nov 2009 18:59:58 -0800 (PST) Received: (qmail 853 invoked from network); 9 Nov 2009 03:00:21 -0000 Received: from unknown (24.8.55.39) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 09 Nov 2009 03:00:20 -0000 Message-ID: <9F0D665F823C480CBAB223CB1ECAE1AC@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 8 Nov 2009 20:00:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] font features in CSS X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:59:59 -0000 Andrew Cunningham wrote: >> b) There's a way in CSS to say: use "SRB" for this text. The selector >> part already exists, the question is just how to create the property >> part, and where to allow it (@font-face and/or general rules). This >> could look something like: >> :lang(mk) { opentype-language-system: 'SRB' } >> >> ... > > I'd argue that b) is a better option. Its easy to see what language > systems individual fonts use, whereas c) is dependant on the web > browsers implementing very comprehensive data sets. I'm no expert on this, which is probably obvious, but I'd be concerned about exposing CSS users to a "language system tags" mechanism which: (a) sounds like it has something to do with "language tags," but doesn't, (b) uses tag values which look like ISO 639 code elements or BCP 47 tags, but aren't, and (c) pertains to a specific font technology which is not a required part of CSS or HTML. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ­ From julian.reschke@gmx.de Tue Nov 10 05:46:59 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8769B3A6AC4 for ; Tue, 10 Nov 2009 05:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.667 X-Spam-Level: X-Spam-Status: No, score=-3.667 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vogE7QWJdcid for ; Tue, 10 Nov 2009 05:46:58 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D9F7B3A6ABF for ; Tue, 10 Nov 2009 05:46:57 -0800 (PST) Received: (qmail invoked by alias); 10 Nov 2009 13:47:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp064) with SMTP; 10 Nov 2009 14:47:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+TZy4MBiiTf9r7IYh9kyfG11H2vvvb9ecQ9mv6ZZ lwXnPbBMeJlY3H Message-ID: <4AF96EE3.2050206@gmx.de> Date: Tue, 10 Nov 2009 14:47:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: LTRU Working Group , HTTP Working Group References: <48037FF9.9030103@gmx.de> <48049274.3090501@gmx.de> <4A61B8B7.7030200@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843B4F@EX-SEA5-D.ant.amazon.com> <4A61F5C2.3050906@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AB843BEE@EX-SEA5-D.ant.amazon.com> <4A6D9396.5020506@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D45E@EX-SEA5-D.ant.amazon.com> <20090727173222.GF32524@mercury.ccil.org> <4D25F22093241741BC1D0EEBC2DBB1DA01ABD5D6D6@EX-SEA5-D.ant.amazon.com> <4AF5A6E2.8000300@gmx.de> In-Reply-To: <4AF5A6E2.8000300@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Subject: Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:46:59 -0000 Julian Reschke wrote: > ... > The change is that the definition of matching is now delegated to RFC > 4647, and we just mention that the "Basic Filtering" scheme is identical > to what RFC 2616 used to say. > > See also > > for the proposed change as a diff from the text in -08. > > Feedback appreciated, > > Julian > ... I just applied the proposed change with . Best regards (and thanks to LRTU for the input), Julian From alexey.melnikov@isode.com Wed Nov 25 15:39:20 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B923A6878 for ; Wed, 25 Nov 2009 15:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx4pAWN2U4E3 for ; Wed, 25 Nov 2009 15:39:20 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CC4AB3A6405 for ; Wed, 25 Nov 2009 15:39:19 -0800 (PST) Received: from [172.16.2.131] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 25 Nov 2009 23:39:13 +0000 Message-ID: <4B0DC001.6080906@isode.com> Date: Wed, 25 Nov 2009 23:38:41 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ltru@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ltru] Appointment of Language Subtag expert reviewers and WG closure X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:39:20 -0000 Hi WG, This is a delayed announcement that IESG has reappointed Michael Everson and Doug Ewell as expert reviewers for the registry governed by RFC 5646. IESG will review the appointment in 6 months. At this point I would like to congratulate the WG with successfully completing all WG milestones and to thank participants for their contributions over the years. Based on prior discussions on the mailing list about rechartering I see no consensus to recharter, so I would like to close the WG. This mailing list will remain open. Thank you, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From root@core3.amsl.com Mon Nov 30 10:30:02 2009 Return-Path: X-Original-To: ltru@ietf.org Delivered-To: ltru@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 073FE28C15D; Mon, 30 Nov 2009 10:30:01 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091130183002.073FE28C15D@core3.amsl.com> Date: Mon, 30 Nov 2009 10:30:01 -0800 (PST) Cc: ltru@ietf.org Subject: [Ltru] WG Action: Conclusion of Language Tag Registry Update (ltru) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 18:30:02 -0000 The Language Tag Registry Update (ltru) working group in the Applications Area has concluded. The IESG contact persons are Alexey Melnikov and Lisa Dusseault. The LTRU working group has successfully completed its deliverables and can now be closed. The ADs would like to thank everyone who participated in the work over the years. The mailing list will remain open. From bortzmeyer@nic.fr Mon Nov 30 13:49:17 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCC13A684C for ; Mon, 30 Nov 2009 13:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puDzUblaG4dP for ; Mon, 30 Nov 2009 13:49:16 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by core3.amsl.com (Postfix) with ESMTP id 62BDE3A68FD for ; Mon, 30 Nov 2009 13:49:16 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id DCE0494ED0; Mon, 30 Nov 2009 22:49:05 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id C3C5B157B6F; Mon, 30 Nov 2009 22:45:24 +0100 (CET) Date: Mon, 30 Nov 2009 22:45:24 +0100 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20091130214524.GA22879@laperouse.bortzmeyer.org> References: <20091130183002.073FE28C15D@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091130183002.073FE28C15D@core3.amsl.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 9.10 (karmic) User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Ltru] WG Action: Conclusion of Language Tag Registry Update (ltru) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:49:17 -0000 On Mon, Nov 30, 2009 at 10:30:01AM -0800, IESG Secretary wrote a message of 14 lines which said: > The Language Tag Registry Update (ltru) working group in the > Applications Area has concluded. So long, and thanks for all the fish. I learned a lot in this Working Group, specially that you should never despair: the RFC were finally done.