Subject: [Ltru] RE: [ietf-provreg] Small bibliography error in RFC 4930

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sun, 17 Jun 2007 17:58:46 -0400

That's not an error.  The references are correct as published for promotion to draft standard status.

-Scott-

 -----Original Message-----
From: 	Stephane Bortzmeyer [mailto:[email-masked]]
Sent:	Sunday, June 17, 2007 03:47 PM Eastern Standard Time
To:	[email-masked]
Cc:	[email-masked]; [email-masked]; [email-masked]
Subject:	[ietf-provreg] Small bibliography error in RFC 4930

RFC 4930 has several normative references to RFC 3066.

RFC 4930 has been approved by the IESG in January 2007 and published
in May 2007.

RFC 3066 have been obsoleted by RFC 4646 in September 2006, several
months before.
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jun 2007 10:42:48 +0200

> promotion to draft standard status.

At the moment you can reconstruct a 3066 registry by looking at
the redundant / grandfathered tags in the 4646 registry, and in
the source standards (i.e. the language and region subtags in the
4646 registry).

IOW just stay away from scripts, variants, and UN region numbers.

With the 4646bis registry it will be more convoluted, you'd also
have to stay away from 639-3 languages (+ extlangs, if any pop up).

Should 4646bis do something for protocols wishing to emulate the
old 3066 registry ?  We could flag the source of language tags in
the description field (just an idea).  Or add a how-to as appendix.

Frank

---

From: Martin Duerst <[email-masked]>
Date: Mon, 18 Jun 2007 19:26:21 +0900

>> promotion to draft standard status.

Like others, I have problems understanding that. Randy made
the procedural argument (both RFC 3066 and RFC 4646 are BCPs).

There is also an implementation argument:
There are no legal language tags in RFC 4646 that aren't legal
according to RFC 3066. I have absolutely no clue what could
break in an implementation when using a tag that became
legal in RFC 4646. The only thing that I can see break is
things such as "language not available", but then that kind
of error was always possible.

>IOW just stay away from scripts, variants, and UN region numbers.

This is one interpretation, but there is also a different,
in my view more plausible, interpretation: RFC 4646 did a
bulk registration of language/region/script/whatever combinations.
Because it became obvious that there would be scaling problems
when registring all combinations, we took the path of changing
the registry structure. The old (RFC 3066) registry has been
obsoleted, there is only the RFC 4646 registry, which is
a direct continuation of the RFC 3066 registry. All the
tags you can generate from the new registry using the rules
in RFC 4646 are legal tags according to RFC 3066, and have
to be considered under RFC 3066 as if they were in fact
registered one-by-one.

Frank's interpretation would mean that only the variants
registered at the time RFC 3066 was replaced by RFC 4646
would be usable. That would lead to weird requests. I remember
that in the transition period from RFC 3066 to RFC 4646,
we had somebody requesting registration of el-Latn.
We rejected this because with RFC 4646, there would be no
such need anymore. With the interpretation above, that would
no longer be true.

>the description field (just an idea).  Or add a how-to as appendix.

No. There is no old registry. There is only one registry.
The current registry IS the RFC 3066 registry, just slightly
overhauled.

With this, of course the reasons for citing RFC 3066 when
RFC 4646 was out become even less understandable.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 18 Jun 2007 10:43:55 +0100

Frank wrote:

> Should 4646bis do something for protocols wishing to emulate 
> the old 3066 registry ?  We could flag the source of language 
> tags in the description field (just an idea).  Or add a 
> how-to as appendix.

Surely that is quite easy to do as each subtag has a date?

Debbie

> From: Frank Ellermann [mailto:[email-masked]] 
> Sent: 18 June 2007 09:43
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ltru] Re: Small bibliography error in RFC 4930
> 
> Hollenbeck, Scott wrote:
>  
> At the moment you can reconstruct a 3066 registry by looking 
> at the redundant / grandfathered tags in the 4646 registry, 
> and in the source standards (i.e. the language and region 
> subtags in the
> 4646 registry).
> 
> With the 4646bis registry it will be more convoluted, you'd 
> also have to stay away from 639-3 languages (+ extlangs, if 
> any pop up).
> 
> Should 4646bis do something for protocols wishing to emulate 
> the old 3066 registry ?  We could flag the source of language 
> tags in the description field (just an idea).  Or add a 
> how-to as appendix.
> 
> Frank
> 
> 
> 
>

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jun 2007 12:25:21 +0200

> Surely that is quite easy to do as each subtag has a date?

Yes, it would be easy to reconstruct a "frozen" (2006) 3066 registry.

But I guess Scott's protocol tries to pretend that 3066 still exists,
i.e. new country codes like IM GG JE are okay, new 639-2 languages
like frr frs are okay, old redundant and grandfathered tags are okay,
while scripts, variants, 639-3 languages, and extlangs are NOT okay.

Personally I'd prefer "4646 registry minus scripts" (or similar) for
this purpose, but Scott said it's intentionally 3066.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jun 2007 13:39:55 +0200

