From nobody Thu Jul 6 12:45:22 2017 Return-Path: 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 D805C1316D0; Thu, 6 Jul 2017 12:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, 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 jQEJ-UTqK4ma; Thu, 6 Jul 2017 12:45:11 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F99128BA2; Thu, 6 Jul 2017 12:45:11 -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=+xJZrEM3gORGMmFpWSDseNNPoyLVTZRO6U0l6dimwJc=; b=AtgoZFzRc/H1oEbTOxnwEJ7yPWjzb+mvB3GhkRerj3kUEb9cdTgYPq4D0Efi+AbHhKTEgLnmCCsjoTEIsQ3WlSrUmVQyRK261WFb0YM31qWXevGF4hsZctSg1DAyBhQ0Z9c3cDDcnPZhRkxxbQvNCJdka459BdXSwUVGCiAdx+w= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0285.namprd21.prod.outlook.com (10.173.53.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.0; Thu, 6 Jul 2017 19:45:09 +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.1261.005; Thu, 6 Jul 2017 19:45:09 +0000 From: Dave Thaler To: "uri-review@ietf.org" , "dispatch@ietf.org" , "art@ietf.org" Thread-Topic: Internet-Draft: Using URIs With Multiple Transport Stacks Thread-Index: AdL2j89KknngpoFTRaiO7w0jXk0ylA== Date: Thu, 6 Jul 2017 19:45:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [167.220.1.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0285; 7:ZasM95k/cTU5KIva9QghSGQjm6ninJ2lPCIp4iCcraHIPW+/BJ+95UJQNHjfhNaAbOpxH6oiS/64TRkztuI3oOhZpYTKqER/xK49ddZBZf0wf6ni2nmKemnTbCj2HJxQCFrtXGPvuu6YKXxaUA8FAW+nZRkcCwHA81TQURZIlXOwtnVdqFUbQ3KkO/rKcxo2PrSvm7p0cAKCoRUaIWTx5a9V128TP6uF/6+I26ko1jKRnFt7E4DZcBIO8/p47FuxLViD86N8nJ7QN3PjGQ1UhZoFxfNqRr/3gkHM1eh581kqhajFQ169gF9ti4WB/o7MiZ/d63ogt0bIKgpdvMIzicbUBIhaFB2ih6jE1iLViHICd/W2xBNiELVIAPAItwMOhiIOP+Bdk2FBvtq8gYxNq9QKuqnYOvWpvjq9k+r3Xh36YAk6dzTs41mnEujfqk8MmDpURTlY7NDiCDO4WpBK0WiM0J6mMblBT3oaF0Ne4cJ4tL8nJn8REHHzegg2kdEz3dBOgB2dCro37Hh4SE94V+4EAkZi0wXL2UgxenzNbDPod6Oz1g6TfBpT1MhL4G5I1b38vKQ93nHAwVwRHBP85LS3UP56NIgwwp56kQxfPjvZi2OboTqAVyQd+5KPvYiZbKPHJejEixV3lPk9f3q7LBAYXgn45Cd6SQgCpfqyBYR14KZMJViW1zezN0AEjIMZ2TmmhokjIsxZpV2zn1tXu+AvdE2knaW78HEhglLez0YFB/3Mdma3d2PY+Js0FQx4ZFONRFLoWOwdLgfEQdtGse2UWom1bePDptjbRQrtJbpeYDmTwXU87vMZgV4AVSQB x-ms-office365-filtering-correlation-id: 993d022f-d388-4792-1b38-08d4c4a782a5 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)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0285; x-ms-traffictypediagnostic: MWHPR21MB0285: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(120809045254105)(236129657087228)(148574349560750)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910052)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0285; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0285; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(377424004)(13464003)(50986999)(86362001)(2201001)(54356999)(6506006)(6116002)(3846002)(102836003)(10090500001)(6436002)(10290500003)(81166006)(5005710100001)(25786009)(8990500004)(38730400002)(7736002)(14454004)(8676002)(55016002)(450100002)(8936002)(9686003)(99286003)(2501003)(6306002)(478600001)(77096006)(53936002)(966005)(33656002)(2900100001)(3280700002)(3660700001)(2906002)(305945005)(7696004)(5660300001)(74316002)(189998001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0285; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 19:45:09.3881 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0285 Archived-At: Subject: [art] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 19:45:14 -0000 UmVjZW50bHkgd2UndmUgc2VlbiBtdWx0aXBsZSByZXF1ZXN0cyAoaW5jbHVkaW5nIGZyb20gdGhy ZWUgZGlmZmVyZW50IFNET3MpIGFuZA0KZGlzY3Vzc2lvbnMgb24gZGlmZmVyZW50IGxpc3RzIHJl Z2FyZGluZyB1c2luZyBVUkkgc2NoZW1lcyBmb3IgYXBwbGljYXRpb24tbGF5ZXIgcHJvdG9jb2xz DQp0aGF0IGNhbiBvcGVyYXRlIG92ZXIgbXVsdGlwbGUgdHJhbnNwb3J0IHN0YWNrcyAoZS5nLiwg VURQLCBUQ1AsIHdlYnNvY2tldHMsIEhUVFAsIGV0Yy4pLiANClRoaXMgZHJhZnQgc3VtbWFyaXpl cyB0aGUgdmFyaW91cyB0ZWNobmljYWwgZGlzY3Vzc2lvbnMgYW5kIGlzc3VlcyByYWlzZWQuDQoN Ck5vdCBzdXJlIGlmIHRoZXJlIGlzIGFueSByZWd1bGFyIG1lZXRpbmcgdGltZSBhdmFpbGFibGUg YXQgSUVURiwgYnV0IEkgYXQgbGVhc3Qgd2FudGVkDQp0byBzaGFyZSB0aGlzIG1vcmUgYnJvYWRs eSBmb3IgdmlzaWJpbGl0eSwgYW5kIHRvIHNvbGljaXQgYWRkaXRpb25hbCBmZWVkYmFjay4NCg0K RGF2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFVzaW5nIFVSSXMgV2l0aCBNdWx0aXBsZSBU cmFuc3BvcnQgU3RhY2tzDQogICAgICAgIEF1dGhvciAgICAgICAgICA6IERhdmUgVGhhbGVyDQoJ RmlsZW5hbWUgICAgICAgIDogZHJhZnQtdGhhbGVyLWFwcHNhd2ctbXVsdGktdHJhbnNwb3J0LXVy aXMtMDEudHh0DQoJUGFnZXMgICAgICAgICAgIDogMTANCglEYXRlICAgICAgICAgICAgOiAyMDE3 LTA3LTAzDQoNCkFic3RyYWN0Og0KICAgTWFueSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXJz IChVUklzKSB0b2RheSBoYXZlIHNvbWUgbWVjaGFuaXNtIHRvDQogICByZXNvbHZlIHRoZW0gdG8g b25lIG9yIG1vcmUgc3BlY2lmaWMgZW5kcG9pbnRzIHdoZXJlIHRoYXQgcmVzb3VyY2UgaXMNCiAg IGF2YWlsYWJsZS4gIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGlzc3VlcyB0aGF0IGFyaXNlIHdo ZW4gdGhlIHNhbWUNCiAgIHJlc291cmNlIGNhbiBiZSByZWFjaGVkIG92ZXIgbXVsdGlwbGUgcHJv dG9jb2wgc3RhY2tzLCBhbmQgZGlzY3Vzc2VzDQogICB2YXJpb3VzIGFwcHJvYWNoZXMgdGhhdCBo YXZlIGJlZW4gdXNlZCBvciBkaXNjdXNzZWQsIGFuZCB0aGUNCiAgIHRyYWRlb2ZmcyBiZXR3ZWVu IHRoZW0uICBTdWNoIGlzc3VlcyBhcmUgaW1wb3J0YW50IHRvIGNvbnNpZGVyIHdoZW4NCiAgIGRl ZmluaW5nIG5ldyBVUkkgc2NoZW1lcyBhbmQgcmVzb2x1dGlvbiBtZWNoYW5pc21zLg0KDQoNClRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGhhbGVyLWFwcHNhd2ctbXVsdGktdHJh bnNwb3J0LXVyaXMvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aGFsZXItYXBwc2F3Zy1t dWx0aS10cmFuc3BvcnQtdXJpcy0wMQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC10aGFsZXItYXBwc2F3Zy1tdWx0aS10cmFuc3BvcnQtdXJpcy0wMQ0KDQpBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdGhhbGVyLWFwcHNhd2ctbXVsdGktdHJhbnNw b3J0LXVyaXMtMDENCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0K From nobody Thu Jul 6 15:19:33 2017 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2980D1271DF; Thu, 6 Jul 2017 15:19:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" Cc: superuser@gmail.com, art@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <149937957212.8549.13479778003508357215.idtracker@ietfa.amsl.com> Date: Thu, 06 Jul 2017 15:19:32 -0700 Archived-At: Subject: [art] WG Action: Conclusion of ART Area General Applications Working Group (appsawg) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 22:19:32 -0000 The APPSAWG has completed all of its milestones and is being closed. Thank you to past and present WG chairs, editors of WG documents, as well as WG participants, who together produced 35 RFCs since 2011. Discussion of new ART area topics should now be brought to the DISPATCH WG. The IESG contact persons are Ben Campbell, Alexey Melnikov, and Adam Roach. From nobody Fri Jul 7 08:15:23 2017 Return-Path: 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 4AB4912EBF5; Fri, 7 Jul 2017 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Mv84VrgnrYpm; Fri, 7 Jul 2017 08:15:13 -0700 (PDT) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id B57C6131642; Fri, 7 Jul 2017 08:15:10 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id v67FF9Ku010692; Fri, 7 Jul 2017 16:15:09 +0100 Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id v67FF8vc029302; Fri, 7 Jul 2017 16:15:08 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id v67FF9lL015825; Fri, 7 Jul 2017 16:15:09 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id v67FF8aX015824; Fri, 7 Jul 2017 16:15:08 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Dave Thaler Cc: "uri-review\@ietf.org" , "dispatch\@ietf.org" , "art\@ietf.org" References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 07 Jul 2017 16:15:08 +0100 In-Reply-To: (Dave Thaler's message of "Thu\, 6 Jul 2017 19\:45\:09 +0000") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Subject: Re: [art] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 15:15:16 -0000 Dave Thaler writes: > Recently we've seen multiple requests (including from three different > SDOs) and discussions on different lists regarding using URI schemes > for application-layer protocols that can operate over multiple > transport stacks (e.g., UDP, TCP, websockets, HTTP, etc.). This draft > summarizes the various technical discussions and issues raised. > > Not sure if there is any regular meeting time available at IETF, but I > at least wanted to share this more broadly for visibility, and to > solicit additional feedback. The W3C TAG devoted a fair amount of effort to this issue about 12 years ago, and our thinking at the time (2005) is recorded here: https://www.w3.org/2001/tag/doc/SchemeProtocols.html which may provide a useful independent perspective, albeit somewhat dated in some respects. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Fri Jul 7 11:18:07 2017 Return-Path: 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 D41591317C2; Fri, 7 Jul 2017 11:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tyqfdgVOHriC; Fri, 7 Jul 2017 11:17:36 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0101.outbound.protection.outlook.com [104.47.42.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7BA129B36; Fri, 7 Jul 2017 11:17:36 -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=7vUzevS01wMiIErAsxHwTvyHDN9QnQYwyCacj5bZscE=; b=lND2YDCH3jdjwWsjaEuIz+HPUk2ShRl3Je/PUHZely3WnT9l/s2gXOOuMpJAVIFNBVEMeX2lh577Z+8KAmXafUPYfDkkpLjlQyhmE7r/1BF/UXR9vraGIqfSH7/y6iVDzRjsWNNVCB7N4ub/6swuVicLZs0itqwtjFD1azfonuk= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0479.namprd21.prod.outlook.com (10.172.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.3; Fri, 7 Jul 2017 18:17:34 +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.1261.007; Fri, 7 Jul 2017 18:17:34 +0000 From: Dave Thaler To: "Henry S. Thompson" CC: "uri-review@ietf.org" , "dispatch@ietf.org" , "art@ietf.org" Thread-Topic: [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks Thread-Index: AdL2j89KknngpoFTRaiO7w0jXk0ylAApAZzNAAZX9MA= Date: Fri, 7 Jul 2017 18:17:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: inf.ed.ac.uk; dkim=none (message not signed) header.d=none; inf.ed.ac.uk; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [167.220.1.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0479; 7:Tic95E8xNrFubmg8RD0caHY+6xdQ5sF93sCEcKb95IOBnevNiaPrEyVBBJnQhYkGe2bYoVWXCkB3hOSOozy5JuxgnQpMEsry31PzLLhm3N31S5pOfX/hHc9sKLhLXciUpgNN1Ki9QtpOkOu07BB+cLSJ1+gUNoxRD84B0CSEcNAj9kaoFx8FGMByIqjJ5LJJ7ZTeQWVCygTU1Fv/FvuLJC+FlPljeN1kfUoE1AeJ5t6NcmAHefOlW8OxTXpMkYhHfQ0E+38Hg1dNrfyBpBxKf1/0Ckqi1T3OV2juGaaWbuE9x9rLntQfkeYAHGSCNQiRYq0bKI0rhICXaaYLIteG2WxjfQrg+k+I8q6oMc/bu6uqaB0KK6sYBoYSo+Q0NxjLQUew7Sj0woUSMNVm/nSx3yfhoQFEnbKHTh0q1u80I65cwpW8hp7VZVUh2ZBAbEsmB6cEReJx0zUaW8WPZ2aDhTI5i/8IAytI4LOP7E8PpunxA265M3wtsCSguF8qYMPBeBlj36c5a50HejweVI5heMX0sNJr4TFCiJBNNVuvwa+xKUOjFEd2GWtVTw68UiCCatFo9p+ELVzPsj5S3+WEKEHKA4JAFvZzf0ZbEP4ui5wVm3vmvkTo+ER3rJzhNtTFqi9BTq24XNTc3vfcS/qmxMuizoAw0GmpaQ5NDFj0X+/ywV5n/Cl410N9qej76cr4TFpWxPALXH5zEFecDeeN8VWEghf3GgdhUPGsYa/Oc/vRQupjGSRiwWMdczJY9AFVcjcOIlY1VFfVBfngQcklFDDkIlCxZI9SXM5mEO0+LxrUmvk5RDQN1IxVW3Ga4sRu x-ms-office365-filtering-correlation-id: d074b94f-2977-4516-77df-08d4c56470ed 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)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0479; x-ms-traffictypediagnostic: MWHPR21MB0479: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(189930954265078)(90097320859284)(181193635805523)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910066)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0479; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0479; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39400400002)(39410400002)(39450400003)(39840400002)(39850400002)(377454003)(13464003)(252514010)(7696004)(66066001)(5660300001)(77096006)(33656002)(76176999)(50986999)(54356999)(8936002)(478600001)(2906002)(229853002)(110136004)(102836003)(6306002)(3846002)(54906002)(9686003)(10090500001)(6116002)(4326008)(81166006)(99286003)(38730400002)(55016002)(8676002)(6246003)(3280700002)(6506006)(74316002)(5005710100001)(305945005)(6436002)(7736002)(2900100001)(3660700001)(8990500004)(966005)(189998001)(2950100002)(6916009)(14454004)(25786009)(53546010)(86362001)(86612001)(575784001)(10290500003)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0479; 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: 07 Jul 2017 18:17:34.6844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0479 Archived-At: Subject: Re: [art] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:17:39 -0000 Thanks Henry for the pointer, that is very relevant and I will cite it (and= some points in it) in a future version of this draft. Dave -----Original Message----- From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk]=20 Sent: Friday, July 7, 2017 8:15 AM To: Dave Thaler Cc: uri-review@ietf.org; dispatch@ietf.org; art@ietf.org Subject: Re: [Uri-review] Internet-Draft: Using URIs With Multiple Transpor= t Stacks Dave Thaler writes: > Recently we've seen multiple requests (including from three different > SDOs) and discussions on different lists regarding using URI schemes=20 > for application-layer protocols that can operate over multiple=20 > transport stacks (e.g., UDP, TCP, websockets, HTTP, etc.). This draft=20 > summarizes the various technical discussions and issues raised. > > Not sure if there is any regular meeting time available at IETF, but I=20 > at least wanted to share this more broadly for visibility, and to=20 > solicit additional feedback. The W3C TAG devoted a fair amount of effort to this issue about 12 years ag= o, and our thinking at the time (2005) is recorded here: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.w3= .org%2F2001%2Ftag%2Fdoc%2FSchemeProtocols.html&data=3D02%7C01%7Cdthaler%40m= icrosoft.com%7C8ef6fcd0d8f64853727a08d4c54af6f5%7C72f988bf86f141af91ab2d7cd= 011db47%7C1%7C0%7C636350373145131799&sdata=3D7tkNgY68gW0EwKJQGU676kclstxp88= Pf1CveKwVzdmM%3D&reserved=3D0 which may provide a useful independent perspective, albeit somewhat dated i= n some respects. ht --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: https://na01.safelinks.protection.outlook.com/?= url=3Dhttp:%2F%2Fwww.ltg.ed.ac.uk%2F~ht%2F&data=3D02%7C01%7Cdthaler%40micro= soft.com%7C8ef6fcd0d8f64853727a08d4c54af6f5%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C636350373145141803&sdata=3DN5MVPCx%2BN%2FeOzkFQLmC%2BPeq9JClV= ApoWwysXCPq4FGc%3D&reserved=3D0 [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From nobody Sun Jul 9 00:09:27 2017 Return-Path: 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 5CE8B129AC6; Sun, 9 Jul 2017 00:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 f_rQ1_mAr_A9; Sun, 9 Jul 2017 00:09:18 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5E3129AC1; Sun, 9 Jul 2017 00:09:17 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.89) (envelope-from ) id 1dU6LE-0001Ai-pd; Sun, 09 Jul 2017 08:09:16 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=sasharissa.local) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dU6LD-0008t3-LJ; Sun, 09 Jul 2017 08:09:15 +0100 Message-ID: <5961D699.50909@ninebynine.org> Date: Sun, 09 Jul 2017 08:09:13 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Henry S. Thompson" , Dave Thaler CC: "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Oxmail-Spam-Status: score=0.0 tests=none X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [art] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 07:09:19 -0000 Henry, thanks for this reminder. FWIW, looking at section 4 (http://www.w3.org/2001/tag/doc/SchemeProtocols.html#findings), I think R1, R3, G5, G6, R7, G8, G9 (i.e., most of the findings!) all have some bearing on the issues being discussed, insofar as they affect the World Wide Web. On a brief scan, I think the discussion here is as relevant today as it was in 2005 - some maybe more so with the move to HTTPS-everywhere. #g -- On 07/07/2017 16:15, Henry S. Thompson wrote: > Dave Thaler writes: > >> Recently we've seen multiple requests (including from three different >> SDOs) and discussions on different lists regarding using URI schemes >> for application-layer protocols that can operate over multiple >> transport stacks (e.g., UDP, TCP, websockets, HTTP, etc.). This draft >> summarizes the various technical discussions and issues raised. >> >> Not sure if there is any regular meeting time available at IETF, but I >> at least wanted to share this more broadly for visibility, and to >> solicit additional feedback. > > The W3C TAG devoted a fair amount of effort to this issue about 12 years > ago, and our thinking at the time (2005) is recorded here: > > https://www.w3.org/2001/tag/doc/SchemeProtocols.html > > which may provide a useful independent perspective, albeit somewhat > dated in some respects. > > ht > From nobody Mon Jul 10 02:30:59 2017 Return-Path: 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 0E32E128DE5; Mon, 10 Jul 2017 02:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=IRjK3+0s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=am1CYEwR 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 G6elSJ9Xvg_m; Mon, 10 Jul 2017 02:30:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA401270A7; Mon, 10 Jul 2017 02:30:48 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8B8B020A8A; Mon, 10 Jul 2017 05:30:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 10 Jul 2017 05:30:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=le1L3c9C4EyUTru7Ox GEaop5rAPKo4vYxmtFIBh/0iI=; b=IRjK3+0sSiC4gUCMa3oDykqMnSNRPnnlFQ hhVeLHHgpVPTkcrG4qP4mu0C4tk1S2nMbKt7EsIu5B/5i85+9/0qIWmhRIwE+H/w U/8MPoPn9LAgTlBmwbmyaxCDUFkoSHAfnx2Elqtfr0OJgRI2ICFli2Kww+gkFR4P s/+c4gVzLftxbrOyAxpOtunZOr3gbRH4udiS1KFMuSg2s6rjy+osQa+9a2YuxWPw XFb8mjGLbPWtMqCk/1aHPWk8v1v4l8LZ6d2Tcxd5I+xqmg767bH5PVXCQAh7+L5U I4Y84I6Wn9b0OTR2bv2HfvKSspXBMqg7/qUosT4C09TPCfDFqnZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=le1L3c9C4EyUTru7OxGEaop5rAPKo4vYxmtFIBh/0iI=; b=am1CYEwR zSZc1ZdfD+w6BmfX+gZX63AoNr33qWMUrgHhncU8XXPSlks1kTrgiAsVcVenxhkH 8+TzHSTcqIaVdhVkKZ9hHkA7ZDg8L8WzTq7uU7iPbuz6Eay25zI3nPFn+eFxUF9M tMLkcgBNSsLOVmsd31vTk3IjZnLB5xXBFuBTMNHhykdu1Zws9mM1Cuyk3iFsYuYY 6jS55fZgi4cHZwxa0rcuoMFQPe3a9AYvgTZvx8bv64yxF+LqbvEdhdb5VXq10cl4 KBWYbI1vtxJX9n1YYP7GeYgWMQ1S06PJqqEDFgJWQfeSALQzhuz14zyHSRyoxTFL /+85AIcFsR9DEA== X-ME-Sender: X-Sasl-enc: mHaAEC8llzyntVAhNyWWThociHmglXPzOCDQgnIiwkkN 1499679047 Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C72B7E8B9; Mon, 10 Jul 2017 05:30:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Mon, 10 Jul 2017 19:30:43 +1000 Cc: Dave Thaler , "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" , Noah Mendelsohn , Daniel Appelquist Content-Transfer-Encoding: quoted-printable Message-Id: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> References: To: "Henry S. Thompson" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] [dispatch] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 09:30:51 -0000 Hi Henry, Thanks for that. Looping in Noah and Dan (sorry for including you on a = list reply!). Why was the document left in draft state? Does the current TAG have any = interest in progressing a finding like this one? Cheers, > On 8 Jul 2017, at 1:15 am, Henry S. Thompson wrote: >=20 > Dave Thaler writes: >=20 >> Recently we've seen multiple requests (including from three different >> SDOs) and discussions on different lists regarding using URI schemes >> for application-layer protocols that can operate over multiple >> transport stacks (e.g., UDP, TCP, websockets, HTTP, etc.). This draft >> summarizes the various technical discussions and issues raised. >>=20 >> Not sure if there is any regular meeting time available at IETF, but = I >> at least wanted to share this more broadly for visibility, and to >> solicit additional feedback. >=20 > The W3C TAG devoted a fair amount of effort to this issue about 12 = years > ago, and our thinking at the time (2005) is recorded here: >=20 > https://www.w3.org/2001/tag/doc/SchemeProtocols.html >=20 > which may provide a useful independent perspective, albeit somewhat > dated in some respects. >=20 > ht > --=20 > Henry S. Thompson, School of Informatics, University of = Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 = 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is = forged spam] >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jul 10 21:14:13 2017 Return-Path: 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 970D712ECC1 for ; Mon, 10 Jul 2017 21:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=jg612XIG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n+po/1z1 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 Bjl8Y6EkZfjn for ; Mon, 10 Jul 2017 21:14:08 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49DF12EC19 for ; Mon, 10 Jul 2017 21:14:08 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2363220616; Tue, 11 Jul 2017 00:14:08 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 11 Jul 2017 00:14:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=UN5HwSToGIjujPD21bDfJPex/zNto5EN02MbWnQpw FY=; b=jg612XIGGfhP86jk9KhgxFzE0XXafU2bxT9x/1243Z3fhKWu5mIRUahGk cJW3gVtIZ4vfVXZtTbzPESv2WoCzgII1k0cWoxzzX39xDgZ/1mEUanKyldFEB1tA tXO3SzN72p1XhqlpyXoOvyQFHbeaWkQES5a9UOQ+tE1jfc3kOwijy3Ray46M3Qpp 8gQr/eXEoVLN3fIpQez0rEBpN8qRcExNAI1o0XjJt+ntW9e8j1uNJUCy0Fiju5X5 gCN3Qyw9NnayKAbGQPw+ZgyPnkWJu2pyIUYDJWH30q+FR8Rm1NIF7nfAY8VzyrE0 Aui19iuHeKw7jDbfM7dDEGUJEFCYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=UN5HwSToGIjujPD21b DfJPex/zNto5EN02MbWnQpwFY=; b=n+po/1z1XtzDdx+/7extOk8QCru5dh+JtS ZYttnKap4XkL274FahIeV5k+Yx/CI/foYzbQN2DEgVzdhYLn6890xvzQQGsmsZZj ll1RStBBxC/Q+FkUzfpOFPI17CLnFZuTSS+aPMhiol4hB5PDM3FjleSY+Ek/n5jn +0yoY4rBa+ypf86+bcuQ/beRhu5P9ZKsq3bkCX2gCFEzDY9GKqDiVwH5XB2PI4/L Wz775CXZTlEYHJY3ks5H2kPiutNLWNZAbVFq+ErQoUH84TWss0yUzYkJSBSoFrfk 0Flml3VW72UTMwdh0xUuqhm2VjXFqfvqMNg/pYvZYDBB0xQUxBsw== X-ME-Sender: X-Sasl-enc: EcblV7QHmkbgWHj13vnsJ3Yc7MJGJgLuj6djs1Bak9dR 1499746447 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id F1AF37E809; Tue, 11 Jul 2017 00:14:06 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> Date: Tue, 11 Jul 2017 14:14:04 +1000 Cc: Patrick McManus , Alexey Melnikov To: art@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 04:14:11 -0000 A number of folks have recently noted that BCP56 addresses the problems = of using HTTP for protocols in the early 2000's, but we've moved on = considerably since then.=20 Given the number of IETF protocols being build upon HTTP these days, it = seems timely to reconsider it. I've been working on a candidate for = replacing it for a little while; see: https://tools.ietf.org/html/draft-nottingham-bcp56bis https://mnot.github.io/I-D/bcp56bis/ I have a small-ish slot in the HTTP WG session on Wednesday to discuss = this.=20 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 11 01:36:10 2017 Return-Path: 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 3A92D1319E7 for ; Tue, 11 Jul 2017 01:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5JPoz1_nUirt for ; Tue, 11 Jul 2017 01:36:07 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4E01319E6 for ; Tue, 11 Jul 2017 01:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3840; q=dns/txt; s=iport; t=1499762167; x=1500971767; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=1+uF8zUnkMXmAByLtG7szMx8XDzV2KzXQVhz5uxxJWc=; b=MqgIQvi1LdF1LcRpWFK5DmyiAeUtkaCTqtYZ/0pgzUFDas/IO/pWcj+J li88YnnW8kqjl8JxIOuK8b5IU0waQrsHk89Ka/HeRpVtWz91GnQ3KRtFc 092TefIJSW1+1SzoJJlKuR7Wp//YY0489dzDcvXUzIm+ugbw1uc2sCUOx A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAQAIjWRZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFI58kHmWA4IRBxoLhDWBFQKDcRcBAgEBAQEBAQFrKIUZAQE?= =?us-ascii?q?BAwEBIUsLEAsOCioCAicwBgEMBgIBAYorEKwcgiaLOQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREKBYMohS4rgnmHfYJhBYcil32EKoIdgQGHC4U5iyaGf5VCIAE2gQoxIQg?= =?us-ascii?q?bFUmFExyBaT42iC4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,345,1496102400"; d="asc'?scan'208";a="654189015" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 08:36:02 +0000 Received: from [10.61.241.136] ([10.61.241.136]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6B8a2wI030430; Tue, 11 Jul 2017 08:36:02 GMT To: Mark Nottingham , art@ietf.org Cc: Patrick McManus , Alexey Melnikov References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> From: Eliot Lear Message-ID: Date: Tue, 11 Jul 2017 10:36:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KPWqQ0bGswajT5R9hRVPOuTc232tD7CEo" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 08:36:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KPWqQ0bGswajT5R9hRVPOuTc232tD7CEo Content-Type: multipart/mixed; boundary="BT0WmkL1eHM1tNLpEV2HAlBdnRPO0F3GH"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham , art@ietf.org Cc: Patrick McManus , Alexey Melnikov Message-ID: Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> In-Reply-To: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> --BT0WmkL1eHM1tNLpEV2HAlBdnRPO0F3GH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Mark, There is no question that 3205 could use a dust off. I would suggest that document really served two purposes. The first was to provide best practices on its use, and the second was more of an applicability statement. You've gone to some detail as to best practices, but it seems to me more attention should be paid to the applicability component.= Good engineering principles dictate not only when a mechanism should be used, but as important, when it should not. HTTP's use has GREATLY expanded thanks in large part to REST, but it also could it might narrow somewhat, thanks to protocols such as CoAP, or through the further development of QUIC. A valuable contribution would be to give guidance as to what substrate is appropriate and when. Related, we TCP/UDP port reviewers occasionally see requests for new ports that make use of HTTP as a substrate. Personally I always welcome more guidance as to when to approve those ports. The standing view is that we approve them in large part to address non-interference with existing services, but at some level that seems a bit of a waste, and perhaps we should come out more strongly to say that if HTTP is really to be used as a substrate, there must be some form of appropriate application layer dispatch perhaps tied to .well-known. I won't be attending the HTTPBIS meeting but I hope you'll consider these comments as you develop the document. Eliot On 7/11/17 6:14 AM, Mark Nottingham wrote: > A number of folks have recently noted that BCP56 addresses the problems= of using HTTP for protocols in the early 2000's, but we've moved on cons= iderably since then.=20 > > Given the number of IETF protocols being build upon HTTP these days, it= seems timely to reconsider it. I've been working on a candidate for repl= acing it for a little while; see: > https://tools.ietf.org/html/draft-nottingham-bcp56bis > https://mnot.github.io/I-D/bcp56bis/ > > I have a small-ish slot in the HTTP WG session on Wednesday to discuss = this.=20 > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --BT0WmkL1eHM1tNLpEV2HAlBdnRPO0F3GH-- --KPWqQ0bGswajT5R9hRVPOuTc232tD7CEo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZZI3xAAoJEIe2a0bZ0nozvxYH+gMBmNJeJJkzWIN9JPXGZg4a svXsNJBw6OP1tpYBHWDWZJaPGy6bIB7RvaS1NdCpsIHE+nfxFMVUNrAwoC3+0Ayu 6Q6/bgF1EOJSC/dYShRHsrK4JcbMbqe6My5QhDhcQspvrKhHy2vXY/5QXjciq2o0 6aJi2ahoZIT2NMnDBIxwj1+sUkDxJccC7mDhXZ+E7hJaHwsdtiKqgEA/pmVKzwet qef97XtevgA0OiHEjr3sA/mNQqb+xCBFFYKfAI4MeQlGNetN05TNOF3qWtqJTzht KDiU4WmrwuyglGVN/1pf4TM/JnUhOUIrr8kkhoQ1rRT5G6StNw3hVoquuDqpE9g= =YppX -----END PGP SIGNATURE----- --KPWqQ0bGswajT5R9hRVPOuTc232tD7CEo-- From nobody Wed Jul 12 04:02:42 2017 Return-Path: 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 5C218131675 for ; Wed, 12 Jul 2017 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ADG0kYA8dyWt for ; Wed, 12 Jul 2017 04:02:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4957413167A for ; Wed, 12 Jul 2017 04:02:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E1C5FB81502; Wed, 12 Jul 2017 04:02:35 -0700 (PDT) To: andreas@sbin.se, nilsson@opera.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, superuser@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: vfaronov@gmail.com, art@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170712110235.E1C5FB81502@rfc-editor.org> Date: Wed, 12 Jul 2017 04:02:35 -0700 (PDT) Archived-At: Subject: [art] [Technical Errata Reported] RFC7239 (5067) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 11:02:40 -0000 The following errata report has been submitted for RFC7239, "Forwarded HTTP Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5067 -------------------------------------- Type: Technical Reported by: Vasiliy Faronov Section: GLOBAL Original Text ------------- proxy Corrected Text -------------- message-forwarding agent Notes ----- According to RFC 7230 Section 2.3, an HTTP "proxy" is a message-forwarding agent that is selected by the client. But this specification (as is clear from Section 1) uses the word "proxy" to refer also to message-forwarding agents that are *not* selected by the client. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7239 (draft-ietf-appsawg-http-forwarded-10) -------------------------------------- Title : Forwarded HTTP Extension Publication Date : June 2014 Author(s) : A. Petersson, M. Nilsson Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Jul 12 09:53:55 2017 Return-Path: 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 477E6127B73; Wed, 12 Jul 2017 09:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 Rr93IIul_XXL; Wed, 12 Jul 2017 09:53:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FC0127978; Wed, 12 Jul 2017 09:53:53 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6CGrpgX032587 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Jul 2017 11:53:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: art@ietf.org Cc: "art-ads@ietf.org" From: Adam Roach Message-ID: Date: Wed, 12 Jul 2017 11:53:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [art] ART Area Directors Office Hours X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 16:53:54 -0000 The ART Area Directors[1] will be holding office hours from 14:20 to 15:50 on Tuesday, July 18th. We will be in the IESG breakout room, Paris [2]. Feel free to drop by if you have anything ART-related to chat about. /a ____ [1] Note that I will only be available from ~15:30 to 15:50, so you may want to come later in the block if you want to speak to me. Ben and Alexey plan to be there the whole time. [2] https://datatracker.ietf.org/meeting/99/floor-plan?room=paris#prague-hilton-lobby From nobody Thu Jul 13 05:37:46 2017 Return-Path: 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 C4FD1131A67 for ; Thu, 13 Jul 2017 05:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tWk4ph-i63V2 for ; Thu, 13 Jul 2017 05:37:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C0A131A5F for ; Thu, 13 Jul 2017 05:37:43 -0700 (PDT) Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6DCb8Ih010887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 05:37:19 -0700 (PDT) To: Eliot Lear , Mark Nottingham , art@ietf.org Cc: Patrick McManus , Alexey Melnikov References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> From: Joe Touch Message-ID: Date: Thu, 13 Jul 2017 05:37:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E6D6B083B140D4AE8056F5A2" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 12:37:46 -0000 This is a multi-part message in MIME format. --------------E6D6B083B140D4AE8056F5A2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, I too look forward to this coordination, especially as Eliot notes its impact on the IANA ports review team. I would encourage a look at RFC 7605 on this issue. Joe On 7/11/2017 1:36 AM, Eliot Lear wrote: > Hi Mark, > > There is no question that 3205 could use a dust off. I would suggest > that document really served two purposes. The first was to provide best > practices on its use, and the second was more of an applicability > statement. You've gone to some detail as to best practices, but it > seems to me more attention should be paid to the applicability component. > > Good engineering principles dictate not only when a mechanism should be > used, but as important, when it should not. HTTP's use has GREATLY > expanded thanks in large part to REST, but it also could it might narrow > somewhat, thanks to protocols such as CoAP, or through the further > development of QUIC. A valuable contribution would be to give guidance > as to what substrate is appropriate and when. > > Related, we TCP/UDP port reviewers occasionally see requests for new > ports that make use of HTTP as a substrate. Personally I always welcome > more guidance as to when to approve those ports. The standing view is > that we approve them in large part to address non-interference with > existing services, but at some level that seems a bit of a waste, and > perhaps we should come out more strongly to say that if HTTP is really > to be used as a substrate, there must be some form of appropriate > application layer dispatch perhaps tied to .well-known. > > I won't be attending the HTTPBIS meeting but I hope you'll consider > these comments as you develop the document. > > Eliot > > > > On 7/11/17 6:14 AM, Mark Nottingham wrote: >> A number of folks have recently noted that BCP56 addresses the problems of using HTTP for protocols in the early 2000's, but we've moved on considerably since then. >> >> Given the number of IETF protocols being build upon HTTP these days, it seems timely to reconsider it. I've been working on a candidate for replacing it for a little while; see: >> https://tools.ietf.org/html/draft-nottingham-bcp56bis >> https://mnot.github.io/I-D/bcp56bis/ >> >> I have a small-ish slot in the HTTP WG session on Wednesday to discuss this. >> >> Cheers, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> > > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art --------------E6D6B083B140D4AE8056F5A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, all,

I too look forward to this coordination, especially as Eliot notes its impact on the IANA ports review team.

I would encourage a look at RFC 7605 on this issue.

Joe


On 7/11/2017 1:36 AM, Eliot Lear wrote:
Hi Mark,

There is no question that 3205 could use a dust off.  I would suggest
that document really served two purposes.  The first was to provide best
practices on its use, and the second was more of an applicability
statement.  You've gone to some detail as to best practices, but it
seems to me more attention should be paid to the applicability component.

Good engineering principles dictate not only when a mechanism should be
used, but as important, when it should not.  HTTP's use has GREATLY
expanded thanks in large part to REST, but it also could it might narrow
somewhat, thanks to protocols such as CoAP, or through the further
development of QUIC.  A valuable contribution would be to give guidance
as to what substrate is appropriate and when.

Related, we TCP/UDP port reviewers occasionally see requests for new
ports that make use of HTTP as a substrate.  Personally I always welcome
more guidance as to when to approve those ports.  The standing view is
that we approve them in large part to address non-interference with
existing services, but at some level that seems a bit of a waste, and
perhaps we should come out more strongly to say that if HTTP is really
to be used as a substrate, there must be some form of appropriate
application layer dispatch perhaps tied to .well-known.

I won't be attending the HTTPBIS meeting but I hope you'll consider
these comments as you develop the document.

Eliot



On 7/11/17 6:14 AM, Mark Nottingham wrote:

A number of folks have recently noted that BCP56 addresses the problems of using HTTP for protocols in the early 2000's, but we've moved on considerably since then. 

Given the number of IETF protocols being build upon HTTP these days, it seems timely to reconsider it. I've been working on a candidate for replacing it for a little while; see:
  https://tools.ietf.org/html/draft-nottingham-bcp56bis
  https://mnot.github.io/I-D/bcp56bis/

I have a small-ish slot in the HTTP WG session on Wednesday to discuss this. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art






_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

--------------E6D6B083B140D4AE8056F5A2-- From nobody Fri Jul 14 05:45:06 2017 Return-Path: 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 94B13131678; Fri, 14 Jul 2017 05:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 RTctepWkXtqx; Fri, 14 Jul 2017 05:44:56 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A36128DE5; Fri, 14 Jul 2017 05:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6ECiprN005609; Fri, 14 Jul 2017 14:44:51 +0200 (CEST) Received: from [10.10.10.206] (unknown [62.214.5.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x8C7l3XXnzDKlr; Fri, 14 Jul 2017 14:44:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 14 Jul 2017 14:44:49 +0200 Cc: Dave Thaler , "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" X-Mao-Original-Outgoing-Id: 521729089.263934-877c281628a79c5651999f5a11a7df6d Content-Transfer-Encoding: quoted-printable Message-Id: <2A71B82F-4A5C-4F09-ADDB-2DD50742D14A@tzi.org> References: To: "Henry S. Thompson" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [art] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 12:44:59 -0000 On Jul 7, 2017, at 17:15, Henry S. Thompson wrote: >=20 > https://www.w3.org/2001/tag/doc/SchemeProtocols.html I think this is an interesting reference, as it confirms what has been = my perception of the debate so far: > Although new protocols have traditionally been associated with new URI = schemes, there are also advantages to supporting new protocols using = existing schemes. In particular, the URIs of existing resources may be = widely known, may have been bookmarked or otherwise recorded, or may = have been the subject of semantic web assertions. It seems to me that the conventional wisdom in this space is shaped by = experience with URIs that are intended to be long-term, stable, possibly = user-visible. Like https://facebook.com =E2=80=94 a *strategic* use of = URIs. The stability of this URI is so important that the additional = time and effort to do discovery (here: DNS lookup, possibly Happy = Eyeballs) is apparently justified (*). In CoRE, URIs are quite often the *result* of discovery (e.g., involving = a resource directory). They are meant to be instantly usable. They are = much more likely to contain IP addresses than in the Browser Web, to = avoid additional lookups. They are *tactical* URIs. I=E2=80=99m not sure we should be applying the wisdom we have for = strategic URIs to tactical URIs without checking whether the underlying = assumptions still apply. Maybe using the URI concept for tactical purposes is the wrong approach. = URIs were the one part of the three pillars of the Web we thought we = could use unmodified, but that caused some trade-offs. There are = multiple proposals to define a URI-like data structure for the purpose = that I called =E2=80=9Ctactical=E2=80=9D above. Doing that would also = enable us to solve the rather limited support for security that URIs = have; right now URIs often need to be packaged with security information = in a larger structure, so we might want to unpack the URI into that. But for now, URIs are in wide use, and it would be good if we could use = them for tactical purposes without getting stuck with all the baggage of = strategic use. Gr=C3=BC=C3=9Fe, Carsten (*) And yet, it only recently replaced http://facebook.com...= From nobody Sat Jul 15 01:49:22 2017 Return-Path: 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 C31C512EC18; Sat, 15 Jul 2017 01:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DwKUTSOzc2Cc; Sat, 15 Jul 2017 01:49:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E28127058; Sat, 15 Jul 2017 01:49:03 -0700 (PDT) Received: from dhcp-9616.meeting.ietf.org (dhcp-9616.meeting.ietf.org [31.133.150.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6F8mw87064523 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 15 Jul 2017 03:49:00 -0500 (CDT) (envelope-from adam@nostrum.com) To: Carsten Bormann , "Henry S. Thompson" Cc: "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" , Dave Thaler References: <2A71B82F-4A5C-4F09-ADDB-2DD50742D14A@tzi.org> From: Adam Roach Message-ID: <7bddc0af-25df-93ba-a682-43fce63c4022@nostrum.com> Date: Sat, 15 Jul 2017 10:48:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2A71B82F-4A5C-4F09-ADDB-2DD50742D14A@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [art] [dispatch] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 08:49:05 -0000 On 7/14/17 14:44, Carsten Bormann wrote: > On Jul 7, 2017, at 17:15, Henry S. Thompson wrote: >> https://www.w3.org/2001/tag/doc/SchemeProtocols.html > I think this is an interesting reference, as it confirms what has been my perception of the debate so far: > >> Although new protocols have traditionally been associated with new URI schemes, there are also advantages to supporting new protocols using existing schemes. In particular, the URIs of existing resources may be widely known, may have been bookmarked or otherwise recorded, or may have been the subject of semantic web assertions. > > It seems to me that the conventional wisdom in this space is shaped by experience with URIs that are intended to be long-term, stable, possibly user-visible. Like https://facebook.com — a *strategic* use of URIs. The stability of this URI is so important that the additional time and effort to do discovery (here: DNS lookup, possibly Happy Eyeballs) is apparently justified (*). > > In CoRE, URIs are quite often the *result* of discovery (e.g., involving a resource directory). They are meant to be instantly usable. They are much more likely to contain IP addresses than in the Browser Web, to avoid additional lookups. They are *tactical* URIs. I think you stopped quoting the paragraph before it got to something highly relevant for CoAP: "...there are serious drawbacks to naming the same resource with more than one URI..." I do see that the TCP draft as submitted for consideration tries to deal with this by making making the TCP-only schemes use a different namespace than the original schemes, but this looks like a sleight of hand: in practice, it seems highly likely that servers will need to make resources available to both TCP-only clients and UDP-only clients, which makes this kind of aliasing inevitable. I do not believe the "tactical versus strategic" distinction you're trying to draw here has any bearing on that aspect of URL use. /a From nobody Sat Jul 15 02:12:51 2017 Return-Path: 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 2419412EBF9; Sat, 15 Jul 2017 02:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 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_H2=-2.8, 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 6jpTBV5m4vVn; Sat, 15 Jul 2017 02:12:48 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0119.outbound.protection.outlook.com [104.47.41.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F5F126DC2; Sat, 15 Jul 2017 02:12:48 -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=Idjp4k4+NP+mnCk5wwRCFZiA4MsgHH/+DqEz06jfdKc=; b=MahVPiYhzkVg4LqTdfvG3t7sZFEwDlRYtJQN+Fgf4hJPyJzW+a6UiVWPjhDVCrTQ3ife1ZLapZR7yqY6+egEw3iNNBLwH0h5nBYBNeApuLWf2OEfJ9qu1UJngIdRlcbzlZtFDbEvQlIm9s7uvR/9Pkv9pjBYqftakRW3YexVmX8= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0509.namprd21.prod.outlook.com (10.172.95.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Sat, 15 Jul 2017 09:12:47 +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.007; Sat, 15 Jul 2017 09:12:47 +0000 From: Dave Thaler To: Adam Roach , Carsten Bormann , "Henry S. Thompson" CC: "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" Thread-Topic: [dispatch] [art] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks Thread-Index: AdL2j89KknngpoFTRaiO7w0jXk0ylAApAZzNAVrJRIAAKg3LgAAArVag Date: Sat, 15 Jul 2017 09:12:47 +0000 Message-ID: References: <2A71B82F-4A5C-4F09-ADDB-2DD50742D14A@tzi.org> <7bddc0af-25df-93ba-a682-43fce63c4022@nostrum.com> In-Reply-To: <7bddc0af-25df-93ba-a682-43fce63c4022@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:1232:144:f040:15e5:6be1:892c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0509; 7:Fz9vNIucJHRZoucMu1h9JKMzmsLTAidtdJGirhJ9bV3MxJtyiRwZL0UaO3/wDc8307OCLw6P+4qlSwXtaWeHmcgpnLDWQjr49N0/bAHuQS+C85UBkK8SFpeBwsaxX+CigvyyY1sdwPu/yc7m4h7vbAuuCLTucbTWwu7si5jDL3rkax6/vYLhGEO//PaL1ZhXjAogoGb09wTG3krO4P6v9+6E2hIlucfLVtLET3jZiUvrNlv6vQ9IonFL0OSxCom7+PeEhlyckYrT2X+k3RknzRL0AY2V0nPEBYencOdqQSw5NaG5yMf3VutjM7Ll5+m/K/gnbL1JxV10Y1n+kA/qt9Os5XO38sK1bgaaYZrS3zfF6Ue3BMN1c57lM0pyEAqCJ/BVXZx7sJYp7zh2CipytJlkH+nFtftGnbrgC7qrphQ+2QnA8aiob0Rja4nLK5qiQmH2ZBGKxgfv7xOiBCGwODuNUJVfGs532A567MuzuRaJbrT4NXTCA/Cycwczko80UVxVarihznGGvOcBWL+fkW8doVA4W3YmzadiPzBOpSsROjdDT2EwFlVBSJ8yGJZuw9rmmu2OklbQthcY9aj/Ecz7UjoxMa2/XNP6dtHgmTFBFgTp5nP7j8gqLQc0eFI0dQf7pgBHeUQfcjTV9VdBrdtJh2d6rk6k46lbyIFj1tmC0D8W20wUOMeSN+c98JakGa1prNz8mpWgZ+Nua4V6iz8b2tkknBhpuFkzzrKGHncYN7Sql+eG+MYAfKHJo7qKeJjVw8XZUeJoPlURKDJEn5RdA7YLoqUaUdghoRHnJDH/Qb2ekxcEu0dTqZf0wI84 x-ms-office365-filtering-correlation-id: 3f4b8bec-462d-45c0-1d8f-08d4cb61a8e9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0509; x-ms-traffictypediagnostic: MWHPR21MB0509: x-exchange-antispam-report-test: UriScan:(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0509; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0509; x-forefront-prvs: 0369E8196C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(24454002)(54356999)(76176999)(54906002)(10290500003)(50986999)(99286003)(7696004)(55016002)(5005710100001)(2900100001)(189998001)(478600001)(9686003)(74316002)(25786009)(6246003)(53936002)(38730400002)(5660300001)(14454004)(10090500001)(6506006)(3280700002)(86612001)(305945005)(86362001)(81166006)(2950100002)(2906002)(77096006)(8676002)(6436002)(3660700001)(4326008)(8936002)(93886004)(229853002)(33656002)(7736002)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0509; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 09:12:47.1417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0509 Archived-At: Subject: Re: [art] [dispatch] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 09:12:50 -0000 QWRhbSBSb2FjaCB3cm90ZToNCj4gSSB0aGluayB5b3Ugc3RvcHBlZCBxdW90aW5nIHRoZSBwYXJh Z3JhcGggYmVmb3JlIGl0IGdvdCB0byBzb21ldGhpbmcgaGlnaGx5IHJlbGV2YW50IGZvciBDb0FQ OiANCj4gIi4uLnRoZXJlIGFyZSBzZXJpb3VzIGRyYXdiYWNrcyB0byBuYW1pbmcgdGhlIHNhbWUg cmVzb3VyY2Ugd2l0aCBtb3JlIHRoYW4gb25lIFVSSS4uLiIgIEkgZG8gDQo+IHNlZSB0aGF0IHRo ZSBUQ1AgZHJhZnQgYXMgc3VibWl0dGVkIGZvciBjb25zaWRlcmF0aW9uIHRyaWVzIHRvIGRlYWwg d2l0aCB0aGlzIGJ5IG1ha2luZyBtYWtpbmcgDQo+IHRoZSBUQ1Atb25seSBzY2hlbWVzIHVzZSBh IGRpZmZlcmVudCBuYW1lc3BhY2UgdGhhbiB0aGUgb3JpZ2luYWwgc2NoZW1lcywgYnV0IHRoaXMg bG9va3MgbGlrZQ0KPiBhIHNsZWlnaHQgb2YgaGFuZDogaW4gcHJhY3RpY2UsIGl0IHNlZW1zIGhp Z2hseSBsaWtlbHkgdGhhdCBzZXJ2ZXJzIHdpbGwgbmVlZCB0byBtYWtlIHJlc291cmNlcw0KPiBh dmFpbGFibGUgdG8gYm90aCBUQ1Atb25seSBjbGllbnRzIGFuZCBVRFAtb25seSBjbGllbnRzLCB3 aGljaCBtYWtlcyB0aGlzIGtpbmQgb2YgYWxpYXNpbmcgaW5ldml0YWJsZS4NCj4NCj4gSSBkbyBu b3QgYmVsaWV2ZSB0aGUgInRhY3RpY2FsIHZlcnN1cyBzdHJhdGVnaWMiIGRpc3RpbmN0aW9uIHlv dSdyZSB0cnlpbmcgdG8gZHJhdyBoZXJlIGhhcyBhbnkgYmVhcmluZw0KPiBvbiB0aGF0IGFzcGVj dCBvZiBVUkwgdXNlLg0KDQpPQ0YgZGVmaW5lcyBhIGhpZ2hlciBsYXllciBVUkkgd2hpY2ggaXMg dGhlIHNhbWUgcmVnYXJkbGVzcyBvZiB3aGljaCB0cmFuc3BvcnQgeW91IHVzZSAoQ09BUCBvdmVy DQpVRFAsIENPQVAgb3ZlciBUQ1AsIEhUVFAsIHdoYXRldmVyIGVsc2UpIGZvciB0aGUgcmVhc29u cyB5b3UgYWxsdWRlIHRvLCBidXQgdGhhdCBVUkkgaXMgYXQgdGhlIA0KbGF5ZXIgdGhhdCBhcHBz IHNob3VsZCB1c2UgKHdoaWNoIEkgdGFrZSBpdCBpcyB3aGF0IENhcnN0ZW4gY2FsbHMgInN0cmF0 ZWdpYyIpLiAgIEJ1dCB0aGF0IGhhcyB0byBiZSByZXNvbHZlZA0KdG8gYSBzZXQgb2YgdHJhbnNw b3J0IGVuZHBvaW50cywgYW5kIGluIHNvbWUgY2FzZXMgdGhlIHRyYW5zcG9ydCBlbmRwb2ludHMg YXJlIGFscmVhZHkgZXhwcmVzc2VkDQp2aWEgVVJJcyAoZS5nLiwgYSB3ZWJzb2NrZXQpLiAgIFRo YXQncyB0aGUgbGF5ZXIgdGhhdCBJIHRoaW5rIENhcnN0ZW4gaXMgY2FsbGluZyAidGFjdGljYWwi LiAgIEEgZGlmZmVyZW50DQp0ZXJtaW5vbG9neSBtaWdodCBiZSBpZCB2cyBsb2NhdG9yLCB3aGVy ZSBVUklzIGFyZSBhbHNvIHVzZWQgZm9yIGxvY2F0b3JzIGluIHRoYXQgc2Vuc2UuICAgVGhhdCdz DQp3aGF0IHRoZSBDT0FQLVRDUCBkcmFmdCBpcyBkb2luZy4uLiBkZWZpbmluZyBzY2hlbWVzIHVz YWJsZSBmb3IgbG9jYXRvcnMgdW5kZXJuZWF0aCBpZHMuICAgT25lIHBvaW50DQppbiBteSBkb2Mg aXMgdGhhdCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgbGF5ZXJzIG5vdCBqdXN0IHR3byAoaWQgdnMg bG9jYXRvcikgYW5kIHNvIHVzaW5nIFVSSXMgYXQgZWFjaCANCmxheWVyIGFsbG93cyBzdWNoIGNo YWluaW5nL3N0YWNraW5nLg0KDQpEYXZlDQo= From nobody Sat Jul 15 02:20:49 2017 Return-Path: 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 51963131B9D for ; Sat, 15 Jul 2017 02:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Zi9eqvD1InaE for ; Sat, 15 Jul 2017 02:20:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1812F131B43 for ; Sat, 15 Jul 2017 02:20:46 -0700 (PDT) Received: from dhcp-9616.meeting.ietf.org (dhcp-9616.meeting.ietf.org [31.133.150.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6F9Kf9W070108 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 15 Jul 2017 04:20:42 -0500 (CDT) (envelope-from adam@nostrum.com) To: Mark Nottingham , art@ietf.org Cc: Patrick McManus , Alexey Melnikov References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> From: Adam Roach Message-ID: Date: Sat, 15 Jul 2017 11:20:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 09:20:47 -0000 I found 4.3.2 particularly interesting, as there doesn't seem to have been consensus in this space in the past. For example, the ws(s) and ipp(s) schemes made a different decision. I presume your assertion is that, were we defining these protocols today, they would be using http(s) instead? I don't see anything wrong with that; I just want to probe the edges of this advice by seeing how it would have applied to decisions we made in the past, since that's a pretty good predictor for how it might apply in the future. The advice in 4.3.3 seems a bit strong, in that it will require whatever process listens on port 443 to take on an ever-increasing role. If we're going to keep this advice, I think the document needs some treatment of the software architecture implications: functionally, whatever listens to port 443 will need to be able to delegate sub-trees of the URL space to other processes. I know that some web servers have mechanisms to handle this kind of thing today; but we're effectively saying that this will become required base functionality for web servers moving forward. I wonder, in that context, whether the current advice strikes the right balance. /a On 7/11/17 06:14, Mark Nottingham wrote: > A number of folks have recently noted that BCP56 addresses the problems of using HTTP for protocols in the early 2000's, but we've moved on considerably since then. > > Given the number of IETF protocols being build upon HTTP these days, it seems timely to reconsider it. I've been working on a candidate for replacing it for a little while; see: > https://tools.ietf.org/html/draft-nottingham-bcp56bis > https://mnot.github.io/I-D/bcp56bis/ > > I have a small-ish slot in the HTTP WG session on Wednesday to discuss this. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Sat Jul 15 02:31:38 2017 Return-Path: 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 67AE9131B43 for ; Sat, 15 Jul 2017 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 uaTWqWO7qtK6 for ; Sat, 15 Jul 2017 02:31:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A703812EC4B for ; Sat, 15 Jul 2017 02:31:33 -0700 (PDT) Received: from [10.43.10.6] (61.3e.32a9.ip4.static.sl-reverse.com [169.50.62.97]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6F9VLpD071924 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 15 Jul 2017 04:31:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 61.3e.32a9.ip4.static.sl-reverse.com [169.50.62.97] claimed to be [10.43.10.6] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Sat, 15 Jul 2017 11:31:19 +0200 Cc: Mark Nottingham , art@ietf.org, Patrick McManus , Alexey Melnikov Content-Transfer-Encoding: quoted-printable Message-Id: <58EE0072-8E7F-4A16-885E-E767F9363E9D@nostrum.com> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 09:31:36 -0000 > On Jul 15, 2017, at 11:20 AM, Adam Roach wrote: >=20 > I found 4.3.2 particularly interesting, as there doesn't seem to have = been consensus in this space in the past. For example, the ws(s) and = ipp(s) schemes made a different decision. I presume your assertion is = that, were we defining these protocols today, they would be using = http(s) instead? >=20 > I don't see anything wrong with that; I just want to probe the edges = of this advice by seeing how it would have applied to decisions we made = in the past, since that's a pretty good predictor for how it might apply = in the future. >=20 > The advice in 4.3.3 seems a bit strong, in that it will require = whatever process listens on port 443 to take on an ever-increasing role. = If we're going to keep this advice, I think the document needs some = treatment of the software architecture implications: functionally, = whatever listens to port 443 will need to be able to delegate sub-trees = of the URL space to other processes. I know that some web servers have = mechanisms to handle this kind of thing today; but we're effectively = saying that this will become required base functionality for web servers = moving forward.\ >=20 > I wonder, in that context, whether the current advice strikes the = right balance. >=20 Also, while I recognize the difference between protocols =E2=80=9Cusing = HTTPS=E2=80=9D on 443 vs non-HTTPS protocols using 443 for NAT traversal = purposes, the recent controversy over CORE's use of 443 suggests that = this discussion will need to go beyond ART. At least, I think some TSV = and OPS people may have opinions. Maybe those opinions will be =E2=80=9Cit= =E2=80=99s HTTPS, use HTTPS=E2=80=9D, but we should verify. (I suspect = network management people may have concerns.) Ben. > /a >=20 > On 7/11/17 06:14, Mark Nottingham wrote: >> A number of folks have recently noted that BCP56 addresses the = problems of using HTTP for protocols in the early 2000's, but we've = moved on considerably since then. >>=20 >> Given the number of IETF protocols being build upon HTTP these days, = it seems timely to reconsider it. I've been working on a candidate for = replacing it for a little while; see: >> https://tools.ietf.org/html/draft-nottingham-bcp56bis >> https://mnot.github.io/I-D/bcp56bis/ >>=20 >> I have a small-ish slot in the HTTP WG session on Wednesday to = discuss this. >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Sat Jul 15 07:09:13 2017 Return-Path: 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 62414129AC4 for ; Sat, 15 Jul 2017 07:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XzMpA2yl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZugKzNXr 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 zK2V0QE2A6ae for ; Sat, 15 Jul 2017 07:09:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA51D127077 for ; Sat, 15 Jul 2017 07:09:09 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EEFC7208DF; Sat, 15 Jul 2017 10:09:08 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 15 Jul 2017 10:09:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=iX+Sbebs8BbLEdJ77f 94ARsU/36pmrAE2LvaBal25IY=; b=XzMpA2yl0v2kRtHEmQx/0rMSJyMdL13QpS a2OTIAgPBPA2hx01+QOjXX5A81WfDp+KkubOfNPRZgIZl+dOwTMoEfPqTDZeIvSn TGXooQtimx2SgyqvtvIJyDseDo2P63nGpeIzJzlBThbn+QLOJaxbz/uY3OD5WBAh am8MiNC9SDBxYOAAtgLO8Yi5eSIqjYHFBroPWXzOJsAVlGXscO2NzPgBpvFNMe7b ZIm81tQjFGnfCeYo0eEcPprpG697yxBfaZMwRhnmC58b5dIjkmJpximwArXe9MxG scR3mrgcIch7+Yov2pM7puyTf1y0VGN1bGSKcj8BbT38ccf5ylHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=iX+Sbebs8BbLEdJ77f94ARsU/36pmrAE2LvaBal25IY=; b=ZugKzNXr s5/PquwtGG0NoYXpdu9u90W/QqHxkjrc1AUfl68AI3OyiUlC/5o0vs4H/lC0wuam bpp9jArmIk9xf8N17ncL6IVHXm7RpLPYyEWpW7fW6oAhgbIjoXC78Gl2aqZ7Q3YY cFuc4cj1cXuEqqkL2aOJvKRco18WN7us9HEtn7IkTHivmIeTthVJvadDWhP3nLWk G0FF4WOzKPhRaTWrsJYfAomQsHoilWoIU3E/s/bh3Rc4lzLCidmfjaZBUMfUy4Nb 5bozgTVukjr1274pCYGM+WxRs9La93ppnOOSv3Z9uGG0aAUmOcYIsGc2fA7NES3A tUPUJMYaoO9FKA== X-ME-Sender: X-Sasl-enc: S4WgSwD9ItnwNUEpI4cKXAjlvU6GHE0aOl9SGsNsbthz 1500127748 Received: from dhcp-813f.meeting.ietf.org (dhcp-813f.meeting.ietf.org [31.133.129.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 436287E46B; Sat, 15 Jul 2017 10:09:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Sat, 15 Jul 2017 16:09:06 +0200 Cc: art@ietf.org, Patrick McManus , Alexey Melnikov Content-Transfer-Encoding: quoted-printable Message-Id: References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 14:09:12 -0000 > On 15 Jul 2017, at 11:20 am, Adam Roach wrote: >=20 > I found 4.3.2 particularly interesting, as there doesn't seem to have = been consensus in this space in the past. For example, the ws(s) and = ipp(s) schemes made a different decision. I presume your assertion is = that, were we defining these protocols today, they would be using = http(s) instead? AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so = as per section 2, it's not "using" HTTP. WS(S) uses port 80/443 to bootstrap into another protocol (using = Upgrade). There probably needs to be a carve-out for that. > I don't see anything wrong with that; I just want to probe the edges = of this advice by seeing how it would have applied to decisions we made = in the past, since that's a pretty good predictor for how it might apply = in the future. >=20 > The advice in 4.3.3 seems a bit strong, in that it will require = whatever process listens on port 443 to take on an ever-increasing role. = If we're going to keep this advice, I think the document needs some = treatment of the software architecture implications: functionally, = whatever listens to port 443 will need to be able to delegate sub-trees = of the URL space to other processes. I know that some web servers have = mechanisms to handle this kind of thing today; but we're effectively = saying that this will become required base functionality for web servers = moving forward. >=20 > I wonder, in that context, whether the current advice strikes the = right balance. I think that's a great conversation to have. Cheers, >=20 > /a >=20 > On 7/11/17 06:14, Mark Nottingham wrote: >> A number of folks have recently noted that BCP56 addresses the = problems of using HTTP for protocols in the early 2000's, but we've = moved on considerably since then. >>=20 >> Given the number of IETF protocols being build upon HTTP these days, = it seems timely to reconsider it. I've been working on a candidate for = replacing it for a little while; see: >> https://tools.ietf.org/html/draft-nottingham-bcp56bis >> https://mnot.github.io/I-D/bcp56bis/ >>=20 >> I have a small-ish slot in the HTTP WG session on Wednesday to = discuss this. >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jul 15 07:26:18 2017 Return-Path: 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 E20AE1318C4 for ; Sat, 15 Jul 2017 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jql_qm9yT-ed for ; Sat, 15 Jul 2017 07:26:14 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96641126CC7 for ; Sat, 15 Jul 2017 07:26:14 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id r30so80638559qtc.0 for ; Sat, 15 Jul 2017 07:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BAJm5dmEGnRWCm7cs3kW8UVLLvGg7/XwXBeLDTucAxg=; b=fHUUXPZgewLbrPhRXuP4vTgC3JMbGqxtKUzOT0YoirA9RDi30Y0TFJpF6QRNMTc6Wz FSqYMd2hk/tIBVuZb7GQTlPa449GbZcCQstZoNCJrar7fpdeG04OIwAIfYlUlmS2kGzF VS8EvHyDUPt7/bDfNeuJ7ikCxOxB5Odc4GWny0EzDXEbN2T73YMEJ5gve6f1AExVuBNn sdxA5hARiR+jAz3zIcMA3Q3/Pa8hgPA+STN7KODEHyLx7mti7H15ZHKJ2KgKh2cJD7xK vNb11YK3N+ca++oEfDQlVOQUQHzwbetvYcjpv8uUWnI1K6NHoOyfhKvJ9hfqbDNzLwNz LkUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BAJm5dmEGnRWCm7cs3kW8UVLLvGg7/XwXBeLDTucAxg=; b=faON0hM2OjZQnfMJQXqmIz9G+psN/TQTjux3mLVC7PxxEYkdRxW9Z04FSh9oyy08zX 7yUpnYIGDHMynnnerLq213dg2Uc4caTBo7SaRXiw67F3QoDBWLnn3fcJQ+f8e/9/F7FQ lmQx+qRu8wZFOd0sZ4TqcwG+zkPpv12rleBV9o0+SgkAdUh9Zr4dxlKOUA+GQ8caMdQ8 6q2ahfxnGFDOD3HIzpmc61nS+NjhobFcqkOAwZ2NI4tCIfgkygzdnaerUkf0iUzfR5E0 munXXCHqAXscl0nriR30jjCXaecozxppfKxqOLio+SBrRAz7tWCuTJYzNA70R5EpNlAB KpQg== X-Gm-Message-State: AIVw110X2McPGm0yyw1kTj0SgW3Wv6QsJbrwiCsh4/sNLTDMDd7YhU8f xxFuBJgFYWrYvOpnYxTGrXy+uZnkSyO3 X-Received: by 10.200.32.146 with SMTP id 18mr18814881qtd.146.1500128773546; Sat, 15 Jul 2017 07:26:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.21 with HTTP; Sat, 15 Jul 2017 07:25:43 -0700 (PDT) In-Reply-To: References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> From: Ted Hardie Date: Sat, 15 Jul 2017 16:25:43 +0200 Message-ID: To: Mark Nottingham Cc: Adam Roach , Alexey Melnikov , art@ietf.org, Patrick McManus Content-Type: multipart/alternative; boundary="f403045ee6a6aa275905545bf2b4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 14:26:17 -0000 --f403045ee6a6aa275905545bf2b4 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham wrote: > > > On 15 Jul 2017, at 11:20 am, Adam Roach wrote: > > > > I found 4.3.2 particularly interesting, as there doesn't seem to have > been consensus in this space in the past. For example, the ws(s) and ipp(s) > schemes made a different decision. I presume your assertion is that, were > we defining these protocols today, they would be using http(s) instead? > > AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as > per section 2, it's not "using" HTTP. > > RFC 7472 describes the HTTPS tranport binding and its relationship to the ipps scheme (it's a successor to some previous work doing similar things for HTTP). It notes: The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230 ] (replacing 'ipps' with 'https' and inserting the port number from the URI or port 631 if the URI doesn't include an explicit port number); While the default isn't the existing HTTPS port, it's my understanding that in some deployments the ipps scheme uses the HTTPS port and so ends up with an HTTPS scheme message over the standard HTTPS port. regards, Ted > WS(S) uses port 80/443 to bootstrap into another protocol (using Upgrade). > There probably needs to be a carve-out for that. > > > I don't see anything wrong with that; I just want to probe the edges of > this advice by seeing how it would have applied to decisions we made in the > past, since that's a pretty good predictor for how it might apply in the > future. > > > > The advice in 4.3.3 seems a bit strong, in that it will require whatever > process listens on port 443 to take on an ever-increasing role. If we're > going to keep this advice, I think the document needs some treatment of the > software architecture implications: functionally, whatever listens to port > 443 will need to be able to delegate sub-trees of the URL space to other > processes. I know that some web servers have mechanisms to handle this kind > of thing today; but we're effectively saying that this will become required > base functionality for web servers moving forward. > > > > I wonder, in that context, whether the current advice strikes the right > balance. > > I think that's a great conversation to have. > > Cheers, > > > > > /a > > > > On 7/11/17 06:14, Mark Nottingham wrote: > >> A number of folks have recently noted that BCP56 addresses the problems > of using HTTP for protocols in the early 2000's, but we've moved on > considerably since then. > >> > >> Given the number of IETF protocols being build upon HTTP these days, it > seems timely to reconsider it. I've been working on a candidate for > replacing it for a little while; see: > >> https://tools.ietf.org/html/draft-nottingham-bcp56bis > >> https://mnot.github.io/I-D/bcp56bis/ > >> > >> I have a small-ish slot in the HTTP WG session on Wednesday to discuss > this. > >> > >> Cheers, > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> > >> _______________________________________________ > >> art mailing list > >> art@ietf.org > >> https://www.ietf.org/mailman/listinfo/art > > > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > -- > Mark Nottingham https://www.mnot.net/ > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --f403045ee6a6aa275905545bf2b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham <mnot@mnot.n= et> wrote:

> On 15 Jul 2017, at 11:20 am, Adam Roach <adam@nostrum.com> wrote:
>
> I found 4.3.2 particularly interesting, as there doesn't seem to h= ave been consensus in this space in the past. For example, the ws(s) and ip= p(s) schemes made a different decision. I presume your assertion is that, w= ere we defining these protocols today, they would be using http(s) instead?=

AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's regi= stries, so as per section 2, it's not "using" HTTP.


RFC 7472 describes the=C2=A0 HTTPS tra= nport binding and its relationship to the ipps scheme (it's a successor= to some previous work doing similar things for HTTP).=C2=A0 It notes:
<= br>
The IPP Client converts the 'ipps' =
URI to an 'https' URI [RFC7230]
      (replacing 'ipps' with 'https' and inserting the port=
 number from
      the URI or port 631 if the URI doesn't include an explicit port
      number);
While the default isn't the existing HTTPS port, it's my unde= rstanding that in some deployments the ipps scheme uses the HTTPS port and = so ends up with an HTTPS scheme message over the standard HTTPS port.

regards,

Ted
=C2=A0=
WS(S) uses port 80/443 to bootstrap into another protocol (using Upgrade). = There probably needs to be a carve-out for that.

> I don't see anything wrong with that; I just want to probe the edg= es of this advice by seeing how it would have applied to decisions we made = in the past, since that's a pretty good predictor for how it might appl= y in the future.
>
> The advice in 4.3.3 seems a bit strong, in that it will require whatev= er process listens on port 443 to take on an ever-increasing role. If we= 9;re going to keep this advice, I think the document needs some treatment o= f the software architecture implications: functionally, whatever listens to= port 443 will need to be able to delegate sub-trees of the URL space to ot= her processes. I know that some web servers have mechanisms to handle this = kind of thing today; but we're effectively saying that this will become= required base functionality for web servers moving forward.
>
> I wonder, in that context, whether the current advice strikes the righ= t balance.

I think that's a great conversation to have.

Cheers,

>
> /a
>
> On 7/11/17 06:14, Mark Nottingham wrote:
>> A number of folks have recently noted that BCP56 addresses the pro= blems of using HTTP for protocols in the early 2000's, but we've mo= ved on considerably since then.
>>
>> Given the number of IETF protocols being build upon HTTP these day= s, it seems timely to reconsider it. I've been working on a candidate f= or replacing it for a little while; see:
>>=C2=A0 =C2=A0https://tools.ietf.org/htm= l/draft-nottingham-bcp56bis
>>=C2=A0 =C2=A0https://mnot.github.io/I-D/bcp56bis/=
>>
>> I have a small-ish slot in the HTTP WG session on Wednesday to dis= cuss this.
>>
>> Cheers,
>>
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>
>> _______________________________________________
>> art mailing list
>> art@ietf.org
>> https://www.ietf.org/mailman/listinfo/art=
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/


_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

--f403045ee6a6aa275905545bf2b4-- From nobody Sat Jul 15 07:55:31 2017 Return-Path: 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 72E2D13169C for ; Sat, 15 Jul 2017 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9zkHbhx6SwH3 for ; Sat, 15 Jul 2017 07:55:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D10128A32 for ; Sat, 15 Jul 2017 07:55:27 -0700 (PDT) Received: from dhcp-8909.meeting.ietf.org (dhcp-8909.meeting.ietf.org [31.133.137.9]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6FEtLra029447 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 15 Jul 2017 09:55:22 -0500 (CDT) (envelope-from adam@nostrum.com) To: Ted Hardie , Mark Nottingham Cc: Alexey Melnikov , art@ietf.org, Patrick McManus References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> From: Adam Roach Message-ID: <989a76b8-7006-5c9b-66cb-0a03f8e9e517@nostrum.com> Date: Sat, 15 Jul 2017 16:55:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A6C44C032D67EC25E0D37F3B" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 14:55:29 -0000 This is a multi-part message in MIME format. --------------A6C44C032D67EC25E0D37F3B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/15/17 16:25, Ted Hardie wrote: > On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham > wrote: > > > > On 15 Jul 2017, at 11:20 am, Adam Roach > wrote: > > > > I found 4.3.2 particularly interesting, as there doesn't seem to > have been consensus in this space in the past. For example, the > ws(s) and ipp(s) schemes made a different decision. I presume your > assertion is that, were we defining these protocols today, they > would be using http(s) instead? > > AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's > registries, so as per section 2, it's not "using" HTTP. > > > RFC 7472 describes the HTTPS tranport binding and its relationship to > the ipps scheme (it's a successor to some previous work doing similar > things for HTTP). It notes: > > The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230 ] > (replacing 'ipps' with 'https' and inserting the port number from > the URI or port 631 if the URI doesn't include an explicit port > number); > While the default isn't the existing HTTPS port, it's my understanding > that in some deployments the ipps scheme uses the HTTPS port and so > ends up with an HTTPS scheme message over the standard HTTPS port. You don't have to rely on the ipps spec for this -- the original design of IPP has a similar transformation for ipp URLs; RFC2910 stipulates: Because the HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP headers. The mapping is simple because the 'ipp' scheme implies all of the same protocol semantics as that of the 'http' scheme [RFC2616], except that it represents a print service and the implicit (default) port number that clients use to connect to a server is port 631. Mark -- if you think the guidance in your document wouldn't apply in these cases, you'll have to be clearer by what you mean when you say 'The URL scheme "http" or "https" is used': I would have thought this qualifies. /a --------------A6C44C032D67EC25E0D37F3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/15/17 16:25, Ted Hardie wrote:
On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 15 Jul 2017, at 11:20 am, Adam Roach <adam@nostrum.com> wrote:
>
> I found 4.3.2 particularly interesting, as there doesn't seem to have been consensus in this space in the past. For example, the ws(s) and ipp(s) schemes made a different decision. I presume your assertion is that, were we defining these protocols today, they would be using http(s) instead?

AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as per section 2, it's not "using" HTTP.


RFC 7472 describes the  HTTPS tranport binding and its relationship to the ipps scheme (it's a successor to some previous work doing similar things for HTTP).  It notes:

The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230]
      (replacing 'ipps' with 'https' and inserting the port number from
      the URI or port 631 if the URI doesn't include an explicit port
      number);
While the default isn't the existing HTTPS port, it's my understanding that in some deployments the ipps scheme uses the HTTPS port and so ends up with an HTTPS scheme message over the standard HTTPS port.

You don't have to rely on the ipps spec for this -- the original design of IPP has a similar transformation for ipp URLs; RFC2910 stipulates:

   Because the HTTP layer does not support the 'ipp' scheme, a client
   MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP
   [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP
   headers.  The mapping is simple because the 'ipp' scheme implies all
   of the same protocol semantics as that of the 'http' scheme
   [RFC2616], except that it represents a print service and the implicit
   (default) port number that clients use to connect to a server is port
   631.

Mark -- if you think the guidance in your document wouldn't apply in these cases, you'll have to be clearer by what you mean when you say 'The URL scheme "http" or "https" is used': I would have thought this qualifies.


/a
--------------A6C44C032D67EC25E0D37F3B-- From nobody Sat Jul 15 08:17:42 2017 Return-Path: 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 378E112711E for ; Sat, 15 Jul 2017 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 JURpQlOdqYMq for ; Sat, 15 Jul 2017 08:17:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E4F124E15 for ; Sat, 15 Jul 2017 08:17:38 -0700 (PDT) Received: from dhcp-8909.meeting.ietf.org (dhcp-8909.meeting.ietf.org [31.133.137.9]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6FFHXNt032921 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 15 Jul 2017 10:17:35 -0500 (CDT) (envelope-from adam@nostrum.com) To: Mark Nottingham , art@ietf.org Cc: Patrick McManus , Alexey Melnikov References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> From: Adam Roach Message-ID: Date: Sat, 15 Jul 2017 17:17:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> Content-Type: multipart/alternative; boundary="------------88B147056FC954FD50FAA164" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 15:17:40 -0000 This is a multi-part message in MIME format. --------------88B147056FC954FD50FAA164 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In reading over the current draft a bit more, another specific piece of advice stuck out as interesting: Another common practice is assuming that the HTTP server's name space (or a portion thereof) is exclusively for the use of a single application. This effectively overlays special, application-specific semantics onto that space, precludes other applications from using it. It's the "or portion thereof" that sticks out at me. I'll note that this *is* consistent with the guidance in RFC7320 section 2.3, but that document didn't cross my radar at the time either. In a similar vein as my questions before -- if this guidance were in effect at the time that RFC 4825 (XCAP) were under development, are we sure that it would have been appropriate? Semantically, the extension of URL paths down into XML documents seems both clean and appropriate; however, it is most certainly overlaying "special, application-specific semantics" onto the path component. So, if we were doing XCAP today from scratch, what *would* be the preferred mechanism for addressing an element? /a On 7/11/17 06:14, Mark Nottingham wrote: > A number of folks have recently noted that BCP56 addresses the problems of using HTTP for protocols in the early 2000's, but we've moved on considerably since then. > > Given the number of IETF protocols being build upon HTTP these days, it seems timely to reconsider it. I've been working on a candidate for replacing it for a little while; see: > https://tools.ietf.org/html/draft-nottingham-bcp56bis > https://mnot.github.io/I-D/bcp56bis/ > > I have a small-ish slot in the HTTP WG session on Wednesday to discuss this. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art --------------88B147056FC954FD50FAA164 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
In reading over the current draft a bit more, another specific piece of advice stuck out as interesting:

   Another common practice is assuming that the HTTP server's name space
   (or a portion thereof) is exclusively for the use of a single
   application.  This effectively overlays special, application-specific
   semantics onto that space, precludes other applications from using
   it.

It's the "or portion thereof" that sticks out at me. I'll note that this *is* consistent with the guidance in RFC7320 section 2.3, but that document didn't cross my radar at the time either.

In a similar vein as my questions before -- if this guidance were in effect at the time that RFC 4825 (XCAP) were under development, are we sure that it would have been appropriate? Semantically, the extension of URL paths down into XML documents seems both clean and appropriate; however, it is most certainly overlaying "special, application-specific semantics" onto the path component.

So, if we were doing XCAP today from scratch, what *would* be the preferred mechanism for addressing an element?

/a


On 7/11/17 06:14, Mark Nottingham wrote:
A number of folks have recently noted that BCP56 addresses the problems of using HTTP for protocols in the early 2000's, but we've moved on considerably since then. 

Given the number of IETF protocols being build upon HTTP these days, it seems timely to reconsider it. I've been working on a candidate for replacing it for a little while; see:
  https://tools.ietf.org/html/draft-nottingham-bcp56bis
  https://mnot.github.io/I-D/bcp56bis/

I have a small-ish slot in the HTTP WG session on Wednesday to discuss this. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--------------88B147056FC954FD50FAA164-- From nobody Sat Jul 15 08:22:28 2017 Return-Path: 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 F310D124E15 for ; Sat, 15 Jul 2017 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jYfl-wGjg183 for ; Sat, 15 Jul 2017 08:22:24 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B481316A1 for ; Sat, 15 Jul 2017 08:22:24 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p73so31630672qka.2 for ; Sat, 15 Jul 2017 08:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bhKoMvNqfMCKkVQcUuJMF/WbeiRnlnrsZ3/e1MjOysM=; b=hLvCvNlIhqjaCzTxNC9rLOQ7IPSWLNXgNx48aH9iaTja/2h37e0W0MKAfS01mZQH0D uDFGHDkohZoX2TSNCQbqvOA35i0vFlsAEMLuGgmso3MQrZ6oP1+HI0QSMy+2a2O+8nNU PZzTu7urCp2AN/9wFvEQ0nJbd3tad8wrA8XaHLOeexJRxGNStijNPPWzPhREms4c2Mgv Cd0BOBsuSVw0fS6zvz8iHRfZlDHn6Y+z4UGpiu9jeGKI2ULItXguJBg7bw+KkxoSxpmQ xP/3iB+rZOvsvbrvTiia59huL8QZSHWIrs90lnucJaCEGQ0PdXnq1hN6rvEHDJypjRik tSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bhKoMvNqfMCKkVQcUuJMF/WbeiRnlnrsZ3/e1MjOysM=; b=o131URSqG7AfdpUGoPrf/JpRqge0ySIQzsq6BdAGkaco0S3X6Lr19q7HG+39D6SZA3 7SiWhCnputso95WILIs44T7bJHF5JBn/WesWeUZNDSs8SLJ/t0HEGTP1CuUWMTLc+UnX KOwViHas3LrXLFdX6/1CySpiM9D68OQ4rGbglYuJqshnj6qj7upVA/0UgZOiSs436kT1 lllG+nXhnb80Qd5Q6tjUqH/RlJq2sc/NnBTlnOiQphuqu9LWEgAiKobBJM/IFPdbiP2Q AxEFTjFLhi4HPAn5t7BH8VhO44kNIICDfcD9Dw60qJrEC1qwemRmkL9CJP09xi3ezcRp g43Q== X-Gm-Message-State: AIVw112fjAKrMSizy6m+7A+dodTXBhrVq2VR4HQyJnLWbhG0tTBD9cgW suZ3j9BdBUp2NosJ3PL7jZvXFyPpDQ== X-Received: by 10.55.103.23 with SMTP id b23mr15808942qkc.55.1500132143760; Sat, 15 Jul 2017 08:22:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.43.101 with HTTP; Sat, 15 Jul 2017 08:22:03 -0700 (PDT) In-Reply-To: <989a76b8-7006-5c9b-66cb-0a03f8e9e517@nostrum.com> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <989a76b8-7006-5c9b-66cb-0a03f8e9e517@nostrum.com> From: Ira McDonald Date: Sat, 15 Jul 2017 11:22:03 -0400 Message-ID: To: Adam Roach , Ira McDonald Cc: Ted Hardie , Mark Nottingham , Alexey Melnikov , Patrick McManus , art@ietf.org Content-Type: multipart/alternative; boundary="94eb2c059c708b8be105545cbba2" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 15:22:27 -0000 --94eb2c059c708b8be105545cbba2 Content-Type: text/plain; charset="UTF-8" Hi, Speaking as the co-editor of both the "ipp" and "ipps" URI schemes and the successor (RFC 8010) to RFC 2910, using HTTP as a substrate for IPP was a serious design mistake that has added numerous implementation errors and no functional value. One prominent (non-conforming) implementation of IPP does use port 443, but that's just plain wrong and fails the IEEE-ISTO PWG IPP Everywhere conformance certification tests. Please don't use IPP as justification in this discussion. The use of HTTP as a substrate was based on bad advice from IETF regulars who should have known better. [ok - back into my cave...] Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Sat, Jul 15, 2017 at 10:55 AM, Adam Roach wrote: > On 7/15/17 16:25, Ted Hardie wrote: > > On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham wrote: > >> >> > On 15 Jul 2017, at 11:20 am, Adam Roach wrote: >> > >> > I found 4.3.2 particularly interesting, as there doesn't seem to have >> been consensus in this space in the past. For example, the ws(s) and ipp(s) >> schemes made a different decision. I presume your assertion is that, were >> we defining these protocols today, they would be using http(s) instead? >> >> AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as >> per section 2, it's not "using" HTTP. >> >> > RFC 7472 describes the HTTPS tranport binding and its relationship to the > ipps scheme (it's a successor to some previous work doing similar things > for HTTP). It notes: > > The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230 ] > (replacing 'ipps' with 'https' and inserting the port number from > the URI or port 631 if the URI doesn't include an explicit port > number); > > While the default isn't the existing HTTPS port, it's my understanding > that in some deployments the ipps scheme uses the HTTPS port and so ends up > with an HTTPS scheme message over the standard HTTPS port. > > > You don't have to rely on the ipps spec for this -- the original design of > IPP has a similar transformation for ipp URLs; RFC2910 stipulates: > > Because the HTTP layer does not support the 'ipp' scheme, a client > MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP > [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP > headers. The mapping is simple because the 'ipp' scheme implies all > of the same protocol semantics as that of the 'http' scheme > [RFC2616], except that it represents a print service and the implicit > (default) port number that clients use to connect to a server is port > 631. > > Mark -- if you think the guidance in your document wouldn't apply in these > cases, you'll have to be clearer by what you mean when you say 'The URL > scheme "http" or "https" is used': I would have thought this qualifies. > > > /a > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > > --94eb2c059c708b8be105545cbba2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Speaking as the co-editor of both the "ipp&quo= t; and "ipps" URI schemes and the
successor (RFC 8010) t= o RFC 2910, using HTTP as a substrate for IPP was
a serious design= mistake that has added numerous implementation errors and
no functiona= l value.

One prominent (non-conforming) implementation o= f IPP does use port 443,
but that's just plain wrong and fails= the IEEE-ISTO PWG IPP Everywhere
conformance certification tests.=

Please don't use IPP as justification in this discussion.= =C2=A0 The use of HTTP as
a substrate was based on bad advice from= IETF regulars who should have
known better.

[ok - ba= ck into my cave...]

Cheers,
- Ira


I= ra McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobil= ity Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary = - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Prin= ting Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue = Roof Music / High North Inc
http://sites.go= ogle.com/site/blueroofmusic
http://sit= es.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: = 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
May-Dec: = PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Sat, Jul 15, 2017 at 10:55 AM, Adam Roach= <adam@nostrum.com> wrote:
=20 =20 =20
On 7/15/17 16:25, = Ted Hardie wrote:
On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham <mnot@= mnot.net> wrote:

> On 15 Jul 2017, at 11:20 am, Adam Roach <adam@nostrum.com> wrote:
>
> I found 4.3.2 particularly interesting, as there doesn't seem to have been consensus in this space in th= e past. For example, the ws(s) and ipp(s) schemes made a different decision. I presume your assertion is that, were we defining these protocols today, they would be using http(s) instead?

AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as per section 2, it's not &quo= t;using" HTTP.


RFC 7472 describes the=C2=A0 HTTPS tranport binding and it= s relationship to the ipps scheme (it's a successor to some previous work doing similar things for HTTP).=C2=A0 It notes:= 

The IPP Cl=
ient converts the 'ipps' URI to an 'https' URI [RFC723=
0]
      (replacing 'ipps' with 'https' and inserting the port=
 number from
      the URI or port 631 if the URI doesn't include an explicit port
      number);
While the default isn't the existing HTTPS port, it's= my understanding that in some deployments the ipps scheme uses the HTTPS port and so ends up with an HTTPS scheme message over the standard HTTPS port.

 You don't have to rely on the ipps spec for this -- the original design of IPP has a similar transformation for ipp URLs; RFC2910 stipulates:

=C2=A0=C2=A0 Because the HTTP layer does not support the 'ipp' = scheme, a client
=C2=A0=C2=A0 MUST map 'ipp' URLs to 'http' URLs, and th= en follows the HTTP
=C2=A0=C2=A0 [RFC2616][RFC2617] rules for constructing a Request-Line a= nd HTTP
=C2=A0=C2=A0 headers.=C2=A0 The mapping is simple because the 'ipp&= #39; scheme implies all
=C2=A0=C2=A0 of the same protocol semantics as that of the 'http= 9; scheme
=C2=A0=C2=A0 [RFC2616], except that it represents a print service and t= he implicit
=C2=A0=C2=A0 (default) port number that clients use to connect to a ser= ver is port
=C2=A0=C2=A0 631.

Mark -- if you think the guidance in your document wouldn't apply i= n these cases, you'll have to be clearer by what you mean when you sa= y 'The URL scheme "http" or "https" is used':= I would have thought this qualifies.


/a

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--94eb2c059c708b8be105545cbba2-- From nobody Sat Jul 15 22:42:20 2017 Return-Path: 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 9160B1289C3 for ; Sat, 15 Jul 2017 22:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=itaoyama.onmicrosoft.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 UVSTgQ0hM-3R for ; Sat, 15 Jul 2017 22:42:13 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0118.outbound.protection.outlook.com [104.47.93.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A9E120726 for ; Sat, 15 Jul 2017 22:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6UW7FHBFvz672fYExyxDUiHWirHSiWw3gYg1TZmf1pQ=; b=r4bGrBT2AL2xC+85ifGQF75EmQaMkTGbfh8PWL8H5lc+V7mKzNoSZAtjVubzMmM+jy32NDrwLsyTJl35JZk2djln+yZ5fK+bKZfeN4CPoMuRlks/dpKbSwWZf6JU+HudiVYqpGYeNW/6NW2zVD/Cff+sRUX2fb/UGC5b9MgupZA= Authentication-Results: ducksong.com; dkim=none (message not signed) header.d=none;ducksong.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0244.jpnprd01.prod.outlook.com (10.161.28.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Sun, 16 Jul 2017 05:42:09 +0000 To: Ira McDonald , Adam Roach CC: Alexey Melnikov , Ted Hardie , Mark Nottingham , , Patrick McManus References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <989a76b8-7006-5c9b-66cb-0a03f8e9e517@nostrum.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Sun, 16 Jul 2017 14:42:01 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0065.jpnprd01.prod.outlook.com (10.167.153.153) To KAWPR01MB0244.jpnprd01.prod.outlook.com (10.161.28.143) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6527146b-bdfe-4bb1-423a-08d4cc0d66f7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:KAWPR01MB0244; X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0244; 3:RBl51wNQw0LtxXfPuB3Kd0NjzyaJPBY8ahkslFTPoxvVZDXaevdqFzyb3UPSyusFUNE9vinWWGblKOhUNanM5gbN9jxHS06+xHaWxg58pU1MgFTYtJHELpj2wgNxaJXfrkPXzqnAXpkyppNgUkQaG9iF2xKVihPz2O9XAKsspXVM/bSSV718nHBCK6ODrj5kAQoMiVDaEjaBMqAmFXsVP/XuQpI7wIoFfPWQVg5RtGtXY9zs4x9jEkjkNFu1gtxJ/1pNm/VKuRDFV6fE9RLHMfzqHeZO2txZoi39hBe/Ww81XKg3er5hpIteuLMOEwMvXOLyKsbaFcfgVArQmrhRfezr6+bneA0hQHZ1x25cPBPN5JJ9UpFGjNIiayIVX2yeYXlO+LoTrlWmEsEzKQ09bJoB2wGcv+IeM8M+9NlDOZBKCGo4EvOaVbY0RX/QjvgiLspmZF5RTaj6XllkYjA1zhptu8aWyRcC/rIQ35CzzapqD3m5OMrK9rxF9Ut7P3UmrxW7NYi+y/rvyQykfjBkANhWh/8deBL20nflh/i2P/cQ9g6JfxpWBYAE8M6xOeAHx93KCtKYSSOCbrYZhLSt4xwus+14N3vufkqyKgo8xzoyrN7NeInZMBzz0+41wfagWX3dspQStSYqY3rx0SmVBVe2TU2IW+4DMXWFv6ks74fKESJdk0Us+xBwHg4XGGe4KlI3MYfpJe9h94Neb433px2jhivqvaCZSZ6Jo29IpXg= X-MS-TrafficTypeDiagnostic: KAWPR01MB0244: X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0244; 25:kDE+/7bYjjm01AAunJWOE4dqrKXR7c9RsmDJZVp3tXn7ObcWKYq6d6BG0FBWOzfXbLaVDsThEoIRZRQcawQ56Cv44MFFdTkvYOfE4S7oDMNraV/qM2pwikFriodby1aC7+naQz5mE/NSU6ZrYNauSoq0LYe4TNsQ4zQAg78QzTCPpWoVQcARWvwIHv3TCJdjFliQFDrBz2z4eSpTtMVj2ZUj4N1yceCjax/2TTHuVgSZukrPzAC1r88hXw0Qdn9202Ey1umq8m4P3Bp8V4u/XWflc+yJv8cGoPvVg8CkSAqTf8+hxz6+/EHXatwfd9cXy9X/rwRb+VDyYNnUytve6EcwGmgt3gj+3NAh0MUj7yjujPefz1ZF+HRIeUKybdewsok49I8tr/xsPcVUH+A9kYHI7Om+t1odcCxd18QkNFN+m5YNM+fPcxHEW11I+kgSOS7oIgeC+eW0pg2b16GXzS3Lq8bkAtJrG7SQ3PgF8Lyq6i2VAywWgwVYm99u6PHRe8KujnEswCIO4r/GaIMcHLAvSyEUZoNkqIbDx4Y6o+cDPi5LNPvBTM/NLBCJwtWH5q7wiNqQtoSyh21nviPIqF/Z1/rWYFpHxy2FQk8OUX0QPX6RAHhyMyaeD6Nd7nN/s7w2jx9ILGuvJlxL3J/q1O/ykfQ+N9gzmvcO5k3lbDU8SWA487wFRHrICBMajqBOv5YCc8/28m/tovkl5HZHMm7lvb4CkcymP1jIFxZX0d4x1+iGszYfe/Inm5k0s7BqJR9mHDohr8jR/jgEsY8t9jEW6nrIfZEthXUKdcSv+zVbbp4XDPfKUXPXdCfyfcXpcfBci7I7HKVEEypsGilPakXFVzmP34s3Y7x3t9xFqTLPIbFePsieVnWRsW8at/XsIMVhABtxAbhcvFH4HK+vg/eo31rtpcj3eufE/737Sk8= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0244; 31:1TDXBKCzP19EMG8UVhuo7terswORqu4zIKuaP6vZf+IdyedKXaaI5itfx+4qs77sIWsYxFbWoTQi0qAPvtebA2yZWzqRCQMD6/nXWlLa+S442EAS9ZWkdraMJqT6XjYKP+2bIRDEmVGU8rwAwzWJ+EmcHZpc4IrkTF8g/86KVkVPb8RFlLLcWPU3jB3DdvxMRhUt4AUs9cbmzm3T9mc3aS09RapACMswRrrG2eFkqTFhKF/s66UdMDYfz0KguIrlnLzgB6YQzALTgV/oDS8orGMOgXZnzU0nhCwf4Wm3ZnW6/ZoAZeJKdQM9a2h73xAvJqRBiKK+Qcua0a8oS1uFE5wxx6eoIoacxGAs+zzyDIfOVapVtG52VsGqXtBLVgmwiiK389MVKS1jn8tz49rV5Wllt9vk+FkLZlVvG3Nz25wywScR4W6XAsgb5GKK+P9AuFKkzyymoRor6PH2I+WfSVKlr1R2vjCPAfx6GLjjwbISdEfFwEVTfmjqpWlECqv6GBa/olqM6XwoCChxcHDF6xZP8T0UUMbsukWKmWy2FeMllz6rqNRooiDOQ0AfB8IiFeBof6wLsB26P8AqZylPhmm3Ujc2AoQtFTDaw6I7HaJCx8h4RdRdCPQA7kR46F+dCpxi4J4NacXcffT6LQOfsPoXxnvM4CRsOzlL+ynITrSGdM2sDvnleO7gj7o3U5iXFqBqxdtUayUGyL9GZGEKew== X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:KAWPR01MB0244; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:KAWPR01MB0244; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMjQ0OzQ6TmUwV2YxeHRZUTMveDVDZFM3U3h0RXFYMmw2?= =?utf-8?B?OEN6QnZabE51WGZJMTBtTHZWWkZISGkwQmQwTk1mWS9EbFZnVDZaQmR3MHVr?= =?utf-8?B?OG9DYW5WcWk2MXpYUkZxWCtmNFpweFQzczVLamNhVTVsQXcxSTZET3d5VGlh?= =?utf-8?B?MUVhTWNqQXNUYUlTRXNKa0hGOEcrVDdoWkh2Q2ZTdDRoL3RFZUtDWWt1VURl?= =?utf-8?B?VTFqSkRDMjlOd1NYbkpVZkJpcW1NQ1ZuSnlpUTdqUmNyclQrdkQ2SEJBazB4?= =?utf-8?B?cGdPdFd1ZFVqcktLMnd4eDdUZXhKS09tSHQxUm1YZ2g5MDVMMEFJTkh1c2M5?= =?utf-8?B?d1B2S2tQQ25HQ3F2TWlMZ1pydEJ0NnJMM043QVJGaHNyTjFjb1AwVmNNdkJQ?= =?utf-8?B?c1cza0xnRkZ1YUppeXIzTXoxb2xrSjFkdHU3WngwaVExcUxFVDJjdDM2MXVq?= =?utf-8?B?L0QwL1BkMDJ1a01Rc05sRkV2UFBGQm1ZdnhGRXdZVUdBaW5GWUNSbTVwdkZn?= =?utf-8?B?QjNHWXlmZ24ydmZCbFpxNElaT3RXVm5tYWFiZCtUMDdtOU0yeXQzYTBPZXBK?= =?utf-8?B?cVMyRXNyS21HU0c2WFYxcS9uOEF3YTk5b0dkaCtteUdUUWw2Rll0RnNxR1NO?= =?utf-8?B?b2FCWTFoK0FBZjFSblJ4Ym05QnE0YVlCT2pXcTNiekRkYmVIYU9sbnpwdCta?= =?utf-8?B?ZnFnNkRtaWlFR2tuNUt5Tm5id2dtclVwZFF6ZklVUWdFaFh1Q2U4bHdSZEFC?= =?utf-8?B?QzRkM0JVV0ovK3pjQ0Q3Z1UvRVhocUZkdGZBN291eCtraGNFUjFIdjljeERw?= =?utf-8?B?dUo1ZXJJT0s3d0J5aC9HL1NtMDRueFVQcmV6bHNUYnlNT0hORHAxd3d1NG5K?= =?utf-8?B?N0N1UTA1dGNzOVpLenN4aGxJSm54cUtsanZtK1BlVDl1L0tWQ3pmcGVpQXJZ?= =?utf-8?B?SXdjaExuOHpBc0REWHJNNWRZaVpNTXBScDRBMnZQcURiM2g2WkVWY3ZPTG1C?= =?utf-8?B?SjgrbzhhK013cFlqZGwrRHllRFZlU00yazAyYlY5S05oNkQzZVZnd3QwNHN5?= =?utf-8?B?K3NreDBPc040bVFCRmVOUERnL0hWNFNUQ1pDazZpYS8waGYxM21zaGw4NFBQ?= =?utf-8?B?eEIxWkpPNHVUWHVkeGIrVXVHbHRaRUpiaDZ4Qlh5YTlaUXBGaDdoYlRkOTRl?= =?utf-8?B?U216cDRqSU9vdVBRTUJwaHpvZkR4UUJNdDBad0Vhd2Y5UTNjMTNMb0prdEV2?= =?utf-8?B?a01NU0FPSDVsVENpU2JML0VPOWIzTVZFeFhiUWlMTEZPNFRMdFpPbXI5OCtr?= =?utf-8?B?R1NoMzZCMTUrWDJjYjJsWGwxNVhRM1ZSclhJNHI4cGtMd1JrV2pzR3FsNmZN?= =?utf-8?B?OGVYVzJuMWFZMHQzUGFTSU93dEtkeWl0ZUErQk1xdmUrOEk2SllLaGhrYmpW?= =?utf-8?B?ek5CZEFjQWpUKzJJU2M0RE91YTNERFM4cEJUQWpBNWQzRDM4a0hFVE9TNjFy?= =?utf-8?B?Ylh6QnFqaFAwU0NUaEVDRnRTK2ZuMTJUcXVFcWR2WC9oS3hhc2gyUjJ3R0ZI?= =?utf-8?B?dlQ3TTdaaUlWRHAydCsyZ3V2clZZKzFzWnlGQlc2U3ZOL25LaHVsY2Y2N0J5?= =?utf-8?B?Y2lsZTUrcHpmeWJJSFRObE54MGxJMm5IQm1UUkFkTUF4VEJJTjRJa3pDai9x?= =?utf-8?Q?yTglMRNa5ZODc2qb8JD6LiZTZoOMqdC7qLz0ef?= X-Forefront-PRVS: 03706074BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(979002)(6009001)(6049001)(39400400002)(39410400002)(39830400002)(39450400003)(24454002)(42186005)(4001350100001)(31686004)(81166006)(33646002)(2950100002)(42882006)(229853002)(25786009)(53546010)(6666003)(23676002)(74482002)(4326008)(2906002)(53936002)(6246003)(38730400002)(478600001)(49976008)(47776003)(305945005)(7736002)(54906002)(65806001)(66066001)(65956001)(189998001)(8676002)(54356999)(50986999)(93886004)(76176999)(90366009)(5660300001)(230700001)(6116002)(3846002)(86362001)(31696002)(64126003)(83506001)(50466002)(65826007)(6486002)(7350300001)(3940600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0244; H:[133.2.210.64]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMjQ0OzIzOllsUFVobDhrNm5UODN2WWxaN09LSjhNYlZj?= =?utf-8?B?a3dzclJteGIzL3JZTW9Cd3ZZa0IyY0VrNzljaVUraUdJR1NRTkZEZXpqZkRx?= =?utf-8?B?TFJZMldoL00yQkF4Z2thWDh2M0FJNHNjaXJYN3NsckdsV0gvWDFiZytjcEJL?= =?utf-8?B?TjZsQWthYjVyUjVHL0U2eHEwMlRnUW9rcUlmaE9RZlpRWGhiTXBQRkVWUjhk?= =?utf-8?B?NW95d2pmSFVkbmRJZ3NvN2RBNEZpdzNjMGdkVkloNkplNDhYRmMzR0pNeXE0?= =?utf-8?B?Z1dQQ1ZESjF1eDkzOVpLSGVRZGk4WVg1aWlLMDhlRTdVSmRVVGkyWldkdHdi?= =?utf-8?B?MnYraTQ4SEE2b1RUdTRZWklycVQ3c29TTVpISXZ1K1pndkV0UVhzWU02eWRS?= =?utf-8?B?TW8xOVdMT0U4aG53eU5PRlpzOStOWlNKUHYwUVZoSTZ5R3lSSG13aEFHb1NC?= =?utf-8?B?K2NGV254c0MwZVZocXBvY1l2M1hiZWcreWFJaFhIdzdyZmlFZWJFM0wrdHBz?= =?utf-8?B?TUY5SWh6Nk9USHBndmc3bU9VWHhscjQzRWdBQyt2ZzBSbExrdFFPUkRGMS9Q?= =?utf-8?B?a05OTGJHcndxMGJTemFTb0Jjai9EZ0JDWnh6L1NjUEhDMGxiRjlLRWdhSnYz?= =?utf-8?B?VEVJWHBoQzlWRk5KbGh3Q2Z6WVNkU0lyUWNvRWd6U3pYMmtOMTVwN0FpSXVq?= =?utf-8?B?ejhoWHhnS0hQdWJrVHZJd0w2OXgxN2Nndm1Db21yYXNyWnlSS2poWUpnd2VS?= =?utf-8?B?d3ovUlNTb2FHYnJ5NXVRUm42TjlVQ2k2RTg2SGFNSDd1RUMyV3AzL2IzSHRZ?= =?utf-8?B?RE1zSFBId0x5VXEwOTJZK3lDVGVHSzN0TGErTjN1NFVYQ2N6YzZ6eUg0Q3l3?= =?utf-8?B?M0JFY2M4b2tkKzJSTytoc3Z3TlF2ZmF2c09Kd3g3djRZT2hLM2dXQnlZMkdG?= =?utf-8?B?dzRuUFcybDRic2pGMkdScHkzN29ZdVlzeGkxT2lFVGw2ckR0L21TUkFKNHJG?= =?utf-8?B?RzJ1MkpteHAyWEVabG1FZTBOUDVYaDJXcUtDMW1JVUhPOWZROHF0K004T0tF?= =?utf-8?B?bWYyS01DbERrY1VsTFpDQnMvL1RtS2Q1V1dnM2ZSekJXbWVRM0cyMC9rTGxJ?= =?utf-8?B?ZktaNXhlQis3R1h4dTNEanFCZXBSYjJ2Si9YcWgreWl6NEZub21JNXRFcHp5?= =?utf-8?B?aVFSUWFvMkQ5dTVjekpWNG9mQ1BwZUpHQU8vVDV5OTZXaTBPZkZhQjNXOEV4?= =?utf-8?B?RTZIeTJWOG01OHdKQmkrZmVwOVMzb1lYS2ExRVFORS9jQW1PaFBXRSsrOWJ3?= =?utf-8?B?R2VuYkVPOEZvOUYvZmNLM2xVcDFtZ3ZYK3NnRXQ3aDE4NkhYMmFFTWJYRVgy?= =?utf-8?B?QjRLczUxcWlFZy9XMHBjNU9XczE5T1JIV2Y1aWV6TmhHRmFxNDdZaERZSWtC?= =?utf-8?B?RDNJa1h4YndGVkZVVjFianJqVlYyb0IwN1p1RUswallkdk9zdnlwRWI0MmM0?= =?utf-8?B?N3VzZDRWQTNTbHZCcnJNcFdoNSsxUjdSZm9NaHBrdFR0ekRaeUlyUkw5SmJs?= =?utf-8?B?eVRHT2kxc1doVGN3REQzbXVYdndrVzR1VnlOcC9JSFB5ODhkdW9Kc0NOaUg3?= =?utf-8?B?eitObzBBZXUwMmhkNkVucXRuS1czMUhpYXBrZ1hKMHYreEdRTnQ5allJaUJB?= =?utf-8?B?U29wOFRCNm8zUmx0K2FLVUR2ekp1SGFxYnVhbHpEbTdCWi9rdzJsaDcwRE5t?= =?utf-8?B?SFRMcjVEMmpDYkJzdW9zaVpRdW0zcEpIYjhlNUlxN2ZucHFDTUFRaVZpcGkw?= =?utf-8?B?T21TVHB2N2taak04M0FMOEZJOGpYQU0xVElWK01sbHFENHdSVWJJOFlUV3JU?= =?utf-8?B?TVVIdHliWmpJTCtTYUNOZ1Y4eUhCK0ZxTTBSS25PRDBMczdsb1pqOXI5YVVq?= =?utf-8?B?ZmdLTER2QVpzWVJXbVVPQmZSWDdza3BGcEVUZzJWQmNVT2lESm1ZbkR6Z3BF?= =?utf-8?B?cVBnLzgzeUdycXJqSjhkdElJUTEwV0Nzb1FvUT09?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMjQ0OzY6MGszeUtOVE9veDFrQ1Nzd3lkR20rZncrVlJ0?= =?utf-8?B?SEF5NmQ3Q2lVcFZFeE9JaTFYbEx4UXBjSnBwc011NjlQQzh3RGpwMTZmWEJr?= =?utf-8?B?UzYyd3VVdTI4U1AzQXVYTmVHcjdVOG9jS2o1cnRuTEJVdXN6VDZsMUR4MlYy?= =?utf-8?B?OTV6ajV5M2llV0hIeWp4WDFxMFJXMnI2MWsyckRDRC9FWHFHb2pHZnNkc1Aw?= =?utf-8?B?TVRRbEVqL241Vk9EaWRFNEZPMTNyZlowOEtIZVFITlFpZ0ZSTW5tMVlONDhm?= =?utf-8?B?TS85c2hTOVZyREprSE1xZVpaQXVRQytySzdzeEgvaTcxUkxWUVp3MkFiSlNI?= =?utf-8?B?Z05PTXMxMzBFa1hOZVE0TmVwRGFBeVNJaFZmUFBqZnE0dGFnZWJUWUdtcHYw?= =?utf-8?B?Nnl0NnQvYXU4MU1Kd2tUVkwwN1lXbmQvbFpGLzN6K1dXUCt4dGpiVVo1dEdq?= =?utf-8?B?elN3QTVpcElpbVpzQnBLQWc0dFdiZHgrYWx4Qmx1K3Y0TE5WWWJUYXRCOHB0?= =?utf-8?B?UlI0bFRsbk5NaDdFS1lmRzhBaytBMGpHYytJdHkxZG1TKzh3MUpacTNSakli?= =?utf-8?B?eEhpeklVOG53VnNxRC92UXlxNmh1cGxoeDM1aHJLMVZkdVpaY3NPZ3ZwLy9D?= =?utf-8?B?dE5hSk9oWGU4eGQ3OFlYVEQvUy9hUnJPd3NodE4yWmNRc1N2bFFmWUZkN2xo?= =?utf-8?B?c1ViZU1MKzdKS1YxUCtKWmlHdVRzRHRMa1VPdjlGT2tNeTNkcWlyQmc0R1cy?= =?utf-8?B?M2EyOWJnVVJPd2N5RnpDNlkveGpXWlg4ejQzV2hIcUdqYTR1MHdiMjltUEtm?= =?utf-8?B?S0w5aFJnVlJPZk9VblNMU05aYXVIdEpSQXJHOVN1MCtxdHB5bzhjT1VUd0FS?= =?utf-8?B?MWVUN203WkdrbmM2bU1BbW0zczFDcW45WDhOYTVvZUx5STUzajdzbFVYb29G?= =?utf-8?B?Z3hlYWhody84Zmlsazd5N0QzT2c0aHdDN091dG5ia0F1blFjUVhhY2JqM0dj?= =?utf-8?B?ZmdSUzBCWXpFQUpraERYWCtmWG1QcEZkM3Y3OHoyZmRNT096WVN5MEIybE5a?= =?utf-8?B?UjJ1ZFU3cHpmNlJ0eEtabWtVek9JUlphSDU3MCtGOTV4QS9GODVza1BMT3Ir?= =?utf-8?B?dFRWbVQxRFlxU0xDZ3FONkhGbmxJbzMzcGEwODdTMk0zUXMzbVBneTdpZ0ky?= =?utf-8?B?OVY4dEFxdldGaGdzdVhMREhHbDFPQlpMRjUzV3MrQUpVUjVtK2ZuYlkweTNX?= =?utf-8?B?OWVtTnJib1piSHNaRUhISUVyVjNCdFNhZ0tyTEdOaCtOMHduaWNtRlpGcnZY?= =?utf-8?Q?vT1rZEF12j+YD4H9y0FYyGOe/mIhOnI=3D?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0244; 5:niL8eWMIJtAgJycqHZGwhHlJmnUoh7qAQh/0wepb0kaakqRoXAsNc54XI3LW8r64c5GYCcP+QJLq5tFFObvj++240f9lNBD1c0ZiXeODPqmUWF4o7ua4A0jUP/XZjgml8fgetHIefLlgefI+44K8i1X1ak/RVNL4fHSw2fSKqxFOAEaETwyYLX0IdkrpUd3lO5NhRHI5ip/KlI0ss3n79XL4Z30KQvBGND3OwU71qHs8r4ahnphm2X7nU/YXlYGVflCaUD1zosnp/yeoqfIeCEJswGz6I0XGxv2WU506EUi/C4UXBjThGrAhWxscyVAAg9QsiS+2p0JmCTF6VzqUkDz6wQOLHiYqGnEP+e8AmCfsjMJEXoNx8IFpxgJJ0+5Xm7+xEUSJMCwNi+LiBOQ8cxj5mUcHlGxCQy2JJg17pP8TacoUoYISup//Ykv6jP7HO1GAYwV0KW5LwzOZd0JAt1/rSWjFMYWeVYVXRnbrzJ006QQqzOV3/oVjZ5Phty9S; 24:jxFLISzlhnkd45jmDh3D+JrcBbek+VM8hX9PGBgY2EesTBQZs7Li8ay2Dc+rtv9ozNHWU4LEpx2Us46rxB5vCTb+5EEwgtmTESe3RAyNNQI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0244; 7:OtkbbQfq8wwOjKgPVcetsKgYqNscj2NMWQDBwsv5P9bVuxjQh8r/bRzYliRbtu/frG6hTEZNaCBLSfB/99ETnSyLdFKpcxOjaHCy7Ku9iK8tkzjQRP61P8w3FTL6ZBMTaekbeuN1Mlw5x8ZdmjSAxVHNEe+cgQyO5hrNoi6092Ki4oqDl3QdEjFAfuGncm1475U73m43R6jwDwLiZGgNXzojYai6JWTNJTUNmSyDwOlcpnuf3k1cGKL09AHoWmO9f1JhLi6kjuxkzEeqGqB20oaDWawxXKCAsOotXuI0NKjISqGTLh6+Z5iDy76dc4CQ1Xq+QIA7HCcXcBA/CNri/QwLl9mDv6owclYc0UAJ/peR8WJirzN3Q/xo6fzIdkwk2PpccGB+gM4CwB1O7NAJ1dQlmeZzXuiZEaJAesDFWS1dH2SoYqq9bm6mwECE6FlTQBKoOruiynIw/+QQMyEvq/5PnZbzfbqXL3umdUaL6i7p/nEsasYtHG+jj8aYkYplEdqXhjCIw3hzI2Drbmfky/nJWMuyHI5zB3xOCaSSQNHBnRxtLeGcilNusLzvq2lIDlpsDsC9cRC2u1HdpBEzzaDrebhpSsG1NYcoS7BVmXGjT4FyudK97mD2udJmH/s3S34Yg7yQ/uW1imRJn+WV9Z+r8QtFFD5URR48MBBEVpZkqQUZLjuIoDm8GLvnnm5dvcSwHqvY6t+SeKlNd+giKFc7KPBKrjIMWVRfZ8rwLVTLn05RkMUJZeAKURIFGBa+iDVot5sTsQVS3/LA7kbmhrYcJFhHDUEWlXUmFFZICVc= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2017 05:42:09.8641 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0244 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 05:42:15 -0000 Hello Ira, On 2017/07/16 00:22, Ira McDonald wrote: > Hi, > > Speaking as the co-editor of both the "ipp" and "ipps" URI schemes and the > successor (RFC 8010) to RFC 2910, using HTTP as a substrate for IPP was > a serious design mistake that has added numerous implementation errors and > no functional value. Can you be a bit more specific, or point to something more specific? Regards, Martin. > One prominent (non-conforming) implementation of IPP does use port 443, > but that's just plain wrong and fails the IEEE-ISTO PWG IPP Everywhere > conformance certification tests. > > Please don't use IPP as justification in this discussion. The use of HTTP > as > a substrate was based on bad advice from IETF regulars who should have > known better. > > [ok - back into my cave...] > > Cheers, > - Ira From nobody Sun Jul 16 01:11:59 2017 Return-Path: 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 C248C12785F for ; Sun, 16 Jul 2017 01:11:57 -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 AL_lU4kxXCSa for ; Sun, 16 Jul 2017 01:11:55 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0126.outbound.protection.outlook.com [104.47.33.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C671127180 for ; Sun, 16 Jul 2017 01:11:55 -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=cm33gtuE2+kWio0ewEQ8HEIyaCdxcTk+pugctitO+5I=; b=Ujt6jvilW+3k+SNS0hSON7vFAuBII1Si6Q0C6xhfOfx0cxi2X0oN3/QbaZQT3EmrA9nC0Na4IW+UHRcNOT2HHVkKRnzyepTUnREy6lmBws6cgUzw4i9eFCfR2JfEo3wW0XKaoiHruJzVvOxBxtX0t0+VHVkgdFkIrH/hpZyqCsg= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0175.namprd21.prod.outlook.com (10.173.52.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.5; Sun, 16 Jul 2017 08:11:53 +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:11:53 +0000 From: Dave Thaler To: Mark Nottingham , Adam Roach CC: Alexey Melnikov , "art@ietf.org" , Patrick McManus Thread-Topic: [art] Revising BCP56: On the use of HTTP as a Substrate Thread-Index: AQHS+fwvBa2rF+wzTE+ph2KDNcIt26JUo0gAgABQlgCAAShFMA== Date: Sun, 16 Jul 2017 08:11:52 +0000 Message-ID: References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> In-Reply-To: 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; MWHPR21MB0175; 7:jSsIKSAYFOvXPgSr3smdQyPnahNPTmxponz5CB6T3HNYnDkV6xkKRo/eJqrvcjUwC0zzADeNgqrUn78RUsq56tlEsWcpBCS97qUOV+Gynyk7U/wXYHLgstq1Uco0CGUZm8k05Lw57Z5lPd0zaEjQBiepWmeEM0LLAx0NpCDnEEpPje/gHBGNs/LUhlSkIZt9OuhLWwfI9Ac0oqt9NWsrwrkqkfc0yxPyKLCNgPq3YS1+bA7FC5d0wbQKNtjMVEpPp/M58fAcLlgFp2kGfPNY9YpVGKryndK0DyED+2UlbuWZYNN7DFHrTZfirpFiaKHRLv95k4Ti7yngRwb4V0fKIBKtTLJBiHehT1BecQbt1QFQASazGMGW9gJVN+KAJB7WY3JGJdRs+LNwh6UXU1T2fpmQ/8DvMCdgDtH2y3yaO6WYrVpGyxvFzUQJ72pudS9d0n3eIICCIwCAUy7XBFOLq1892FnqBBVF6PD/mEuTevNpC/SBkAV1oYzItd8rbMWjA4IY2vO0yWIIf34CukGataXeJUQ8Wz5D/d1ybnMMSudbYsxvj/pG7yhfQo3eAJvmGDFiYgUwE//X2Rh6fLJ/HFSHWsIbrJcdXaXoKnYXOoJ8NFG90xf17HlxzzgrQ8LtCRDsrvtQF0X7Rp4RUweStq6EKMloi/TTawJ49XuGiv+0BUHbvHD4f1/lZPexfpE7Hg+CgcgvdT3PTuCosEX7NDFWB3jB7nyS7nGQw+K9sHsSYrgGTT/TpGbncmfdh1vYEyaZCe0M1UQw83OkzSqgcza7lvCDVUtlHpoZp4TQfnWg8Blg81xFS+XB2Uc5D/L/ x-ms-office365-filtering-correlation-id: 454c5245-7b1b-4420-5de8-08d4cc225147 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:MWHPR21MB0175; x-ms-traffictypediagnostic: MWHPR21MB0175: x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(189930954265078)(48057245064654)(100405760836317)(219752817060721)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0175; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0175; x-forefront-prvs: 03706074BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(39400400002)(377454003)(13464003)(24454002)(51444003)(305945005)(9686003)(5005710100001)(54906002)(55016002)(6246003)(7736002)(6306002)(99286003)(2906002)(53936002)(3660700001)(33656002)(3280700002)(38730400002)(189998001)(7696004)(74316002)(6436002)(2950100002)(5660300001)(8936002)(8676002)(10090500001)(6506006)(77096006)(2900100001)(229853002)(76176999)(81166006)(54356999)(478600001)(6116002)(50986999)(14454004)(4326008)(25786009)(53546010)(575784001)(86362001)(966005)(102836003)(10290500003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0175; 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:11:52.8012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0175 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 08:11:58 -0000 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 se= parate 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 protoco= l an app supports is HTTP, which is not the case. If an application defines higher layer semantics w= here HTTP and something else can both be used as transports (the topic of draft-thaler-appsawg-multi-tra= nsport-uris discussion), than 4.3.2 would imply that one must use multiple URIs for the same transpo= rt, rather than having one higher-layer URI for the application-layer protocol or semantics. http://www.w3.org/TR/webarch/#uri-aliases discusses multiple URIs for the s= ame 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 shou= ld use different URIs with the same resource. Dave -----Original Message----- From: art [mailto:art-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Saturday, July 15, 2017 4:09 PM To: Adam Roach Cc: Alexey Melnikov ; art@ietf.org; Patrick McMa= nus Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate > On 15 Jul 2017, at 11:20 am, Adam Roach wrote: >=20 > I found 4.3.2 particularly interesting, as there doesn't seem to have bee= n consensus in this space in the past. For example, the ws(s) and ipp(s) sc= hemes made a different decision. I presume your assertion is that, were we = defining these protocols today, they would be using http(s) instead? AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as p= er section 2, it's not "using" HTTP. WS(S) uses port 80/443 to bootstrap into another protocol (using Upgrade). = There probably needs to be a carve-out for that. > I don't see anything wrong with that; I just want to probe the edges of t= his advice by seeing how it would have applied to decisions we made in the = past, since that's a pretty good predictor for how it might apply in the fu= ture. >=20 > The advice in 4.3.3 seems a bit strong, in that it will require whatever = process listens on port 443 to take on an ever-increasing role. If we're go= ing to keep this advice, I think the document needs some treatment of the s= oftware architecture implications: functionally, whatever listens to port 4= 43 will need to be able to delegate sub-trees of the URL space to other pro= cesses. I know that some web servers have mechanisms to handle this kind of= thing today; but we're effectively saying that this will become required b= ase functionality for web servers moving forward. >=20 > I wonder, in that context, whether the current advice strikes the right b= alance. I think that's a great conversation to have. Cheers, >=20 > /a >=20 > On 7/11/17 06:14, Mark Nottingham wrote: >> A number of folks have recently noted that BCP56 addresses the problems = of using HTTP for protocols in the early 2000's, but we've moved on conside= rably since then. >>=20 >> Given the number of IETF protocols being build upon HTTP these days, it = seems timely to reconsider it. I've been working on a candidate for replaci= ng it for a little while; see: >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo= ls.ietf.org%2Fhtml%2Fdraft-nottingham-bcp56bis&data=3D02%7C01%7Cdthaler%40m= icrosoft.com%7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd= 011db47%7C1%7C0%7C636357245624370624&sdata=3DSXTi6jowkOjw%2FcueFIzjv8pgO6xr= 2CWNs03T%2FmjC5%2Bo%3D&reserved=3D0 >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmno= t.github.io%2FI-D%2Fbcp56bis%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7C= a6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C636357245624370624&sdata=3DdfU3abFGiVGy5GoWjP3%2Fqs%2Bz9GA5mDTpkOahKaYHG= z0%3D&reserved=3D0 >>=20 >> I have a small-ish slot in the HTTP WG session on Wednesday to discuss t= his. >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7Ca6d= dee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C= 636357245624370624&sdata=3DaKla74j9QLO02JvWmdd%2BG8ie9U0R9MFKdO1UCDFOOsU%3D= &reserved=3D0 >>=20 >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fart&data=3D02%7C01%7Cdthaler%40microsoft.com= %7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%= 7C0%7C636357245624370624&sdata=3DE7%2F7g5BJkM6FgK0HHSxmflR0oN7zWPfqQRybZ55E= q0Y%3D&reserved=3D0 >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fart&data=3D02%7C01%7Cdthaler%40microsoft.com%= 7Ca6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7= C0%7C636357245624370624&sdata=3DE7%2F7g5BJkM6FgK0HHSxmflR0oN7zWPfqQRybZ55Eq= 0Y%3D&reserved=3D0 -- Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7Ca6ddee= 6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636= 357245624370624&sdata=3DaKla74j9QLO02JvWmdd%2BG8ie9U0R9MFKdO1UCDFOOsU%3D&re= served=3D0 _______________________________________________ art mailing list art@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fart&data=3D02%7C01%7Cdthaler%40microsoft.com%7C= a6ddee6841bc45cc22fd08d4cb8b15ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C636357245624370624&sdata=3DE7%2F7g5BJkM6FgK0HHSxmflR0oN7zWPfqQRybZ55Eq0Y= %3D&reserved=3D0 From nobody Sun Jul 16 01:16:20 2017 Return-Path: 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 661DE1275AB for ; Sun, 16 Jul 2017 01:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=fUsLCvLy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c8Esaaz2 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 21tqodA-raU2 for ; Sun, 16 Jul 2017 01:16:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF967127180 for ; Sun, 16 Jul 2017 01:16:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 39F3D204DB; Sun, 16 Jul 2017 04:16:16 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 16 Jul 2017 04:16:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=XLTEoHi0UwsH04mZVB gpTbZ+4hFtE4Dsvwp+X5fEzMQ=; b=fUsLCvLyKJb4xnu2In7SHjKBPYOoIkPt9m 0oIW5XbLo4qfxM8fp71E+Qhndgb4XCsdzOaHQmBiw9JoSdb033Qcii7nEu+ynWK3 4IoegCJdQBTXYcGnlDrj9UXUufZnUKe7vDyPJGH3xsY7MuafGjKXG++NF0Z90Y8T 7UKiRibJ/uRnV/JyYkDBybDo2Ou2csxX5cwmkWzzQ264wAjjBti8eXAWnNpnRlu1 mc7DiyvVMY9QgdCVCADlpwBHVOUULQwZFKzvrXdB6nulqUks3GzTSP2/ZIk/qptk yhsmD1vQg1iBrA7/ISiT3QNzW/9zkZrhNFXrSj6ssuBV70mBRosw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=XLTEoHi0UwsH04mZVBgpTbZ+4hFtE4Dsvwp+X5fEzMQ=; b=c8Esaaz2 Aud7RYyy9dMWtoqepWxc6Ko9AbV6Xd5vxxNVq8WkXSeJ1glY34a3gTCH/udQUYyO XstpyO3xkm6x99U/NgGKREjq2yrnrFhiplqfB4pqJncuPxfdCKVQL/s7vw850xMd 2OOct8O0MKmLWvxz9eKrAJQX9biXW2fGZjj5k8Fk3sYBqvnnvJqKADfErYDoQzhr 3Ei9Kw0gGqycvi9NDkke89XCPEBsikNo0h4ABZZ5iOtMp98/19he6TzTlgpHLtqS 1xafcR6ty9t0hSkB5AprLyeRy5SOylUUXInADIJWQ/VvGbakR/CAJ8P8iqt5LtPN 6zXShrLoUaLm2g== X-ME-Sender: X-Sasl-enc: iuqyN7qh40RpVbiDLxum9sRmfSiRxFKfXFbwBLZqLJ11 1500192975 Received: from dhcp-813f.meeting.ietf.org (dhcp-813f.meeting.ietf.org [31.133.129.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 7067A24254; Sun, 16 Jul 2017 04:16:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Sun, 16 Jul 2017 10:16:14 +0200 Cc: Adam Roach , Alexey Melnikov , Patrick McManus , "art@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <57B020F0-3FB8-423D-BDB6-4AF98BE9C4BA@mnot.net> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> To: Dave Thaler X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 08:16:19 -0000 > On 16 Jul 2017, at 10:11 am, Dave Thaler = wrote: >=20 > 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]. >=20 > 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". >=20 > 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. >=20 > http://www.w3.org/TR/webarch/#uri-aliases discusses multiple URIs for = the same resource and has recommendations like > "A URI owner SHOULD NOT associate arbitrarily different URIs with the = same resource." >=20 > 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://www.mnot.net/ From nobody Sun Jul 16 01:18:54 2017 Return-Path: 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 ; 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 ; 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 ; 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 To: Mark Nottingham CC: Adam Roach , Alexey Melnikov , Patrick McManus , "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: References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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? =20 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]=20 Sent: Sunday, July 16, 2017 10:16 AM To: Dave Thaler Cc: Adam Roach ; Alexey Melnikov ; Patrick McManus ; 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 wrote: >=20 > I think 4.3.2 is problematic as currently worded. For example, >> Using other schemes to denote an application using HTTP makes it more=20 >> difficult to use with existing implementations (e.g., Web browsers), =20 >> and is likely to fail to meet the requirements of [RFC7595]. >=20 > The "URI Schemes and Web Protocols" document Henry pointed to argues=20 > for separate URI schemes for different protocols (ftp, http, coap, etc.),= e.g. "G4. Serve using the protocol associated with the URI scheme". >=20 > I think the "HTTP as a Substrate" document is worded as if the only proto= col 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=20 > draft-thaler-appsawg-multi-transport-uris discussion), than 4.3.2=20 > would imply that one must use multiple URIs for the same transport, rathe= r than having one higher-layer URI for the application-layer protocol or se= mantics. >=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.w3 > .org%2FTR%2Fwebarch%2F%23uri-aliases&data=3D02%7C01%7Cdthaler%40microsoft= .com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C636357897782919498&sdata=3Dklbb40TomYZ216cxDZFHGBh1EiXMaVc2pmT4%2= FjsXKv4%3D&reserved=3D0 discusses multiple URIs for the same resource and h= as recommendations like "A URI owner SHOULD NOT associate arbitrarily diffe= rent URIs with the same resource." >=20 > Thus that would argue that apps should have higher-layer URIs for=20 > concepts that are not specific to HTTP, since there may be different=20 > URIs that differ by existing protocol (and URI scheme). As such,=20 > 4.3.2 seems problematic since it seems to be saying that that's bad and a= pps should use different URIs with the same resource. W3C doesn't share the IETF's aversion to using HTTP to identify higher-leve= l 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 nego= tiation). -- Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aa= bcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636= 357897782929506&sdata=3DhLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW%2FkQiFIiWxFtT8%3D&re= served=3D0 From nobody Sun Jul 16 01:21:06 2017 Return-Path: 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 7B5CC127180 for ; Sun, 16 Jul 2017 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=aAJb2g4a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cQ2BQgez 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 DQAd3nPTkvos for ; Sun, 16 Jul 2017 01:21:02 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F931317C3 for ; Sun, 16 Jul 2017 01:21:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ADBC820892; Sun, 16 Jul 2017 04:21:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 16 Jul 2017 04:21:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=/Jq4zxZWhHany3+4Dj CE5wqpPn7RnDvva8CL+MNY27U=; b=aAJb2g4aLXls+5b3gP/uxT2vWZHOBl8vh3 hLYPB2QFb7V7k/OOoJK+olei4riX/Wwiq7ROw9hT80ECpjNRiN/jU/E82sE/q09a BOTdRFXdVq81f60i8f6kJllVI3pp/jfRvltWG4XclWqkoBS8DTeP1C3uKDH908F9 0czWG3udUJiNpCj/7dD5uISuvwKEDo1hJhlXHs9iRQs1QevM188JGgjfS5QOwEG0 9Kl3l/rzR7t6ibE+n4x51CFZJatEYG3SDxpnhNK3MDwjdhj9XCKmgux77gbjeY// fFjCutFbehDDf1Qx3daTwcy23XRkvJaDVaBLEEcxB218XuS7jVwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=/Jq4zxZWhHany3+4DjCE5wqpPn7RnDvva8CL+MNY27U=; b=cQ2BQgez gx7IQr2izDDKex3DtnbtmP0FJ+RiHqKmbMktc7W3tfmCWKZdWChIUpVqgM4ozdzb 9qxE4XEWarhMpIPs4Z+8WVs3VaHC17Lz4kTJsv1A/LCu1HgGuENZYa+3KRdWxzO/ 4KhvifQbBmml8DztOtcPwY6C4xj+y7752+XC43HlPrsbOlyrZe1LlfZlexUr2Dp4 9Kf/ixucOb6miJXRW3FCbrOf+8aqUa5XSTqMgK/ORPpqyrmGCxZeRMFb1AW0ZTU8 k6tBuJW63NSNePd96NeghxXaswZ3oAkG0M5XwQwEW9ujGhYgOx+/2yV1m5ZJJWG/ joZgqObaxGvSCA== X-ME-Sender: X-Sasl-enc: IupDLBMEyrU6RtMPJLxGKIllLAyGxNTxuDNnPBAM67n/ 1500193261 Received: from dhcp-813f.meeting.ietf.org (dhcp-813f.meeting.ietf.org [31.133.129.63]) by mail.messagingengine.com (Postfix) with ESMTPA id E771F24253; Sun, 16 Jul 2017 04:21:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Sun, 16 Jul 2017 10:20:59 +0200 Cc: Adam Roach , Alexey Melnikov , Patrick McManus , "art@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1A730736-4F70-4474-9E93-51900D7AF35E@mnot.net> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <57B020F0-3FB8-423D-BDB6-4AF98BE9C4BA@mnot.net> To: Dave Thaler X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 08:21:04 -0000 I think we learned that that kind of wallpapering over of application = protocol semantics doesn't work well when WS-* failed. People still keep = on trying to do it, though. > On 16 Jul 2017, at 10:18 am, Dave Thaler = wrote: >=20 > 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? =20 >=20 > http://www.w3.org/2001/tag/doc/SchemeProtocols.html#useNaturalProtocol = says: > 4.2.1 G4. Serve using the protocol associated with the URI scheme >=20 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net]=20 > Sent: Sunday, July 16, 2017 10:16 AM > To: Dave Thaler > Cc: Adam Roach ; Alexey Melnikov = ; Patrick McManus ; = art@ietf.org > Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate >=20 >=20 >> On 16 Jul 2017, at 10:11 am, Dave Thaler = wrote: >>=20 >> I think 4.3.2 is problematic as currently worded. For example, >>> Using other schemes to denote an application using HTTP makes it = more=20 >>> difficult to use with existing implementations (e.g., Web browsers), = =20 >>> and is likely to fail to meet the requirements of [RFC7595]. >>=20 >> The "URI Schemes and Web Protocols" document Henry pointed to argues=20= >> for separate URI schemes for different protocols (ftp, http, coap, = etc.), e.g. "G4. Serve using the protocol associated with the URI = scheme". >>=20 >> 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=20 >> draft-thaler-appsawg-multi-transport-uris discussion), than 4.3.2=20 >> 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. >>=20 >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.w3 >> = .org%2FTR%2Fwebarch%2F%23uri-aliases&data=3D02%7C01%7Cdthaler%40microsoft.= com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C636357897782919498&sdata=3Dklbb40TomYZ216cxDZFHGBh1EiXMaVc2pmT4%= 2FjsXKv4%3D&reserved=3D0 discusses multiple URIs for the same resource = and has recommendations like "A URI owner SHOULD NOT associate = arbitrarily different URIs with the same resource." >>=20 >> Thus that would argue that apps should have higher-layer URIs for=20 >> concepts that are not specific to HTTP, since there may be different=20= >> URIs that differ by existing protocol (and URI scheme). As such,=20 >> 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. >=20 > 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). >=20 >=20 >=20 > -- > Mark Nottingham = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.mno= t.net%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708= d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782929506= &sdata=3DhLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW%2FkQiFIiWxFtT8%3D&reserved=3D0 -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jul 16 05:41:53 2017 Return-Path: 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 EE011130133 for ; Sun, 16 Jul 2017 05:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SANwCv_DuC7t for ; Sun, 16 Jul 2017 05:41:50 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3C11300BC for ; Sun, 16 Jul 2017 05:41:49 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d78so103765464qkb.1 for ; Sun, 16 Jul 2017 05:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tWYWjl7lc0nJ/yfj173/x12FXwIInvHeXfZ5g5xwSrY=; b=jxQUgqYFm8nA+kKQJRHuI1kwoHs2ENxQRfMLvbu22EV4SHRtbpdSuIP/7yKXyAL5ww c1XmRM5SolUkd5eqNxXR9FTihJdw2x6mFhRe4NPzOQaCI/sEZDaB2eXmQQ0kjUYhQPyy zeOaxX6Qi67dPIFWUTeW7HuECX1WkwQp4QAvaemBpbfGvwxzP0oVv2kuv4WdMIsFQqDo AcQFcIADH5v39NblIFYMs52/rAF4bpaQNTz+NpjKPFDESjCQw7kjPVFGBHlQplfuZwT3 aZoRperFZffqJPuWyyyZy36U+Oxxce6AcII645gjoAVwmI8Ius+E4q4iOUii4DFLY/el E/9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tWYWjl7lc0nJ/yfj173/x12FXwIInvHeXfZ5g5xwSrY=; b=UCqwlGTBDelJQa9h8oApOIhnxW2pz/DCG/g79ssMTCBd6vJqjBUWJueoVV7BXpNfGL Ji8eQnvflUcwePJF5R57ON4rLNpY3PKfrb3Yq13Wn80pdwnz/zg3/q81bpz2gefgvDRN FYxooT9ZH8SMxs7eDdknHDogLf0jjm2Hp/z+FAqcT+iV1ipnodwdHuROy8LvXVnWKx4W YBrNeWOLnHVoahxwdoXV9+NpqSuvnlXLPGV44igsYXFupPDQpmsqDsxtskKCSU6UsGM8 KuISlRbZjuYWM2I0nJ8B/d1lFF0FP3a/1m8uOQppm0XD+ZWz6C+aAtsYz25fJ8tbx7eK LQ4A== X-Gm-Message-State: AIVw112fKJ8HnuXb16QtR4Jw38sbo1zQTQwlpJSeh/77KTKt9k19h//G 6QAdxB74dvAj69RnVhNXUkA6hwemUQ== X-Received: by 10.55.27.83 with SMTP id b80mr20788882qkb.148.1500208909064; Sun, 16 Jul 2017 05:41:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.43.101 with HTTP; Sun, 16 Jul 2017 05:41:28 -0700 (PDT) In-Reply-To: References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <989a76b8-7006-5c9b-66cb-0a03f8e9e517@nostrum.com> From: Ira McDonald Date: Sun, 16 Jul 2017 08:41:28 -0400 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: Adam Roach , Alexey Melnikov , Ted Hardie , Mark Nottingham , art@ietf.org, Patrick McManus Content-Type: multipart/alternative; boundary="001a1147f15c1d1dcf05546e9b82" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 12:41:52 -0000 --001a1147f15c1d1dcf05546e9b82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, I'll try to be more specific: IPP uses a unique binary encoding of its primitive datatypes (integer, language-tagged string, keyword (registered) as distinct from name (vendor free-form), etc.). So the HTTP payload of IPP is opaque. IPP original authors were told that using an HTTP substrate would make penetrating firewalls easier - it didn't of course. IPP "resources" do not correspond to the general HTTP idea of resources, so the semantics of HTTP Get on an IPP URI are surprising. IPP uses HTTP POST for the main operation requests. The fact that the wrapper was HTTP has led to numerous problems with intermediate entities attempting to optimize/cache/whatever the IPP operation requests and responses. HTTP Basic and Digest were supposed to be good authentication methods - but they're weak and have been largely replaced by Kerberos, OAuth, etc., in practice. Printer vendors sometimes re-invented their own HTTP layers (LOTS of bugs) or pasted in HTTP layers from immature sources (and then never maintained them). What IPP needed was a TLS connection for end-to-end authentication and encryption. Modern printers almost universally use TLS "under" their HTTP layer, as is mandated by IPP Everywhere (IEEE-ISTO PWG 5100.14). IPP is ubiquitous (over 98% of all printers sold in recent years), but the HTTP layer was just used as an over-complicated way of getting a TLS connection. I hope this helps explain my aversion to the use of HTTP in the IPP protocol stack. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Sun, Jul 16, 2017 at 1:42 AM, Martin J. D=C3=BCrst wrote: > Hello Ira, > > On 2017/07/16 00:22, Ira McDonald wrote: > >> Hi, >> >> Speaking as the co-editor of both the "ipp" and "ipps" URI schemes and t= he >> successor (RFC 8010) to RFC 2910, using HTTP as a substrate for IPP was >> a serious design mistake that has added numerous implementation errors a= nd >> no functional value. >> > > Can you be a bit more specific, or point to something more specific? > > Regards, Martin. > > > One prominent (non-conforming) implementation of IPP does use port 443, >> but that's just plain wrong and fails the IEEE-ISTO PWG IPP Everywhere >> conformance certification tests. >> >> Please don't use IPP as justification in this discussion. The use of HT= TP >> as >> a substrate was based on bad advice from IETF regulars who should have >> known better. >> >> [ok - back into my cave...] >> >> Cheers, >> - Ira >> > --001a1147f15c1d1dcf05546e9b82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

=
I'll try to be more specific:

IPP uses a unique bina= ry encoding of its primitive datatypes (integer,
language-tagged s= tring, keyword (registered) as distinct from name
(vendor free-for= m), etc.).=C2=A0 So the HTTP payload of IPP is opaque.

IPP original = authors were told that using an HTTP substrate would make
penetrating f= irewalls easier - it didn't of course.=C2=A0

IPP &q= uot;resources" do not correspond to the general HTTP idea of resources= ,
so the semantics of HTTP Get on an IPP URI are surprising.

IPP= uses HTTP POST for the main operation requests.

Th= e fact that the wrapper was HTTP has led to numerous problems
with intermediate entities attempting to optimize/cache/whatever the
IPP operation requests and responses.=C2=A0 HTTP Basic and Digest = were
supposed to be good authentication methods - but they= 9;re weak and
have been largely replaced by Kerberos, OAuth, = etc., in practice.

Printer vendors sometimes re-invented = their own HTTP layers
(LOTS of bugs) or pasted in HTTP layers= from immature sources
(and then never maintained them).=C2= =A0 What IPP needed was a TLS
connection for end-to-end authe= ntication and encryption.=C2=A0 Modern
printers almost univer= sally use TLS "under" their HTTP layer, as is
manda= ted by IPP Everywhere (IEEE-ISTO PWG 5100.14).=C2=A0

IPP is ubiquit= ous (over 98% of all printers sold in recent years), but
the HTTP layer= was just used as an over-complicated way of getting
a TLS connection.<= br>
I hope this helps explain my aversion to the use of HTTP = in the IPP
protocol stack.

Cheer= s,
- Ira

Ira McDonald (Musician / Softwa= re Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Li= nux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Gr= oup
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Desig= nated Expert - IPP & Printer MIB
Blue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc<= /a>
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place=C2=A0 Saline, MI= =C2=A0 48176=C2=A0 734-944-0094
May-Dec: PO Box 221=C2=A0 Grand Marais, = MI 49839=C2=A0 906-494-2434


On Sun, Jul 16, 2017 at 1:42 AM, Martin J. D= =C3=BCrst <duerst@it.aoyama.ac.jp> wrote:
Hello Ira,

On 2017/07/16 00:22, Ira McDonald wrote:
Hi,

Speaking as the co-editor of both the "ipp" and "ipps" = URI schemes and the
successor (RFC 8010) to RFC 2910, using HTTP as a substrate for IPP was
a serious design mistake that has added numerous implementation errors and<= br> no functional value.

 Can you be a bit more specific, or point to something more specific?

Regards,=C2=A0 =C2=A0Martin.


One prominent (non-conforming) implementation of IPP does use port 443,
but that's just plain wrong and fails the IEEE-ISTO PWG IPP Everywhere<= br> conformance certification tests.

Please don't use IPP as justification in this discussion.=C2=A0 The use= of HTTP
as
a substrate was based on bad advice from IETF regulars who should have
known better.

[ok - back into my cave...]

Cheers,
- Ira

--001a1147f15c1d1dcf05546e9b82-- From nobody Sun Jul 16 16:48:54 2017 Return-Path: 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 05657129B25 for ; Sun, 16 Jul 2017 16:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.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 4E45zsP1_ind for ; Sun, 16 Jul 2017 16:48:51 -0700 (PDT) Received: from homiemail-a59.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEF3129AD1 for ; Sun, 16 Jul 2017 16:48:51 -0700 (PDT) Received: from homiemail-a59.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a59.g.dreamhost.com (Postfix) with ESMTP id 2ECA6E00092B; Sun, 16 Jul 2017 16:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=qOKS48w2Z+1v+8b9re47v59zqK0=; b=EaunFLUm2qdLMiwPgEqL+CpSUGlW bwn0/9MJiebNxIsUbF0H6ATb7tveyjXIpEuUSY/BM3tGjBIyq67xVKAkxaZpGsGf BPFN4zI+xTiqxuowgXlCLFO+1JCNIoIuMCHy+oYXZ0RlfsSyCYSxkKTV88W6+zHa gBHbM5VeUtPPYyM= Received: from [192.168.1.11] (ip68-228-64-138.oc.oc.cox.net [68.228.64.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a59.g.dreamhost.com (Postfix) with ESMTPSA id 66BC2E000927; Sun, 16 Jul 2017 16:48:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: Date: Sun, 16 Jul 2017 16:48:49 -0700 Cc: =?utf-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Ted Hardie , Adam Roach , Patrick McManus , Mark Nottingham , art@ietf.org, Alexey Melnikov Content-Transfer-Encoding: 7bit Message-Id: <83749F0F-4D1D-4CA1-9C72-CFAA56F4E773@gbiv.com> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <989a76b8-7006-5c9b-66cb-0a03f8e9e517@nostrum.com> To: Ira McDonald X-Mailer: Apple Mail (2.2104) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:48:53 -0000 > On Jul 16, 2017, at 5:41 AM, Ira McDonald wrote: > > Hi Martin, > > I'll try to be more specific: > > IPP uses a unique binary encoding of its primitive datatypes (integer, > language-tagged string, keyword (registered) as distinct from name > (vendor free-form), etc.). So the HTTP payload of IPP is opaque. > > IPP original authors were told that using an HTTP substrate would make > penetrating firewalls easier - it didn't of course. Umm, what advice are you referring to? I remember ftp://ftp.pwg.org/pub/pwg/ipp/minutes/961212-ietf-bof.txt and being quite explicit about why that plan was bogus. I also remember advising that HTTP be used as designed, not tunneled through with an opaque blob of poorly designed vendor-specific options. Whatever problems IPP may have encountered after that, they weren't due to the authors following IETF advice, nor were they due to using HTTP as a substrate (any more than they were due to using TCP as a substrate). They might have been due to not inventing a completely new protocol that performed streaming RPC with opaque data through firewalls, but I think that's a bit fanciful given the lack of successful examples. ....Roy From nobody Tue Jul 18 03:48:20 2017 Return-Path: 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 07444129AC4 for ; Tue, 18 Jul 2017 03:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=hI8VXlmT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EsQLDzQx 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 VLdICuLexUOJ for ; Tue, 18 Jul 2017 03:48:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1376012714F for ; Tue, 18 Jul 2017 03:48:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8312320A5D; Tue, 18 Jul 2017 06:48:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 18 Jul 2017 06:48:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=deuPIkNSRlFhdX+pTv TDU67tJAFIwSkm/Mo65dYjuqk=; b=hI8VXlmT0DOMlH2xldYD2+s1ipYEz0fpT9 06hdtR6nT3zYNhslWGaMrHhsOhRwvcPRvslX1mjbYm8ywolFpYm0jY9oC0RyHrL7 HJyXFMD+hkC8KzWRjrDeI4Y2g+Vu6uPoKVJ98FoUNW8l1WKgYKoUL5LPSfGKBBR4 yQY9B+EHNKKuf7VjpAjsozaV7iHsDqiv5mDL16WHqW28+9dr3jIU91/+Cek6fubA Ngi54Fr0Ly/MYGIM+dluebxJcQY3k4ODpd+hjWP2A49cXzzxDvGTGUTDDYEvWc44 f3ZHxd7iQIq6c9yiFW4SdnZYszKbrnuAb6Sla4Y6bi/E1BLFJUwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=deuPIkNSRlFhdX+pTvTDU67tJAFIwSkm/Mo65dYjuqk=; b=EsQLDzQx OdAKS0k8UKUGoqq49UD0BmZUweOE6F9Q0kH38GwMvmDoSAhL8cJB5c5q5GjqOsH1 VmV44aMmAoUKabSXAd3ljsgxHhU19BES62Nq0gvqPFk/M0CF0rPnQChOZMqz/uzy g2jqYy6nUTykOZatdwaZTiUtZm1wZWUzwAVU/wguKDZwHvjL/HffMlvnhI56eZeN ArTuRntfWGYtNOyA5SR92WLE3iR0uXzCanag2LiZ3o0WeZqpIeH92j38eY5AUPmO 2E/+waHUeOuBQqOstl0yu0zCIx4Gfg2kbyejc7+iRXcJTgBduKeQugGd6MYOUh7i c6gDjdK8iEBYiQ== X-ME-Sender: X-Sasl-enc: Qzh/aDghYxX12FHdYwZ+UM1cL70l2bUolKmjKLBJj4GZ 1500374895 Received: from dhcp-813f.meeting.ietf.org (dhcp-813f.meeting.ietf.org [31.133.129.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 883427E312; Tue, 18 Jul 2017 06:48:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Tue, 18 Jul 2017 12:48:12 +0200 Cc: Alexey Melnikov , "art@ietf.org" , Adam Roach , Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: <8557ED98-EC4F-4D16-9793-C87915B2AFAA@mnot.net> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <57B020F0-3FB8-423D-BDB6-4AF98BE9C4BA@mnot.net> To: Dave Thaler X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 10:48:19 -0000 After this and some offline discussion, my current copy has: ~~~ ### URL Schemes {#scheme} Applications that use HTTP will typically use the "http" and/or "https" = URL schemes. "https" is preferred to mitigate pervasive monitoring = attacks {{?RFC7258}}. However, application-specific schemes can be defined as well. When defining an URL scheme for an application using HTTP, there are a = number of tradeoffs and caveats to keep in mind: * Unmodified Web browsers will not support the new scheme. While it is = possible to register new URL schemes with Web browsers (e.g. = registerProtocolHandler() in {{custom-handlers}}, as well as several = proprietary approaches), support for these mechanisms is not shared by = all browsers, and their capabilities can vary. * Likewise, existing non-browser clients, intermediaries, servers and = associated software will not recognise the new scheme, and might fail to = operate. For example, a client library might fail to dispatch the = request; a cache might refuse to store the response, and a proxy might = fail to forward the request.=20 * Because URLs occur in and are generated in HTTP artefacts commonly, = often without human intervention (e.g., in the `Location` header), it = can be difficult to assure that the new scheme is used consistently. * The resources identified by the new scheme will still be available = with "http" and/or "https" URLs to clients. While it is possible to = define the relationship between these resources in new new scheme's = specification, existing HTTP software (such as clients, caches, = intermediaries and servers) will not be available, so there is a danger = of confusion when the "wrong" URL is used. * Features that rely upon the URL's origin {{?RFC6454}}, such as the = Web's same-origin policy, will be impacted by a change of scheme. * HTTP-specific features such as cookies {{?RFC6265}}, authentication = {{?RFC7235}}, caching {{?RFC7234}}, and CORS {{CORS}} might or might not = work correctly, depending on how they are defined and implemented. = Generally, they are designed and implemented with an assumption that the = URL will always be "http" or "https". * Web features that require a secure context {{secure-context}} will = likely treat a new scheme as insecure. For these reasons, it is preferable to use the message payload to = indicate the application in use, rather than the URL scheme. See {{?RFC7595}} for more information about minting new URL schemes. ~~~ Thoughts? > On 16 Jul 2017, at 10:18 am, Dave Thaler = wrote: >=20 > 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? =20 >=20 > http://www.w3.org/2001/tag/doc/SchemeProtocols.html#useNaturalProtocol = says: > 4.2.1 G4. Serve using the protocol associated with the URI scheme >=20 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net]=20 > Sent: Sunday, July 16, 2017 10:16 AM > To: Dave Thaler > Cc: Adam Roach ; Alexey Melnikov = ; Patrick McManus ; = art@ietf.org > Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate >=20 >=20 >> On 16 Jul 2017, at 10:11 am, Dave Thaler = wrote: >>=20 >> I think 4.3.2 is problematic as currently worded. For example, >>> Using other schemes to denote an application using HTTP makes it = more=20 >>> difficult to use with existing implementations (e.g., Web browsers), = =20 >>> and is likely to fail to meet the requirements of [RFC7595]. >>=20 >> The "URI Schemes and Web Protocols" document Henry pointed to argues=20= >> for separate URI schemes for different protocols (ftp, http, coap, = etc.), e.g. "G4. Serve using the protocol associated with the URI = scheme". >>=20 >> 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=20 >> draft-thaler-appsawg-multi-transport-uris discussion), than 4.3.2=20 >> 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. >>=20 >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.w3 >> = .org%2FTR%2Fwebarch%2F%23uri-aliases&data=3D02%7C01%7Cdthaler%40microsoft.= com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C636357897782919498&sdata=3Dklbb40TomYZ216cxDZFHGBh1EiXMaVc2pmT4%= 2FjsXKv4%3D&reserved=3D0 discusses multiple URIs for the same resource = and has recommendations like "A URI owner SHOULD NOT associate = arbitrarily different URIs with the same resource." >>=20 >> Thus that would argue that apps should have higher-layer URIs for=20 >> concepts that are not specific to HTTP, since there may be different=20= >> URIs that differ by existing protocol (and URI scheme). As such,=20 >> 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. >=20 > 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). >=20 >=20 >=20 > -- > Mark Nottingham = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.mno= t.net%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708= d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782929506= &sdata=3DhLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW%2FkQiFIiWxFtT8%3D&reserved=3D0 >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 18 21:54:17 2017 Return-Path: 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 93625124D85 for ; Tue, 18 Jul 2017 21:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CfZxXF1KRFJJ for ; Tue, 18 Jul 2017 21:54:14 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDBD1200C5 for ; Tue, 18 Jul 2017 21:54:13 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 21so32292758qtx.3 for ; Tue, 18 Jul 2017 21:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dJjM0tPbq+IMPghUCbt95mXhQa4mZFwX0t8mNr80TNk=; b=C8LVEypk3TTzZYA+N2dhe6bjvVu10l/zNf4e00rTOBxf+EYrMHn8v9hkckMAbLtkD6 F8PdweFTlMUkBvpKfY9ewce8jvmlZr1pmlTs95gG3+jidzkYjUtnJtQcK4Thsl7bcIbL kV1X5JbF/NazfXAlrNq8QguhtEW6yMpqm9+YFnkQZTF6p5Rhjr5dx3VO9Iag7KxMHdN+ +j62n47Kdj2ncFhOKeCRDeDPK9d3Twfu6FICP5Qd/v6LNPfVRrSxvpGHJqmtf9C1xawc QC4KWu0t42pk5CPcTnp6Ydod45STuuo7cUvJrQINmLP6fiUE846RGveXLv7H+ne3xtbS FEMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dJjM0tPbq+IMPghUCbt95mXhQa4mZFwX0t8mNr80TNk=; b=OdSZtXHJVQ1hNGtHee9soO8d66qKCkuyZnw5S6Fh3DuDg9ux2EjvO0bATzpswIiyJ4 7hn4PO3pYmv4PbRVF7nVWOVFIJjOasSvWQ6OOkebNUocRsark3XNaPhAKDT2byw6D6Xa fPS8au8HVI4LQbq+LlVABICJ2cNJ2l0JjyMLY1hJr4MF+tA+cO+Hkd+qEeaFqT+4iNcz GrqnuHy6o8PcpxxTncF8lLesXJuyWgDogyXTpexuNWRK/lSyk/XG1SG/KOmZUiRH3/g1 JZaKlRGIyzJFgUdAMqQqRLY8o2Wj+OmqiiwY/CCuTbBQxbsdsHcBpWs+sq/EmYlCRCN2 OnpQ== X-Gm-Message-State: AIVw1117zuY4tEF1MgQIPq7fSDKHGk2bCySxqsyP8DPaQF3/jOgCdO6m RyJERzrE11dkiDe+stbpJvm2p7t3zw== X-Received: by 10.237.37.140 with SMTP id x12mr1207158qtc.133.1500440052906; Tue, 18 Jul 2017 21:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.21 with HTTP; Tue, 18 Jul 2017 21:53:42 -0700 (PDT) In-Reply-To: <8557ED98-EC4F-4D16-9793-C87915B2AFAA@mnot.net> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <57B020F0-3FB8-423D-BDB6-4AF98BE9C4BA@mnot.net> <8557ED98-EC4F-4D16-9793-C87915B2AFAA@mnot.net> From: Ted Hardie Date: Wed, 19 Jul 2017 06:53:42 +0200 Message-ID: To: Mark Nottingham Cc: Dave Thaler , Alexey Melnikov , Adam Roach , Patrick McManus , "art@ietf.org" Content-Type: multipart/alternative; boundary="001a114211e25c3fab0554a46c71" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 04:54:16 -0000 --001a114211e25c3fab0554a46c71 Content-Type: text/plain; charset="UTF-8" I generally like this, but have one suggested adjustment On Tue, Jul 18, 2017 at 12:48 PM, Mark Nottingham w > For these reasons, it is preferable to use the message payload to indicate > the application in use, rather than the URL scheme. > > See {{?RFC7595}} for more information about minting new URL schemes. > > I think you cover what the issues are with using URI schemes, but the preference to use message payload appears pretty suddenly. There are trade-offs there too and some of the usual methods (dispatching mime type) have pretty big gotchas. I'd suggest you either elide this text or expand it. regards, Ted > > ~~~ > > Thoughts? > > > > On 16 Jul 2017, at 10:18 am, Dave Thaler wrote: > > > > 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 > > Cc: Adam Roach ; Alexey Melnikov < > alexey.melnikov@isode.com>; Patrick McManus ; > 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 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%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636357897782929506&sdata=hLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW > %2FkQiFIiWxFtT8%3D&reserved=0 > > > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > -- > Mark Nottingham https://www.mnot.net/ > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --001a114211e25c3fab0554a46c71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I generally like this, but have one suggested adjustment

On Tue, Jul 18,= 2017 at 12:48 PM, Mark Nottingham <mnot@mnot.net> w
=C2=A0<= /div>
For these reasons, it is preferable to use the message payload to indicate = the application in use, rather than the URL scheme.

See {{?RFC7595}} for more information about minting new URL schemes.


I think you cover what the issues are = with using URI schemes, but the preference to use message payload appears p= retty suddenly.=C2=A0 There are trade-offs there too and some of the usual = methods (dispatching mime type) have pretty big gotchas.=C2=A0 I'd sugg= est you either elide this text or expand it.

regards,
=
Ted
=C2=A0

~~~

Thoughts?


> On 16 Jul 2017, at 10:18 am, Dave Thaler <dthaler@microsoft.com> wrote:
>
> 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/ta= g/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@mn= ot.net]
> Sent: Sunday, July 16, 2017 10:16 AM
> To: Dave Thaler <dthaler@m= icrosoft.com>
> Cc: Adam Roach <adam@nostrum.co= m>; 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.=C2=A0 For exampl= e,
>>> Using other schemes to denote an application using HTTP makes = it more
>>> difficult to use with existing implementations (e.g., Web brow= sers),
>>> and is likely to fail to meet the requirements of [RFC7595]. >>
>> The "URI Schemes and Web Protocols" document Henry point= ed to argues
>> for separate URI schemes for different protocols (ftp, http, coap,= etc.), e.g. "G4. Serve using the protocol associated with the URI sch= eme".
>>
>> 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.=C2=A0 =C2=A0If an application defines highe= r 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 protoco= l or semantics.
>>
>> https://na01= .safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.w3<= br> >> .org%2FTR%2Fwebarch%2F%23uri-aliases&data=3D02%7C01%= 7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782919498= &sdata=3Dklbb40TomYZ216cxDZFHGBh1EiXMaVc2pmT4%2FjsXKv4%3D&= ;reserved=3D0 discusses multiple URIs for the same resource and has recomme= ndations 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<= br> >> concepts that are not specific to HTTP, since there may be differe= nt
>> URIs that differ by existing protocol (and URI scheme).=C2=A0 As s= uch,
>> 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 identif= y 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 wi= th H2 and now QUIC negotiation).
>
>
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://na01.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cf5e1aabcbc1b4a7a6fb708d4cc22eea2%7C72f98= 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357897782929506&sdat= a=3DhLIqYngKJ4NFkbB3zJl6Pf6jeL0dgW%2FkQiFIiWxFtT8%3D&reserved= =3D0
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/


_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--001a114211e25c3fab0554a46c71-- From nobody Fri Jul 21 09:30:16 2017 Return-Path: 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 223CC131891 for ; Fri, 21 Jul 2017 09:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.926 X-Spam-Level: X-Spam-Status: No, score=-3.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 gIDVWd9py0UB for ; Fri, 21 Jul 2017 09:30:13 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-oln040092065013.outbound.protection.outlook.com [40.92.65.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05236131771 for ; Fri, 21 Jul 2017 09:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PWjSgHqLQrcyGrFWsILi5EVxqieYb+Cgg1R0v+mBkps=; b=XoajYMyNAcNIyvo4LWMpgzkyAHdwhSFVXhz+vmXcJw0B0p8IbQ1mdZ1uWRQZEcjraa57xtLm9D37MyNgB5WqXgb8SDmbF9UnMlIpwAOGlxFOYWrJ/y0XT+4nZdsJfpJI6BvaOPlkzVAQ/4wPFeSn486Vr6ePUvDWER9uz8XbAY0asffS4VR1/xRQGkPbXaDMkcyScmkZX1qNNoNLo8CW8sSku2+s6DO8TV6gwIF7u+rsb+zq8FAxzLDzgRxznSpWwSHbRBsJsSKSvDxPx1YIt0mkPnhcNO6t3q4xZQVnAHHphqG75wb9W5x8K8y/bwwhMrvXIcFtunOrlP69+I9lbg== Received: from HE1EUR01FT016.eop-EUR01.prod.protection.outlook.com (10.152.0.54) by HE1EUR01HT202.eop-EUR01.prod.protection.outlook.com (10.152.0.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9; Fri, 21 Jul 2017 16:30:11 +0000 Received: from DB6PR0401MB2629.eurprd04.prod.outlook.com (10.152.0.54) by HE1EUR01FT016.mail.protection.outlook.com (10.152.0.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.9 via Frontend Transport; Fri, 21 Jul 2017 16:30:10 +0000 Received: from DB6PR0401MB2629.eurprd04.prod.outlook.com ([fe80::a4f4:8e6:b112:bac7]) by DB6PR0401MB2629.eurprd04.prod.outlook.com ([fe80::a4f4:8e6:b112:bac7%13]) with mapi id 15.01.1282.008; Fri, 21 Jul 2017 16:30:10 +0000 From: Antoine Germanos To: "art@ietf.org" Thread-Index: AQHTAj6eHTyeisboZ0akiWX38CL+Rw== Date: Fri, 21 Jul 2017 16:30:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:CBF5F86F1B4C29D0E2577004FE170332A7C6DF454C8CF2D7C2746FE32D0F9C4E; UpperCasedChecksum:7093871EAE471AD8B38480CE65FFC03CB80FE7FA6668A2826800B405B720C309; SizeAsReceived:6991; Count:42 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [hLCEr/2CLFM4XaMhygN0S2lxiIakD/tw] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR01HT202; 7:EsVlzLKPr+/SbAqqLqRqi2OnV1UHyvgJKOaPJxgk0DivvjVlw9CXesoi5Vm/xWygan8hEJ7MmX9OgixU/HES+zdhztdj+oQhmd47BKCpe1XmlR4l+oqOMbW+ETEJqXVMx8wienhe7dt6Wi6IHftT2MhdheBu46cJee3FPUa73w9L+LcOyiBhdqYXs+TSfU0EP+FY42goFo4g29s+4q7AVmj+kiVYPdSpHOBI3dd5S73Yr74tFqG3wSISeuhirinsBHYcaadqnHlta3aIi5R8aqw/9YLtuhR6PDxeG+J+gGtCw3WeSjmdOzknufLMsoQaAAK8X/DwW0YEEUIYSSWNqmh48zb9RGB0MkGw06EJpx0eRXCzh2FuKCie1NNH12k8M9I6gwS0cdb8HhtJtZCwvYpEMuUmtbG5BdHJDnhmZF5qGe6/SV9gqhdyyuVoc8EjUe4qx3q6S6KxfB6FPrhhpYgRrSuZf8s+cmLM3+9Mo4wModBFkhA/CwqoIFauqW9N0lAsdoj+cBwWQb1epXAC65Y9liSGI93ZPR1SjhxBwQj89xrN/xsJWVmSst2TrF9wUJRrjjP2boE+Txf/O9CkiiszDiQJRcKAVDDYUxjCwO47Zmtpy7aIo+9ygltcM4oGRNy4OPqvYJQirQPvHuAtV4M4+n7BeqAAwxLRM18V8TRsH5ITBu8pKGiwWdt8H2NDCXlXrsaMVMiuMouT9QoN7ysrk8SUWp0+e4Y7SghQpYxXgqkU/OsQLX/weDE/f64hkllidjfkn55AlDTVOHNLAQ== x-incomingheadercount: 42 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR01HT202; H:DB6PR0401MB2629.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 54b1e134-01a3-4e7e-96d5-08d4d055c1ad x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1EUR01HT202; x-ms-traffictypediagnostic: HE1EUR01HT202: x-exchange-antispam-report-test: UriScan:(111885846020525)(81439100147899)(25034144782879); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HE1EUR01HT202; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1EUR01HT202; x-forefront-prvs: 0375972289 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR0401MB2629C93D42E2904C4567579C99A40DB6PR0401MB2629_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 16:30:10.5946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT202 Archived-At: Subject: [art] (no subject) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 16:30:15 -0000 --_000_DB6PR0401MB2629C93D42E2904C4567579C99A40DB6PR0401MB2629_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Me. Antoine Germanos --_000_DB6PR0401MB2629C93D42E2904C4567579C99A40DB6PR0401MB2629_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Me. Antoine Germanos
--_000_DB6PR0401MB2629C93D42E2904C4567579C99A40DB6PR0401MB2629_-- From nobody Mon Jul 24 21:17:05 2017 Return-Path: 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 48E6A126E3A for ; Mon, 24 Jul 2017 21:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=cyuXv5/t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GSdGMmNZ 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 zwp8EvR9D15C for ; Mon, 24 Jul 2017 21:17:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE17120227 for ; Mon, 24 Jul 2017 21:17:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1B0E72068B; Tue, 25 Jul 2017 00:17:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 25 Jul 2017 00:17:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=r12Fifj27eeHS+5jkL 7hAe5rwXv/ndKEcZTw43xdncw=; b=cyuXv5/t5/utNCfKsxz8FwaF8XJN+gPlhw a61FbCd7ixrtI4RWnSzu5MJV4pdbhP+pybKexDMAVEiHlLjtVNfT5KmwB0Emyq0T AjH2N5T2uZBSO0bfz/azzwxJkSDtt5oTrXmp3mH6pBrU/3FMfJgBjkGW0JC9CTSB u+pCkbMxYyn/byp2JawBqnRmD1iKYahcQTDKDBRavlCBJz9BhJT0IChE9XW5Qt54 2AWz3+6IAua9prEwUOLP5Uqq/D9e0l6BxoTn03p6oLiGoZOxLMupTzorRssUyJvl ZsvyvqzibBGdAeCZRvpSdSAjOQMnqdG6eHlroRUensLzRKPyIgoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=r12Fifj27eeHS+5jkL7hAe5rwXv/ndKEcZTw43xdncw=; b=GSdGMmNZ cfzoipRRSa3W6+lIv2gvSVp0NKX7RbXJ+w5andPfzNsSU4yQ3/4tO+8kHQGCw2Gm QvUFdKNKcsmnu0CBIYLolhrejJFbKRfvXSjfpIo7DdBoQxjuYeLDvQduF+yYICRm 8o9LtkDZhSFSJCFqmm4DAX0gKIXfcZS84qIgKrmhq0c2KzD9Q9KhiVYj0hLoLjVr PW1AM9PNCC4/n6w87h6/U4dFZBpnwnw2qB/a3yUV9LIlrnq1904T74zRHwwK2/p6 NkH1ex/Lls8t8WcBilVAeB7xLzvuuwPP6zepat0mSQlr7Vl/pIBYkFTKi2II7BQn D+Y3MA37mbeIUw== X-ME-Sender: X-Sasl-enc: /sLc67JSy2/H2cjA28n5oew/jtdW82u/lhcKpI3bg46G 1500956220 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 3868F24130; Tue, 25 Jul 2017 00:16:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Tue, 25 Jul 2017 14:16:56 +1000 Cc: Dave Thaler , Alexey Melnikov , Adam Roach , Patrick McManus , "art@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3B02192D-E9C1-4617-B8AC-D9CE598EB515@mnot.net> References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <57B020F0-3FB8-423D-BDB6-4AF98BE9C4BA@mnot.net> <8557ED98-EC4F-4D16-9793-C87915B2AFAA@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 04:17:04 -0000 > On 19 Jul 2017, at 2:53 pm, Ted Hardie wrote: >=20 > I generally like this, but have one suggested adjustment >=20 > On Tue, Jul 18, 2017 at 12:48 PM, Mark Nottingham w > =20 >> For these reasons, it is preferable to use the message payload to = indicate the application in use, rather than the URL scheme. >>=20 >> See {{?RFC7595}} for more information about minting new URL schemes. >=20 > I think you cover what the issues are with using URI schemes, but the = preference to use message payload appears pretty suddenly. There are = trade-offs there too and some of the usual methods (dispatching mime = type) have pretty big gotchas. I'd suggest you either elide this text = or expand it. Yes; I think saying "preferable" here is too strong; it should just = refer to the (soon to be exist) section on defining payloads. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 25 07:56:12 2017 Return-Path: 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 8BCC6131CD0; Tue, 25 Jul 2017 07:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VaBW_ydqVpHQ; Tue, 25 Jul 2017 07:56:09 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1556F1317B1; Tue, 25 Jul 2017 07:56:09 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t201so48301896wmt.1; Tue, 25 Jul 2017 07:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=c3tcKycGl4IIMFMcnhbLx5i1fC/oUYQ5jB4ZY9U+fsg=; b=pIrcM7a0bizU+lRl77lr1wlsUus2wOcQarL9RJV80YafmT7uGjWRt+ogGlh+bUsbTj xLYl4FQPL6LfMvQowZRpScmK5SP4ZsN4wCbaWhBzJdjxtIw5Go9gZx/1K+ilKsMYtQWJ AyMthsTCU5S+ktog68w7mJCGSrNxzKE4jOl1X+Ue7Y/OJR5ocg8077kJ8NdM+sG28SMt C9uNU2hM5FP88GnfXwA5aU7glvxM5io0CI5BnH3mErKtX/dsdSjtmgSy4DxrNW2aMImt V98ojPBPuCJGcSGkJX8gfM0hNvWYqZKl77/dLEwAIufdgayHQg+lDVzkEqZZ26qqSxfT +K8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=c3tcKycGl4IIMFMcnhbLx5i1fC/oUYQ5jB4ZY9U+fsg=; b=RpOdeJ6pBB55hfe0npOdDydj8oePYdhjFrim9m0Qd/y2DbovTuJRXREopqSp0UICBI GWsjtZhCpUVdxMZxVTZwRVo/0f90SegKwGGODG6McrKrZ5e2ISaTfnStRQN593Jtiq7t kX/AffAsPqFfRnFNCo6+Li6YqW5ke3UL5YmmBLk2u3b/XW/KGdDoP2a7//GRL0y0pVys MISOZC6apuN5rwmmW4adInWnXJy6fKJB39AeMnLOocu0FLrx23atHJPzN1lIy/ILZOLB imcp3OfVTyDdYhN99a8+GCzJv36GTxYisvBIYCvy6XO2uYBl+qKjdY1WsNxRzc7fV1S2 XFdw== X-Gm-Message-State: AIVw113bZLLgKjfEI8rjJfELH7csTDphbtDT7swuZv9RPwB4U3nOojDR lNcCnrbbGuyLEOhgskuvqmnzge9EEW4u X-Received: by 10.28.33.67 with SMTP id h64mr7867435wmh.87.1500994567485; Tue, 25 Jul 2017 07:56:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.139 with HTTP; Tue, 25 Jul 2017 07:56:07 -0700 (PDT) From: tjw ietf Date: Tue, 25 Jul 2017 10:56:07 -0400 Message-ID: To: art@ietf.org Cc: "dnsop-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a113d78ba0158f60555258883" Archived-At: Subject: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 14:56:12 -0000 --001a113d78ba0158f60555258883 Content-Type: text/plain; charset="UTF-8" Application Folks We in DNSOP have a draft that is formalizing the use of _underscore labels in DNS, and the creation of a "DNS Global Underscore Scoped Entry Registry". We want the application folks to give us some comments, as we feel we are fairly close to Working Group Last Call. The draft is here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ and I'll be glad to shepherd feedback toward the author, or bring them here if it becomes quite contentious. thanks tim/suzanne DNSOP chairs --001a113d78ba0158f60555258883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Application Folks

We in = DNSOP have a draft that is formalizing the use of _underscore labels in DNS= , and the creation of a "DNS Global Underscore Scoped Entry Registry&q= uot;. =C2=A0 We want the application folks to give us some comments, as we = feel we are fairly =C2=A0close to Working Group Last Call.=C2=A0
=
The draft is here:


a= nd I'll be glad to shepherd feedback toward the author, or bring them h= ere if it becomes quite contentious.

thanks
<= div>
tim/suzanne
DNSOP chairs


--001a113d78ba0158f60555258883-- From nobody Wed Jul 26 22:03:58 2017 Return-Path: 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 80E6E129AD2 for ; Wed, 26 Jul 2017 22:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0rmvBu-Wb2z2 for ; Wed, 26 Jul 2017 22:03:56 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F58127868 for ; Wed, 26 Jul 2017 22:03:55 -0700 (PDT) Received: (qmail 19085 invoked from network); 27 Jul 2017 05:03:54 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Jul 2017 05:03:54 -0000 Date: 27 Jul 2017 05:03:32 -0000 Message-ID: <20170727050332.1445.qmail@ary.lan> From: "John Levine" To: art@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 05:03:57 -0000 In article you write: >We in DNSOP have a draft that is formalizing the use of _underscore labels >in DNS, and the creation of a "DNS Global Underscore Scoped Entry >Registry". We want the application folks to give us some comments, as we >feel we are fairly close to Working Group Last Call. When I last talked to Dave about this, we had a problem with URI records. They can be named _service._tranport.whatever, just like SRV, but they can also be named with enumservice (RFC 3761 and 6117) names, _subtype._type.whatever. There are about 24 type names in the enumservice registry, none of which currently collide the transport names. To prevent collisions in the future, we need somehow to cross-reference the port and service name registries so any attempt to register a name in one checks for an entry in the other. I asked IANA and as I recall Michelle said they can do that, but Dave was worried about the long term viability of a special case in the registration process. We also noted that the number of URI records in the wild is still small, so another possibility would be to change RFC 7553 so enumservice URIs are _subtype._type._enum.whatever, and then reserve "enum" as a transport name. R's, John From nobody Fri Jul 28 07:56:33 2017 Return-Path: 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 77230131E86; Fri, 28 Jul 2017 07:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fJVOwgxk4EV2; Fri, 28 Jul 2017 07:56:30 -0700 (PDT) Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CC1131D1F; Fri, 28 Jul 2017 07:56:30 -0700 (PDT) Received: from smtp1.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B90375C2A; Fri, 28 Jul 2017 10:56:27 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4469D5DE9; Fri, 28 Jul 2017 10:56:27 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 28 Jul 2017 10:56:27 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 28 Jul 2017 08:56:25 -0600 Cc: art@ietf.org, "dnsop-chairs@ietf.org" , dnsops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <43437154-AD8C-4041-86B7-A33F8A5F15CC@iii.ca> References: To: tjw ietf X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:56:32 -0000 The IANA registration policy of "or are documented by a specification = published by another standards organization" seems very undefined to me and hard for IANA = to execute. Could you give specific advice on what is a standards = organization?=20 I have seen previous efforts to to this and eventually it comes up = looking more or less the same as our usual "specification required". > On Jul 25, 2017, at 8:56 AM, tjw ietf wrote: >=20 >=20 > Application Folks >=20 > We in DNSOP have a draft that is formalizing the use of _underscore = labels in DNS, and the creation of a "DNS Global Underscore Scoped Entry = Registry". We want the application folks to give us some comments, as = we feel we are fairly close to Working Group Last Call.=20 >=20 > The draft is here: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ >=20 > and I'll be glad to shepherd feedback toward the author, or bring them = here if it becomes quite contentious. >=20 > thanks >=20 > tim/suzanne > DNSOP chairs >=20 >=20 >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Fri Jul 28 08:54:54 2017 Return-Path: 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 884EC13213E; Fri, 28 Jul 2017 08:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 vXstzP0DvCAd; Fri, 28 Jul 2017 08:54:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0631D131CA2; Fri, 28 Jul 2017 08:54:49 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6SFslj7095153 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Jul 2017 10:54:48 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: tjw ietf , art@ietf.org Cc: "dnsop-chairs@ietf.org" References: From: Adam Roach Message-ID: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> Date: Fri, 28 Jul 2017 10:54:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A21C64238F05230B5211FCFF" Content-Language: en-US Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:54:53 -0000 This is a multi-part message in MIME format. --------------A21C64238F05230B5211FCFF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [I sent this directly to the document-related personnel a few days ago, but I'm re-sending it to the ART list as I think it could benefit from additional input from the ART community.] I have some tiny editorial comments, but I'm leaving them aside for now to bring up what appears to be a major structural defect in the document. The document is pretty clear about its intended scope, containing statements like: > Only the right-most names are registered in the IANA Underscore table and > The current definition of a global underscore registry attends only to > the "upper-level" names used for these RRs, that is the "_proto" names. But then the table includes things like "_ldap" and "_certificates". The only SRV records for (e.g.) LDAP will look like "_ldap._tcp...", which (according to the cited statements) would mean that "_ldap" doesn't get an entry in this table: it is not the "upper-level" name, and it is not the "right-most" name. It is clearly under "_tcp". On a casual check, the vast majority of the SRV records in the table shouldn't be in here by the rules I cite above. So, what I *think* this document probably wants to do is define a top-level registry containing things like "_tcp", "_udp", and "_domainkey", and then create two additional sub-tables (one for "_tcp" and one for "_udp"), which register all the "_service" types that can appear under these two "_proto" types (e.g., "_sip", "_certificates", "_xmpp-client", "_crls"). You might want to also add a table for "_sctp", although it would appear to only have two entries at the moment ("_diameter" and "_diameters" -- cf RFC6733). The alternative approach to making the document internally consistent would be to remove almost all of the SRV entries presently in Table 1, and leave them to fend for themselves (which would make this document a kind of weak half-measure). /a On 7/25/17 9:56 AM, tjw ietf wrote: > > Application Folks > > We in DNSOP have a draft that is formalizing the use of _underscore > labels in DNS, and the creation of a "DNS Global Underscore Scoped > Entry Registry". We want the application folks to give us some > comments, as we feel we are fairly close to Working Group Last Call. > > The draft is here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ > > and I'll be glad to shepherd feedback toward the author, or bring them > here if it becomes quite contentious. > > thanks > > tim/suzanne > DNSOP chairs > > > > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art --------------A21C64238F05230B5211FCFF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[I sent this directly to the document-related personnel a few days ago, but I'm re-sending it to the ART list as I think it could benefit from additional input from the ART community.]

I have some tiny editorial comments, but I'm leaving them aside for now to bring up what appears to be a major structural defect in the document.

The document is pretty clear about its intended scope, containing statements like:

Only the right-most names are registered in the IANA Underscore table

and

The current definition of a global underscore registry attends only to the "upper-level" names used for these RRs, that is the "_proto" names.

But then the table includes things like "_ldap" and "_certificates". The only SRV records for (e.g.) LDAP will look like "_ldap._tcp...", which (according to the cited statements) would mean that "_ldap" doesn't get an entry in this table: it is not the "upper-level" name, and it is not the "right-most" name. It is clearly under "_tcp". On a casual check, the vast majority of the SRV records in the table shouldn't be in here by the rules I cite above.

So, what I *think* this document probably wants to do is define a top-level registry containing things like "_tcp", "_udp", and "_domainkey", and then create two additional sub-tables (one for "_tcp" and one for "_udp"), which register all the "_service" types that can appear under these two "_proto" types (e.g., "_sip", "_certificates", "_xmpp-client", "_crls"). You might want to also add a table for "_sctp", although it would appear to only have two entries at the moment ("_diameter" and "_diameters" -- cf RFC6733).

The alternative approach to making the document internally consistent would be to remove almost all of the SRV entries presently in Table 1, and leave them to fend for themselves (which would make this document a kind of weak half-measure).

/a


On 7/25/17 9:56 AM, tjw ietf wrote:

Application Folks

We in DNSOP have a draft that is formalizing the use of _underscore labels in DNS, and the creation of a "DNS Global Underscore Scoped Entry Registry".   We want the application folks to give us some comments, as we feel we are fairly  close to Working Group Last Call. 

The draft is here:


and I'll be glad to shepherd feedback toward the author, or bring them here if it becomes quite contentious.

thanks

tim/suzanne
DNSOP chairs





_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--------------A21C64238F05230B5211FCFF-- From nobody Fri Jul 28 09:13:10 2017 Return-Path: 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 990841276AF; Fri, 28 Jul 2017 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 FUAauQlDvItS; Fri, 28 Jul 2017 09:13:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6634412EC3F; Fri, 28 Jul 2017 09:13:04 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1db7sp-0006El-73; Fri, 28 Jul 2017 12:12:59 -0400 Date: Fri, 28 Jul 2017 12:12:53 -0400 From: John C Klensin To: Cullen Jennings , tjw ietf cc: art@ietf.org, dnsop-chairs@ietf.org, dnsops@ietf.org Message-ID: <27C709A8477170E52D8F48E1@PSB> In-Reply-To: <43437154-AD8C-4041-86B7-A33F8A5F15CC@iii.ca> References: <43437154-AD8C-4041-86B7-A33F8A5F15CC@iii.ca> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:13:06 -0000 Cullen, IIR, we introduced the concept of a "recognized standards organization" (note "recognized", which is important) with media types, deliberately left it vague, and did so for one primary reason. At least in the media type case, there were issues of probably-legitimate registrations in which it was clear that the IETF had absolutely no expertise as to the substance or subject matter of such a request. As an extreme example, if an international body responsible for chemical names or plant taxonomy wanted to establish a media type to be consistent with the terminology rules they were setting, having amateurs (at best) in the IETF try to second-guess their decisions was a rather strange idea and probably an unprofessional and insulting one. Sadly, experience indicates that we might try, possibly proving the value of adages such as a little knowledge being a dangerous thing. Our (quite explicit) assumption was that the IESG would need to figure out who was and was not a recognized SDO. More on that below. An important part of the idea is that "recognized SDO" was an alternative to another, IETF-centric process. While I don't think we ever documented it (perhaps deliberately --- I don't remember), the IESG can always say "no" on the basis that the IETF is fully qualified to evaluate a particular request or family of requests and should do so. At the same time, we understood and recognized that, if some standards body out there was well-established and more recognized in it own field and area of expertise, IETF decisions that were inconsistent with theirs were likely to be ignored or, worse, lead to inconsistent and competing standards used by different sub-communities. All a matter of tradeoffs. Whether the IESG can get them right or not, we don't have any body or mechanism that would be likely to consistently do much better. Whether we got the principle and its expression right is another question -- it is a bit of a subjective notion and the IETF and IANA should probably have some input into whether the request/application conforms to whatever we have decided is needed for a request to be complete. We also concluded, after considerable discussion, that what was and was not to be "recognized" should be left to IESG discretion on a case-by-case basis rather than descending into the rathole of trying to lay out criteria and cover even most of the edge cases. Perhaps not a perfect solution, but we had the expectation that the IESG could do, or arrange to have done, a certain amount of due diligence and make an acceptable (and conservative) decision. One of the important properties of most identifiers or type encodings is stability and we were also aware of the potential for DoS attacks in this area. We thought it was reasonable to trust the IESG to distinguish between established bodies that were likely to be around and ad hoc arrangements and between legitimate bodies and, e.g., the Fraternal Order of Trolls or other potentially-hostile parties and even to sort out situations in which there were multiple claimants to be the recognized international standards body in some particular area. It did not appear to us that debating those issues on the IETF list would be helpful, especially given that possibility of DoS attacks and the ease with which conversations on the IETF list in which there is little expertise but many opinions converse on N/S ratios with near-infinite values. All of these differs from "specification required" because it is expected that some authoritative and consensus body take responsibility for (and be accountable for) the substantive content of that specification. If it isn't working that way, that is a problem with the IESG's implementation of the principle, not the principle itself. Whether that principle, and rules derived from it, are appropriate for a particular case is another issue. We used it very recently in RFC 8141 and I don't recall significant concerns. I don't have an opinion as to whether it is appropriate for this particular draft, just that we should not abandon the concept of recognizing work by other standards bodies in their area of expertise because of a perception that it doesn't work. It has worked in a number of important cases and continues to do so. john --On Friday, July 28, 2017 08:56 -0600 Cullen Jennings wrote: > The IANA registration policy of "or are documented by a > specification published by another standards organization" > seems very undefined to me and hard for IANA to execute. Could > you give specific advice on what is a standards organization? > > I have seen previous efforts to to this and eventually it > comes up looking more or less the same as our usual > "specification required". From nobody Fri Jul 28 09:18:11 2017 Return-Path: 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 B63EC131CC0; Fri, 28 Jul 2017 09:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 Cdmg5aA94nVq; Fri, 28 Jul 2017 09:18:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F67131CBF; Fri, 28 Jul 2017 09:18:09 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6SGI5hW099021 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Jul 2017 11:18:07 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: John C Klensin , Cullen Jennings , tjw ietf Cc: art@ietf.org, dnsop-chairs@ietf.org, dnsops@ietf.org References: <43437154-AD8C-4041-86B7-A33F8A5F15CC@iii.ca> <27C709A8477170E52D8F48E1@PSB> From: Adam Roach Message-ID: <4a8635c1-c89b-7cb9-31db-e069d54980f8@nostrum.com> Date: Fri, 28 Jul 2017 11:18:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <27C709A8477170E52D8F48E1@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:18:11 -0000 On 7/28/17 11:12 AM, John C Klensin wrote: > I don't have an opinion as to whether it is > appropriate for this particular draft, just that we should not > abandon the concept of recognizing work by other standards > bodies in their area of expertise because of a perception that > it doesn't work. It has worked in a number of important cases > and continues to do so. This would imply that an update to RFC8126 is in order. /a From nobody Fri Jul 28 11:30:27 2017 Return-Path: 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 7F7FB132073 for ; Fri, 28 Jul 2017 11:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 29gMM6IR63JO for ; Fri, 28 Jul 2017 11:30:23 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A76A13206C for ; Fri, 28 Jul 2017 11:30:23 -0700 (PDT) Received: (qmail 90038 invoked from network); 28 Jul 2017 18:30:22 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 28 Jul 2017 18:30:22 -0000 Date: 28 Jul 2017 18:30:00 -0000 Message-ID: <20170728183000.26378.qmail@ary.lan> From: "John Levine" To: art@ietf.org Cc: adam@nostrum.com In-Reply-To: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 18:30:26 -0000 In article <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> you write: >So, what I *think* this document probably wants to do is define a >top-level registry containing things like "_tcp", "_udp", and >"_domainkey", ... Right, that's part of what this registry is. The protocol names were casually mentioned in RFC 2782, and a few more have been added along the way, but have never been put in a registry other than implicitly in a column in the service name registry. I suggested a while ago that the table needs another column to say what kinds of subnames are allowed if it's names out of another registry. > ... and then create two additional sub-tables (one for "_tcp" >and one for "_udp"), which register all the "_service" types that can >appear under these two "_proto" types Please, no. That registry has existed for decades and has upward of 10,000 entries. See RFC 6335 and: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml I agree that service names that appear in the registry do not belong in attrleaf. R's, John From nobody Fri Jul 28 13:37:41 2017 Return-Path: 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 045AC129B2A for ; Fri, 28 Jul 2017 13:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 a7j2OKUJjo1c for ; Fri, 28 Jul 2017 13:37:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B76129562 for ; Fri, 28 Jul 2017 13:37:37 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6SKbZSO040907 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Jul 2017 15:37:36 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: John Levine , art@ietf.org References: <20170728183000.26378.qmail@ary.lan> From: Adam Roach Message-ID: Date: Fri, 28 Jul 2017 15:37:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170728183000.26378.qmail@ary.lan> Content-Type: multipart/alternative; boundary="------------858F402D4BA10EE08DE6AC77" Content-Language: en-US Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 20:37:40 -0000 This is a multi-part message in MIME format. --------------858F402D4BA10EE08DE6AC77 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/28/17 1:30 PM, John Levine wrote: >> ... and then create two additional sub-tables (one for "_tcp" >> and one for "_udp"), which register all the "_service" types that can >> appear under these two "_proto" types > Please, no. That registry has existed for decades and has upward of > 10,000 entries. See RFC 6335 and: > > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > I agree that service names that appear in the registry do not belong in attrleaf. Ah, yes. I'd missed that the intention of RFC2782 was to allow SRV records to be instantly usable for all registered services, rather than having each service defining specific additional procedures for SRV resolution. (For example, RFC3263 defines some specific rules around handling priorities across different transports, which goes beyond the handling described by RFC2782). On review, your interpretation appears to be correct. In that case, it would appear that the main action here would be to clean up the SRV entries in Table 1 -- by my understanding, the way RFC2782 is written, the only registered SRV entries in the registry this document establishes should consist of some strict subset of . /a --------------858F402D4BA10EE08DE6AC77 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 7/28/17 1:30 PM, John Levine wrote:
... and then create two additional sub-tables (one for "_tcp" 
and one for "_udp"), which register all the "_service" types that can 
appear under these two "_proto" types 

Please, no.  That registry has existed for decades and has upward of
10,000 entries.  See RFC 6335 and:

 https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

I agree that service names that appear in the registry do not belong in attrleaf.


Ah, yes. I'd missed that the intention of RFC2782 was to allow SRV records to be instantly usable for all registered services, rather than having each service defining specific additional procedures for SRV resolution. (For example, RFC3263 defines some specific rules around handling priorities across different transports, which goes beyond the handling described by RFC2782). On review, your interpretation appears to be correct.

In that case, it would appear that the main action here would be to clean up the SRV entries in Table 1 -- by my understanding, the way RFC2782 is written, the only registered SRV entries in the registry this document establishes should consist of some strict subset of <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml>.

/a

--------------858F402D4BA10EE08DE6AC77-- From nobody Sat Jul 29 07:40:07 2017 Return-Path: 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 19DB5127B73 for ; Sat, 29 Jul 2017 07:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=MRncuj67; dkim=pass (1536-bit key) header.d=taugh.com header.b=dWaRk4/u 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 D1TiMT0DaXj2 for ; Sat, 29 Jul 2017 07:40:03 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D121317C1 for ; Sat, 29 Jul 2017 07:40:03 -0700 (PDT) Received: (qmail 99768 invoked from network); 29 Jul 2017 14:40:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=185b6.597c9e42.k1707; bh=YkiYyQg/BTfsXOLi3EoKt5UARnLlMQHrgvY7tCVIvFA=; b=MRncuj67UPNrzW9kBsuO+Py6iIlbFY15oj2rxz0o0lbLm6mjuayGVYO8yyZuaG/KyR7k5ZJxbOI0npMIyvcnSuYTgo/a6j5o300vOeN8Cg1lB9BFnLnzdrytEoBJgtJCQybfFsNNNG8n0nTMbtdqvGrG5XrMvlNOqh9rs3TDjep9oGj9C+D07BBA3JyRiVdFD9ugA6htCWpEoNU3D/ShPpf5xE0nPsFf3NabPM8++uz6312zm5lCJD1djIJJwfR9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=185b6.597c9e42.k1707; bh=YkiYyQg/BTfsXOLi3EoKt5UARnLlMQHrgvY7tCVIvFA=; b=dWaRk4/uKQwFceYK+Mm8m7NITMN5wMq77OhY0f/Zcf5Qpu7nt0mIwNcGUUsid/x+FUyUYIVcyo102Dm1W5nRr0++c/99WqMVL7nN6lM5Ay286Y4QNle4A11EAwZn4xzqIGFsJ3CjalzYwdGcPWFa1O0xBDVqXgOhoFZF07c6PXL1xnK9ejkumx7YTChcJXciY4Af2NLXnBospW8HIRQA0PiX0/X9s009p74te+par1So5nQ2ocdhm0nDfJv2IGEQ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 29 Jul 2017 14:40:01 -0000 Date: 29 Jul 2017 10:40:01 -0400 Message-ID: From: "John R Levine" To: "Adam Roach" Cc: art@ietf.org In-Reply-To: References: <20170728183000.26378.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 14:40:05 -0000 On Fri, 28 Jul 2017, Adam Roach wrote: > In that case, it would appear that the main action here would be to clean up > the SRV entries in Table 1 -- by my understanding, the way RFC2782 is > written, the only registered SRV entries in the registry this document > establishes should consist of some strict subset of > . Right, the protocols that appear in the proto column of the services table, but none of the services. This should make the draft considerably shorter. There's still the URI enumservice issue. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jul 30 21:09:18 2017 Return-Path: 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 52CE6131BC8 for ; Sun, 30 Jul 2017 21:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gxZwApHaD8Ij for ; Sun, 30 Jul 2017 21:09:15 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60908131D6B for ; Sun, 30 Jul 2017 21:09:15 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 5C28524AE10; Mon, 31 Jul 2017 04:07:44 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4F7BD160048; Mon, 31 Jul 2017 04:07:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3406216004F; Mon, 31 Jul 2017 04:07:49 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UcUvJoU4nDMD; Mon, 31 Jul 2017 04:07:49 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CBDE6160048; Mon, 31 Jul 2017 04:07:48 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 57C0C806E75D; Mon, 31 Jul 2017 14:07:45 +1000 (AEST) To: Adam Roach Cc: John Levine , art@ietf.org From: Mark Andrews References: <20170728183000.26378.qmail@ary.lan> In-reply-to: Your message of "Fri, 28 Jul 2017 15:37:29 -0500." Date: Mon, 31 Jul 2017 14:07:45 +1000 Message-Id: <20170731040745.57C0C806E75D@rock.dv.isc.org> Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 04:09:17 -0000 In message , Adam Roach writes: > > On 7/28/17 1:30 PM, John Levine wrote: > >> ... and then create two additional sub-tables (one for "_tcp" > >> and one for "_udp"), which register all the "_service" types that can > >> appear under these two "_proto" types > > Please, no. That registry has existed for decades and has upward of > > 10,000 entries. See RFC 6335 and: > > > > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numb > ers.xhtml > > > > I agree that service names that appear in the registry do not belong in attrleaf. > > > Ah, yes. I'd missed that the intention of RFC2782 was to allow SRV > records to be instantly usable for all registered services, rather than > having each service defining specific additional procedures for SRV > resolution. (For example, RFC3263 defines some specific rules around > handling priorities across different transports, which goes beyond the > handling described by RFC2782). On review, your interpretation appears > to be correct. > > In that case, it would appear that the main action here would be to > clean up the SRV entries in Table 1 -- by my understanding, the way > RFC2782 is written, the only registered SRV entries in the registry this > document establishes should consist of some strict subset of > . > > /a SRV records are ONLY to be use for protocols that specify that they be looked up. There are generic proceedures for how to select a server given that SRV records are permitted in the first place. RFC2782 Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification. This was written this way so that existing protocols like SMTP, DNS, and HTTP didn't just suddenly sprout SRV "support". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Jul 30 21:17:56 2017 Return-Path: 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 4FD6E131DA1; Sun, 30 Jul 2017 21:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=arcanedomain.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 HcAYwbginZuo; Sun, 30 Jul 2017 21:17:53 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D505D131D7F; Sun, 30 Jul 2017 21:17:53 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 36B4A5BE06D; Sun, 30 Jul 2017 21:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=QodkO/7zh0jVZN3+4PRJtfsJVT0=; b=kfahYwjBwW0 QoW8ou19yOvPz6Lq0YDtgY9Icz0ovYC9Zp6MEj8oze2BNOdp3OFdgH2vAEhEg0ks YwxHcRcNC2WqARizOVk80aLJtx1ZcrqzhPAWJAj51aEKmlPBXJysjqicQj7fm9tj 2YLsjcqnXX97DTUU8Uoa2abH1yJyUbPM= Received: from [192.168.1.101] (216-15-112-214.s4564.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com [216.15.112.214]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 0C7F65BE06B; Sun, 30 Jul 2017 21:17:51 -0700 (PDT) To: Mark Nottingham , "Henry S. Thompson" Cc: Dave Thaler , "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" , Daniel Appelquist , Dan Connolly References: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> From: Noah Mendelsohn Message-ID: Date: Mon, 31 Jul 2017 00:17:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] [dispatch] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 04:17:55 -0000 On 7/10/2017 5:30 AM, Mark Nottingham wrote: > Hi Henry, > > Thanks for that. Looping in Noah and Dan (sorry for including you on a list reply!). > > Why was the document left in draft state? Does the current TAG have any interest in progressing a finding like this one? > > Cheers, > A little history on the drafts at: https://www.w3.org/2001/tag/doc/SchemeProtocols.html There were two of these drafts, the first one dated 16 June 2005 and the second one 21 November 2005. As a newly appointed member of the TAG at the time I found the relationship between URIs to be interesting, somewhat confusing, and as far as I could tell not completely documented. I did not at the time consider myself expert in the nuances, so I decided to write a draft (June version) that set out how I assumed things worked. My assumption was that the relationship was in fact clear. My hope was to set down the rules clearly, and in the process to learn them myself. Discussion at the subsequent TAG meeting made clear that several members had serious concerns with some of what was said, so I wrote the November draft to try to get closer to "the truth" and to capture the advice I'd received. Discussion of the November draft also resulted in strong concerns being expressed, some of which seemed to contradict what I had been advised in June. On a break at the meeting I expressed my newcomer's confusion to someone (probably Dan Connolly) who said: "well, you know that TAG members XXXX, YYYY and ZZZZ famously disagree about this subject?" No, I hadn't known. I thought all Web experts must have agreed on something so fundamental. One aspect of the disagreement was whether schemes and protocols should always be 1-to-1 (modulo incremental versioning of the protocol), but there were other disagreements as well. My perception (not necessarily correct) was that Tim BL preferred that there be (nearly) no new schemes introduced, with use of http/https schemes encouraged wherever possible. The reason, I believe, was so that resourcews could have stable names that wouldn't change even if the protocols used for deployment evolved over time. New protocols would be introduced either as HTTP X.Y, or activated by retrieval via traditional HTTP of a document that would as a consequence of its Content-type and contents lead to further interactions using some new protocol. So, video resources would be named something like http://example.com/myvideo. If some non-HTTP peer-to-peer protocol were to be used, there would be an initial traditional HTTP interaction; the video server would return a document of a Content-type that could convey the instruction to "start using P2P to get the video". In any case, the creation of and confusing debate about the draft TAG finding convinced me that (1) what I had assumed to be a straightforward aspect of the Web that merely needed better documention was in fact subtle and a source of disagreement even among the best experts and (2) that I as a new TAG member who had not been part of the prior debates was not the right person to drive the discussion to consensus. I therefore abandoned work on the drafts and as I recall the TAG did not revisit the topic in its general form during my time in the group. Maybe or maybe not there is useful discussion in either of the drafts, but there was no TAG consensus on either. Furthermore it's not clear that there was more agreement with the 2nd draft than with the first. I hope this is helpful. Noah From nobody Mon Jul 31 08:34:21 2017 Return-Path: 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 BFA0613253D; Mon, 31 Jul 2017 08:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=arcanedomain.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 PkDa3aNe6DH9; Mon, 31 Jul 2017 08:34:18 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45401132522; Mon, 31 Jul 2017 08:34:17 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id C7B425BE06D; Mon, 31 Jul 2017 08:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= subject:from:to:cc:references:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=/LvZ9Z5ia3qj0kKEb2yQlBE4pxk=; b=WYzXASju+1n yVJqOBavNwWMPI4lSQvL9PNgd7riSqEW4izbErF4eWrItdRcf2Jo7PBlWPSJc6oe veDOyQYIMbxY6KfIS+ixNezW7aFQmsLst5R9tyKvgKc0O/YpTLwFH/4xplEA0mRl FSWuLKWPsPd8EahoaShU6ph/yT/g9TPw= Received: from [192.168.1.101] (216-15-112-214.s4564.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com [216.15.112.214]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id DF6285BE066; Mon, 31 Jul 2017 08:34:15 -0700 (PDT) From: Noah Mendelsohn To: Mark Nottingham , "Henry S. Thompson" Cc: Dave Thaler , "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" , Daniel Appelquist , Dan Connolly References: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> Message-ID: Date: Mon, 31 Jul 2017 11:34:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] [dispatch] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 15:34:20 -0000 On 7/31/2017 12:17 AM, Noah Mendelsohn wrote: > As a newly appointed member of the TAG at the time I found the relationship > between URIs to be interesting Typo. I meant: "As a newly appointed member of the TAG at the time I found the relationship between URI schemes and Web protocols to be interesting" Noah From nobody Mon Jul 31 17:15:41 2017 Return-Path: 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 E7603131C99 for ; Mon, 31 Jul 2017 17:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DzPGZ39n; dkim=pass (1536-bit key) header.d=taugh.com header.b=Ir4srPzx 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 pXE-11iKfg1B for ; Mon, 31 Jul 2017 17:15:38 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AFF120724 for ; Mon, 31 Jul 2017 17:15:38 -0700 (PDT) Received: (qmail 2874 invoked from network); 1 Aug 2017 00:15:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b38.597fc829.k1707; bh=gPaVNc8AMrAYOcsrvyNyrFU8NFXpP/Fm+Fcc16++6QE=; b=DzPGZ39nf9zp5y+nd+UEPXEjxSXW+7By5v0w25Q7R1dusUZ9CJXQAg6PWanXYQS4O3SV3mbMeymTqV95JfTRMCXKfzxX+6SaJIUccq3UocXB57ChDUe+at7PdWdZ0DdQCknz8Eau0+67MTlAOX2ViV4t8nTfvt1SuihoYCkN55Ni2oQSaRbV85KeogHYEd5M8DwJOWRVt6HoL63rdo8WRABXaI5WrIScOX64SRuFkhdb9B6h441jUaWUBIyAzNov DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b38.597fc829.k1707; bh=gPaVNc8AMrAYOcsrvyNyrFU8NFXpP/Fm+Fcc16++6QE=; b=Ir4srPzxG4wiW23AW9qrRBGl0VF7SWbw30UvQMC8n9w3VYkKOUFCHyBoDiAFu+qKXB+FBawAEpa6jnu61T221V30hHLpAR9u5BZxAs/M9MZq1L2LhnFoVIZWIq3Plb/9QcCEYXmBA6E2WC+oEjXdDoej6br7KKYMk1O0w66DZZ8YEfDRDZoqoEbcmZn1KAfepil8c5a42DdFSCYdU7II02+XC9nBBdXmRnVJon8duo0EueuPzE76SN26HQSl/3Oa Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 01 Aug 2017 00:15:37 -0000 Date: 31 Jul 2017 20:15:36 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: art@ietf.org In-Reply-To: <20170731040745.57C0C806E75D@rock.dv.isc.org> References: <20170728183000.26378.qmail@ary.lan> <20170731040745.57C0C806E75D@rock.dv.isc.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 00:15:40 -0000 On Mon, 31 Jul 2017, Mark Andrews wrote: > SRV records are ONLY to be use for protocols that specify that they > be looked up. There are generic proceedures for how to select a > server given that SRV records are permitted in the first place. Sorry, but I don't see what your point is. I think that Adam and I agree that none of the services in the port/service registry should be listed here, and only the transports that are used for registered services. We are not saying anything about what services use SRV. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly