Re: Last Call: draft-saintandre-tls-server-id-check

John C Klensin <john-ietf@jck.com> Mon, 19 July 2010 00:02 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C663A69A8 for <ietf@core3.amsl.com>; Sun, 18 Jul 2010 17:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.088
X-Spam-Level:
X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=1.511, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM+2jXGKAoCD for <ietf@core3.amsl.com>; Sun, 18 Jul 2010 17:02:40 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id D5D2E3A680B for <ietf@ietf.org>; Sun, 18 Jul 2010 17:02:39 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Oador-000Ot8-7b; Sun, 18 Jul 2010 20:02:53 -0400
Date: Sun, 18 Jul 2010 20:02:52 -0400
From: John C Klensin <john-ietf@jck.com>
To: =JeffH <Jeff.Hodges@KingsMountain.com>, IETF Discussion List <ietf@ietf.org>
Subject: Re: Last Call: draft-saintandre-tls-server-id-check
Message-ID: <F58003E6309229D79ACF41DD@PST.JCK.COM>
In-Reply-To: <4C437F0C.1030907@KingsMountain.com>
References: <4C437F0C.1030907@KingsMountain.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2010 00:02:41 -0000

--On Sunday, July 18, 2010 15:24 -0700 "=JeffH"
<Jeff.Hodges@KingsMountain.com> wrote:

> Paul Hoffman replied..
>  >
>  > At 5:22 AM -0400 7/17/10, John C Klensin wrote:
>  >> (1) In Section 4.4.1, the reference should be to the
> IDNA2008 discussion.
>  >> The explanations are a little better vis-a-vis the DNS
> specs and it is a
>  >> bad idea to reference an obsolete spec.
>  >
>  > +1. I accept blame on this one, since I was tasked on an
> earlier version to
>  > bring the IDNA discussion up to date.
> 
> Well, I wrote the "traditional domain name" text in
> -tls-server-id-check, and yes I looked at IDNA2008, but only
> -idnabis-protocol I think, and missed -idnabis-defs where said
> discussion resides. So mea culpa. Yes, the latter discussion
> is even better than the one in IDNA2003. Thanks for catching
> this.
> 
> Here's a re-write of the first para of -tls-server-id-check
> Section 4.4.1, I've divided it into two paragraphs..
> 
>     The term "traditional domain name" is a contraction of
> this more
>     formal and accurate name: "traditional US-ASCII
>     letter-digit-hyphen DNS domain name". Note that
>     letter-digit-hyphen is often contracted as "LDH".
> (Traditional)
>     domain names were originally defined in [DNS-CONCEPTS] and
>     [DNS] in conjunction with [HOSTS], though
>     [I-D.ietf-idnabis-defs-13] provides a complete, up-to-date
>     domain name label taxonomy.
> 
>     Traditional domain names consist of a set of one or more
>     non-IDNA LDH labels (e.g., "www", "example", and "com"),
> with
>     the labels usually shown separated by dots (e.g.,
>     "www.example.com"). There are additional qualifications,
> see
>     [I-D.ietf-idnabis-defs-13], but they are not germane to
> this
>     specification.
> 
> 
> how does that look?

Jeff, this works for me, but I don't think you really do the
spec's readers any favors by trying to reiterate the entire
history of terminology in this area (and, incidentally, leaving
things out that some folks might consider important like the
leading digit exception in 1123).  Someday, someone should
produce a definitive DNS terminology document, but this spec
shouldn't try to be it.

Given that, let me argue for simplicity.  Accept the definition
of "LDH label" from the RFC-to-be that represents
ietf-idnabis-defs-13, use that term where appropriate (you are
likely to need it where you discuss what gets converted to an
A-label) and, if you then need it at all, define "traditional
domain name" as consisting entirely of LDH labels.   

That avoids getting unnecessarily tangled up in the 1034/1035
text on the subject, the debate about whether pieces of the host
table definition are part of the normative story at all, and the
question of whether 2181 has to be read in a way that would
prevent your preempting "traditional" for this restricted set of
names, especially if you are trying to re-derive the rules from
primary sources.  And it shortens your text considerably.

    john