Subject: [Ltru] IPR for draft-4645bis (was: Re: Issue Tracker)

From: "Doug Ewell" <[email-masked]>
Date: Tue, 17 Feb 2009 23:36:23 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> 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.

I would say that except for a few short passages, the text of 
draft-4645bis is essentially all mine.  There are some sentences that 
deal with the RFC Editor removing the Registry contents before 
publication; these were contributed by one co-chair or the other.  I 
think John Cowan contributed part of a sentence having to do with the 
new Registry being a complete replacement and not a set of changes to be 
applied by IANA.  That's it.

Of course, the draft does incorporate concepts and ideas (but not 
verbatim text) from many other list members.  I think that's what an 
editor in a WG is supposed to do.

> 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?

<ianal>I don't feel there's much to worry about.</ianal>

"Phillips, Addison" <addison at amazon dot com> wrote:

> 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).

The concept of a separate Registry was described in 
draft-phillips-langtag well before it was decided to use an 
Internet-Draft to transmit the Registry contents to IANA (the first 
purpose of 4645), and also before it was decided to use the draft to 
explain the process of arriving at those contents (the second purpose). 
But I don't believe any version of draft-langtag went into anywhere near 
enough depth in these regards to be considered a Contribution toward 
4645, let alone 4645bis.

In any event, <ianal>I don't expect Addison or Mark to sue me 
either.</ianal>

--
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  ˆ

---

From: Lang Gérard <[email-masked]>
Date: Wed, 18 Feb 2009 09:20:52 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 17 février 2009 20:35
À : [email-masked]
Objet : Ltru Digest, Vol 48, Issue 40

Send Ltru mailing list submissions to
	[email-masked]

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
	[email-masked]

You can reach the person managing the list at
	[email-masked]

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" <[email-masked]>
Subject: [Ltru] idnits and editor's copy posted
To: LTRU Working Group <[email-masked]>
Message-ID:
	<[email-masked]>
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" <[email-masked]>
Subject: Re: [Ltru] issue #1 resolution
To: "LTRU Working Group" <[email-masked]>
Message-ID: <001001c9907d$036915a0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

Both as a technical contributor and as co-chair...

> From: "Phillips, Addison" <[email-masked]>
> To: "Phillips, Addison" <[email-masked]>; "Randy Presuhn" 
> <[email-masked]>; "LTRU Working Group" <[email-masked]>
> 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" <[email-masked]>
Subject: Re: [Ltru] Issue #4: "different from" issue
To: <[email-masked]>
Message-ID: <006201c9909c$f6acfdc0$6801a8c0@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" <[email-masked]>
To: <[email-masked]>
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
[email-masked]

--------------------------------------------------------------------------------

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

------------------------------

Message: 4
Date: Mon, 16 Feb 2009 19:04:50 -0700
From: "Doug Ewell" <[email-masked]>
Subject: Re: [Ltru] Issue Tracker
To: "LTRU Working Group" <[email-masked]>
Message-ID: <ABF3D6D2CC164F24B433DC5DB460DDBF@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" <[email-masked]>
Subject: Re: [Ltru] Issue Tracker
To: "LTRU Working Group" <[email-masked]>
Message-ID: <000401c9912f$762fbbe0$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

As co-chair:

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Monday, February 16, 2009 6:04 PM
> Subject: Re: [Ltru] Issue Tracker
>
> > 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" <[email-masked]>
Subject: Re: [Ltru] Issue Tracker
To: Randy Presuhn <[email-masked]>, LTRU Working Group
	<[email-masked]>
Message-ID:
	<[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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" <[email-masked]>
> > To: "LTRU Working Group" <[email-masked]>
> > Sent: Monday, February 16, 2009 6:04 PM
> > Subject: Re: [Ltru] Issue Tracker
> >
> > > 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
> Randy
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

------------------------------

Message: 7
Date: Tue, 17 Feb 2009 11:35:15 -0800
From: "Randy Presuhn" <[email-masked]>
Subject: Re: [Ltru] Issue Tracker
To: "LTRU Working Group" <[email-masked]>
Message-ID: <000401c99136$dc59bd60$6801a8c0@oemcomputer>
Content-Type: text/plain;	charset="utf-8"

Hi -

As co-chair...

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

End of Ltru Digest, Vol 48, Issue 40
************************************

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 18 Feb 2009 10:51:06 -0800

Hi -

As co-chair:
PLEASE, if you are raising (or attempting to re-open) issues, PLEASE
use a different subject line for EACH issue for tracking sanity.  Otherwise,
I'll just assume this post was a bunch of rhetorical questions.

Randy

----- Original Message ----- 
From: "Lang Gérard" <[email-masked]>
To: <[email-masked]>
Cc: "Lang Gérard" <[email-masked]>
Sent: Wednesday, February 18, 2009 12:20 AM
Subject: Re: [Ltru] Ltru Digest, Vol 48, Issue 40

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 ?

Cordialement.
Gérard LANG

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 17 février 2009 20:35
À : [email-masked]
Objet : Ltru Digest, Vol 48, Issue 40

Today's Topics:

Message: 1

... 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.

(for the editors)

Addison

Addison Phillips

Message: 2

Hi -

RFC 2434 said:

RFC 5226 says:

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

Hi -

Randy

----- Original Message -----
From: "CE Whitehead" <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 16, 2009 9:01 AM
Subject: Re: [Ltru] Issue #4: "different from" issue

Hi!

Thanks!

--C. E. Whitehead
[email-masked]

Message: 4

Message: 5

Hi -

...

Randy

Message: 6

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

Message: 7

Hi -

As co-chair...

Randy