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

"Roy T. Fielding" <> Wed, 05 July 2017 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82ABD131C88; Wed, 5 Jul 2017 10:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BizkT1VFhzUx; Wed, 5 Jul 2017 10:40:00 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2910D131C81; Wed, 5 Jul 2017 10:40:00 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 8F6D5E036902; Wed, 5 Jul 2017 10:38:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=DK/a8Xow23nO7et9Bc9A7ySc/DE=; b=StIWitCY7ys1iS4UnHYJC6LYXhfB IdKDCMsyKG3hzs8EAiryuD9s5DgV3QFYRllM/lK6XjbXxO/p9U3gE1ZUr2/0mm3i HFRX5CT8hzne2HAPa1B3IRyvKNpDF3DTXt9CAySytVsyrNqLUSby9PcYqiQwP82Q cRWKFQDvt5XuUog=
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id D9D61E003A95; Wed, 5 Jul 2017 10:29:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Wed, 05 Jul 2017 10:29:18 -0700
Cc: Mark Andrews <>, dnsop <>, IETF Rinse Repeat <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Matthew Kerwin <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jul 2017 17:40:03 -0000

> On Jul 4, 2017, at 9:23 PM, Matthew Kerwin <> wrote:
> On 5 July 2017 at 13:19, Mark Andrews <> wrote:
>> In message <>, Matthew Kerwin writes:
>>> On 5 July 2017 at 10:02, Mark Andrews <> wrote:
>>>> Who owns a name is a different question to what machines serve the
>>>> <name,type,class> tuple and how do you reach those machines.  There
>>>> is absolutely no reason why the zones <name,IN> and <name,CLASS56>
>>>> need to be served by the same machines.  There is a argument for
>>>> them both being under control of the same people.
>>>> Mark
>>> Hi, I'm jumping in at a random time with a possibly dumb question, but
>>> the talk of <name,type> and <name,type,class> tuples got me wondering
>>> about representation in general, and URLs in particular.
>>> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks
>>> like a DNS name is a DNS name, and that they have to be resolved to IP
>>> addresses if you want to fetch them, but they don't talk meaningfully

No, RFC3986 does not say anything of the sort.  Neither does 7230.

>>> [*] :
>>>   """A registered name intended for lookup in the DNS uses the syntax
>>>   defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]."""
>>> I read that as: "if it matches RFC1034 (and isn't overridden by the
>>> specific URI scheme's rules) it's a DNS name."  It could be read the
>>> other way, but that just adds more assumptions.

Just read the text as written:  "A registered name intended for lookup in DNS ..."
which doesn't limit much at all, and certainly doesn't say that all dot-notations
are DNS names.

The sentence immediately preceding that one is:

   A host identified by a registered name is a sequence of characters
   usually intended for lookup within a locally defined host or service
   name registry, though the URI's scheme-specific semantics may require
   that a specific registry (or fixed name table) be used instead.

with both "usually" and "locally defined" being relevant.

And two paragraphs later it has:

   This specification does not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.  A URI resolution implementation might use DNS,
   host tables, yellow pages, NetInfo, WINS, or any other system for
   lookup of registered names.  However, a globally scoped naming
   system, such as DNS fully qualified domain names, is necessary for
   URIs intended to have global scope.  URI producers should use names
   that conform to the DNS syntax, even when use of DNS is not
   immediately apparent, and should limit these names to no more than
   255 characters in length.

And that's exactly how it works, in practice.