Re: Unicode/ISO 10646 BOF in Munich

From: Eric Brunner (teb@opengroup.org)
Date: Thu Jun 05 1997 - 12:10:27 EDT


Personally Martin, I don't think it inappropriate to seek something more
substantive than a one-time BOF at Munich, let alone just that, though I
do think the presumption that such is sufficient to be optimistic.

Like yesterday's note, this is long.

The IAB directive I mentioned yesterday is met, with differing degrees of
sucess, by many of the Working Groups functioning under the IETF aegis.
The list of work-products, I-Ds, RFCs, STDs and FYIs that make mention
of some mechanism for handling code sets is rather large. Having to work
through the limitations of each in isolation, possibly repeated across a
wide number of distinct "area" incantations, is unattractive. How many
times must we repeat our nastiest fights over unification or other nuances?

Would the networking community (taken loosely) "sit still" if we invented
packet formats and transport protocols for each code set? Obviously only
until their sense of humor abated. The same onus of due dilligence is
imposed upon that community.

We had, between the Unicode Consortium and X/Open (now, again my employer,
as "The Open Group", formed chiefly by the join of X/Open and OSF), the
XoJIG vehicle, which had some utility and lasting deliverables. At present,
we've no distinct institutional venue for UTC-IAB technical work.

When did you write to Keith and Harald? (the IETF AA Directors)

I for one see no reason why the IABs directive on the subject of character
sets ought not to result in the issuance of a charter and agenda consistent
with that directive, though into which particular area directorate this
pan-service issue best fits may be solved with dice.

From the Working Group Guidelines <draft-ietf-poisson-wg-guide-00.txt>:
[pages 1 and 2]
   The IETF is a large, open community of network designers, operators,
   vendors, users, and researchers concerned with the Internet and the
   technology used on it. The primary activities of the IETF are
   performed by committees known as working groups. There are currently
   more than 70 working groups. ( See the IETF web page for a up-to-date
   list of IETF Working Groups - http://www.ietf.org.) Working groups
   tend to have a narrow focus and a lifetime bounded by the completion
   of a specific set of tasks, although there are exceptions.

   For management purposes, the IETF working groups are collected
   together into areas, with each area having a separate focus. For
   example, the security area deals with the development of security-
   related technology. Each IETF area is managed by one or two Area
   Directors. There are currently 8 areas in the IETF but the number
   changes from time to time. (See the IETF web page for a list of the
   current areas and for a list of which working groups are assigned to
   which area.)

   In many areas the Area Directors have formed an advisory group or
   directorate. These comprise experienced members of the IETF and the
   technical community represented by the area The specific name and
   the details of the role for each group differs from area to area, but
   the primary intent is that these groups assist the Area Director(s),
   e.g., with the review of specifications produced in the area.

Cite:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-poisson-wg-guide-00.txt

Turning to Section 2.1 of the same POISSON WG I-D, Criteria for formation
of an IETF Working Group (numbering added for clarity):

(1) - Are the issues that the working group plans to address clear and
      relevant to the Internet community?

Yes, and yes.

(2) - Are the goals specific and reasonably achievable, and achievable
      within the time frame specified by the milestones?

Well, a statement of goals slightly more detailed than those captured in
the IAB minutes of April 8, 1997 could help, along with a statement of the
proposed milestones. However, some WGs do not have a bounded lifetime, and
ideosyncratic proposed solutions to character set issues in IETF WG work
products may be the lifetime bounding factor. 70 WGs is a lot of paper to
sift.

(3) - What are the risks and urgency of the work, to determine the level
      of attention required?

Like (1), this is in essence, asked and answered by the IAB itself.

(4) - Do the working group's activities overlap with those of another
      working group? If so, it may still be appropriate to create the
      working group, but this question must be considered carefully by
      the Area Directors as subdividing efforts often dilutes the
      available technical expertise.

Obviously. The obvious question to ask however is why such activity is at
present duplicated with the obvious dilution of available technical expertise.

(5) - Is there sufficient interest within the IETF in the working group's
      topic with enough people willing to expend the effort to produce
      the desired result (e.g., a protocol specification)? Working
      groups require considerable effort, including management of the
      working group process, editing of working group documents, and
      contribution to the document text. IETF experience suggests that
      these roles typically cannot all be handled by one person; a
      minimum of four or five active participants are typically
      required.

If "within the IETF" is expanded to include, say, the UTC, the answer appears
to be a solid "YES". The "within the ..." issue is nuanced elsewhere as the
IAB has an external expertise solicitation mechanism -- asking or accepting
an offer.

(6) - Is there enough expertise within the IETF in the working group's
      topic, and are those people interested in contributing in the
      working group? - Does a base of interested consumers (end users)
      appear to exist for the planned work? Consumer interest can be
      measured by participation of end-users within the IETF process, as
      well as by less direct means.

The first part of this criteria is met in the response to (5), above. The
second is met by the startling observation that there are living writing
systems other than modern colonial English. Of course, this is an appeal
to a "less direct means".

(7) - Does the IETF have a reasonable role to play in the determination
      of the technology? There are many Internet-related technologies
      that may be interesting to IETF members but in some cases the IETF
      may not be in a position to effect the course of the technology in
      the "real world". For example, if the technology is being
      developed by another standards body or an industry consortium.

Yes. Clearly the UTC has an interest, but that interest isn't intrusive into
wire encodings or protocol specifications, at least not obviously to me.

(8) - Are all intellectual property rights relevant to the proposed
      working group's efforts issues resolved.

This criteria appears to be either met, or moot.

(9) - Is the proposed work plan an open IETF effort or is it an attempt
      to "bless" non-IETF technology where the effect of input from IETF
      participants may be limited.

Yes, but only in the same sense that ASCII or EBCDIC are also "non-IETF
technologies" with the same limitation upon IETF participant input. Further,
the _use_ is what is at issue, not the content of UTC work product.

Given the above, my suggestion is that we (UTC members and/or periphery,
and I'm peripherial) offer, not simply to the AA Directors, but to the IAB
as a body, the opportunity to constitute a WG with a charter consistent to
the IAB minutes of April 8, 1997, and a membership of some unicode-list
and IETF-lists volunteers.

Until my medication wears off and I cease thinking I'm in charge of the
world, I'd draft Martin, Rick, Alain, Glenn, David, ... for this onerous
task.

Nice statement by Martin follows, it bears repeating in the context of
this sub-thread.

    Not every application protocol may need a different solution. But
    each application protocol should carefully consider the interaction
    of language with other protocol parameters and features, and think
    things through. If several protocols can share the same solution,
    that's fine, but to think that a single solution can just be
    pluged in everywhere is dangerous.

Kitakitamatsinohpowaw (I'll see you again, in Siksika/Blackfeet),

Thomas Eric Brunner email: teb@opengroup.org
Principal Research Engineer http://www.opengroup.org/~teb
The Open Group Research Institute http://www.opengroup.org
11 Cambridge Center Tel: (617) 621-7314
Cambridge, MA 02142 FAX: (617) 621-8696



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT