Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Patrik Fältström <paf@frobbit.se> Sat, 03 January 2015 15:49 UTC

Return-Path: <paf@frobbit.se>
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 2D9B61A8763 for <ietf@ietfa.amsl.com>; Sat, 3 Jan 2015 07:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level:
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 W_nhF41CFFS3 for <ietf@ietfa.amsl.com>; Sat, 3 Jan 2015 07:49:57 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E191A8762 for <ietf@ietf.org>; Sat, 3 Jan 2015 07:49:56 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::55a3:4750:b473:890f] (unknown [IPv6:2a02:80:3ffc:0:55a3:4750:b473:890f]) by mail.frobbit.se (Postfix) with ESMTPSA id 06CC921A11; Sat, 3 Jan 2015 16:49:55 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CCC87CBA-B64A-4B29-BCBA-9AB47B634958"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.5b4
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <20150103143226.GC13599@besserwisser.org>
Date: Sat, 03 Jan 2015 16:49:53 +0100
Message-Id: <89DB2965-68B1-43D0-BBEB-FF49DB666A6D@frobbit.se>
References: <CAK3LatFh3ZU8ACk8grzLA9oCv2qqUHttz2z83b66xKnfs78mRA@mail.gmail.com> <54A7DBFC.8010800@cisco.com> <20150103143226.GC13599@besserwisser.org>
To: Måns Nilsson <mansaxel@besserwisser.org>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/FyCeegLlXkdS-ctGt5kMVzrqI5I
Cc: Delan Azabani <delan@azabani.com>, 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: Sat, 03 Jan 2015 15:49:58 -0000

> On 3 jan 2015, at 15:32, Måns Nilsson <mansaxel@besserwisser.org> wrote:
> 
> I strongly support incorporating SRV record support in the HTTPbis
> specification.

FWIW, I am also in favor or SRV, although I (being biased) think "how to use URI with HTTP2" would not be a bad addition either[1].

We do though have multiple discussions like these, that I do not think really conclude:

<https://news.ycombinator.com/item?id=8404612>

Because of this, what I think IS (at least) needed in the http2 spec are a few words about DNS. Else the discussions will just continue and continue...

One could for example say something like:

"If the URI does not include a path (only consists of scheme and authority, which in turn include domain), a client MIGHT look up either SRV record _http._tcp.domain or URI for the same owner_http._tcp.domain and act on the result of those lookups according to the SRV and URI spec respectively."

And then reference some "happy eyeballs" specification on how to do it in detail.

What I think would be good with such text is that _http._tcp would be well defined (and it should be repeated in the IANA considerations section).

And maybe even replace _http with _http2 which might even make things more efficient?

   Patrik

[1] The URI RR Type 256 has been registered for a number of years, but the I-D that describe the use (draft-faltstrom-uri) has been stuck in IESG for quite a number of years. AD has been working on unstucking it for half a year or so, and I hope it really will happen shortly.