Inconsistency in descriptions in BCP 47.

Re: Inconsistency in descriptions in BCP 47.

Re: Inconsistency in descriptions in BCP 47.

Finishing up - prepare for second WG last call

Hi -

Though I am encouraged by the continued updates to the I-D for
RFC 4646 bis (after all, that means that *someone* is reading it)
we as a working group really need to finish this stuff.  To
paraphrase a well-known paradox: every specification has at least one
unnecessary statement, and every specification has at least one
error.  (Consequently, ....  

I *really* want to be done with this.  When the next i-d update appears,
we'll begin a *ONE-WEEK* working group last call on both documents.
If no "show-stopping" problems are identified, we'll then hand the
documents to our Area Directors to take to the IESG.

Randy
ltru co-chair

Re: Inconsistency in descriptions in BCP 47.

Re: Addition to ISO 639-3: [lyg]

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> Although I think that this should form part of the formal process. I 
> think it should be written into the RFC as a "Should" for this type of 
> situation.

I'm concerned about using the word "should" (with or without RFC 2119 
uppercasing) for anything relating to Comments fields.  If the content 
absolutely has to be there, or else the Registry can't be used properly, 
then they shouldn't be comments; there should be a new field (i.e. "See 
Also") for this sort of must-have information.  And I say this knowing 
how Randy feels about finishing off this work, and not adding new things 
to it, and I say this 99.9% agreeing with him.

> With a comment field within 'lyg' directing Joe to 'kha' he can do a 
> secondary match.  With no comment he has no chance of finding the 
> documents unless he knows enough about the LSR to do a search for 
> comments regarding 'lyg' (which would bring up my proposed comment 
> within 'kha' but only in this particular instance).

Not only that, but this use case expands our -- somebody's -- task of 
digging beneath the surface of ISO 639-3 changes even more than I 
anticipated.  This is because of the four different paths that ISO 
639-3/RA can take when splitting a language, as outlined by Joan Spanne.

Suppose Joe, on his second week with Company A (luckily not having been 
sacked over the Lyngngam headache), receives a new request to find 
documents relating to Rangpuri, one of two languages split off from what 
used to be called Rajbanshi (the other "new" language is also called 
Rajbanshi).  This was another of the 2007 changes, one that follows the 
first of Joan's four cases.  Joe can find 'rkt' for Rangpuri, but is 
unlikely to find any correlation to either the old Rajbanshi ('rjb') or 
the new Rajbanshi ('rjs').  The subtag 'rjb' would have been deprecated, 
either with no Preferred-Value or with a P-V of 'rjs', but probably not 
with a P-V of 'rkt'.

Thus we would need to supply comments not only for the narrowing cases, 
which Joan expects to be comparatively rare, but also for what she 
called the "simple splits" like Rajbanshi, which constitute a 
significant percentage of the churn in ISO 639-3.  The "merge" cases 
would probably have to be commented as well, for similar reasons.  In 
essence this is a reverse Preferred-Value, telling the user how the 
language *used to be* tagged, whereas Preferred-Value leads the user 
from the old subtag to the new one.

And while I would love to think the rate of churn in ISO 639-3 is 
dwindling to a trickle, the Change Request Index page suggests 
otherwise: 45 proposed language changes already since the publication of 
the 2007 changes four months ago.

> At the moment these comments may or may not be there according to the 
> rules of the current RFC.  I don't think this is good enough.  We can 
> do better and I don't think it will cost a lot to do it.  A simple 
> rule that states "where the meaning of a subtag is narrowed and a new 
> subtag is issued as a result both subtags should have comment fields 
> denoting the change history".  A simple "watch this page" scenario on 
> the ISO 639-3 change notification page would assist in the process.

They don't post their changes on an incremental basis, with explanation, 
as ISO 639-2/RA does.  Rather, they make entire new files available for 
download, with the changes in place but not annotated, and only once a 
year do they publish a Summary of Outcomes document which explains the 
nature of the change.  It is then for us -- by which I assume is meant 
the Designated Experts, Michael and Doug -- to do the exegesis on the 
downloadable files, deciding which changes in ISO 639-3 require this 
type of "obligatory" comment.  The downloadable files are wonderful, 
don't get me wrong, but a list of changes posted on a Web page, in date 
order, would be necessary to make good use of WatchThatPage.

