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

william manning <chinese.apricot@gmail.com> Wed, 05 July 2017 02:36 UTC

Return-Path: <chinese.apricot@gmail.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 3CCB11243FE; Tue, 4 Jul 2017 19:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fvaAeWbhxZBS; Tue, 4 Jul 2017 19:36:44 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 6D5EF127601; Tue, 4 Jul 2017 19:36:44 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id h64so78723921iod.0; Tue, 04 Jul 2017 19:36:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1dqQGD5puf7Dlu+IcYs4nRjWmT+Ly9rk1Ar4UTxGMMM=; b=U6+NChRKrY+xJ3+CpxaEAYnQwywpLw+mY9xlToOMgXJJ6hKI7a2lYkopfmvPuVbvXx d2mylhEo1Y1mmYV6n/3kP8jcQYPyyzfRqkSaKHiOCTqSon2MssMB7qpRsooZEB1Djloo vHQTBS58+rzMt7U3wsGnj8aJ2krTiB9cU5T1gKFTzwIe9NtDmD16JlFr/UEh2QPSUFba TvsdgboHKMMHp2Kbr4mHIgBIsv38DBnPIoTrQxMOQRHMm00owH+7QRQpZ9NeHD358eZq m/jcsYtutn/IXL9o1i+yhQL5Ax5lfjzwioYYH63zl8om+B+5ebHC3bShYHzg7qbg4P25 harg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1dqQGD5puf7Dlu+IcYs4nRjWmT+Ly9rk1Ar4UTxGMMM=; b=ZzbLXfHMEVSKxH7E+0v44Kj5hFMe4BS02atjQYHXyr+mohatdj/xD8wRanJUijIGJi l41VigUjIuPTSzh+f5XixKCeqly7JYSRjNldZWrKTmuoHBXCFas81iLvxNMIoV1XngNG Fqoqxq3EaWCzyZhHmCVVPkauMFU3ACdsxskCkqR4U2e+iU86cXTktX2zJwnFEupBudOK SNoJLRyC9MrVKfW8waElAcSIFzgUxBUTPzolmSI95amdxZq1Rzhz5tQMjsTfqHOfY0tM BoPL8D/pNg4n8fIkHdk5wGTia5IU4IFKVMVmRzEVXRe2dcKxKcazycwRkwUlCZJBVoyY szSw==
X-Gm-Message-State: AKS2vOwfnpQD/k8phEE9qWq7XKtjxmdIgwvF9bRdqFnVnjMMo1CUFnti 2BrS7as33VdJjWwfEmktoLHeYhrDiQ==
X-Received: by 10.107.128.230 with SMTP id k99mr40480581ioi.115.1499222203825; Tue, 04 Jul 2017 19:36:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.18.170 with HTTP; Tue, 4 Jul 2017 19:36:43 -0700 (PDT)
In-Reply-To: <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com>
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>
From: william manning <chinese.apricot@gmail.com>
Date: Tue, 4 Jul 2017 19:36:43 -0700
Message-ID: <CACfw2hjahuUH=xnBPpP80NteEjyBB1aWp4hk_xpoQ6Vw12TWhA@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Mark Andrews <marka@isc.org>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f8b1ee608f7055388de18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I-WeZ4jwvZNYgUWdYOE-4GK6Spk>
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: Wed, 05 Jul 2017 02:36:47 -0000

Most of the other application (besides dns) presume a single class, IN,
hence the URL presumption of "DNS name" will -always- be in the IN class.
Technically imprecise and sloppy, but pragmatically it works...  until some
loons come along and do something creative with classes.   Then all bets
are off.
RFC 1034 also uses IN in its examples and most folks forget inheritence
rules.

/Wm

On Tue, Jul 4, 2017 at 7:23 PM, Matthew Kerwin <matthew@kerwin.net.au>;
wrote:

> On 5 July 2017 at 10:02, Mark Andrews <marka@isc.org>; 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
> about how to do that resolution. Given that we always assume class=IN
> (not to mention type=A|AAAA via happy eyeballs), how would we go about
> practically presenting an alternative class in things like URLs?
> (Registering a new "alt-http" URL scheme doesn't strike me as a great
> idea.)
>
> Because it's all well and good setting up your own .org hierarchy
> under class=FOO or whatever, but there's not much point if you can't
> send people to www.not-icann.org using it. Unless you don't want to
> expose your new hierarchy to the web ...?
>
> Cheers
>
>
> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 :
>
>    """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.
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>