Re: [art] Revising BCP56: On the use of HTTP as a Substrate
Dave Thaler <dthaler@microsoft.com> Sun, 16 July 2017 08:18 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29412EC01 for <art@ietfa.amsl.com>; Sun, 16 Jul 2017 01:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.012
X-Spam-Level:
X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 FpV1dgbBUwzI for <art@ietfa.amsl.com>; Sun, 16 Jul 2017 01:18:50 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0106.outbound.protection.outlook.com [104.47.34.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD445127180 for <art@ietf.org>; Sun, 16 Jul 2017 01:18:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/sSl7z9Ojh5re7S7gV3cdckaiFU6BrTWCMr8RMHOe2I=; b=YmbLBuCIMT/p/eS5/ZdXczWKke5ELTUoG8c19XBV40yRTrUHHvMNRpao/gSsyUqv9QNhszoVuQMb7Kdj/aRYB8UZeu5aH7ODuYE/V6k+pMpab4M7OWkqYAN8/KPxJ4ko9VFR2ipJmA1WSbWvmv3zL5nyl9z0183hRLAs6ppuFa0=
Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0512.namprd21.prod.outlook.com (10.172.95.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Sun, 16 Jul 2017 08:18:48 +0000
Received: from MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) by MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) with mapi id 15.01.1282.008; Sun, 16 Jul 2017 08:18:48 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Mark Nottingham <mnot@mnot.net>
CC: Adam Roach <adam@nostrum.com>, Alexey Melnikov <alexey.melnikov@isode.com>, Patrick McManus <mcmanus@ducksong.com>, "art@ietf.org" <art@ietf.org>
Thread-Topic: [art] Revising BCP56: On the use of HTTP as a Substrate
Thread-Index: AQHS+fwvBa2rF+wzTE+ph2KDNcIt26JUo0gAgABQlgCAAShFMIAAB3kAgAAATcA=
Date: Sun, 16 Jul 2017 08:18:48 +0000
Message-ID: <MWHPR21MB0125A6F31A0F572A381C174AA3A30@MWHPR21MB0125.namprd21.prod.outlook.com>
References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <ebabe106-d914-f21b-30c2-f91f583f4de5@nostrum.com> <DE1772EA-E54A-4FC5-AF5B-6958477B0F44@mnot.net> <MWHPR21MB0125968A70D48B275C8EC08CA3A30@MWHPR21MB0125.namprd21.prod.outlook.com> <57B020F0-3FB8-423D-BDB6-4AF98BE9C4BA@mnot.net>
In-Reply-To: <57B020F0-3FB8-423D-BDB6-4AF98BE9C4BA@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mnot.net; dkim=none (message not signed) header.d=none;mnot.net; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:67c:1232:144:b4f4:e5be:e89a:b40e]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0512; 7:iyNfass1ZY73zYdEM+xRpkhS7yxhQ3nTYy76WhiTIqLvz6bn9RO+zzOrXzNesYHFybzys2HTwjPNP+LPwVLJ7IPzeX40Gy/eRdjpNlPDsIlURSjXH5S/bEcTvRTOQ4q7Cpzor2uOGrAmcNJO32pMHIwqELBIjOKr+r8EmZ2a8KyCRO743ojwqM1OT6c4tmuXgVvXZ0WlvSasOterQ4OGf2eV+rSAAMdohGPrOUpULuARVbJM0+l6faFY4d5CIS/wLaQVHPHtrVrbCy4Xbz4FAKrrn2YEnivO0P7d6TH7urhrHlXEvQ9shJJa0HuNU1ujBJNlde/HsuohaNoT7ap8lJj73JDamXyQrFdAVhrXjbL+wKG2LrfJFVwPoXviutAAskc154IEHSdT9WXNjU9eAd+T5iA/DGxKGr8YzmBd1X/hjF/xU0DqfC5g6EiG/3AR6PEmzv6SA7vixtGS/yEbyBVj/zWUkHyDOxTS7s++Jy1ejU71giPFR6OskokWqd0hU9vZnyd06QeCMce6Ba+tEj1J89FeUcHdsmajSPqO5loMi0GvB6P7FEJHRe8t7ZvBsRcKNsOOmItSHPX5vv1Bq4wF4/OQ1u+QyXYaeIbhhTRthtHQqwVjyIG9zZi/mQd5bU4Pwy3p3bWGgXzz+03YB9AFgtty6yI6gY1arSe6fS4JJ0p9J54bnVXiJBwYlYvk2djK3a2ZJcUe0n+3uWQ9lOpizyDEx5hLksaLEKcKHHCss4eZWwtlavpt7AoQTZL09Z/0VA5N2DY3qVwnAyHUCib9ooWWPCzgpWsqosHoLpiA//B+VSLAtdG5rXPV/YuP
x-ms-office365-filtering-correlation-id: 219bef2b-0420-4f13-ac7a-08d4cc23492b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0512;
x-ms-traffictypediagnostic: MWHPR21MB0512:
x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(189930954265078)(219752817060721)(247924648384137);
x-microsoft-antispam-prvs: <MWHPR21MB0512F4F5A36C20D4097D83ECA3A30@MWHPR21MB0512.namprd21.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0512; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0512;
x-forefront-prvs: 03706074BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(377454003)(13464003)(24454002)(53546010)(14454004)(5660300001)(81166006)(966005)(305945005)(7736002)(33656002)(110136004)(38730400002)(6436002)(5005710100001)(8676002)(6116002)(25786009)(102836003)(7696004)(6246003)(74316002)(76176999)(8936002)(6506006)(53936002)(3660700001)(575784001)(99286003)(6306002)(478600001)(10290500003)(229853002)(55016002)(54906002)(93886004)(3280700002)(189998001)(2950100002)(9686003)(2906002)(50986999)(86362001)(54356999)(10090500001)(4326008)(77096006)(2900100001)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0512; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2017 08:18:48.7415 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0512
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/PyNGN1fo_Nu6peSQxR_R6JPh-4o>
Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jul 2017 08:18:53 -0000
So if you have a resource that is served over multiple other protocols (ftp, coap, whatever) but NOT http, W3C would tell people to use the HTTP scheme anyway? http://www.w3.org/2001/tag/doc/SchemeProtocols.html#useNaturalProtocol says: 4.2.1 G4. Serve using the protocol associated with the URI scheme -----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net] Sent: Sunday, July 16, 2017 10:16 AM To: Dave Thaler <dthaler@microsoft.com> Cc: Adam Roach <adam@nostrum.com>; Alexey Melnikov <alexey.melnikov@isode.com>; Patrick McManus <mcmanus@ducksong.com>; art@ietf.org Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate > On 16 Jul 2017, at 10:11 am, Dave Thaler <dthaler@microsoft.com> wrote: > > I think 4.3.2 is problematic as currently worded. For example, >> Using other schemes to denote an application using HTTP makes it more >> difficult to use with existing implementations (e.g., Web browsers), >> and is likely to fail to meet the requirements of [RFC7595]. > > The "URI Schemes and Web Protocols" document Henry pointed to argues > for separate URI schemes for different protocols (ftp, http, coap, etc.), e.g. "G4. Serve using the protocol associated with the URI scheme". > > I think the "HTTP as a Substrate" document is worded as if the only protocol an app supports is HTTP, > which is not the case. If an application defines higher layer semantics where HTTP and something else > can both be used as transports (the topic of > draft-thaler-appsawg-multi-transport-uris discussion), than 4.3.2 > would imply that one must use multiple URIs for the same transport, rather than having one higher-layer URI for the application-layer protocol or semantics. > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3 > .org%2FTR%2Fwebarch%2F%23uri-aliases&data=02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782919498&sdata=klbb40TomYZ216cxDZFHGBh1EiXMaVc2pmT4%2FjsXKv4%3D&reserved=0 discusses multiple URIs for the same resource and has recommendations like "A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource." > > Thus that would argue that apps should have higher-layer URIs for > concepts that are not specific to HTTP, since there may be different > URIs that differ by existing protocol (and URI scheme). As such, > 4.3.2 seems problematic since it seems to be saying that that's bad and apps should use different URIs with the same resource. W3C doesn't share the IETF's aversion to using HTTP to identify higher-level concepts. The "Web" way that has emerged is to use HTTP to discover more about the other protocols as necessary (as we see with H2 and now QUIC negotiation). -- Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782929506&sdata=hLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW%2FkQiFIiWxFtT8%3D&reserved=0
- [art] Revising BCP56: On the use of HTTP as a Sub… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Eliot Lear
- Re: [art] Revising BCP56: On the use of HTTP as a… Joe Touch
- Re: [art] Revising BCP56: On the use of HTTP as a… Adam Roach
- Re: [art] Revising BCP56: On the use of HTTP as a… Ben Campbell
- Re: [art] Revising BCP56: On the use of HTTP as a… Ted Hardie
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Adam Roach
- Re: [art] Revising BCP56: On the use of HTTP as a… Adam Roach
- Re: [art] Revising BCP56: On the use of HTTP as a… Ira McDonald
- Re: [art] Revising BCP56: On the use of HTTP as a… Martin J. Dürst
- Re: [art] Revising BCP56: On the use of HTTP as a… Dave Thaler
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Dave Thaler
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Ira McDonald
- Re: [art] Revising BCP56: On the use of HTTP as a… Roy T. Fielding
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Ted Hardie
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham