Matching of Language Tags
draft-ietf-ltru-matching-15

[Ballot discuss]
(from Gen-ART review by Elwyn Davies)

Assuming we are supposed to be using RFC4234 conventions throughout:
s2, para 3: s/%2A/%x2A/
s3.3.2, para 2 (Item 1.): s/%2D/%x2D/

[Ballot comment]
INTRODUCTION, paragraph 13:

>    selection.  This document, in combination with RFC 3066bis (Ed.:
>    replace "3066bis" with the RFC number assigned to
>    draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC
>    1766.

  Convert this comment from the document editor into an RFC Editor note.

1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes. The chairs have repeatedly reviewed the drafts, including this
version, and we firmly believe that this ID is ready for forwarding
to the IESG for publication.

                                                Which chair is the WG
        Chair Shepherd for this document?

That's Martin Duerst, duerst@it.aoyama.ac.jp.


  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes. Key outside reviewers included internationalization experts from W3C
and from the Unicode Consortium.

                                Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

No.


  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

No, not at all. Internationalization and XML concerns have been very well
covered due to the nature of the topic of the draft. Operational issues
(related to registry access) have been discussed and resolved, too.
Security issues (which relate more to the use of language tags as such
than to the definition of particular matching schemes) have been documented.

A list of issues brought up during the first and second WG Last Calls
and their disposition can be found at
http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/.


  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

There are no concerns about whether there is really a need for the
three matching schemes described in the draft. In earlier versions
of the draft, there were more matching schemes, and the question "is
there really a need for all of these" was quite legitimate. However,
the number of matching schemes has been reduced to what we think is
the minimum: a) Basic Filtering, as available already in RFC 3066 and
widely used, b) Extended Filtering, which addresses the need for
certain new kinds of matching due to the change from a tag registry
to a subtag registry in draft-ietf-ltru-registry-14, and c) Lookup,
which, although newly described in this document, is already implemented,
with slight variations, in some HTTP servers, language/locale resource
lookup schemes, and so on).

If there is any concern that I have personally, it is that I still
feel that in a few odd places, the language could be slightly more
polished. But I have to admit that I'm usually way more sensitive on
such editorial details than others.


  1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

I think it is fair to say that the WG as a whole understands and agrees
with the document, and that there is wide consensus. Even those members
of the WG that have mainly been interested and been working on the
-registry and -inital draft and are not totally familiar with every
minor detail of the -matching draft have read it and understand and
agree with the general direction.


  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

Yes. See separate mail.


  1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

Yes.


  1.h) Has the document split its references into normative and
        informative?

Yes.

                      Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?

No. On the contrary, there is draft-ietf-ltru-registry-14
(and draft-ietf-ltru-initial-06) which are already in the
RFC Editor queue but are held up by this draft.

                        The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publicatioin).  If the
        normative references are behind, what is the strategy for their
        completion?

No strategy needed.

                    On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]?

No.

                            Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "Action" announcements for approved documents.


Technical Summary

The document describes recommended practices for matching language
tags as defined in draft-ietf-ltru-registry-14 (customarily called
RFC3066bis) to user preferences. To express user preferences,
two types of syntax are used, called "Basic Language Range"
(allowing wildcards only as single characters) and
"Extended Language Range" (allowing wildcards as subtags).
Both Basic Language Ranges and Extended Language Ranges can
(and customarily are) used in lists which are called "Language
Priority Lists".

The document describes three different matching schemes.
The first matching scheme, Basic Filtering, matches (lists of)
Basic Language Ranges against (lists of) language tags, resulting
in a (possibly empty) list of matching language tags. This
matching scheme is identical to that described in RFC 3066.

The second matching scheme, Extended Filtering, matches (lists of)
Extended Language Ranges against (lists of) language tags, and
produces a (possibly empty) list of matching language tags.
This matching scheme takes into account that draft-ietf-ltru-registry
(RFC3066bis), in contrast to RFC3066, defines language tags by
using a *sub*tag registry.

The third matching scheme, Lookup, differs from filtering in that
it produces a single matching language tag, possibly by falling
back to some default. Lookup is therefore suitable for situations
where a single result that best matches user preferences is needed.
An example would be the generation of content from a data store.
Filtering is useful for situations where multiple results are
acceptable, such as searching matching documents or document
fragments with certain language tags, or applying certain
operations such as styling to document fragments.


Working Group Summary

This document is the second work item of the LTRU WG. A large part
of the work on this document was done after finishing the first
work item, which is currently draft-ietf-ltru-registry-14
(together with draft-ietf-ltru-initial-06). While in an intermediary
stage, the document contained a larger number of matching schemes,
some of which were not well defined, had too many options,
or were at best 'nice to have', the WG worked hard to reduce
the number of schemes to the necessary minimum.


Protocol Quality

Of the three language tag matching schemes described in the document,
Basic Filtering is already widely implemented. Various implementations
of Extended Filtering exist, but they are not yet widely deployed.
Implementations corresponding to Lookup also exist and are well used,
although not currently directly in IETF technology.