Subject: [Ltru] Re: Editor's copy of draft-initial-03

From: "Doug Ewell" <[email-masked]>
Date: Sat, 16 Jul 2005 12:24:39 -0700

I wrote:

> I've put up an editor's copy of draft-initial-03 at the familiar
> locations:
> ...
> I haven't submitted this yet because of the question of deprecating
> "zh-guoyu" in favor of the new "zh-cmn".

I apologize for this misstatement.  Since we are in Working Group Last
Call, this revised version will not be formally submitted until the end
of WG Last Call on July 28.  We need to make sure we are all reviewing
the same version of each draft.

The "zh-guoyu" question can be resolved at any time before the end of
WGLC (hopefully sooner rather than later), and the resolution will be
reflected in future editor's drafts if time permits.

Sorry for the confusion.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

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

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 17 Jul 2005 03:01:03 +0200

Doug Ewell wrote:

>> I haven't submitted this yet because of the question of
>> deprecating "zh-guoyu" in favor of the new "zh-cmn".
 
> I apologize for this misstatement.  Since we are in Working
> Group Last Call, this revised version will not be formally
> submitted until the end of WG Last Call on July 28.  We need
> to make sure we are all reviewing the same version of each
> draft.

In theory that makes sense, in practice there won't be new
I-Ds after Monday for more than two weeks, and therefore a
last snapshot before the IETF meeting could be interesting
(only for your part).

> The "zh-guoyu" question can be resolved at any time

Just get rid of it (= mark as deprecated inserting the new
preferred value plus a comment how to interpret the latter -
it's a case of a redundant preferred value, isn't it ?)

                           Bye, Frank

---

From: "Kent Karlsson" <[email-masked]>
Date: Mon, 18 Jul 2005 21:22:46 +0200 (CEST)

Hi!

I’ve looked a bit at the references sections for both the -registry draft
and the -initial draft, and I have the following comments.

=====================================================================

http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.txt says:

> 9.  References
>
> 9.1  Normative References
>
>    [ISO639-1]
>               International Organization for Standardization, "ISO 639-
>               1:2002, Codes for the representation of names of languages
>               -- Part 1: Alpha-2 code", ISO Standard 639, 2002, <ISO
>               639-1>.

The ", <ISO 639-1>" part does not seem to belong here...
Likewise for other references.

There is no mention of "edition" here.

>    [ISO639-2]
>               International Organization for Standardization, "ISO 639-
>               2:1998 - Codes for the representation of names of
>               languages -- Part 2: Alpha-3 code - edition 1",
>               August 1988, <ISO 639-2>.

1998 versus 1988? It should be 1998. But the date duplication seems
needless. The iso.org catalogue does not mention "August", but that
may still be correct.

The official ISO reference should be:

  ISO 639-2:1998,  Codes for the representation of names of languages -
  Part 2: Alpha-3 code, first edition

(not " - edition 1"; ", "Ed. 1" may be ok too).

There is no mention of "edition" for [ISO639-1], nor for [ISO15924].

>    [ISO15924]
>               ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the
>               representation of names of scripts", January 2004, <ISO
>               15924>.
>
>    [ISO3166]  International Organization for Standardization, "Codes for
>               the representation of names of countries, 3rd edition",
>               ISO Standard 3166, August 1988, <ISO 3166>.
>
>    [UN_M.49]  Statistical Division, United Nations, "Standard Country or
>               Area Codes for Statistical Use", UN Standard Country or
>               Area Codes for Statistical Use, Revision 4 (United Nations
>               publication, Sales No. 98.XVII.9, June 1999, <UN M.49>.
>
>    [ISO10646]
>               International Organization for Standardization, "ISO/IEC
>               10646-1:2000. Information technology -- Universal
>               Multiple-Octet Coded Character Set (UCS) -- Part 1:
>               Architecture and Basic Multilingual Plane and ISO/IEC
>               10646-2:2001. Information technology -- Universal
>               Multiple-Octet Coded Character Set (UCS) -- Part 2:
>               Supplementary Planes, as, from time to time, amended,
>               replaced by a new edition or expanded by the addition of
>               new parts", 2000, <ISO/IEC 10646>.

There is a newer version of this one, 2003, and this newer version is
not divided into parts.

>    [RFC2234bis]
>               Crocker, D. and P. Overell, "Augmented BNF for Syntax
>               Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00
>               (work in progress), March 2005.

Work in progress should not be a normative reference, unless one is
certain that that work will be finished (and the "work in progress"
remark removed) before this work is finished.

>    [ISO646]   ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, Information
>               technology -- ISO 7-bit coded character set for
>               information interchange.", 1991.
>
>    [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
>               3", BCP 9, RFC 2026, October 1996.

That should be an informative reference.

>    [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
>               the IETF Standards Process", BCP 11, RFC 2028,
>               October 1996.

That should be an informative reference.

>    [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
>               Part Three: Message Header Extensions for Non-ASCII Text",
>               RFC 2047, November 1996.

That should be an informative reference.

>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.

That should probably be an informative reference.

>    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
>               October 1998.

That should be an informative reference.

>    [RFC2781]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
>               10646", RFC 2781, February 2000.

That should be an informative reference, if needed at all.

>    [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
>               Understanding Concerning the Technical Work of the
>               Internet Assigned Numbers Authority", RFC 2860, June 2000.

That should be an informative reference.

>    [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
>               Timestamps", RFC 3339, July 2002.
>
>    [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
>               Text on Security Considerations", BCP 72, RFC 3552,
>               July 2003.

That should be an informative reference.

> 9.2  Informative References
>
>    [initial-registry]
>               Ewell, D., Ed., "Initial Language Subtag Registry",
>               June 2005, <http://www.ietf.org/internet-drafts/
>               draft-ietf-ltru-initial-registry-00.txt>.

I think this one should be a normative reference.

>    [iso639.principles]
>               ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory
>               Committee:  Working principles for ISO 639 maintenance",
>               March 2000,
>               <http://www.loc.gov/standards/iso639-2/
>               iso639jac_n3r.html>.
>
>    [record-jar]
>               Raymond, E., "The Art of Unix Programming", 2003.
>
>    [XML10]    Bray (et al), T., "Extensible Markup Language (XML) 1.0",
>               02 2004.
>
>    [XMLSchema]
>               Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2:
>               Datatypes Second Edition", 10 2004, <
>               http://www.w3.org/TR/xmlschema-2/>.
>
>    [Unicode]  Unicode Consortium, "The Unicode Consortium. The Unicode
>               Standard, Version 4.1.0, defined by: The Unicode Standard,
>               Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-
>               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.

If 10646 is a normative reference, then so should this one be.

>    [RFC1766]  Alvestrand, H., "Tags for the Identification of
>               Languages", RFC 1766, March 1995.
>
>    [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
>               Word Extensions: Character Sets, Languages, and
>               Continuations", RFC 2231, November 1997.
>
>    [RFC3066]  Alvestrand, H., "Tags for the Identification of
>               Languages", BCP 47, RFC 3066, January 2001.
>

======================================================================

http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.txt says:

> 7.  References
>
> 7.1  Normative References
>
>    [I-D.ietf-ltru-registry]
>               Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
>               Languages", June 2005.
>
> 7.2  Informative References
>
>    [ISO15924]
>               ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the
>               representation of names of scripts", January 2004.

I think this one should be a normative reference also for "ltru-initial"
(more than for the "ltru-registry" document), since data is culled from
this reference.

>    [ISO3166-1]
>               International Organization for Standardization, "ISO 3166-
>               1:1988 - Codes for the representation of names of
>               countries, 3rd edition", August 1988.

I think this one should be a normative reference also for "ltru-initial"
(more than for the "ltru-registry" document), and the RA’s registry itself,
since data is culled from this reference.

>    [ISO639-1]
>               International Organization for Standardization, "ISO 639-
>               1:2002 - Codes for the representation of names of
>               languages - Part 1: Alpha-2 code", 2002.

I think this one should be a normative reference also for "ltru-initial"
(more than for the "ltru-registry" document), and the RA’s registry itself,
since data is culled from this reference.

>    [ISO639-2]
>               International Organization for Standardization, "ISO 639-
>               2:1998 - Codes for the representation of names of
>               languages - Part 2: Alpha-3 code - edition 1",
>               August 1988.

1998 vs. 1988? (See comment on same reference in the -registry draft.)

I think this one should be a normative reference also for "ltru-initial"
(more than for the "ltru-registry" document), and the RA’s registry itself,
since data is culled from this reference.

>    [RFC1766]  Alvestrand, H., "Tags for the Identification of
>               Languages", RFC 1766, March 1995.
>
>    [RFC3066]  Alvestrand, H., "Tags for the Identification of
>               Languages", BCP 47, RFC 3066, January 2001.
>
>    [UN-M.49]  United Nations Statistical Division, "Standard Country or
>               Area Codes for Statistical Use", June 1999.

I think this one should be a normative reference also for "ltru-initial"
(more than for the "ltru-registry" document), and the RA’s registry itself,
since data is culled from this reference.

>    [record-jar]
>               Raymond, E., "The Art of Unix Programming", 2003.
>

Since the initial registry contains character references, 10646
and Unicode should be normative references also for the -initial
document.

=================================================================

Please use the same sort order for both -initial and -registry when
ordering the references, as well as the exact same formulation for
common references.

====================================================================

	/kent k

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Jul 2005 22:48:45 +0200

Kent Karlsson wrote:
 
 [RFC2234bis]
> Work in progress should not be a normative reference, unless
> one is certain that that work will be finished

That's intentional, and it's finished from our POV, compare
<http://www.rfc-editor.org/queue.html#crocker-abnf-rfc2234bis>

 [RFC2026]
> That should be an informative reference.

We need its appeal procedures, and they are not only for info.

 [RFC2028]
> That should be an informative reference.

Maybe, but one of 2860 and 2028 might be normative.

 [RFC2047]
> That should be an informative reference.

But it justifies / explains major parts of some length limits.
If that also works as informative reference it's fine.

 [RFC2119]
> That should probably be an informative reference.

No, that's definitely normative.

 [RFC2434]
> That should be an informative reference.

Yes.
 
 [RFC2781]
> That should be an informative reference, if needed at all.

Used in an example in chapter 2.1, where it essentially says
that you can't use laguage tags in any encoding without ALPHA,
DIGIT, or hyphen.

 [RFC2860]
> That should be an informative reference.

AFAIK Jefsey wanted it as "normative" for some details of the
appeal procedure.  I prefer to delete it keeping 2028 for info
(= explaining the acronym "IANA").

 [RFC3552]
> That should be an informative reference.

Yes.

 [initial-registry]
> I think this one should be a normative reference.

Then they'd point to each other as "normative".  For Martin's
strategy (= never publish the [initial-registry] as RfC, only
"last call" it and then let IANA create the real registry) we
could not reference it at all, or it has to be replaced by the
URL of the real registry.

> (http://www.unicode.org/versions/Unicode4.1.0).", March 2005.
> If 10646 is a normative reference, then so should this one be

Depends, if the IETF recognizes this private club as "official"
it could be "normative".  I don't find "unicode" on the page
<https://datatracker.ietf.org/public/liaisons.cgi>

 [ISO15924]
> I think this one should be a normative reference also for
> "ltru-initial" (more than for the "ltru-registry" document),

The idea is to create a new normative registry from the input
sources, not something that could be overruled by the input.

Dito all others informative references in the initial registry.
 
> Since the initial registry contains character references,
> 10646 and Unicode should be normative references also for
> the -initial document.

All informative references in the initial registry are only a
courtesy for the reader, the normative stuff is in the one and
only normative reference, i.e. the future 3066bis.  Bye, Frank

---

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 19 Jul 2005 00:20:16 +0200 (CEST)

> that you can't use laguage tags in any encoding without ALPHA,

That is a reference, as you say, from an *example*. I see no reason for
it to be normative. B.t.w., it is also covered by the (normative) reference
to 10646, which specifies UTF-16.

> Then they'd point to each other as "normative".  For Martin's

Yes, so? They are mutually dependent in normativeness.

> URL of the real registry.

That is a different matter, of course.

> sources, not something that could be overruled by the input.

I know. Making (a particular version) of this kind of reference
normative does not change that. The initial data is still "normatively"
culled from (particular versions of) these references.

		/kent k

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 Jul 2005 16:12:10 -0700

Hi -

As a technical contributor, I have a bunch of replies to Kent's comments.
I agree with many of them, but also disagree with a few.  See in-line below.

> From: "Kent Karlsson" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Monday, July 18, 2005 12:22 PM
> Subject: [Ltru] Reference lists
...
> remark removed) before this work is finished.

RFC2234bis should stay as is.  We want the most recent version, and
our AD wants us to use it, too.  Since we'll probably be heading for BCP
rather than Proposed Standard, it shouldn't be any issue anyway.

...
> That should be an informative reference.

Disagree.  Since RFC 2026 provides the rules for appeals, the reference
is normative.

> That should be an informative reference.

Agree.  The places where it is cited it only serves to provide the information
on what the IESG is.  All those places are immediately followed by a reference
to 2026, so in my opinion it would be a reasonable editorial change to remove
all references fro RFC 2028 from the document, since they add no information.

> That should be an informative reference.

Agree, since it is only used in an example justifying the choice of what might
otherwise seem to be an arbitrary number.

> That should probably be an informative reference.

Disagree.  Normal practice is to consider RFC2119 a normative reference,
since it provides definitions essential to the specification.

> That should be an informative reference.

I can see your point with respect to the -09 internet draft.
However, the resolution of issue #1075 affects this.
The wording currently on the table for this issue would make a
normative reference to RFC 2434, so I think this should stay in
the normative references section.

> That should be an informative reference, if needed at all.

I agree with making this an informative reference.  The sole citation is clearly
not normative.

>  That should be an informative reference.

Agreed, if it is needed at all.  Since IANA considerations sections are required
in all documents submitted for publication as RFCs, there seems to be little
point in putting in a reference to IANA.  I don't object to it, but it is clearly
informative rather than normative, if needed at all.

...
> That should be an informative reference.

Agreed.

> I think this one should be a normative reference.

That would be problematic.  The initial subtag registry is intended
for "informational".  If its content were to somehow change, it would in no way
cause the meaning of anything in the registry document.  Consequently, I
think "informative" is the correct designation.

...
> If 10646 is a normative reference, then so should this one be.

The only place where [Unicode] is cited is in an example, so the reference
is informative.  (From my point of view 10646 could have been referenced
here, allowing elimination of the Unicode reference.)

...
...
> (more than for the "ltru-registry" document), since data is culled from

I agree.

> (more than for the "ltru-registry" document), and the RA's registry itself,

Yup.

> (more than for the "ltru-registry" document), and the RA's registry itself,

Agreed.

...
> (more than for the "ltru-registry" document), and the RA's registry itself,

Agreed.

...
> (more than for the "ltru-registry" document), and the RA's registry itself,

Agreed.

...
> and Unicode should be normative references also for the -initial

Disagree.  The format is defined in the registry draft, which contains
the necessary references.  No need to pull in or flatten "indirect" references.

...

I suggest using the <?rfc sortrefs='yes'?> option in the xml2rfc source.

Randy

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Jul 2005 13:37:56 +0900

Hello Frank, others,

 ><https://datatracker.ietf.org/public/liaisons.cgi>

I find Unicode at http://www.ietf.org/liaisonActivities.html,
which means that there is a liaison. Your pointer is just a
list of liaison documents, and by chance, there are no such
for Unicode (such documents are important for ISO, ITU, ETSI,...
but not for other organizations).

Regards,    Martin.

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 Jul 2005 22:55:34 -0700

Hi -

> From: "Martin Duerst" <[email-masked]>
> To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
> Sent: Monday, July 18, 2005 9:37 PM
> Subject: Re: [Ltru] Re: Reference lists
...
...

True.  However, the existance of liaison relationships is orthogonal to
whether a normative reference is possible.  The "Tao" section 8.8
(http://www.ietf.org/internet-drafts/draft-hoffman-taobis-03.txt) says:

8.8  Normative References in Standards

   One aspect of writing IETF standards that trips up many novices (and
   quite a few long-time IETF folk) is the rule about how to make
   "normative references" to non-IETF documents or to other RFCs in a
   standard.  A normative reference is a reference to a document that
   must be followed in order to implement the standard.  A non-normative
   reference (sometimes called an "informative reference") is one that
   is helpful to an implementor but is not needed.  As we noted above, a
   "MUST" specification would certainly be normative, so any reference
   needed to implement the "MUST" would be normative.  A "SHOULD" or
   "MAY" specification is not necessarily normative, but it could be
   normative based on what is being required.  There is definitely room
   for debate here!

   An IETF standard may make a normative reference to any other
   standards-track RFC that is at the same standards level or higher, or
   to any "open standard" that has been developed outside the IETF.  The
   "same level or higher" rule means that before a standard can move
   from Proposed to Draft, all of the RFCs for which there is a
   normative reference must also be at Draft or Internet Standard.  This
   rule gives implementors assurance that everything in a Draft Standard
   or Internet Standard is quite stable, even the things referenced
   outside the standard.  This can also delay the publication of the
   Draft or Internet Standard by many months (sometimes even years)
   while the other documents catch up.

   There is no hard and fast rule about what is an "open standard," but
   generally this means a stable standard that anyone can get a copy of
   (although they might have to pay for it) and that was made by a
   generally recognized standards group.  If the external standard
   changes, you have to reference the particular instantiation of that
   standard in your specification, as with a designation of the date of
   the standard.  Some external standards bodies don't make old
   standards available, which is a problem for IETF standards that need
   to be used in the future.  When in doubt, a draft author should ask
   the WG chair or appropriate Area Director if a particular external
   standard can be used in an IETF standard.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Jul 2005 08:24:08 +0200

> I find Unicode at http://www.ietf.org/liaisonActivities.html,

Much better than my first Google hit, bookmarked, thanks.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 19 Jul 2005 01:25:04 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, July 18, 2005 1:48 PM
> Subject: [Ltru] Re: Reference lists
...
...

As a technical contributor I find Frank's argument more convincing than
Kent's, so I withdraw my comments on these references [ISO15924]
[ISO3166-1] [ISO639-1]  [ISO639-2] and [UN-M.49] in the initial registry.
I stand by my comments on the other reference comments.

I think Frank and I are largely in agreement on these, and trust the editors
will let us know if there are cases where looking at Kent's, Frank's, and my
comments leaves things in doubt.

Randy