Subject: [Ltru] draft ID nearly ready...

From: Addison Phillips <[email-masked]>
Date: Sun, 10 Sep 2006 10:44:44 -0700

I have posted my first cut at a new I-D on my website:

   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.html

In this version I have incorporated all of the RFC Editor's changes to 
the old draft-registry. I have also inserted text for ISO 639-3, 
although by no mean all such text that we've discussed. I have also 
taken the liberty to remove some material that pertains to the 
transition from 3066 and to modify the text describing the update of the 
registry.

Comments welcome, although I'll probably post this version shortly 
(after creating a diff, running the spellchecker, and other preparatory 
stuff).

Addison

-- 
Addison Phillips
Globalization 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: Frank Ellermann <[email-masked]>
Date: Sun, 10 Sep 2006 21:51:40 +0200

Addison Phillips wrote:

> after creating a diff

In USEFOR I've recently learned how to do this with any URLs
in five steps.  Take two URLs (1) like:

ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt
http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt

Then add
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=
before the older URL (2). Add
&url2=
before the 2nd URL (3), and finally add
&difftype=--hwdiff
at the end (4), resulting in one monstrous (here folded) URL:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=
ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt&url2=
http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.txt
&difftype=--hwdiff

Check that this works, and then create a tiny URL (5) for it:
http://tinyurl.com/hq367

IETF tools server magic, credits to Henrik.  Other types are
--chbars (only the new text with a change bar in the 1st
column), and --abdiff (like the default side by side diff,
but arranged for narrow browser windows).

Frank

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 10 Sep 2006 15:02:13 -0600

I wish there were tools like that for the HTML version, since that is so
vastly easier to read!

Mark

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 10 Sep 2006 15:31:05 -0600

Nice. Some quick notes:

1. You changed "two-character" to drop the hyphen. On the purely stylistic
side, I prefer "two-character codes" over "two character codes" since it
reduces ambiguity, and for consistency we also get "two-character code".

2. Since we know that there will be only one extlang, do we want to change
the following?

>There MAY be up to three extended language subtags.

The disadvantage is that some tags will be well-formed (although invalid) on
past parsers but not this one.

3. I disagree with removing the check on prefixes of variant tags in
*validating* parsers. (Validating parsers have access to the registry --
well-formedness doesn't and shouldn't.)

   o  For variant and extended language subtags, if the registry
      contains one or more 'Prefix' fields for that subtag, check that
the tag matches at least
      one prefix. *'Prefix' field associated with the subtag.*  The
tag matches if
      all the subtags in the 'Prefix' also appear in the tag.  For
      example, the prefix "es-CO" matches the tag "es-Latn-CO-x-private"
      because both the 'es' language subtag and 'CO' region subtag
      appear in the tag.**

=>

   o  For variant subtags, if there are any 'Prefix' fields associated
      with the tag, check that the tag matches at least one of the
*      'Prefix' fields.*  The tag matches if
      all the subtags in the 'Prefix' also appear in the tag.  [fix example]

   o  For extended language subtags, check that the tag matches the
*      'Prefix' field associated with the subtag.*  The tag matches if
      all the subtags in the 'Prefix' also appear in the tag.  [fix example]

I realize that some people (including yourself) want to disallow variants
without prefixes. I don't agree with that. We had left off the ability to
have registered region codes and scripts, because they could be handled via
variants with no Prefix. We should not rush to eliminiate this feature
without thoroughly discussing the consequences. My changes here just
reconcile the issue between validation and registration.

4. Correct the addition of Prefix.

   3.   Values in the field 'Prefix' MAY be added to records of type
        'variant' via the registration process.
=>
   3.   Values in the field 'Prefix' MUST NOT be added to records
        of type 'extlang' or to records of type 'variant'
        that do not have any 'Prefix' values. Values
        MAY be added to records of type 'variant' that already
        have a field of type 'Prefix' via the registration process.

