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
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.
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
(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
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
(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
Nice statement by Martin follows, it bears repeating in the context of
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: firstname.lastname@example.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