Subject: [Ltru] RE: submission: draft-ietf-ltru-matching #09

From: "Addison Phillips" <[email-masked]>
Date: Tue, 7 Feb 2006 13:20:34 -0800

Dear Editor,

Please find attached the corrected draft #9 (I previously forgot to change
the year to 2006 from 2005) of draft-ietf-ltru-matching.

Best Regards,

Addison (for the editors)

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 07, 2006 1:10 PM
> To: Addison Phillips
> Subject: Re: submission: draft-ietf-ltru-matching #09
> 
> The Secretariat CANNOT process your Internet-Draft submission due to
> following reason(s):
> 
>  * All Internet-Drafts must include the following statement:
> 
> Copyright (C) The Internet Society (2006).
> 
> 
> 
> > Dear Editor,
> >
> > Please find attached draft #9 of draft-ietf-ltru-matching in text
format.
> > Fenner's ABNF validator and idnits both ran clean against it.
> >
> > Addison (for the editors)
> >
> > Addison Phillips
> > Internationalization Architect - Yahoo! Inc.
> >
> > Internationalization is an architecture.
> > It is not a feature.
> >
> >
> 

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

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 7 Feb 2006 13:38:45 -0800

... and it helps if I attach the *right one*.

Addison

Addison Phillips

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Addison Phillips
> Sent: Tuesday, February 07, 2006 1:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ltru] RE: submission: draft-ietf-ltru-matching #09
> 
> Dear Editor,
>

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Feb 2006 23:22:43 +0100

Addison Phillips wrote:

> it helps if I attach the *right one*.

:-)  See below for an old-fashioned plain "diff"
based on xml2rfc unpaginated output, I still got
a "February 2005" edition of the XML source.  Bye

6c6
< Internet-Draft                                            Quest Software
---
> Internet-Draft                                                Yahoo! Inc
8,9c8,9
< Expires: June 10, 2006                                               IBM
<                                                         December 7, 2005
---
> Expires: August 10, 2005                                          Google
>                                                         February 6, 2005
13c13
<                       draft-ietf-ltru-matching-08
---
>                       draft-ietf-ltru-matching-09
38c38
<    This Internet-Draft will expire on June 10, 2006.
---
>    This Internet-Draft will expire on August 10, 2005.
111,113c111,113
<    implement a matching scheme either need to choose a particular option
<    or indicate that the particular options is left to the specific
<    implementation to decide.
---
>    implement a matching scheme either need to specify each particular
>    choice or indicate the options that are left to the implementation to
>    decide.
147a148,153
>    Language ranges are similar in structure and content to language
>    tags: they consist of alphanumeric "subtags" separated by hyphens,
>    plus a special subtag consisting of the character "*" (%2A,
>    ASTERISK), which is used in ranges as a "wildcard", that is, a value
>    that matches any subtag.
>
159c165
<    language range is defined by the following the ABNF[RFC4234]:
---
>    language range is defined by the following ABNF[RFC4234]:
198,199c204,205
<                  / privateuse              ; private-use tag
<                  / grandfathered           ; grandfathered registrations
---
>                  / privateuse       ; a private-use range
>                  / grandfathered    ; a grandfathered registration
211c217
<                  / "*"                    ; ... or wildcard
---
>                  / "*"                    ; or wildcard
223c229
<                  / "*"                    ; ... or wildcard
---
>                  / "*"                    ; or wildcard
227c233
<                  / "*"                    ; ... or wildcard
---
>                  / "*"                    ; or wildcard
234,235c240,241
<    singleton     = "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
<                  ; Single letters: x/X is reserved for private use
---
>    singleton     = "a" - "w" / "y" - "z" / DIGIT
>                  ; single characters, "x" is reserved for private use
237c243
<    privateuse    = ("x"/"X") 1*("-" (1*8alphanum))
---
>    privateuse    = "x" 1*("-" (1*8alphanum))
349,351c355,357
<        _exactly_ one piece of content.  For example, if process were to
<        insert a human readable error message into a protocol header, it
<        might select the text based on the user's language preference.
---
>        _exactly_ one piece of content.  For example, if a process were
>        to insert a human readable error message into a protocol header,
>        it might select the text based on the user's language preference.
362a369,371
>    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.
365,371c374,380
<    information for that purpose.  Implementations MAY 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 th
<    at content labeled "zh-CN" is more likely to match the range "zh-
<    Hans" than equivalent content labeled "zh-TW".
---
>    information for that purpose.  Implementations MAY also use semantic
>    information external to the registry when matching tags.  For ex
>    ample, 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-CN" is more likely to match the range "zh-Hans"
>    than equivalent content labeled "zh-TW".
378,380c387,388
<    large number of matching items--as many as match the language range
<    used to specify the items, thus filtering out the non-matching
<    content.
---
>    large number of matching items: as many items as match the language
>    priority list, thus "filtering out" the non-matching items.
419c427
<    language range that represents the 'distance' between the two.  A
---
>    languag e range that represents the 'distance' between the two.  A
421c429
<    indicates that they are very similar, and a large distance indic ates
---
>    indicates that they are very similar, and a large distance indicates
458,459c466,467
<    following tags because the unspecified variant field is expanded to
<    "*":
---
>    following tags, in part because the unspecified variant, extension,
>    and private-use subtags are expanded to "*":
499c507
<    sequences prevents a range such as "x-twain" from m atching all
---
>    sequences p revents a range such as "x-twain" from matching all
513,519c521,528
<    this subtag to form language tags and this document recommends that
<    users not use them to form ranges.  For example, if the script were
<    not expanded in this manner, a range such as "de-DE" would produce a
<    more-distant score for content that happened to be labeled
<    "de-Latn-DE" than users would expect that it should.  Note that
<    languages which have a "Suppress-Script" field in the registry are
<    predominantly written in a single script.
---
>    this subtag to form language tags and this document (see Section 4.1)
>    recommends that users not use them to form ranges.  Languages which
>    have a "Suppress-Script" field in the registry are predominantly
>    written in that single script, making the subtag redundant in forming
>    a language tag or range.  Thus if the script were not expanded in
>    this manner, a range such as "de-DE" would produce a more-distant
>    score for content that happened to be labeled "de-Latn-DE" than users
>    would expect that it should.
593,599c602,622
<    Note: A variation of this algorithm might vary the scoring used
<    overall or for specific values.  For example, sometimes it might make
<    sense to use more sophisticated weighting that depends on the values
<    of the corresponding elements.  Thus, depending on the domain, an
<    implementation might assign a smaller distance to the difference
<    between closely related subtags (or treat certain values as equal).
<    Some examples of closely related subtags might be:
---
>    Where a language priority list follows the syntax of the "Accept-
>    Language" header defined in [RFC2616] (see Section 14.4) and
>    [RFC3282], language ranges without a Q value are given values equal
>    to the value of the previous language range in the list (processing
>    from first to last).  If the first language range has no Q value, it
>    is given a value of 1.0.  Language ranges with Q values of zero are
>    removed.  For example, "fr, en;q=0.5, de, it" becomes
>    "fr;q=1.0,en;q=0.5,de;q=0.5,it;q=0.5".  The distance values given
>    above are then divided by the Q values.  For example, if that
>    language tag "fr-FR" has a distance of 384 from a language range with
>    a Q value of 0.8, then the resulting distance is 480 (384 div 0.8).
>
>    Implementations or protocols MAY use different weighting systems than
>    the ones described above, as long as the weightings and weighting
>    mechanisms are clearly specified.  Thus, for example, an
>    implementation or protocol could give all language tags with missing
>    Q values a value of 1.0, or give the distance value 1000 to a
>    language mismatch.  They MAY also use more sophisticated weights that
>    depend on the values of the corresponding elements.  For example, an
>    implementation might give a small distance to the difference closely
>    related subtags.  Some examples of closely related subtags might be:
727,732c750,771
<    Another way an implementation could address extended language ranges
<    would be to map them to basic language ranges: if the first subtag is
<    a "*" then the entire range is treated as "*" (which matches the
<    default content), otherwise the wildcard subtag is removed.  For
<    example, if the language range were "en-*-US", then the range would
<    be mapped to "en-US".
---
>    Implementations MAY also map extended language ranges to basic
>    language ranges: if the first subtag is a "*" then the entire range
>    is treated as "*" (which matches the default content), otherwise each
>    wildcard subtag is removed.  For example, if the language range were
>    "en-*-US", then the range would be mapped to "en-US".
>
>    Where a language priority list contains Q values as in the syntax of
>    the "Accept-Language" header defined in [RFC2616] (see Section 14.4)
>    and [RFC3282], language tags without a Q value are given values equal
>    to the value of the previous language tag (processing from first to
>    last).  If the first language tag has no Q value, it is given a value
>    of 1.0.  Then language tags with zero Q values are removed.  For
>    example, "fr, en;q=0.5, de, it" becomes "fr;q=1.0, en;q=0.5,
>    de;q=0.5, it;q=0.5".  The language priority list is then sorted from
>    highest priority to lowest, whereby any two language tags with the
>    same Q values are remain in the same order as in the original
>    language priority list.  This list is then traversed as described
>    above in doing lookup.
>
>    Implementations or protocols MAY use different lookup mechanisms
>    systems than the ones described above, as long as those mechanisms
>    are clearly specified.
747,750c786,789
<    Most matching schemes make no attempt to process the semanti c
<    meaning of the subtags.  The language range (or its subtags) is
<    usually compared in a case-insensitive manner to each language tag
<    being matched, using basic string processing.
---
>    Most matching schemes make no attempt to process the semantic meaning
>    of the subtags.  The language range (or its subtags) is usually
>    compared in a case-insensitive manner to each language tag being
>    matched, using basic string processing.
770c809
<    ranges), these subtags normally do not interefer with filtering
---
>    ranges), these subtags normally do not interfere with filtering
1059c1098,1099
<    Patton, Randy Presuhn, Eric van der Poel, and many, many others.
---
>    Patton, Randy Presuhn, Eric van der Poel, Markus Scherer, and many,
>    many others.
1073c1113
<    Quest Software
---
>    Yahoo! Inc
1075c1115
<    Email: addison dot phillips at quest dot com
---
>    Email: addison at inter dash locale dot com
1079c1119
<    IBM
---
>    Google
1081c1121
<    Email: mark dot davis at ibm dot com
---
>    Email: mark dot davis at macchiato dot com

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 7 Feb 2006 14:37:21 -0800

Hi Frank,

... because I hadn't updated inter-locale.com yet. The actual text file
submitted is correct.

Uploading is now complete. Try diff again now (and don't forget to refresh).

Addison

Addison Phillips

> Frank Ellermann
> Sent: Tuesday, February 07, 2006 2:23 PM
> To: [email-masked]
> Subject: [Ltru] Re: submission: draft-ietf-ltru-matching #09
> 
> Addison Phillips wrote:
>

---

From: Martin Duerst <[email-masked]>
Date: Wed, 08 Feb 2006 13:12:21 +0900

Hello Addison,

Because your email went out Tuesday, and the deadline was Monday,
I assume that this latest correction doesn't make it into the
repository. Once we know what's in the repository, can you please
change your web-published copy to reflect that?

Regards,      Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Feb 2006 16:23:51 +0100

Addison Phillips wrote:

> I hadn't updated inter-locale.com yet.

No problem, I was more interested in the improved ABNF
than in the year... ;-)  Martin mumbled something about
a deadline, are we already beyond the -0x (for x > 0)
deadline ?  Checking...

<http://permalink.gmane.org/gmane.ietf.announce/10940>

...no, March 06.  Maybe Martin meant the daily deadline.

http://rtg.ietf.org/~fenner/ietf/rfc/hist.cgi?draft=draft-ietf-ltru-registry
reports that the registry draft is in states REF-EXT and
MISSREF*R.

MISSREF*R:
| Processing delayed pending receipt of a normative reference.

REF          draft-ietf-ltru-matching        NOT-RECEIVED
| Holding for normative reference (followed by ID string of
| referenced document)

That's strange, there's no reference to the matching draft
in the registry draft, let alone any normative reference.
Was that added in an IESG note ?  Checking...

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13008

...the tracker already knows Mark's new address.  Following
the links via...

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13008&rfc_flag=0
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1811&filename=draft-ietf-ltru-registry

| Note to the RFC Editor:

| draft-ietf-ltru-registry-14 in combination with draft-ietf-ltru-matching
| (not yet approved by the IESG) are intended to obsolete RFC 3066
| and BCP 47. These two documents should thus be published at the same
| time as draft-ietf-ltru-matching once draft-ietf-ltru-matching has been
| approved by the IESG.

| Please add text to the Abstract and Introduction of
| draft-ietf-ltru-registry-14 to make this clear.  "TBD" refers to the
| RFC number assigned to draft-ietf-ltru-matching.

| To be added to the end of the Abstract:

| This document, in combination with RFC TBD, replaces RFC 3066,
| which replaced RFC 1766.

| Introduction, second to last paragraph:

| OLD:
| This document replaces [RFC3066], which replaced [RFC1766].

| NEW:
| This document, in combination with [RFCTBD], replaces [RFC3066],
| which replaced [RFC1766].

| Please add an Informative reference in draft-ietf-ltru-registry-14
| to the RFC that draft-ietf-ltru-matching becomes.

Somehow I missed when the WG and/or the authors accepted
this part, but it's clearly in in the published approval:
<http://permalink.gmane.org/gmane.ietf.announce/9882>

Still only "informative", but with [RFCTBD] in the intro
it's as near to "normative" as it can get.  Ugly, not what
I wanted (maybe Bruce and John wanted this, and apparently
Scott adopted this position).  If the [RFCTBD] ends up as
a second RfC forming BCP 47 it's messy, IIRC we wanted the
registry to be independent of the matching PS.  Especially
we wanted matching as PS and not as part of BCP 47.

What went wrong except from the obvious problem that I did
not check all details in the approval message ?  Bye, Frank