Subject: [Ltru] conformance requirements for matching

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Mar 2006 13:41:14 -0800

Hi -

As a WG chair and as an I-D author / editor I know how frustrating
very general comments can be, but, as a technical contributor, I think
one is necessary in regard to the matching draft.

Specifically, it is very unclear to me just what an implementation
must do in order to conform to this specification.  A protocol specification
referencing this document needs to be able to specify (and parameterize)
a matching algorithm sufficiently well to ensure interoperability.

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.  I suggest providing a way for
documents referencing this specification to clearly identify the
algorithms to which they require conformance, along with any parameters
and options.

A related problem is the document's statement that "Implementations or
protocols MAY use different matching schemes from the ones described
in this document, as long as those mechanisms are clearly specified."
Taken at face value, this means that ANY application doing language
tag matching of some kind could claim conformnce to this specification,
as long as whatever matching scheme it used was clearly specified.
This would be absurd, and this text should be removed.

Randy

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 30 Mar 2006 14:12:58 -0800

> This would be absurd, and this text should be removed.

I have no problem with removing that text.

> 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? 

There are clearly a large number of potential applications that can use these schemes (ranging from language negotiation of web pages to applying styles to paragraphs to selecting content in a database). The actual protocol or application has to define how the scheme chosen works in the context of this higher level application of matching. Specifically, I'd refer you to Harald's comment:

   http://article.gmane.org/gmane.ietf.ltru/4180/match=protocol

(The text suggested in this message appears in Section 3.1)

Can you identify examples of what the problem is? I have no idea how we would address this.

> very general comments can be

Yeah. And you saved one for the last day of the Last Call too :-).

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: 2006年3月30日 13:41
> To: LTRU Working Group
> Subject: [Ltru] conformance requirements for matching
>

---

From: John Cowan <[email-masked]>
Date: Thu, 30 Mar 2006 17:31:52 -0500

> algorithms to which they require conformance, along with any parameters

I agree with Addison here: the names of the matching schemes suffice.

-- 
John Cowan  [email-masked]  www.ap.org  www.ccil.org/~cowan
Promises become binding when there is a meeting of the minds and consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today. 
       --Specht v. Netscape

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Mar 2006 15:22:35 -0800

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, March 30, 2006 2:31 PM
> Subject: Re: [Ltru] conformance requirements for matching
...
> I agree with Addison here: the names of the matching schemes suffice.
...

Presumably "Basic Filtering", "Extended Filtering", and "Lookup"?
Then the document should say that a conformant implementation
MUST implement at least one of these three, and that a specification
based on this one needs to identify it by the appropriate name.

This still leaves the question of identifying their respective options
or parameters.

Four examples of behavioural options I was able to find just by looking
for SHOULD and MAY in the text:
   Implementations that specify basic ranges MAY map extended language
   Implementations SHOULD ignore extensions and unrecognized private-use
   language ranges, it SHOULD be skipped.  If the language range "*" is
   range follows, the default content SHOULD be returned.

(BTW, talking about default "content" is really in the scope of an application
using these algorithms, and should only be mentioned here as an example,
if at all.)

The combination of the SHOULD/MAYs with the three schemes gives
quite a number of things to which implementations could claim conformance,
and provides no guidance to the referencing specification to identifying
which options are to be used. 

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Mar 2006 15:46:22 -0800

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; "'LTRU Working Group'" <[email-masked]>
> Sent: Thursday, March 30, 2006 2:12 PM
> Subject: RE: [Ltru] conformance requirements for matching
...
> There are clearly a large number of potential applications that can use
> these schemes (ranging from language negotiation of web pages to applying
> styles to paragraphs to selecting content in a database). The actual
> protocol or application has to define how the scheme chosen works in
> the context of this higher level application of matching. Specifically,
> I'd refer you to Harald's comment:
>

I agree with Harald's comment.

> (The text suggested in this message appears in Section 3.1)

It the spirit of his comment were pursued rigorously, I think we'd
have a much trimmer document with much clearer conformance requirements.

> Can you identify examples of what the problem is? I have no idea how we would address this.

See my other message on the MAY and SHOULDs that permit differing behaviour
that could potentially affect interoperability.  In general, any place where
we permit variation in behaviour that could affect interoperability needs
to be accounted for in the list of options.  We have a few ways to get rid of
the complexity, which we can employ alone or in combination to keep the
conformance requirements clear and avoid complexity:
    (1) define the difference in results as non-significant (implementations
        MUST NOT depend on the difference)
    (2) get rid of the option by making a particular choice mandatory
    (3) get rid of the option by making it the responsibility of something else,
        e.g., the application or protocol using the matching algorithm

Harald's suggested text uses technique (3).

> Yeah. And you saved one for the last day of the Last Call too :-).

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.

Randy

---

From: "Addison Phillips" <[email-masked]>
Date: Fri, 31 Mar 2006 16:30:04 -0800

> It's better to get the comment from me, now, than from an AD, the IESG,

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)

3. Section 3.3 (Lookup) has a fair bit of waffle about the handling of default content. This could all be removed by replacing the last sentence in the first paragraph with a new paragraph:

"If no content matches the request, the "default" content is returned. The application, protocol, or specification MUST specify the default content for a request, which MAY include returning an error condition, such as "not found"."

We can then tighten up the remaining content about default handling (implementations can still choose what the default content is, including having a default language).

Addison

Addison Phillips

> Sent: 2006年3月30日 15:46
> To: 'LTRU Working Group'

---

From: Mark Davis <[email-masked]>
Date: Fri, 31 Mar 2006 19:16:04 -0800

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