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

[Delan Azabani <[e-mail]>]

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]