Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

["James Seng" <jseng@pobox.org.sg>]

I have tried to remain silent and observe the discussion going on.

I think the discussion of IETF history, experience and best practice should
be bought to another list (poised?) or offline, despite the education value.
Given we are in the last stage of the wg, I dont think we have too many
newcomers lately.

Thanks.

-James Seng

----- Original Message -----
From: "Dave Crocker" <dhc@dcrocker.net>
To: "John C Klensin" <klensin@jck.com>
Cc: <idn@ops.ietf.org>
Sent: Sunday, June 16, 2002 5:08 AM
Subject: Re: [idn] IDNA: is the specification proper, adequate, and
complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)


> At 09:59 AM 6/11/2002 -0400, John C Klensin wrote:
> >         Is IDNA properly and adequately specified for the uses to
> >         which it will be put and is it designed appropriately
> >         for that range of uses?
> >
> >I think the answer is probably that more specification, tightly
> >bound to IDNA, is needed.  In terms of the sequencing of things,
> >I believe that the beginning of serious work on those
> >specifications will expose specification problems with the
> >current IDNA spec.
>
> It is certainly true that further work will develop further
> understanding.  In this business, that's a truism.
>
> The pattern of IETF experience suggest a number of interesting guidelines,
> some of which are impressively counter-intuitive.
>
> And intuitively obvious rule is that a complex problem needs to be studied
> carefully and thoroughly and the solution needs to be complete, before it
> is release.
>
> The rule is wrong.
>
> IETF experience shows that consistently, yet it is being cited here.
>
> The rule that works -- especially for a new effort -- it to find a way to
> release the smallest, useful piece of work as quickly as possible, so that
> the learning and improving can be based on experience, rather than on
> academic introspection.
>
> It is essential to note both words -- smallest and useful.  The former
> permits releasing something quickly, though one is hardpressed to find a
> way to apply the word quickly to IDN.  The latter ensures market pull to
> deply and use the new facility.
>
> Infinite delay of the IDN work will have one major benefit:  The current
> proprietary solutions will gain permanent position in the market.  The
> derivative likelihood is that the IETF work will cease to matter.
>
> We have an excellent example of this possibility with instant
> messaging.  Let's not repeat it for IDN.
>
>
> >(i) The specification now appears to say that applications can
> >decide to use IDNA or not.
>
> Yes, it is a meaningless statement and should be removed.  IETF standards
> are always optional.
>
> In other words, the problem is with the presence of the statement.  The
> statement itself does not cite a meaningful problem.
>
>
> >(ii) The specification seems inconsistent about what it about
> >and who needs to understand it.
>
> So the applicability text needs clarifying.  Not the normative text.  That
> is hardly a major issue.
>
>
> >   It implies in several places
> >that it is not about the DNS and has no impact on the DNS.
>
> Yes, the text could be more clear.  That is often true of new
> text.  However this example of needing greater clarity again does not
> pertain to normative specification.
>
> My own effort to work through the text suggests that the specification
> really covers 3 issues:
>
> 1.  Enhancement of the DNS label namespace, to expand to include
Unicode --
> IDN.  This is clearly a change to the formal DNS model.
>
> 2.  Provision of a general mechanism for encoding Unicode (non-Ascii) into
> a portion of the ASCII namespace -- ACE.  This requires reserving a piece
> of the existing name space.  It also requires changes to participating
> resolvers (or the software that calls resolvers) and to DNS server
> administrative tools.  However it requires no changes to the DNS protocol,
> nor to non-participating DNS entities.  Obviously it also requires changes
> to participating applications, but that is a matter concerning support for
> Unicode, rather than anything about the DNS, itself.
>
> 3.  Rules for creating internationalized host names (ie, domain names
> intended for use in URLs and email addresses) by using IDNA but still
> working under both STD13 and STD3.  For convenience, I am starting to call
> this IDNA-Host.
>
>
> >(iii) Despite the "applications can choose to do this, or not do
> >it" language, section 6.4 effectively implies a requirement that
> >any application that uses the DNS be upgraded.
>
> If a DNS entity is going to participate in IDNA, it must be upgraded.
That
> is a truism.  Here again, the real problem is that the attempt to help
> clarify things has been counter-productive.  The right solution is simply
> to remove that bit of text.  It is not normative;.
>
>
> >(iv) Section 7 imposes several normative requirements on name
> >servers and zone populations.  ...
> >
> >(v) In particular, several of the statements in the draft go
> >beyond almost anything we have about the DNS in trying to
> >narrowly constrain the behavior of RR labels and data that are
> >not yet defined,
>
> Interestingly, I believe the real problem here is with trying to do
exactly
> what you are proposing, namely to work on a whole problem, rather than
> first solving the smallest, immediately useful part that can be done.  So,
> here again, the right answer is to factor out the larger work for a later
> time.  (My reading of your note suggests you might even agree on this
point.)
>
> That immediately useful work needs to be about domain names -- and more
> specifically about the strings that are used in URLS and email
> addresses.  Other domain labels that occur within DNS RRs can be
considered
> in separate work.
>
>
> >(vi) I suggest that it is a useful general principle to design
> >service ("micro layer" to use Dave's term) protocols to be as
>
> The IDNA document's term is "shim".  I find myself preferring the
> contextual implications of that word.  Micro-layer works as a formalism,
> but shim is a term that carries more information.
>
>
> >general as feasible without making them overly complex.
>
> What generality is lacking from the current IDNA spec?
>
>
> >It should be revised and some of that material should be pulled
> >out and into separate documents.  As an alternative, that
> >material should be highlighted: the abstract and introductory
> >material should indicate that these normative DNS requirements
> >are present, that 2181 is explicitly updated, and so on.
>
> >Finally, the apparent reach of the protocol should be narrowed
> >and specified, either in this document or elsewhere.
>
> This is amusing.
>
> You are suggesting a bit of work that I believe is straightforward
document
> cleanup, rather than substantial delay.
>
> I agree with you.
>
> d/
>
>
> ----------
> Dave Crocker <mailto:dave@tribalwise.com>
> TribalWise, Inc. <http://www.tribalwise.com>
> tel +1.408.246.8253; fax +1.408.850.1850
>
>
>