headers
Addison Phillips | 1 Apr 02:30
Picon
Favicon

RE: conformance requirements for matching

> This issue has been around for a while (as Harald's message attests).
> It's better to get the comment from me, now, than from an AD, the IESG,
> or in IETF last call.

Yes, I hear you. And I don't disagree with your reasoning. If the point is to generally describe some
matching schemes, I think we long ago achieved our purposes. If our goal is a thorough specification, then
your comments are probably correct. The problem is being specific about implementation details
(particularly in lookup) in areas in which the choice is not clear cut.

I've posted a new editor's copy, mid-stream in a rewrite of the extended filtering section, but with a
number of your suggested changes (plus some additional editing to remove waffle from the Lookup and
"choosing" sections). I have not dealt with the last two paras of Section 4.1 yet. Specific advice on
wording is most appreciated.

Of particular concern if we go down this track:

1. In Section 3.1 (Choosing a Type of Matching), we permit implementations to not enforce
validity/well-formedness on tags or ranges. My first inclination was to require this ("MUST NOT depend
on valid/well-formed") for ranges, but the following text provides problems for this:

2. In the following paragraph, we permit implementations to canonicalize ranges/tags and to use external
information ('nb'->'no', for example) to "inform" the choices made in matching. This is the exact
opposite of #1, since canonicalization requires the registry and presumably a validating processor. I
think the answer here is:

   a. MUST NOT depend on valid/well-formed ranges
   b. if validity checking is done, MUST canonicalize
   c. whether or not validity checking is done, MAY use external information (RFC2616 already suggests that
this is permitted)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Davis | 1 Apr 05:06
Favicon

Re: some editorial comments from Randy

mark.davis <at> macchiato.com

I don't mind scrapers; with a whitelist and *extremely* aggressive spam filters I'm not bothered much.

Mark

Addison Phillips wrote:
> Comments follow.
>
> Addison Phillips
> Internationalization Architect - Yahoo! Inc.
>
> Internationalization is an architecture.
> It is not a feature. 
>
>   
>> -----Original Message-----
>> From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com]
>> Sent: 2006年3月30日 13:20
>> To: LTRU Working Group
>> Subject: [Ltru] some editorial comments from Randy
>>
>> Hi -
>>
>> Here are a few editorial comments I have as a technical contributor
>> on draft-ietf-ltru-matching-11.txt.  I'll be sending technical
>> comments separately.
>>
>>
>> Editorial
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Davis | 1 Apr 05:16
Favicon

Re: conformance requirements for matching

I disagree with the wholesale removal. I think it is perfectly 
reasonable for someone to claim conformance with additional 
qualifications. That is done in quite a few other specifications.

For example, I think it is perfectly reasonable to state the following.

The implementation is conformant to RFC xxx Lookup, with the following 
extensions:
- default content matches the default locale as specified in 
setDefaultLocale()
- closely related variants, such as no, nn, nb, fallback to each other 
first, before resorting to the default content. The exact mapping is 
found with getVariantFallbacks().

Mark

Addison Phillips wrote:
>> This would be absurd, and this text should be removed.
>>     
>
> I have no problem with removing that text.
>
>   
>> In its current form, it's not even clear how a protocol specification
>> referencing this document is supposed to identify the portions of the
>> matching specification it employs.
>>     
>
> This I don't understand. There are three mechanisms. They are clearly named and identified. What would
you suggest we do differently in the text to make implementation decisions clear?
(Continue reading)

Permalink | Reply | 10 comments |
headers
Mark Davis | 1 Apr 05:17
Favicon

Re: Re: WG last call for draft-ietf-ltru-matching

+1
>
> I tend to agree with the second comment, although I note that the section on
> Lookup actually has a normative SHOULD recommending this. Might I suggest:
>
> --
> <xref target="lookup">Lookup</xref> implementations are advised to ignore 
> unrecognized private-use and extension subtags when performing language tag
> fallback.
> --
>
>
>
Permalink | Reply | 0 comments |
headers
Addison Phillips | 1 Apr 20:33
Picon
Favicon

RE: conformance requirements for matching

> I disagree with the wholesale removal. I think it is perfectly
> reasonable for someone to claim conformance with additional
> qualifications. That is done in quite a few other specifications.

I agree (although maybe we were discussing different text?!?), but think the problem is trying to rework
the text as it stands rather than spell out implementation-chosen detail. The problem with the current
text is that it makes interoperability more difficult. The text currently says:

--
The types of matching in this document are designed so that implementations are not required to validate or
understand any of the semantics of the language tags or ranges or of the subtags in them. None of them
require access to the IANA Language Subtag Registry (see Section 3 in [RFC3066bis]). This simplifies
implementation. Applications, protocols, or specifications MUST NOT depend on the language ranges
being "well-formed" or "valid" (see [RFC3066bis], Section 2.2.9).

Regardless of the matching scheme chosen, protocols and implementations MAY canonicalize language tags
and ranges by mapping grandfathered and obsolete tags or subtags into modern equivalents. If an
implementation canonicalizes either ranges or tags, then the implementation will require the IANA
Language Subtag Registry information for that purpose. Implementations MAY also use semantic
information external to the registry when matching tags. For example, the primary language subtags 'nn'
(Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) might both be usefully matched to the more general
subtag 'no' (Norwegian). Or an implementation might infer that content labeled "zh-Hans" (Chinese as
written in the Simplified script) is more likely to match the range "zh-CN" (Chinese as used in China,
where the Simplified script is predominant) than equivalent content labeled "zh-TW" (Chinese as used in
Taiwan, where the Traditional script is predominant).
--

Instead of this, I propose:

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Presuhn | 2 Apr 02:57
Picon

Re: conformance requirements for matching

Hi -

> From: "Mark Davis" <mark.davis <at> icu-project.org>
> To: "Addison Phillips" <addison <at> yahoo-inc.com>
> Cc: "'Randy Presuhn'" <randy_presuhn <at> mindspring.com>; "'LTRU Working Group'" <ltru <at> ietf.org>
> Sent: Friday, March 31, 2006 7:16 PM
> Subject: Re: [Ltru] conformance requirements for matching
>
> I disagree with the wholesale removal. I think it is perfectly 
> reasonable for someone to claim conformance with additional 
> qualifications. That is done in quite a few other specifications.
> 
> For example, I think it is perfectly reasonable to state the following.
> 
> The implementation is conformant to RFC xxx Lookup, with the following 
> extensions:
> - default content matches the default locale as specified in 
> setDefaultLocale()
> - closely related variants, such as no, nn, nb, fallback to each other 
> first, before resorting to the default content. The exact mapping is 
> found with getVariantFallbacks().
...

But the current text isn't just about extensions. Section three says:

   There are several types of matching scheme.  This document presents
   two types: those that produce zero or more information items (called
   "filtering") and those that produce a single information item for a
   given request (called "lookup").
(Continue reading)

Permalink | Reply | 8 comments |
headers
Addison Phillips | 3 Apr 22:17
Picon
Favicon

RE: conformance requirements for matching

Okay... in the interest of expediency, I have implemented a bunch of edits in the Editor's copy of draft-12
in an attempt to bring both sides of this discussion together. I tried to quote them all in an email, but the
rewrites involved a lot of paragraphs of text. It is easier to view the diff and see what I changed.

http://www.inter-locale.com/ID/matching-diff-11-12.html

The notable differences are:

1. Insertion of the "seems to imply" text into Section 2.1

2. A complete rewrite of the text describing the mapping of extended language ranges to basic ones in
Section 2.2

3. Upgrading of SHOULD to MUST in conformance requirements and elimination of the text allowing
unspecified algorithms to be used in Section 3.0

4. A total rewrite of the material about canonicalization of tags/ranges and understanding the semantics
of language tags in Section 3.1

5. A full rewrite of Section 3.2.2 (Extended Filtering) to include a step-by-step algorithm.

6. Insertion of Martin's text at the end of 3.2.2

7. A number of changes to Section 3.3 (Lookup) to make the return of default content a requirement and to be
specific that implementations specify what the content is and how it is arrived at.

8. A rewrite of the text on extensions in Section 3.3 to make it more specific.

9. Removed the SHOULDs in the paragraph about the range "*" in Section 3.3 (this makes the specified
behavior obligatory).
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Cowan | 3 Apr 22:26

Re: conformance requirements for matching

Addison Phillips scripsit:

> Okay... in the interest of expediency, I have implemented a bunch of
> edits in the Editor's copy of draft-12 in an attempt to bring both
> sides of this discussion together. I tried to quote them all in an
> email, but the rewrites involved a lot of paragraphs of text. It is
> easier to view the diff and see what I changed.

+1.  I have no further comments.

--

-- 
The experiences of the past show                John Cowan
that there has always been a discrepancy        cowan <at> ccil.org
between plans and performance.                  http://www.ap.org
        --Emperor Hirohito, August 1945         http://www.ccil.org/~cowan
Permalink | Reply | 0 comments |
headers
Mark Davis | 4 Apr 00:22
Favicon

Re: conformance requirements for matching

This might be an artifact of the diff, but looks like a typo.

 > (see: ).

Other than that, I like the rewrite. +1
Mark

Addison Phillips wrote:
> Okay... in the interest of expediency, I have implemented a bunch of edits in the Editor's copy of draft-12
in an attempt to bring both sides of this discussion together. I tried to quote them all in an email, but the
rewrites involved a lot of paragraphs of text. It is easier to view the diff and see what I changed.
>
> http://www.inter-locale.com/ID/matching-diff-11-12.html
>
> The notable differences are:
>
> 1. Insertion of the "seems to imply" text into Section 2.1
>
> 2. A complete rewrite of the text describing the mapping of extended language ranges to basic ones in
Section 2.2
>
> 3. Upgrading of SHOULD to MUST in conformance requirements and elimination of the text allowing
unspecified algorithms to be used in Section 3.0
>
> 4. A total rewrite of the material about canonicalization of tags/ranges and understanding the
semantics of language tags in Section 3.1
>
> 5. A full rewrite of Section 3.2.2 (Extended Filtering) to include a step-by-step algorithm.
>
> 6. Insertion of Martin's text at the end of 3.2.2
(Continue reading)

Permalink | Reply | 1 comment |
headers
Addison Phillips | 4 Apr 01:08
Picon
Favicon

RE: conformance requirements for matching

> This might be an artifact of the diff, but looks like a typo.
> 
>  > (see: ).

Good catch.

It's a typo: the format attribute of the xref is set to "none" instead of "default" or "title". I've fixed it
in my local copy and will post it when I get a chance later tonight.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Mark Davis [mailto:mark.davis <at> icu-project.org]
> Sent: 2006年4月3日 15:23
> To: Addison Phillips
> Cc: 'Randy Presuhn'; 'LTRU Working Group'
> Subject: Re: [Ltru] conformance requirements for matching
> 
> This might be an artifact of the diff, but looks like a typo.
> 
>  > (see: ).
> 
> Other than that, I like the rewrite. +1
> Mark
(Continue reading)

Permalink | Reply | 0 comments |

Gmane