Dear All,
1-I have a question in relation with clause 15 B inside 3.4 Stability of the IANA Registry Entries, concerning "narrowing" of the meaning associated with a code element and how does this apply in the case of "YU".
From the beginning and this is also the case inside ISO 3166 (1988), third edition, (YU, YUG, 890) representing YUGOSLAVIA (The Socialisqt Federative Repuiblic of Yugoslavia) covers the six Republics forminf YUGOSLAVIA.
But, on 1992-06-06, ISO 3166 created (HR, HRV, 191) for CROATIA, so that Yu was left with only five Republics.
The same happened when ISO 3166 created (BA, BIH, 070) for BOSNIA-HERZEGOVINE and (SI, SVN, 705) for SLOVENIA on 1993-06-15 and also after rthat created (Mk, MKD, 807) for MAKEDONIA, so that YU was gradually narrowed from 6 to only 2 of the original Republics forming YUGOSLAVIA, without any change of the country name.
Only on 1993-07-15 intervened a minor change, transforming (YU, YUG, 890) to (YU, YUG, 891) marking the "narrowing" of the considered territory without any change of the country name., that only changed to SERBIA AND MONTENEGRO on 2003-07-23 when (YU, YUG, 890) was deprecated.
How does clause 3.4 manage with this interesting case ?
2-Concerning point 9.1 of 4646bis-21, the dates for standards should be aligned with precision :
-ISO 639-1 July 2002;
-ISO 639-2 October 1998 (Moreover "first edition", that is not included in the standard's title should be deleted );
-ISO 639-3 February 2007;
-ISO 646 December 1991.
Cordialement.
Gérard LANG
-----Message d'origine-----
De : ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] De la part de ltru-request at ietf.org
Envoyé : mardi 17 février 2009 20:35
À : ltru at ietf.org
Objet : Ltru Digest, Vol 48, Issue 40
Send Ltru mailing list submissions to
ltru at ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ltru
or, via email, send a message with subject or body 'help' to
ltru-request at ietf.org
You can reach the person managing the list at
ltru-owner at ietf.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Ltru digest..."
Today's Topics:
1. idnits and editor's copy posted (Phillips, Addison)
2. Re: issue #1 resolution (Randy Presuhn)
3. Re: Issue #4: "different from" issue (Randy Presuhn)
4. Re: Issue Tracker (Doug Ewell)
5. Re: Issue Tracker (Randy Presuhn)
6. Re: Issue Tracker (Phillips, Addison)
7. Re: Issue Tracker (Randy Presuhn)
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Feb 2009 12:01:53 -0800
From: "Phillips, Addison" <addison at amazon.com>
Subject: [Ltru] idnits and editor's copy posted
To: LTRU Working Group <ltru at ietf.org>
Message-ID:
<4D25F22093241741BC1D0EEBC2DBB1DA01824D9B07 at EX-SEA5-D.ant.amazon.com>
Content-Type: text/plain; charset="utf-8"
... ran relatively cleanly against our new text. However, it complains that we're using the 10 November 2008 copyright boilerplate rather than the 12 Feburary 2009 boilerplate. Since today is the 16th of February, I suspect that we need to wait for a new xml2rfc. This will also eliminate the need (I suspect) for my special note.
Are there any *other* comments on the new draft? The editor's copy on inter-locale is updated. The diff remains at:
http://tinyurl.com/cmhgy8
(for the editors)
Addison
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
------------------------------
Message: 2
Date: Mon, 16 Feb 2009 13:24:54 -0800
From: "Randy Presuhn" <randy_presuhn at mindspring.com>
Subject: Re: [Ltru] issue #1 resolution
To: "LTRU Working Group" <ltru at ietf.org>
Message-ID: <001001c9907d$036915a0$6801a8c0 at oemcomputer>
Content-Type: text/plain; charset="utf-8"
Hi -
Both as a technical contributor and as co-chair...
> From: "Phillips, Addison" <addison at amazon.com>
> To: "Phillips, Addison" <addison at amazon.com>; "Randy Presuhn"
> <randy_presuhn at mindspring.com>; "LTRU Working Group" <ltru at ietf.org>
> Sent: Monday, February 16, 2009 11:48 AM
> Subject: issue #1 resolution[was: RE: IPR mumbles..]
>
> (editor hat OFF)
>
> > > - The text put in for issue #1 (which was cast as just
> > > updating a reference) creates a technical change
>
> I... don't exactly see it that way. Processes do get updated over
> time. In this case, they renamed the process but don't appear to have
> changed it appreciably. It still requires an RFC to get a registry
> entry.
People of good will may have different interpretations of "appreciably."
RFC 2434 said:
IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made via
RFCs approved by the IESG. Typically, the IESG will seek
input on prospective assignments from appropriate persons
(e.g., a relevant Working Group if one exists).
RFC 5226 says:
IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.
To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.
If there are no objections to this change (or if you think this is a non-change) then it's fine with me. I just want people to be clear about what the (non)changes are.
Randy
------------------------------
Message: 3
Date: Mon, 16 Feb 2009 17:13:37 -0800
From: "Randy Presuhn" <randy_presuhn at mindspring.com>
Subject: Re: [Ltru] Issue #4: "different from" issue
To: <ltru at ietf.org>
Message-ID: <006201c9909c$f6acfdc0$6801a8c0 at oemcomputer>
Content-Type: text/plain; charset="iso-8859-1"
Hi -
As co-chair: the editors are requested to make the agreed change.
Randy
----- Original Message -----
From: "CE Whitehead" <cewcathar at hotmail.com>
To: <ltru at ietf.org>
Sent: Monday, February 16, 2009 9:01 AM
Subject: Re: [Ltru] Issue #4: "different from" issue
Hi!
Back to section 1, par. 3:
"Standards, protocols, and applications that reference this document
normatively but apply different rules to the ones given in this
section MUST specify how language tag selection varies from the
guidelines given here."
I thought the issue tracker for issue 4 said "different to" would be replaced by the more widely used "different from"??
(http://www.ietf.org/mail-archive/web/ltru/current/msg12171.html)
I don't see this change in the text draft (http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-21.txt).
(Otherwise looks really nice but I've just glanced at it.)
Thanks!
--C. E. Whitehead
cewcathar at hotmail.com
--------------------------------------------------------------------------------
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>
------------------------------
Message: 4
Date: Mon, 16 Feb 2009 19:04:50 -0700
From: "Doug Ewell" <doug at ewellic.org>
Subject: Re: [Ltru] Issue Tracker
To: "LTRU Working Group" <ltru at ietf.org>
Message-ID: <ABF3D6D2CC164F24B433DC5DB460DDBF at DGBP7M81>
Content-Type: text/plain; format=flowed; charset="utf-8";
reply-type=original
"Phillips, Addison" <addison at amazon dot com> wrote:
> I did install the latest xml2rfc DTD. It does produce some of the
> correct magic mumbles, but not 6.c.iii. Since we include the 6.c.iii
> mumble, I have applied the noDerivatives200811 IPR directive.
That would be exactly the wrong IPR statement to use in draft-4645bis,
since one of its major raisons d'?tre is to allow IANA to create a
derivative work, namely the replacement Language Subtag Registry. So
I'm eagerly awaiting guidance on what statement I should use.
--
Doug Ewell * Thornton, 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 ?
------------------------------
Message: 5
Date: Tue, 17 Feb 2009 10:42:17 -0800
From: "Randy Presuhn" <randy_presuhn at mindspring.com>
Subject: Re: [Ltru] Issue Tracker
To: "LTRU Working Group" <ltru at ietf.org>
Message-ID: <000401c9912f$762fbbe0$6801a8c0 at oemcomputer>
Content-Type: text/plain; charset="utf-8"
Hi -
As co-chair:
> From: "Doug Ewell" <doug at ewellic.org>
> To: "LTRU Working Group" <ltru at ietf.org>
> Sent: Monday, February 16, 2009 6:04 PM
> Subject: Re: [Ltru] Issue Tracker
>
> "Phillips, Addison" <addison at amazon dot com> wrote:
>
> > I did install the latest xml2rfc DTD. It does produce some of the
> > correct magic mumbles, but not 6.c.iii. Since we include the 6.c.iii
> > mumble, I have applied the noDerivatives200811 IPR directive.
>
> That would be exactly the wrong IPR statement to use in draft-4645bis,
> since one of its major raisons d'?tre is to allow IANA to create a
> derivative work, namely the replacement Language Subtag Registry. So
> I'm eagerly awaiting guidance on what statement I should use.
...
noDerivatives200811 is definitely NOT the option to use.
With regard to 4645bis, the question is whether Doug, as editor,
sees a need for the 6.c.iii option. That's it, and it's his
decision. If all (or practically all) the words are his, or
were his in a previous incarnation, then there should be no
need for the 6.c.iii text.
Also worth keeping in mind: what is the likelihood that someone
who contributed substantial text (not just an idea) to the development
of 4645bis would sue if IANA used that text? What is the probability
that such a litigant would prevail in court?
Randy
------------------------------
Message: 6
Date: Tue, 17 Feb 2009 10:57:00 -0800
From: "Phillips, Addison" <addison at amazon.com>
Subject: Re: [Ltru] Issue Tracker
To: Randy Presuhn <randy_presuhn at mindspring.com>, LTRU Working Group
<ltru at ietf.org>
Message-ID:
<4D25F22093241741BC1D0EEBC2DBB1DA0182728B0C at EX-SEA5-D.ant.amazon.com>
Content-Type: text/plain; charset="utf-8"
I have no objection to omitting the 6.c.iii from 4645bis (or including it, if Doug prefers). Should Mark and I file anything related to 4645bis? After all, I suppose one could obliquely consider draft-langtag (way back at the start of this project) to be the source of 4645 (neither of us has ever edited the document, please note).
Addison
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> Behalf Of Randy Presuhn
> Sent: Tuesday, February 17, 2009 10:42 AM
> To: LTRU Working Group
> Subject: Re: [Ltru] Issue Tracker
>
> Hi -
>
> As co-chair:
>
> > From: "Doug Ewell" <doug at ewellic.org>
> > To: "LTRU Working Group" <ltru at ietf.org>
> > Sent: Monday, February 16, 2009 6:04 PM
> > Subject: Re: [Ltru] Issue Tracker
> >
> > "Phillips, Addison" <addison at amazon dot com> wrote:
> >
> > > I did install the latest xml2rfc DTD. It does produce some of
> the
> > > correct magic mumbles, but not 6.c.iii. Since we include the
> 6.c.iii
> > > mumble, I have applied the noDerivatives200811 IPR directive.
> >
> > That would be exactly the wrong IPR statement to use in draft-
> 4645bis,
> > since one of its major raisons d'?tre is to allow IANA to create
> a
> > derivative work, namely the replacement Language Subtag Registry.
> So
> > I'm eagerly awaiting guidance on what statement I should use.
> ...
>
> noDerivatives200811 is definitely NOT the option to use.
>
> With regard to 4645bis, the question is whether Doug, as editor,
> sees a need for the 6.c.iii option. That's it, and it's his
> decision. If all (or practically all) the words are his, or
> were his in a previous incarnation, then there should be no
> need for the 6.c.iii text.
>
> Also worth keeping in mind: what is the likelihood that someone
> who contributed substantial text (not just an idea) to the
> development
> of 4645bis would sue if IANA used that text? What is the
> probability
> that such a litigant would prevail in court?
>
> Randy
>
>
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
------------------------------
Message: 7
Date: Tue, 17 Feb 2009 11:35:15 -0800
From: "Randy Presuhn" <randy_presuhn at mindspring.com>
Subject: Re: [Ltru] Issue Tracker
To: "LTRU Working Group" <ltru at ietf.org>
Message-ID: <000401c99136$dc59bd60$6801a8c0 at oemcomputer>
Content-Type: text/plain; charset="utf-8"
Hi -
As co-chair...
> From: "Phillips, Addison" <addison at amazon.com>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "LTRU Working Group" <ltru at ietf.org>
> Sent: Tuesday, February 17, 2009 10:57 AM
> Subject: RE: [Ltru] Issue Tracker
>
> I have no objection to omitting the 6.c.iii from 4645bis (or including it,
> if Doug prefers). Should Mark and I file anything related to 4645bis?
The "Contributor Non-Exclusive License" at http://trustee.ietf.org/licenses.html
is still undergoing revision. If you like, you could fill it out and send
it in when it becomes possible to do so. In the meantime, if you and
Mark made clear on this list your intent to do so, that should be sufficient
to make life easier for Doug. (BTW, I also intend to sign the "Contributor
Non-Exclusive License" when it becomes available.)
In Doug's case, if he is comfortable that the relevant contributors
are willing to grant the same rights for their pre-RFC 5378
contributions as they now grant under the "NOTE WELL" currently in
effect, (that's what signing the license accomplishes) then he doesn't
need to do the 6.c.iii. The only reason I encourage doing 6.c.iii for
*4646bis* is that there's a much larger set of contributors whose text
may have made it verbatim into the document, and it's not immediately clear
whether all of them have agreed / will agree to the RFC 5378 terms for
their pre-RFC 5378 contributions.
> After all, I suppose one could obliquely consider draft-langtag
> (way back at the start of this project) to be the source of 4645
> (neither of us has ever edited the document, please note).
In this particular case, since the issue is copyright, there is
a concern only if significant text has been copied verbatim.
If the authors of that earlier work can assure Doug that they
agree to the 5378 terms, then there is no need for 6.c.iii,
at least as far as those portions of the text are concerned.
I hope this makes things clearer. (I also hope that I've understood
the issues correctly. Martin, please speak up if I've mis-stated
anything.)
Randy
------------------------------
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru
End of Ltru Digest, Vol 48, Issue 40
************************************
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.