Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)

hardie <notifications@github.com> Thu, 02 February 2017 19:09 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77BE129547 for <quic-issues@ietfa.amsl.com>; Thu, 2 Feb 2017 11:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.156
X-Spam-Level:
X-Spam-Status: No, score=-8.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 qRrlbP8dZ5TG for <quic-issues@ietfa.amsl.com>; Thu, 2 Feb 2017 11:09:37 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AC612950F for <quic-issues@ietf.org>; Thu, 2 Feb 2017 11:09:36 -0800 (PST)
Date: Thu, 02 Feb 2017 11:09:33 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1486062573; bh=M14PMsL93tOAd3Hud1YWPqCEFC6ZxlY+H246gOF1ZLo=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WvSW1owxNZAIkw9y/lzgNgQ0l7MZFcUOSt8gT/wEh7HjhR9f5bQDPZY5RtsFTv693 gp/4yLVzXj0Ish5xIKN2Nho/sNzg3EhQgAgRlB3rGBAT/Pg9PuZzbiObRgE2vBCL+U iNj+986LsHsYsYGQKJBjXy5opHxnb1XRajY3SYw0=
From: hardie <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/253/277052107@github.com>
In-Reply-To: <quicwg/base-drafts/issues/253@github.com>
References: <quicwg/base-drafts/issues/253@github.com>
Subject: Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_589383ed22bc9_45193f96e996b1343489a6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: hardie
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/kSU21DuH0YDfOZRa1XPKcK3vn-0>
Cc: Subscribed <subscribed@noreply.github.com>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quic@ietf.org
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 19:09:41 -0000

On Wed, Feb 1, 2017 at 10:19 AM, Mike Bishop <notifications@github.com>
wrote:

> Oh, and also in RFC 7230:
>
> Although HTTP is independent of the transport protocol, the "http" scheme
> is specific to TCP-based services because the name delegation process
> depends on TCP for establishing authority. *An HTTP service based on some
> other underlying connection protocol would presumably be identified using a
> different URI scheme....*
>
> I read that as requiring a different scheme when the name delegation
process was different.  I don't see a different name delegation process as
probably for names served over QUIC (or least I don't see it as required).

If you dipped your toes into the "special use dns names" discussion, you'll
probably also remember that one of reasons TOR wanted .onion was so that
the signal that something should be resolved via TOR could be used within
the authority section of an HTTPS URL. That really did have a different
name delegation process for names below the .onion TLD, but that
consideration was ignored in favor of being able to pass "normal" (really
normal-looking) URLs around.

That experience hints to me that our minting a new scheme for this will
just be ignored in the common case, and I don't see a good reason to
generate the potential confusion as a result.

Just my take on it,

Ted




> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/253#issuecomment-276736742>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5CTcjjxL9mg74HKcICfQaXaWK2Gxks5rYMykgaJpZM4LzLA5>
> .
>


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/253#issuecomment-277052107