IETF Logo Mail Archive

Re: Openness (Re: UTF-16)

Valdis.Kletnieks@vt.edu Tue, 14 September 1999 15:50 UTC

Received: by ietf.org (8.9.1a/8.9.1a) id LAA26085 for ietf-outbound.10@ietf.org; Tue, 14 Sep 1999 11:50:02 -0400 (EDT)
Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25662 for <ietf@ietf.org>; Tue, 14 Sep 1999 11:41:25 -0400 (EDT)
Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Beta0/8.10.0.Beta0) with ESMTP id d8EFeJl04280; Tue, 14 Sep 1999 11:40:19 -0400
Message-Id: <199909141540.d8EFeJl04280@black-ice.cc.vt.edu>
X-Mailer: exmh version 2.1.0 04/14/1999
To: Harald Tveit Alvestrand <Harald@Alvestrand.no>
Cc: ietf@ietf.org
Subject: Re: Openness (Re: UTF-16)
In-Reply-To: Your message of "Tue, 14 Sep 1999 01:31:24 +0200." <4.2.0.58.19990914012601.01cd1b60@dokka.maxware.no>
From: Valdis.Kletnieks@vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#; 3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[<!v4-0bVIpaxF#-) %9#a9h6JXI|T|8o6t\V?kGl]Q!1V]GtNliUtz:3},0"hkPeBuu%E,j(:\iOX-P,t7lRR#
References: <19990913013842.A3991@light.dkuug.dk> <4.2.0.58.19990914012601.01cd1b60@dokka.maxware.no>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_940497696P"; micalg="pgp-md5"; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 14 Sep 1999 11:40:14 -0400

On Tue, 14 Sep 1999 01:31:24 +0200, Harald Tveit Alvestrand said:
> We gave up on "open" having to mean "free" a *very* long time ago.
> We've even given up on "online" meaning "free" - see ITU.

A bad choice of examples on my part (although recent mail from Francois Yergeau 
indicates that cost *is* an issue:

  Given the price and accessibility of ISO standard, and especially of 10646,
  it is a fact that the Unicode terminology is much more widely known and

> "open" means something like (IMHO):
> 
> - the content is accessible to all in some fashion (which may involve
>    tossing money at the problem); everyone gets the same content

There's an implicit assumtion here that the standard that you throw money
at is (a) functional and (b) still aligned with what the RFC intended.
Given that some standards (such as ISO-3166) are by definition moving
targets, this is a potential problem...

> - the procedure for changing it is known, and administered by some body that
>    is regarded as "neutral" under some (sometimes contorted) meaning
>    of that term

Read RFC1829, with its normative references to FIPS-46.
Now ponder the implications if the US Government gets even more
silly in its stance regarding the export of cryptographic information.

The point I made badly was that RFC2026 makes no discussion of what
to do if a section 7.1.1 "standards body" becomes unable, for whatever
reason, to act in a "neutral" manner, *or* manages to break a standard
that we've included as a normative reference.

This isn't purely hypothetical - we've already seen allegations that
ISO3166 has been used as a political tool for not recognizing new
countries.

Seen in RFC1101 (April 1989):

   Note that "YP" is NOT a valid country code under [ISO 3166] (although
   we may want to worry about the future), and the existence of a

I think if RFC2026 is ever overhauled, section 7.1.1 needs some more
text regarding what to do if normative reference is made to an external
standard that may in some way become broken over time.  Possible solutions
include requiring citing specific releases/modifications/versions,
or requiring a discussion of what to do if a moving-target standard
such as 3166 or one of the charset standards ecomes broken.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

v2.23.0 | Report a Bug | By Email