RE: [idn] NSI Multilingual Testbed Information (fwd)

[John C Klensin <klensin@jck.com>]

Bill,

Let me try, once more, in short sentences:

	* If one is going to use UTF-8, 2279 unquestionably
	specifies the IETF-approved definition of UTF-8.
	
	* The working group is expected to find the right --from
	an engineering standpoint-- solution for its
	requirements.  If that is UTF-8, then a 2279-compatible
	interpretation of UTF-8 is expected.  If it is not UTF-8,
	the WG will be expected, _at most_, to explain coherently
	why UTF-8 was not chosen.   And, if the WG finds that it
	needs to use a different interpretation/ definition of
	UTF-8 than that in 2279, it will be expected (at least by
	me and I will insist fairly loudly) to explain why that
   is necessary _and_ to propose changes to 2279 if 
   appropriate.
	
	* The activity of playing Protocol Lawyer (or Standards
	Lawyer) has never been considered an acceptable
	substitute for hard engineering work, logic, and careful
	consideration of alternatives around IETF, and this WG
	will not be the first exception.

There may be good reasons for using UTF-8 as defined by 2279.
There may be good reasons for using some other variation of
UTF-8, or something else entirely.  But let's focus on the
reasons in terms of IDN requirements and constraints and lose
"there is a standards-track doc, or BCP, or collection of letters
on stone tablets, that says we should do it that way" as an
argument.  Those earlier documents just may not be applicable (as
Patrik pointed out, the whole Character Set workshop was focused
on a different set of issues).  The WG needs to figure out if
they are appropriate, and pointing repeatedly to them as
justification for selecting them is just not useful or
appropriate.

      john
      (again, putting on Technical Advisor hat)


--On Sunday, 27 August, 2000 10:53 -0400 "J. William Semich"
<bill@mail.nic.nu> wrote:

> Ran:
> 
> At 08:46 AM 8/27/00 -0400, RJ Atkinson wrote:
>> At 20:58 26/08/00, J. William Semich wrote:
> 
>>> 2. It [the IETF] has actually set a standard for (or has put
>>> on a
> standards track)
>>> UTF-8 itself under RFC 2279.
>> 
>> Not quite. 
> 
> 
> Yes, quite exactly. RFC 2279 is a standard (or standards track
> document) which specifically defines a standard for UTF-8,
> including versioning information. The information in section 5
> doesn't change that.  AFAIK, the final language of the RFC will
> function as the IETF standard for UTF-8 implementations,
> period. 
>...