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

Delan Azabani <delan@azabani.com> Fri, 02 January 2015 08:29 UTC

Return-Path: <delan@azabani.com>
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 2CBA21A0087 for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 00:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.021
X-Spam-Level:
X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 mLCoJy84GRXb for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 00:29:18 -0800 (PST)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06B61A0095 for <ietf@ietf.org>; Fri, 2 Jan 2015 00:29:17 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id x13so5931246wgg.26 for <ietf@ietf.org>; Fri, 02 Jan 2015 00:29:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azabani.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=M+bG79d7zRmnNLmG7TXiXjI1VkoTdpNG2xEfFN2lvuE=; b=dXLJ0dt71t6WLtzFR+Vn0SO90yN/psTH1I8sd2VNTfYLx21BrLwt3hPoDhXC25O/6T 9FNgxqVlidTxMVJ/gQP9vmHYoh1/ADPBqRN95QDfoPPEg7bpiGUzypMW9oW5S/CXL3B6 kaT1XLYM0Yc8NChn5mjaiAAxdaqXRwn35BInQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=M+bG79d7zRmnNLmG7TXiXjI1VkoTdpNG2xEfFN2lvuE=; b=EB4YAuZCwhlKnEIJgul6Hnd6TCML16PrRLZI8QgupA2UBqEbCsPV7/K9Fbbfh2g1o2 figxf7VebBtseizz6arRanymapyDc8A0EAOmiaNhwffb9BPrmb6m5kcLONc9YdpIBtCA NH1fLkLgB1dyJUpG2gjt7E3/Ty5oMAuM0/m/zGv1U6N6PGaqFJdorvZ5UoWp+A7FC4iU LDuuNgMFGTo6llFA/PAR/kxTcx/hIG3TIdxsOJF2zVCzCXdL6ewr7fjlSMryRHmK7YGB 00cPBshKZExeKYXV7rz1WUT8T7S+qGvMklaWfdz8LMQb+Fk/WceJ2RCr4YXPwa5SCqxD ia8g==
X-Gm-Message-State: ALoCoQksQ0QuGTKaxgAgaPJsfbKWWhCL99xRaFyxthhkWHCvPkbqD5gOk7O/ORYt0qVihIWhh0qU
MIME-Version: 1.0
X-Received: by 10.194.157.4 with SMTP id wi4mr145368519wjb.54.1420187356727; Fri, 02 Jan 2015 00:29:16 -0800 (PST)
Received: by 10.27.213.203 with HTTP; Fri, 2 Jan 2015 00:29:16 -0800 (PST)
Date: Fri, 2 Jan 2015 16:29:16 +0800
Message-ID: <CAK3LatFh3ZU8ACk8grzLA9oCv2qqUHttz2z83b66xKnfs78mRA@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
From: Delan Azabani <delan@azabani.com>
To: ietf@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/LtEbSaXVhT8b2RPkGkSyPCtAlp4
X-Mailman-Approved-At: Fri, 02 Jan 2015 08:21:50 -0800
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, 02 Jan 2015 08:31:24 -0000

I'm not sure if it's appropriate for a random netizen like myself to
contribute to these comments, so my apologies in advance if it isn't.

Please consider supporting SRV resource records.

HTTP is simultaneously important enough that one can't simply run a
single server for any popular application, but not so important that it
deserves to necessarily be the A/AAAA record for every hostname.

SRV makes service discovery more flexible than even MX records by:

  * Decoupling the default use of TCP port 80 for HTTP, allowing hosts
    to run multiple distinct HTTP servers without needing a reverse
    proxy or requiring users to explicitly override the port;

  * Allowing server administrators to create a tiered and weighted form
    of load balancing by using the record's Priority and Weight fields,
    again without shifting the point of failure to reverse proxies; and

  * Making it easier to transparently and scalably host services for
    multiple protocols on a single apex domain name.

Although the Target field of a SRV RR is a domain name, not an IPv6 or
IPv4 address, the resolution delay before a TCP connection is initiated
is unlikely to increase significantly because:

  * To reduce the need for multiple queries, "Implementors are urged,
    but not required, to return the address record(s) in the Additional
    Data section." [RFC 2782 page 4]

  * Like the record types PTR, MX and CNAME, "Domain names in RRs which
    point at another name should always point at the primary name and
    not the alias. This avoids extra indirections in accessing
    information." [RFC 1034 § 3.6.2]

To further avoid the complexity and inefficiency of multiple queries,
'only the service name "http" should be used' when SRV records are
used, not the synonyms "www" or "www-http". [RFC 6335 § 5]

LDAP, SIP, XMPP and Kerberos are successful examples of protocols which
rely on SRV resource records for service discovery.

For these benefits to be realised however, HTTP/2 should explicitly opt
into support for SRV records, because "Service SRV records SHOULD NOT
be used in the absence of" an indication in the protocol specification
that clients should use SRV records for discovery. [RFC 2782 page 2]