[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Final remarks concerning requirments
- To: idn@ops.ietf.org
- Subject: [idn] Final remarks concerning requirments
- From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
- Date: Sun, 16 Dec 2001 11:00:36 -0500
If we pick and choose between contradictory, or underspecified statements,
we can end up with fewer statements which do, in principle, either cohere,
or are completely specified, or both. To be true, however, these statements
must correspond to implementations, or be capable of implementation.
Memos that document requirements, whether partially or completely, whether
contradictorily or harmoniously, have the innate utility of providing well
known, and possibly critically annotated, points of reference.
Several alternative sources exist for statements of technical requirements:
- other memos originally published as Internet Drafts,
- other technical bodies also affiliated with ICANN,
- other technical bodies, not affiliated with ICANN,
Additionally, alternative sources exist for statements of general requirements,
arguably these are ill-posed as "technical" memos, but in some contexts these
are considered "technical":
- statements from MINC,
- one or more statements from ICANN DNSO Constituencies,
- functional specifications available from application, connectivity,
and nameserver vendors and operators,
I suspect neither of these two lists of alternative sources is exhaustive.
The corrollory is that of necessity, absent any distinct requirement
statement(s), other than those contained and satisfied in specific memos,
e.g., draft-ietf-idn-idna, draft-ietf-idn-nameprep, etc., alternative
requirements statements are not merely subordinate to, or co-equal with,
a IDN WG requirements document, but the better technical authority, for any
area outside the scope of requirements captured incidently in any specific
draft such as the idna set of drafts.
I've never anticipated that the IETF would become generally irrelevant to
the problem of 7-bit processing, retaining only specific relevance as one
source of niche presentation-level work-arounds. I hope this isn't what this
WG chooses, and urge those not predisposed otherwise to express a preference
that a requirements document remains under the change control of the working
group.
Fixing it, which in practice means at least directing its editors to maintain
the utility of the draft, is a distinct issue, and already addressed by one
assertion of process error.
Eric