5. Restore the change from U5.0 reference.

   [Unicode]  Unicode Consortium, "The Unicode *Consortium. The Unicode
              Standard, Version 4.1.0, defined by: The Unicode* Standard,
              Version
                  5.0", Boston, *4.0 (Boston,* MA, Addison-Wesley,
2007. *2003.* ISBN 0-321-
                  48091-0.
              *18578-1), as amended by Unicode 4.0.1
              (http://www.unicode.org/versions/Unicode4.0.1) and by
              Unicode 4.1.0
              (http://www.unicode.org/versions/Unicode4.1.0).",
              March 2005.*

6. We'll have to fix the following:

        At the time this document was written, there were
        only four such codes: 830 (Channel Islands), 831 (Guernsey), 832
        (Jersey), and 833 (Isle of Man).  This way, UN M.49 codes remain
        available as the value of last resort in cases where ISO 3166
        reassigns a deprecated value in the registry.

**

---

From: Addison Phillips <[email-masked]>
Date: Sun, 10 Sep 2006 20:55:11 -0700

Some comments follow.

> reduces ambiguity, and for consistency we also get "two-character code".

Where? I thought I was pretty consistent in *including* the hyphens in 
the new draft.

>> There MAY be up to three extended language subtags.

I don't know that we know that yet. So I didn't change it.

I'm also reluctant to remove it, even if, in practice, only one extlang 
can occur. We might include text to reserve additional extlangs for 
future standardization instead.

> well-formedness doesn't and shouldn't.)

Your proposed changes prevent informative registration of prefixes for a 
variant. A lot of people +1'ed removing the check because it supports 
our (meaning "Mark and Addison's") original idea that this was 
informative information.

With my proposal, "tlh-western" (let's pretend you registered it for a 
second) is as valid as "hy-western", but "hy-western" actually has a 
registered meaning. "tlh-western" is junk... but so are "tld-CO", 
"tlh-Latg", and "tlh-Latn-AQ". Each of those is perfectly "valid", if 
entirely stupid.

I think that removing the prefix check from variant requirements allows 
for both generic variants and the development of additional prefixes 
over time with the least disruption to end users. It is entirely in 
keeping with the IETF's koan "be strict in what you emit and promiscuous 
in what you accept". Since "validation" is usually on the accept 
side........

 > without prefixes.

That would be a mis-reading of my intent. I believe what I did was 
suggest that we not register a subtag without a prefix at present while 
considering problems with validation, etc. I actually do support (in 
general) the idea of generic variants, provided we have a decent 
understanding of them.

> I don't agree with that. We had left off the ability to

+1, only see below.

>        have a field of type 'Prefix' via the registration process.

I'm not sure that the text about extlangs is necessary per-se. I think 
it is probably a true requirement, but it may be covered by other 
stability requirements. (I'd support including it for precision, though).

I don't agree with it about variants. By eliminating validation of the 
prefix, we achieve the same effect, while allowing for registration of 
useful informative information (that is, here is a subtag that means 
"western dialect"; with 'hy' it means a particular Armenian dialect--it 
is probably a mistake to use it with a prefix that is unregistered).

Or, to put it another way, I think we're in violent agreement, but I 
like my solution (making all variants somewhat generic, but 
ill-considered with other than a registered prefix) better than yours 
(there is a sharp distinction between generic and non-generic variants) :-).

>              (http://www.unicode.org/versions/Unicode4.1.0).",

Argh. I missed that change.

>        reassigns a deprecated value in the registry.

Good catch.

---

From: Addison Phillips <[email-masked]>
Date: Sun, 10 Sep 2006 21:02:31 -0700

(laughing) Yeah, I know. Where do you think my TinyURLs have been coming 
from?

It even has the benefit of dynamically updating when I upload a 
corrected copy. On the other hand, I like to read the diff before I 
announce it. Sometimes I find more problems when I do that :-)

Addison

---

From: John Cowan <[email-masked]>
Date: Mon, 11 Sep 2006 00:15:27 -0400

> (after creating a diff, running the spellchecker, and other preparatory 

Multiple extlang tags should be allowed in 4646bis, with recursive
interpretation.  The use case is this:  if it turns out that
ar-aao (Algerian Arabic) is really two different languages, say
Northern Algerian Arabic and Southern Algerian Arabic, then
639-3 will assign two new language tags, say xxx and yyy.  For
backward compatibility and ease of matching, then, we register
these as extlang subtags with a Prefix of ar-aao.

The result is the tags ar-aao-xxx and ar-aao-yyy.  Naturally we
hope this won't happen, but we can't rule it out either.
(What happens after two more splits?  We lose.)

-- 
John Cowan  [email-masked]  http://ccil.org/~cowan
If he has seen farther than others,
        it is because he is standing on a stack of dwarves.
                --Mike Champion, describing Tim Berners-Lee (adapted)

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Sep 2006 14:07:36 +0200

Addison Phillips wrote:
 
> (laughing) Yeah, I know. Where do you think my TinyURLs have
> been coming from?

The part with "add &difftype=--hwdiff" was new for me - with my
browser the side-by-side default is precisely the only unusable
format.  That's why I tried to create plain text diffs based on
the unpaginated output for some 4646-drafts.  Complete waste of
time, the &difftype=--hwdiff is fine.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Sep 2006 14:57:16 +0200

Addison Phillips wrote:

> I think that removing the prefix check from variant
> requirements allows for both generic variants and the
> development of additional prefixes over time with the
> least disruption to end users. It is entirely in keeping
> with the IETF's koan "be strict in what you emit and
> promiscuous in what you accept". Since "validation" is
> usually on the accept side........

I thought it's for (among others) online validators like
Unicorn.  If I'd install a validator locally I wouldn't
update the registry daily, because I don't need the most
recent tags worldwide.  If you install it locally you'd
probably try to get the most recent registry.  And you'd
be interested to get warnings for junk like tlh-1996 etc.

> I actually do support (in general) the idea of generic
> variants, provided we have a decent understanding of them.

Extension registry "g".  Mark's example "generic regions"
below the 3166-1 level deserves its own extension registry.

For a pseudo-generic "europeun" listing the prefixes of all
EU languages would be a PITA, but not imposssible.  And IMO
still better than a true generic "europeun".

  [Mark about generic variants]
>> We should not rush to eliminiate this feature without
>> thoroughly discussing the consequences.

Sure, and under RFC 4646 rules the review list is free to
ignore the SHOULD.  As soon as they've done this we can't
twist it into a MUST anymore.  But if they don't use this
loophole we can block it in 4646bis.

> there is a sharp distinction between generic and
> non-generic variants

Yes, and generic can be replaced by extension registries.
Generic region variants would be a can of worms.  I'm free
to send "unsubscribe" to the review list if it hits the
fan, others (probably including you) are not,

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Sep 2006 15:23:17 +0200

Mark Davis wrote:
 
> I wish there were tools like that for the HTML version,
> since that is so vastly easier to read!

Probably the W3C has such tools, they can generate "diffs"
based on <del> and <ins>.  Pointless from my POV with an
old browser not supporting these tags, but it should be
what you want.  The two input URLs are the HTML output of
xml2rfc:

http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-00.html
http://www.inter-locale.com/ID/draft-ietf-ltru-registry-14.html

The -14 isn't exactly 4646, but you know all minor AUTH48
changes.  The missing step from last draft to final RFC
is a known issue, I hope they'll fix it soon (before 2008).

Maybe Addison has an unofficial post-AUTH48 XML somewhere.
IIRC the SPF folks tried this for 4408 (= retrofitting the
Rfc-editor modifications into the XML source).  Otherwise
you'd need tools to create HTML from nroff, and then the
diff-marked HTML based on these nroff-to-HTML versions.

Frank

---

From: Addison Phillips <[email-masked]>
Date: Mon, 11 Sep 2006 08:25:44 -0700

I believe the wdiff feature is new: I learned about it during AUTH48 of 
4646. If it isn't new, it wasn't formerly documented on the rfcdiff home 
page.

Addison