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

Mark Andrews <marka@isc.org> Fri, 07 July 2017 00:44 UTC

Return-Path: <marka@isc.org>
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 09CB9129562; Thu, 6 Jul 2017 17:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XckLVaVw8iFw; Thu, 6 Jul 2017 17:44:21 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970461293D6; Thu, 6 Jul 2017 17:44:21 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 3DCAA24AE09; Fri, 7 Jul 2017 00:42:58 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D147D160047; Fri, 7 Jul 2017 00:43:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8A298160098; Fri, 7 Jul 2017 00:43:01 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jWbkpEXdm5hh; Fri, 7 Jul 2017 00:43:01 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3B6F8160047; Fri, 7 Jul 2017 00:43:01 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 541A17DB62A2; Fri, 7 Jul 2017 10:42:59 +1000 (AEST)
To: John C Klensin <john-ietf@jck.com>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
From: Mark Andrews <marka@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> <901C29488D8446E4176CF83E@PSB>
In-reply-to: Your message of "Thu, 06 Jul 2017 14:04:10 -0400." <901C29488D8446E4176CF83E@PSB>
Date: Fri, 07 Jul 2017 10:42:59 +1000
Message-Id: <20170707004259.541A17DB62A2@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sGUhxPNet4Shl-Nok8DRFxszO00>
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: Fri, 07 Jul 2017 00:44:23 -0000

In message <901C29488D8446E4176CF83E@PSB>, John C Klensin writes:
> 
> 
> --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

Which really should never have been allowed.  Beyound the UI
everything should be absolute.  Relative names in URI really don't
work in practice because search lists are not constistent even
inside a single organisation.

I had my ISP hand me a relative link for their support pages.  IT
DID NOT WORK.  There support line got a call complaining about it.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org