Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

Andrew Newton <andy@hxr.us> Fri, 27 February 2015 15:02 UTC

Return-Path: <andy@hxr.us>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CBE1ACC87 for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 07:02:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 MNQcaIeG7V45 for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 07:02:11 -0800 (PST)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (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 D920D1A01D5 for <ietf@ietf.org>; Fri, 27 Feb 2015 07:02:10 -0800 (PST)
Received: by iecat20 with SMTP id at20so31414239iec.12 for <ietf@ietf.org>; Fri, 27 Feb 2015 07:02:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mvBZC9yqB/Cd3U4r57p6sZ+DSV8fFeo1jzA2Hp2DTGA=; b=mEy6xBqKMN/xaFHHYGUrlNOD81+IasXjDc35FyWGV2s+AV4RBAaeo4KpwUbt5qnz/J 7zxhYQp2IqFJDg/zup8HGt72/rZEtxexCofrtRT3zZtZDssvUTzk8PQROZaWQueQe6tE 26WiQfUQF7xJu977p3Cy/Af1ZcKFsLbQjs12noy9qmfMyid8uBX16vFiJpywMz4w8nE3 wbqkkNfUUIpR1nT6lb1YhUGnLK/1CFtc3nEBgO69TH/8lsZUFSjb6L2GbYsk1obHwH5i 888TVX8UTd5gWWlD38NCPx436O8StU19wA6ZznWopCTVmoAy8XFWw8fqnkM8fw8lryq2 Az3Q==
X-Gm-Message-State: ALoCoQmzdYUa041pdiqN71R8zePpuFPeVosTLj51t0AT6TWNIPXyYxSFaJIDfECYsBaZoD6sbiXl
MIME-Version: 1.0
X-Received: by 10.50.39.65 with SMTP id n1mr3334200igk.37.1425049330256; Fri, 27 Feb 2015 07:02:10 -0800 (PST)
Received: by 10.36.120.6 with HTTP; Fri, 27 Feb 2015 07:02:10 -0800 (PST)
X-Originating-IP: [2001:500:4:15:e4a6:48c1:f627:57]
In-Reply-To: <83FCB47C-ED48-4B26-B898-F1A47528595E@netnod.se>
References: <20150127223859.28024.43756.idtracker@ietfa.amsl.com> <4257D8A3-0EFE-40E3-B0AD-8E23772B7693@mnot.net> <CAAQiQRdLvcQLskOuo7g_=SfmowCtyyF7OwWb-Y0nsRDeTdgncA@mail.gmail.com> <39D5E26A-E1FE-4C77-9624-5E9396497F65@mnot.net> <83FCB47C-ED48-4B26-B898-F1A47528595E@netnod.se>
Date: Fri, 27 Feb 2015 10:02:10 -0500
Message-ID: <CAAQiQRckc6V234gzmMhZQV-QTt=hVqk8G+zarRDFF5RR3pXxAw@mail.gmail.com>
Subject: Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
From: Andrew Newton <andy@hxr.us>
To: Patrik Fältström <paf@netnod.se>
Content-Type: multipart/alternative; boundary="047d7bdc14381e2a88051013274a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/r1CXAZOru5B1R-xvm10P628OG_M>
Cc: Mark Nottingham <mnot@mnot.net>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 27 Feb 2015 15:02:12 -0000

On Fri, Feb 27, 2015 at 2:07 AM, Patrik Fältström <paf@netnod.se> wrote:

> My feedback to Andrew when he presented this to me was that:
>
> - In general I am nervous of moving HTTP header attributes into the DNS,
> as it might create inconsistencies when for example the data in DNS do not
> match what is in the HTTP header, and we already have a content-negotiation
> mechanism in HTTP
>
>
I think that is simply solved by stating none of it overrides the content
negotiation of the application. But a mismatch here is an adminstrative
error, in my opinion.


> - Given experience with length of URI / text fields in DNS, I would have
> had the encoding of RDATA as "flag" "flag" "flag" "uri" (while being
> nervous over the size restrictions of the URI...which is the reason in URI
> the uri is all of RDATA except the weight and priority).
>
> - I am also nervous over the size of the RRSet, i.e. same issue I see with
> NAPTR, and the reason why I added the prefix (like SRV) to the URI RR
>

I plan to move to use this advice. Thanks.

-andy