Martin Duerst wrote:

 [I've stripped "ietf-provreg" from the Cc: list]
> Randy made the procedural argument (both RFC 3066 and RFC 4646
> are BCPs).

Just to clarify, I think you or Randy mean "RFC 3066 used to be
a BCP before RFC 4646 obsoleted it".

> I have absolutely no clue what could break in an implementation
> when using a tag that became legal in RFC 4646.

Matching is tricky in the presence of script subtags (and other
less likely scenarios), it was one line in RFC 3066, now it's a
separate document.

For 4646bis no implementation will be able to match nl-BE with
what-was-it, vlm (?), by only looking at the registry, unless
we deprecate it manually in favour of nl-BE.

It makes perfect sense to exclude some constructs.  When I try
the language option of a "popular" search engine I won't find
de-1996 pages while looking for de, or en-GB-oed pages while
looking for en (I'm too lazy to check what it was, maybe both).

And I won't find frr pages while looking for fy-DE (or v.v.).
But that's no 639-3 or 4646 issue, it would be the same with
3066.  For 3066 stability was an implicit assumption, and 4646
made it explicit, trying to guarantee it for region tags.

RFC 3066, 4646, and 4646bis fail miserably when language tags
are narrowed, or when language-region combinations get their
own language tag.

Maybe we should keep RFC 4646 as is, and later replace it
wholesale by ISO 639-6.  The fy-DE and nl-BE examples (plus
the "extlang" discussion) are a warning.

This nl-BE confusion is in essence the same issue as the old
CS chaos, we're trying to mix standards designed to be used
for something else.  For ISO 639-3 it's logical to replace
nl-BE by something "better" as soon as somebody seriously
wants it, they don't know any "nl-BE", they only know "nl".

But we know that nl-BE exists, and we've no way to deprecate
it in favour of whatever comes, we could at best manually
deprecate the new subtag in favour of nl-BE.

For fy-NL, fy-DE, frr, and fy, let alone frs, I thought that
it's okay to ignore the implications, after all I tried to
find a single page tagged as fy-DE and found nothing.  But
for nl-BE (and zh-*) we might be in serious trouble.

Frank

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 18 Jun 2007 12:52:18 +0100

> No. There is no old registry. There is only one registry.

I would have to disagree here.  I can see applications for using an "old"
registry in order to update to a "new" registry.

Best

Debbie

> From: Martin Duerst [mailto:[email-masked]] 
> Sent: 18 June 2007 11:26
> To: Frank Ellermann; [email-masked]
> Subject: Re: [Ltru] Re: Small bibliography error in RFC 4930
> 
> There are no legal language tags in RFC 4646 that aren't 
> legal according to RFC 3066. I have absolutely no clue what 
> could break in an implementation when using a tag that became 
> >At the moment you can reconstruct a 3066 registry by looking at the 
> >redundant / grandfathered tags in the 4646 registry, and in 
> the source 
> >standards (i.e. the language and region subtags in the
> >4646 registry).
> >
> This is one interpretation, but there is also a different, in 
> my view more plausible, interpretation: RFC 4646 did a bulk 
> registration of language/region/script/whatever combinations.
> Because it became obvious that there would be scaling 
> problems when registring all combinations, we took the path 
> of changing the registry structure. The old (RFC 3066) 
> registry has been obsoleted, there is only the RFC 4646 
> registry, which is a direct continuation of the RFC 3066 
> registry. All the tags you can generate from the new registry 
> using the rules in RFC 4646 are legal tags according to RFC 
> 3066, and have to be considered under RFC 3066 as if they 
> were in fact registered one-by-one.
> 
> would be usable. That would lead to weird requests. I 
> remember that in the transition period from RFC 3066 to RFC 
> 4646, we had somebody requesting registration of el-Latn.
> also have 
> >to stay away from 639-3 languages (+ extlangs, if any pop up).
> >
> >Should 4646bis do something for protocols wishing to emulate the old 
> >3066 registry ?  We could flag the source of language tags in the 
> >description field (just an idea).  Or add a how-to as appendix.
> 
> With this, of course the reasons for citing RFC 3066 when RFC 
> 4646 was out become even less understandable.
> 
> Regards,   Martin.
> 
>

---

From: John Cowan <[email-masked]>
Date: Mon, 18 Jun 2007 10:34:19 -0400

Frank Ellermann scripsit:

> what-was-it, vlm [recte "vls"], by only looking at the registry, unless

We can't do that; they are two different languages, though closely
related and intertwined in use  It would be like deprecating nds in
favor of de-northern.

And fy-DE could never have been more than a hack like zh-TW for zh-Hant:
is it North Frisian, or is it Saterfrisian aka East Frisian (not to be
confused with the variety of nds also called "East Frisian", still less
with the variety of Standard German (de) spoken in Ostfriesen)?

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics.                                    [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jun 2007 18:45:11 +0200

John Cowan wrote:

>> what-was-it, vlm [recte "vls"]

Thanks.
 
> they are two different languages, though closely related and
> intertwined in use  It would be like deprecating nds in favor
> of de-northern.

Sometimes I think they're making up languages for non-technical
reasons.

> fy-DE could never have been more than a hack like zh-TW for
> zh-Hant: is it North Frisian, or is it Saterfrisian

All you can know is that it's not West Frisian (fy since 2006).

For the frr suppress-Latn registration request I tried to find
some background info, apparently frr is subdivided into three
or more variants.

> not to be confused with the variety of nds also called "East
> Frisian"

Yeah, I made sure that Wikipedia had this right when I was at
it about a year ago.

> still less with the variety of Standard German (de) spoken
> in Ostfriesen

I'd guess that that's no language, when nds-folks speak "de"
they end up with a rather pure "de".

Frank

---

From: John Cowan <[email-masked]>
Date: Mon, 18 Jun 2007 17:13:24 -0400

> Sometimes I think they're making up languages for non-technical

Sometimes I think so too, but I don't think this is one of them.
Low Saxon (or whatever you want to call it) is pretty clearly established,
though whether the non-Dutch dialects in the Netherlands are really all
that separate from it is a question.

> some background info, apparently frr is subdivided into three

Pretty much mainlander, islander (except Sylt which is no longer
Frisian-speaking in practice), and Heligolander.  Of course, finer
distinctions can be and are made.

> they end up with a rather pure "de".

Well, that's what de is:  High German syntax in Low German phonology
(cf. "lingua toscana in bocca romana").

-- 
Go, and never darken my towels again!           John Cowan
        --Rufus T. Firefly                      http://ccil.org/~cowan

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Jun 2007 11:17:10 +0900

>registry in order to update to a "new" registry.

Hello Debbie,

I'm not sure I can parse the above sentence correctly. Are you saying
that somebody could, now, make an application for registration on
http://www.iana.org/assignments/language-tags according to RFC 3066?
At http://www.iana.org/numbers.html#L, it explicitly says
"No further registrations in this registry.".
Or are you talking about something else?

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Jun 2007 12:21:11 +0900

>a BCP before RFC 4646 obsoleted it".

Well, yes, very good point. In that sense, using RFC 3066 instead
of RFC 4646 is actually a bad idea, it means that you are going
to Draft Standard with a reference to something that was a BCP
rather than with a reference to an actual BCP.

>less likely scenarios), it was one line in RFC 3066, now it's a

Yes, that's a valid point (but probably the only one). That means
that in RFC 4930, it might have said something like "this protocol
uses Basic Filtering as defined in RFC 4647 for matching language
tags". But my guess is that not even this is needed.

The protocol just sends languages that the server has available,
and the client is free to use that to pick whichever it thinks might
work (including, e.g., showing the list to a user).

Also, the protocol has some elements where the language can be
indicated. Here is an example, taken directly from the spec:

   - A <msg> element containing a human-readable description of the
         response code.  The language of the response is identified via
         an OPTIONAL "lang" attribute.  If not specified, the default
         attribute value MUST be "en" (English).

There is nothing in terms of matching here, just simple identfication.
[As an aside, there are several points in the above text that are
suboptimal. The first is the use of lang instead of xml:lang.
(Of course, that's difficult to change when going to Draft,
it should have been cought much earlier.)
The second is the last sentence, which seems to prescribe a
value for an attribute that is optional. It would be better if
it were reworded as "If not specified, the implied attribute
value is "en" (English)." A MUST might be appropriate e.g.
to say that the content of the <msg> element has to be English
in the absence of a lang attribute. Using 'implied' is much
clearer, because it's the terminology that XML is using.
The third problem is the use of "en" rather than "i-default".
The later is specifically defined for this fallback purpose.

>looking for en (I'm too lazy to check what it was, maybe both).

It makes perfect sense for some servers to exclude some languages,
to translate into all languages that even RFC 3066 allows for
tagging would be quite expensive. But that has nothing to do
with the question of which spec to references, it is purely
an implementation/data issue.

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Jun 2007 11:17:10 +0900

Hello Debbie,

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Jun 2007 12:21:11 +0900

Regards,   Martin.

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 19 Jun 2007 10:37:56 +0100

Hi Martin

No I did not mean to register new subtags according to 3066.  What I mean is
that I can see an application for doing (say) a transaction within a
database that will bring out all records that match the Registry as it stood
in the 3066 era.  Perhaps in a housekeeping/update routine. Is there a way
to pull that historical registry once ISO 639-3 is added?

Best regards

Debbie 

> Sent: 19 June 2007 03:17
> To: Debbie Garside; 'Frank Ellermann'; [email-masked]
> Subject: RE: [Ltru] Re: Small bibliography error in RFC 4930
> 
> I'm not sure I can parse the above sentence correctly. Are 
> you saying that somebody could, now, make an application for 
> registration on http://www.iana.org/assignments/language-tags 
> according to RFC 3066?
> At http://www.iana.org/numbers.html#L, it explicitly says "No 
> further registrations in this registry.".

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 19 Jun 2007 11:04:50 +0100

This is exactly the sort of application I had in mind when I proposed (many
moons ago) that the syntax be changed to include "[RFC3066]" within the tag
(something similar was originally proposed within Dublin Core). How much
easier it would be for those within archive industries.  

Best regards

Debbie

> From: Debbie Garside [mailto:[email-masked]] 
> Sent: 19 June 2007 10:38
> To: [email-masked]; 'Frank Ellermann'; [email-masked]
> No I did not mean to register new subtags according to 3066.  
> What I mean is that I can see an application for doing (say) 
> a transaction within a database that will bring out all 
> records that match the Registry as it stood in the 3066 era.  
> Perhaps in a housekeeping/update routine. Is there a way to 
> pull that historical registry once ISO 639-3 is added?
> 
> Best regards
> 
> Debbie 
> 
> you saying