Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

John C Klensin <john-ietf@jck.com> Thu, 06 July 2017 18:04 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6A13188A; Thu, 6 Jul 2017 11:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmLOzk9ivNm2; Thu, 6 Jul 2017 11:04:20 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79F1131879; Thu, 6 Jul 2017 11:04:20 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1dTB8S-0009TV-WC; Thu, 06 Jul 2017 14:04:17 -0400
Date: Thu, 06 Jul 2017 14:04:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: Mark Andrews <marka@isc.org>, "Roy T. Fielding" <fielding@gbiv.com>
cc: dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Message-ID: <901C29488D8446E4176CF83E@PSB>
In-Reply-To: <20170705231101.E23E77D9B7A1@rock.dv.isc.org>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com> <20170705031957.834B97D8FBDD@rock.dv.isc.org> <CACweHNCAmZPOUmat5ruh6qkYrECM2fh15n49P+zDcJ0gfoEGvg@mail.gmail.com> <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com> <20170705231101.E23E77D9B7A1@rock.dv.isc.org>
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-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BACsp7Fmrg-NTYwA3ubfUBle-Uw>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 18:04:22 -0000


--On Thursday, July 6, 2017 09:11 +1000 Mark Andrews
<marka@isc.org>; wrote:

>...
> And the actual presentation limit for LDH with DNS is 253
> (encodes as 255 octets on the wire).  Remember URI names do
> not have a final period and the each label has length octet
> when encoded as a DNS name and the name is terminated by the
> root label (0x00) in DNS wire form and the DNS wire name is
> limited to 255 octets.

Mark,

My apologies for nit-picking, but RFC 3986, Section 3.2.2 is
quite clear than DNS names in URIs are permitted to have a final
period and encouraged to do so under some circumstances.
Specifically,

	"The rightmost domain label of a fully qualified domain
	name in DNS may be followed by a single "." and should
	be if it is necessary to distinguish between the
	complete domain name and some local domain."

I don't think that changes the 253 octet limit, but the comment
about URIs is misleading and could contribute to an, IMO,
already high level of confusion about what RFC 3986 does or does
not specify.

The same subsection of RFC 3986 also uses the term "host
subcomponent" for what you are referring to as a name and allows
it to be a "registered name" (or <reg-name>) that might not be a
DNS name or reference at all -- whether it is or not is
scheme-dependent. 

best,
   john