Re: font features in CSS

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

Re: Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

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.

Re: Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

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.

Re: font features in CSS

Re: Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

(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    =
                <language-range, defined in [RFC4647], Section 2.1>

    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 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/181/181.diff> 
for the proposed change as a diff from the text in -08.

Feedback appreciated,

Julian

Re: font features in CSS

Andrew Cunningham <lang dot support at gmail dot com> 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 ­

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Re: Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

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 
> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/181/181.diff> 
> for the proposed change as a diff from the text in -08.
> 
> Feedback appreciated,
> 
> Julian
> ...

I just applied the proposed change with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/724>.

Best regards (and thanks to LRTU for the input), Julian

Appointment of Language Subtag expert reviewers and WG closure

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, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

WG Action: Conclusion of Language Tag Registry Update (ltru)

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.

Re: WG Action: Conclusion of Language Tag Registry Update (ltru)

On Mon, Nov 30, 2009 at 10:30:01AM -0800,
 IESG Secretary <iesg-secretary <at> ietf.org> 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.