[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE:Who's proble? (was [idn] Mixed TC/SC (was Re: Layer2 and "idn identities"))
--On Friday, 07 December, 2001 07:13 -0500 "Hollenbeck, Scott"
<shollenbeck@verisign.com> wrote:
> Is the issue of mixed TC and SC an engineering issue, or a
> policy issue? I haven't seen much on this thread to suggest
> that an engineering issue exists. If registrar or registry
> guidelines are being described as the way to resolve the
> issue, Rick is probably right about this not being an IETF
> issue, but a DNSO issue.
Scott,
FWIW, I think there are significant engineering issues in TC/SC,
"mixed" or otherwise. Clearly some of the possible "solutions"
are policy-only. E.g., to ban registration of "mixed", or of a
[label containing a] TC character when a corresponding SC
character exists, etc., would be policy decisions. Other
approaches, including most mapping approaches and the boundaries
to their effectiveness, are engineering problems.
While the locus for decisions about recommendations is different
(see my earlier note about what either IETF or ICANN can
compel), some of these are inexorably intertwined and, IMO, we
either create confusion or abdicate responsibility if we try to
draw hard lines. I believe that we have some responsibility to
define and explain to the policy people what the alternatives
actually are and what boundaries and constraints exist around
various solutions. That is particularly important if we come
up with an engineering proposal that is workable only if
specific policy decisions are made. E.g., if we had a solution
for TC/SC that would work iff registration of names containing a
mix of TC and SC characters were banned, I think we would be
obligated to be sure that ICANN and the various domain
administrators were aware of that restriction and of what would
happen if it were violated (that requirement would be even
stronger if we had to ban labels containing a mix of Chinese and
non-Han characters).
Indeed, my personal belief is that we would need to go further
than that. IETF standards are based on, and ultimately credible
and accepted only if they obtain, community consensus. That
"community" is usually defined as "within the IETF", but that is
because we believe that we have all of the interested parties
participating in the process (or deciding to not participate).
But, where a protocol requires, for its proper implementation
and interoperable deployment, that particular policy decisions
be made, I think our consensus process has to extend out enough
to the policy people to be sure they consider those restrictions
reasonable.
We cannot, responsibly, I think, say "this protocol will work
acceptably only if pigs fly" and then standardize the protocol
any more than we think ICANN (or some other body) can,
responsibly, say "we are going to adopt this policy, which will
work well only if the laws of physics don't apply".
Of course, none of this addresses the question of whether any of
this is appropriately on the IDN WG agenda. That is a separate
issue.
john