Comments on idnabis-rationale-01

[Frank Ellermann]

John C Klensin wrote:
 
> (1)  At present, LDH-label, A-label, and U-label are disjoint
> categories.

Yes, and that cannot work, because everybody knows what "LDH"
means, as specified in 2821bis and numerous other RFCs.  Any
newspeak "LDH-label" has no chance against this, it would be
hopelessly confusing.

Whatever else "xn--0zwm56d" might be, it IS an LDH-label, it
does work in hostnames for IETF protocols expecting hostnames.

> if LDH-label is to include both A-labels and traditional 
> ASCII labels (i.e., labels that do not start in "xn--"),

...and maybe <xn-label>s which are no A-label under IDNAbis...
   
> then we need a term for an LDH label that is not an A-label.

What for ?  We need <top-label> and likely <xn--label>.  But
other LDH-labels not starting with "xn--" are irrelevant for
the IDNAbis purposes.  

LDH-labels are by definition no U-label, if U-label requires
at least one non-ASCII character.  And that is the case, for
a simple disambiguation from A-label.  Therefore the rest of
the LDH-labels cannot affect us - there are more than enough
RFCs talking about them.

We also have no compelling reasons to talk about LDH-labels
with "--" at positions 3+4 of the label.  Therefore in the
spirit of KISS simply don't talk about it.  Only "xn--" is
what we are interested in wrt <ldh-label> and <top-label>.

> the general idea is to have categories that are disjoint
> and that, ideally, span the label space, not ones that
> overlap in some fuzzy way and therefore require additional
> qualification.

Sure, but the overall design principle is that all A-labels
are LDH-labels.  That's the one and only idea of IDNA.  This
discussion reminds me of discussions when folks proposed to
remove the one and only idea of SPF from SPF.  Some of these
folks had no problem with an 1 - 1 = 0 result, but I digress.

> people talked about "punycode" as a label type

For my simplified Chinese test "xn--0zwm56d" I'd guess that
would be "0zwm56d" with a required hyphen MIA.  IMO A-label
is fine, either as an "IDNAbis valid" subset of <xn--label>,
or instead of <xn--label> resulting in valid versus invalid
A-labels.  The latter is IMHO less desirable, but might work
if used consistently in all IDNAbis documents.

> This WG's scope rather clearly does not including modifying
> the DNS specifications, particularly 1034, 1035, and 2181).

ACK, but IDNAbis needs the <top-label> 1123-fix for IDN TLDs.
Therefore it's the job of IDNAbis to do this, especially now,
after the simple errata-approach was rejected.  

> getting entangled in debates similar to those that recently
> raged on the IETF list about domain names and host names
> would be unwise

Most of these articles had "2606" in the subject and did not
even remotely talk about RFC 2606, let alone the 2606bis I-D.

That is IMO no problem, I read all the articles, and where it
was remotely related I added the contributors to the credits.

There were a few tangible ideas:  Notably ".tld" in examples;
why I18N of ".invalid" or ".localhost" would be wrong; and
why ".bar", ",bat", ".baz" might be ".bad" ideas.  

No new insights wrt <top-label>, and your 1123-erratum would 
kill all reported oddities (my 3696-version missed 0x).  Now
after both errata were rejected we need one line of ABNF to
define it, and the four digits 1123 (in this order) in an
XML source to get an "updates: 1123" effect.

We already agree that 2606bis is not the place to pull this.

Let's do it elsewhere, rationale or protocol or in a unified
IDNAbis draft.  Doing it nowhere is no option, after all we
want IDN TLDs.  Asking DNS folks to do this now for us, while
they have a major crisis, would be not only unwise, it cannot
work...  My crystal ball says.

> redefining the syntax or length of LDH-label (while making
> it the superset definition while you prefer), specifying
> its length, etc., or about defining a <top-label> category
> that is not needed for the IDNA2008 protocol or tables, are,
> I believe, out of scope and inappropriate.

Nobody proposed to redefine LDH-label.  It is what it always
was, LD, optionally followed by up to 62 LDH ending with LD.

You only need this syntax with a reference, in the direction
of "as specified in RFC 1123 (among others)".  Based on that
it is a mere clerical task to specify the minimally different
<top-label> and say that this updates a note in RFC 1123 2.1.

I'm not going to repeat the details the third time here - or
rather for the 1001st time since I proposed a "toplabel task
force" in USEFOR back in 2006.

We do agree that we want IDN TLDs, or don't we ?  IFF we do
it is our job to fix RFC 1123, the individual attempts based
on RFC 3696 with errata didn't fly.  We can't ask say EAI to
do it for us, IDN TLDs are no E-mail Address I18N experiment.

> 3987 (the IRI spec) must inevitably reference (normatively)
> IDNA

It does.  And 3987bis is not the place to define <top-label>;
it will simply update these references from IDNA to IDNAbis.
(In a "downref", but that's no serious obstacle for 3987bis.)

 Frank