I do use WatchThatPage to find out about the new 639-3 files, and I had 
expected to do some exegesis on them already, such as identifying 
deprecated language subtags and their Preferred-Values.  These 
suggestions add an unknown amount of exegesis to what I was already 
going to do.  It's unlikely anyone else would volunteer to do it, to be 
honest.

We could extend this concept even further, by adding Comments fields to 
the region subtags for all of the former Soviet republics, pointing them 
back to 'SU', so that Joe could find documents related to "Kurdish as 
used in Armenia" that were tagged before Armenia was independent.  This 
is not meant to be sarcastic, but is a logical outgrowth of adding 
comments to language subtags pointing them back to "previously coded as" 
values.  I don't know where it would end.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Re: fix for TP

Shall I use draft-4645bis-05 as the vehicle to make the suggested change 
to the Deprecated field for region subtag TP?

From:

Type: region
Subtag: TP
Description: East Timor
Added: 2005-10-16
Preferred-Value: TL
Deprecated: 2002-11-15

To:

...
Deprecated: 2002-05-20

No change is needed for the record for TL.

I would suggest adding some prose in the draft indicating that this date 
was changed to correct a research error, but also calling attention to 
Section 3.1.5 of draft-4646bis, which points out that the deprecation 
date of really old subtags like 'in' might only be approximate.  The 
implication is that other dates prior to the launch of the Language 
Subtag Registry might not be perfectly accurate either.  As I stated 
earlier, since there was no LSR in 2002, the exact date in 2002 when TL 
replaced TP in ISO 3166-1 is only of academic interest.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Re: Addition to ISO 639-3: [lyg]

Hi Doug

I do see the points you have made and can see that quite a lot of extra work
would be involved - although I am sure that the ISO 639-3 MA/RA would
facilitate a better change page if required.  I still think that for
backward compatibility as well as assistance to the end user that this
should be done.  However, as there has been no supporting discussion on this
and as Randy is hoping for a last call pretty soon I won't labour the points
for doing this.

Best

Debbie

> -----Original Message-----
> From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On
> Behalf Of Doug Ewell
> Sent: 01 May 2008 06:39
> To: LTRU Working Group
> Subject: Re: [Ltru] Addition to ISO 639-3: [lyg]
>
> Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
>
> > Although I think that this should form part of the formal
> process. I
> > think it should be written into the RFC as a "Should" for
> this type of
> > situation.
>
> I'm concerned about using the word "should" (with or without RFC 2119
> uppercasing) for anything relating to Comments fields.  If
> the content absolutely has to be there, or else the Registry
> can't be used properly, then they shouldn't be comments;
> there should be a new field (i.e. "See
> Also") for this sort of must-have information.  And I say
> this knowing how Randy feels about finishing off this work,
> and not adding new things to it, and I say this 99.9%
> agreeing with him.
>
> > With a comment field within 'lyg' directing Joe to 'kha' he
> can do a
> > secondary match.  With no comment he has no chance of finding the
> > documents unless he knows enough about the LSR to do a search for
> > comments regarding 'lyg' (which would bring up my proposed comment
> > within 'kha' but only in this particular instance).
>
> Not only that, but this use case expands our -- somebody's --
> task of digging beneath the surface of ISO 639-3 changes even
> more than I anticipated.  This is because of the four
> different paths that ISO 639-3/RA can take when splitting a
> language, as outlined by Joan Spanne.
>
> Suppose Joe, on his second week with Company A (luckily not
> having been sacked over the Lyngngam headache), receives a
> new request to find documents relating to Rangpuri, one of
> two languages split off from what used to be called Rajbanshi
> (the other "new" language is also called Rajbanshi).  This
> was another of the 2007 changes, one that follows the first
> of Joan's four cases.  Joe can find 'rkt' for Rangpuri, but
> is unlikely to find any correlation to either the old
> Rajbanshi ('rjb') or the new Rajbanshi ('rjs').  The subtag
> 'rjb' would have been deprecated, either with no
> Preferred-Value or with a P-V of 'rjs', but probably not with
> a P-V of 'rkt'.
>
> Thus we would need to supply comments not only for the
> narrowing cases, which Joan expects to be comparatively rare,
> but also for what she called the "simple splits" like
> Rajbanshi, which constitute a significant percentage of the
> churn in ISO 639-3.  The "merge" cases would probably have to
> be commented as well, for similar reasons.  In essence this
> is a reverse Preferred-Value, telling the user how the
> language *used to be* tagged, whereas Preferred-Value leads
> the user from the old subtag to the new one.
>
> And while I would love to think the rate of churn in ISO
> 639-3 is dwindling to a trickle, the Change Request Index
> page suggests
> otherwise: 45 proposed language changes already since the
> publication of the 2007 changes four months ago.
>
> > At the moment these comments may or may not be there
> according to the
> > rules of the current RFC.  I don't think this is good
> enough.  We can
> > do better and I don't think it will cost a lot to do it.  A simple
> > rule that states "where the meaning of a subtag is narrowed
> and a new
> > subtag is issued as a result both subtags should have
> comment fields
> > denoting the change history".  A simple "watch this page"
> scenario on
> > the ISO 639-3 change notification page would assist in the process.
>
> They don't post their changes on an incremental basis, with
> explanation, as ISO 639-2/RA does.  Rather, they make entire
> new files available for download, with the changes in place
> but not annotated, and only once a year do they publish a
> Summary of Outcomes document which explains the nature of the
> change.  It is then for us -- by which I assume is meant the
> Designated Experts, Michael and Doug -- to do the exegesis on
> the downloadable files, deciding which changes in ISO 639-3
> require this type of "obligatory" comment.  The downloadable
> files are wonderful, don't get me wrong, but a list of
> changes posted on a Web page, in date order, would be
> necessary to make good use of WatchThatPage.
>
> I do use WatchThatPage to find out about the new 639-3 files,
> and I had expected to do some exegesis on them already, such
> as identifying deprecated language subtags and their
> Preferred-Values.  These suggestions add an unknown amount of
> exegesis to what I was already going to do.  It's unlikely
> anyone else would volunteer to do it, to be honest.
>
> We could extend this concept even further, by adding Comments
> fields to the region subtags for all of the former Soviet
> republics, pointing them back to 'SU', so that Joe could find
> documents related to "Kurdish as used in Armenia" that were
> tagged before Armenia was independent.  This is not meant to
> be sarcastic, but is a logical outgrowth of adding comments
> to language subtags pointing them back to "previously coded as"
> values.  I don't know where it would end.
>
> --
> Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
> http://www.ewellic.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages  ^
>
> _______________________________________________
> Ltru mailing list
> Ltru <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>

Re: Inconsistency in descriptions in BCP 47.

draft-4646bis, Section 4.1 (4)(4)

Hi -

I think the following text in section 4.1 (4)(4) is misleading, if
not simply incorrect.  The current text says
           Note: where there are fragments of
           linguistic content, such as programming source code
           containing comments written in English, the subtag 'zxx'
           might still be used to indicate the primary status of the
           content, just as 'en' can be applied to a predominantly
           English text that contains a few French phrases.

I realize that this is already quite weak, with no normative force,
but it is misleading, and I believe it points in the wrong direction
for the tagging of artifacts like programming source code.  Now this
may be a function of the quality of source code in question, but I
think the analogy to an English document containing a few French phrases
is incorrect.  For well-maintained source code, the embedded comments
make up a substantial percentage, if not the majority of the
textual content.  In some ways, the comments are more important than
the code itself, since they (rather than anything machine-readable)
provide the interface semantics in most environments.  A more
appropriate analogy would be to an English-language document containing
some mathematical stuff.  I've seen (unmaintainable) chunks of code
with no comments at all.  For such abominations zxx makes a lot of sense.
But the vast majority of he production-grade software I've seen would
be much more sensibly tagged 'en'.

Proposal: delete the note.

Randy