From nobody Mon Jan 4 17:43:39 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9CA1ACE3E for ; Mon, 4 Jan 2016 17:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 Jx-1jXRqXN1s for ; Mon, 4 Jan 2016 17:43:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A41751ACE3B for ; Mon, 4 Jan 2016 17:43:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 88C5A18000C; Mon, 4 Jan 2016 17:42:45 -0800 (PST) To: ht@inf.ed.ac.uk, chris@w3.org, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160105014245.88C5A18000C@rfc-editor.org> Date: Mon, 4 Jan 2016 17:42:45 -0800 (PST) Archived-At: Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC7303 (4578) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:43:38 -0000 The following errata report has been submitted for RFC7303, "XML Media Types". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7303&eid=4578 -------------------------------------- Type: Technical Reported by: Martin Dürst Section: 4.2 Original Text ------------- In addition to the changes described above, the change controller has been changed to be the World Wide Web Consortium (W3C). Corrected Text -------------- In addition to the changes described above, the change controller for the '+xml' Structured Syntax Suffix has been changed to be the World Wide Web Consortium (W3C). Notes ----- At https://mailarchive.ietf.org/arch/msg/lager/hRVFkda9GKFTYeBcmK2Ge9OdvoA, the sentence was misread to apply to all registrations with a +xml suffix, rather than only to the registration of the suffix itself. 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7303 (draft-ietf-appsawg-xml-mediatypes-10) -------------------------------------- Title : XML Media Types Publication Date : July 2014 Author(s) : H. Thompson, C. Lilley Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Jan 5 04:02:39 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE991B2B05 for ; Tue, 5 Jan 2016 04:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WRLDWD=2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eevks243XAQh for ; Tue, 5 Jan 2016 04:02:34 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26AC1B2B00 for ; Tue, 5 Jan 2016 04:02:34 -0800 (PST) Received: from ppp-94-67-39-236.home.otenet.gr ([94.67.39.236] helo=[192.168.1.91]) by raoul.w3.org with esmtpsa (TLS1.1:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aGQJi-000ENd-Is; Tue, 05 Jan 2016 12:02:22 +0000 Date: Tue, 5 Jan 2016 14:02:17 +0200 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1707442344.20160105140217@w3.org> To: RFC Errata System , ht@inf.ed.ac.uk, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com In-Reply-To: <20160105014245.88C5A18000C@rfc-editor.org> References: <20160105014245.88C5A18000C@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7303 (4578) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 12:02:39 -0000 Hello RFC Errara System, Tuesday, January 5, 2016, 2:42:45 AM, you wrote: > The following errata report has been submitted for RFC7303, > "XML Media Types". I believe that the original text is correct, because W3C is change controller not only of the +xml suffic but also of application/xml and related types. Henry, do you agree? > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7303&eid=3D4578 > -------------------------------------- > Type: Technical > Reported by: Martin D=C3=BCrst > Section: 4.2 > Original Text > ------------- > In addition to the changes described above, the change controller has > been changed to be the World Wide Web Consortium (W3C). > Corrected Text > -------------- > In addition to the changes described above, the change controller for > the '+xml' Structured Syntax Suffix has been changed to be the World > Wide Web Consortium (W3C). > Notes > ----- > At > https://mailarchive.ietf.org/arch/msg/lager/hRVFkda9GKFTYeBcmK2Ge9OdvoA, > the sentence was misread to apply to all registrations with a +xml > suffix, rather than only to the registration of the suffix itself. > 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 (IESG) > can log in to change the status and edit the report, if necessary.=20 > -------------------------------------- > RFC7303 (draft-ietf-appsawg-xml-mediatypes-10) > -------------------------------------- > Title : XML Media Types > Publication Date : July 2014 > Author(s) : H. Thompson, C. Lilley > Category : PROPOSED STANDARD > Source : Applications Area Working Group APP > Area : Applications > Stream : IETF > Verifying Party : IESG --=20 Best regards, Chris Lilley Technical Director, W3C Interaction Domain From nobody Tue Jan 5 05:14:45 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DE71A6FEB for ; Tue, 5 Jan 2016 05:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 KJM4P4-eW5o7 for ; Tue, 5 Jan 2016 05:14:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37BC81A6FE3 for ; Tue, 5 Jan 2016 05:14:42 -0800 (PST) Received: from [192.168.1.158] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MEnX8-1aQx9P178s-00FzDT; Tue, 05 Jan 2016 14:14:33 +0100 To: Chris Lilley , RFC Errata System , ht@inf.ed.ac.uk, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com References: <20160105014245.88C5A18000C@rfc-editor.org> <1707442344.20160105140217@w3.org> From: Julian Reschke Message-ID: <568BC1BB.3000004@gmx.de> Date: Tue, 5 Jan 2016 14:14:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <1707442344.20160105140217@w3.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UIEf22R2P8XkATMXLl1CXLuup1zf7X8OV6nActhbggktauP/p+e d/MqShOCsitj/exmnK06YCJ2piWjhqyVJpwczr0KiNAlr53UPEpT5VuHWsyJ0E57m2hWhN1 giWReykmPj9CTqaowSGaiBAEWjzs94iaNM7qfELHeqaTO4bv/+QGdjxefTsBSpaeJoiAmoh 5KPYuOPLqwxrKjsn+gpQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ybJc3nDFGzw=:LFZ0AbB/Kyay+3F8ltpfAT f80R+9+5ot4+yqJ5yX2ng5r/eSEnE17D60JKisS2ANRJ0dDShPV+uFpw2aP6TZFTNBtBTWkoi DGl/+EH4Pflvybg8Q9CeS25Zi++6Gb6AOygen/UM31eBeCBKTRBKzJ7OajFKoDu72xL1mpNOs AoqFKm3VvjcbsQZbdIymBlrDrA75sfYmEB6hCBTrgxv9cK8pvJ6+JEeIk1SuLBGkQemmKhrop /d12uk5Wu3Cq6mdKt4xqRbl6mjvyei24M2LoqtUPWzsWCBcwvQwYTWlDeVlNGy9hAl3P9JMm7 3CQpTD650ZeSVnQqrlQ+hrGablyV6gO6QcyjJNCOjUY90TLRnH8MiELMC3PL3Af3tgoYYrnPl qyLmdNt2lySSNJ3mJ8lCfbrrNijkt4QSTMbjgliEZrLdJ9/ADFZ5PO7DTu8dv4UekCHCrSc4c DUKHR+nLkP5DndLuG5i4c5xEWClyjJAIDF7kEyO8z1QRbhtyk+GcyqCpfQuM6VhllP9ehEBZ4 X2OpIIHUsQ9ZjlpPhs7MBnW0bI7U/4jHMR1kAgbHX7j7QyUr6dLNwhzlzgseVLYye0hnepRNT yqr09Ur1uSRgWL+zMyFXoRaPHYOLVHxIVyD6aBOrc3m0CT+9SyvUOaphP8oRF+lW7QvCEf5LE 1jYIcxraSz2GV+paTgVQ7DuRJY+Ofiy9kB5gT0HC9PxJ2VZtQsb3+eyGQ1Bc7v5sb4YTrK0AU UU50dpa5Ks5nNIMZYSJbuWC5ZefAz7VZL076WqWWCESQ6AVya2cXhqfoG2VgJl4Jh5r2kHNH9 htd876H Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7303 (4578) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 13:14:44 -0000 On 2016-01-05 13:02, Chris Lilley wrote: > Hello RFC Errara System, > > Tuesday, January 5, 2016, 2:42:45 AM, you wrote: > >> The following errata report has been submitted for RFC7303, >> "XML Media Types". > > I believe that the original text is correct, because W3C is change > controller not only of the +xml suffic but also of application/xml and > related types. > > Henry, do you agree? > .... The set of affected media types by definition can't be open-ended. If that's what people read out of this statement, then it's at least misleading. Best regards, Julian From nobody Tue Jan 5 21:53:53 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C8D1A9248 for ; Tue, 5 Jan 2016 21:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WRLDWD=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDAdYRYqH33o for ; Tue, 5 Jan 2016 21:53:45 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0116.outbound.protection.outlook.com [104.47.125.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FED21A9240 for ; Tue, 5 Jan 2016 21:53:44 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0131.jpnprd01.prod.outlook.com (10.161.27.12) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 05:53:40 +0000 To: Chris Lilley , RFC Errata System , , , , References: <20160105014245.88C5A18000C@rfc-editor.org> <1707442344.20160105140217@w3.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <568CABE4.4090407@it.aoyama.ac.jp> Date: Wed, 6 Jan 2016 14:53:40 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <1707442344.20160105140217@w3.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0010.apcprd06.prod.outlook.com (25.164.91.20) To KAWPR01MB0131.jpnprd01.prod.outlook.com (25.161.27.12) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0131; 2:9oKoxDV/XQzGKueIABhf7FVx492F1jBjD+v9gm91E+SGQNgq/bkjhkpNMAMYjiAtVLbXmLNT5VcVQX9kUjos+Ay5UfQh7vC6g0EQtwgJj2Ba2YTYtl3VUoqGhjk/XF39EGsJDNzf1zz/wdw9BSq66Q==; 3:WIPYYs4xU6Rc4Djss/+wdTc4fOqIwWbNL0vgWMwCG+2d8B87EGir0T4ODIqucvc903s4DTmpx3NvBbwsq+A4uOyE/fUyQQF1lAD2oWtN3NYVOlPw+qNKHxGboEorTkpI; 25:/6gVPUPsgcbVsSgzuSMWaROFC75aEqNdvMIK4P8rCu6u1vRj3Tsp2Yh1lOCN4W5kJeZth49m8V9hSliZZ3nbmV2feJ0OoZBvKgO3x8aeo8KLNYrHAtk8pyTbSPRHcE9NwMZt8LaxJl8+crpyUKD4J88Jkj12FOFjansVZ7YKCmeeq4Ams+SQ6c6/ZHJQpdxLFbzYXKychcQF7V+XdkPBbpKmf1ZinWI3sYkYCue3nRIZYUzafk6Xl0KBa1j/lHsky/NFHC701M0djfWC4onPSQ==; 4:c79ZekB6irJbHmsKj/nD347zZ6MBcTEaDeX2lCtgul/w9ig+Esm1JDQQ1iXDwVhiLsW3X1sVNGHNkNur/GPF7LE6bgD/Uq6NyLazhhGSR1s+znwOkGW/05k4o7EoMqxG7ITzzjXmoJ4JeFSQms4deUwYf8t4JZO9J4JsrNWwgBOvbMwPd3/pu/HWq3AgT5mH3I0J/cmJf25R4QwW1UYKYGYHd7A65/Qwdo+jo6IghW3MRoUqRb20OZKPD3irwMncydwLTIjRdQbek10T/2wmLKHip7Kl0b/v7izoI+x1ebsX6/1Et2DZdi5wrFWtgaqXtVulqC41NhA+Metv4azX+ZQKMTdR5Eh8nRK4HoLe1Dxdv2X4C0J7ku5672cINzJX X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0131; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:KAWPR01MB0131; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0131; X-Forefront-PRVS: 0813C68E65 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(479174004)(24454002)(189002)(377454003)(19580395003)(54356999)(80316001)(19580405001)(40100003)(2950100001)(586003)(66066001)(50466002)(5008740100001)(5001770100001)(1096002)(76176999)(65806001)(87266999)(16799955002)(4001350100001)(81156007)(65816999)(101416001)(65956001)(106356001)(105586002)(83506001)(6116002)(4326007)(86362001)(15188155005)(97736004)(50986999)(23676002)(122386002)(3846002)(189998001)(87976001)(92566002)(5001960100002)(64126003)(33656002)(77096005)(2201001)(42186005)(5004730100002)(47776003)(59896002)(74482002)(15975445007)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0131; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTMxOzIzOjNEOEJhQnppMFFxKzFNQmZubVlYZlV6czVh?= =?utf-8?B?anpqb3JRSkxuZkduRUdwTmhxSXdZK29Jb3YvVFhYVjg5YUx4ZjdvazJRK3ox?= =?utf-8?B?ZWc2WlJFUjJ0OHp3OGdLM3lteWswOU9sc0dXSXdPcW9xQlhabi91bTBsYm5J?= =?utf-8?B?OGpUNEJ6TTRZT0didHFjOUNsUXdYRE10aVhDMlQvMzk0MEdCQzF3VnRuc3Ry?= =?utf-8?B?ZHBKVGdVQjRsR29rZXhCeVB6dWRCOTVSeXcyOXZ3bjZNUmpTWEZtZTNLVUVv?= =?utf-8?B?OEpoVE1WM3d1ZU9KeWxpMVZkWGo0SDBTOFk1OC9iejdWYmxNTnFTYUNmRTdM?= =?utf-8?B?NVVFNHFaRVlRREw4WEhuYUhtUWFyZzNlU1p5OHBKOTRjRFdpaXdOc1BrcFJq?= =?utf-8?B?SExTL3VKWU5UN3cwcGlaaTd6eW92UnZ0elpCLzRtcndNRTdIbnRFV1pxKzBQ?= =?utf-8?B?RnErNDBGRmNxMjVnZ0xPL2JnSzhYVkdZTER1MXNyTWYxVUZqRHlJNW4zdUhD?= =?utf-8?B?aTN1SVRwYndwSktuRHJPazlJN211MGgwd1BQRmc3Z2tEakdOaHFNeTE3WUxy?= =?utf-8?B?cGNYdDMrU1pvVnJ2YlBCbmtycHdRS2IvL3g4emNuMEJ2VEd0RjcrdmlteDcx?= =?utf-8?B?Mnd3UEVhSWl1dit1SkIyRTJ4NlJaeTBnOWhTaTAzQVBLZkJwNmR6c2ZJbjgw?= =?utf-8?B?ZGRhSjR0azVOaU1aek5zTHFpT3oyTUtiTEI5YkNaOVVtTWM4NnZ5bnVSRHF6?= =?utf-8?B?K2NZWXJNZTRtSmNQY1FpMjVaRWF1dEh1a2pOM3ZTUytCejhWeEZyVXZIKzZQ?= =?utf-8?B?akNCZHlCcHBDVVR1MkJHcXB0V3JTMTl5RnRaTjMzWTVZQTBLdDdpdm1TOWFW?= =?utf-8?B?WHBpTzFpb1lxalRpYjZ3MXB4MklEZ3I3VXdCOGtEKzJpUEU1aEUxc1hhSlBX?= =?utf-8?B?cEgwWTZRNzJBNGhvVDhjY0JyeFF2ZDVGbUhMa1VFeFJHbUpDZUxqUFlqV0pY?= =?utf-8?B?Zm9KVXQ5aWRoWk11N20wVC95cCtlRHJWNXoydDZqUjJ4QXlwa1FKVFhNWXdp?= =?utf-8?B?RTQ0VHlHeWNhWDRnMWJJSVhrQUV2a3pDK1JrTW9EMjVYaVdrNC9NOFBjNnBX?= =?utf-8?B?RGh4Z0dRcVl3bmFRZWY5U0grYlVGQkJoZ1RxV1YxanJQUGRRRW5YbjlIZDVr?= =?utf-8?B?Y2krRXdZTEVLWkMzVWE3QWRvUHZ6anptTnk4SmRPRGFLOFA0Sk5id1pPYVky?= =?utf-8?B?MVB5ZjNtRXQyTjVmdTd5NXBBY3BUMkNNaVhLa3ZtOTFJZGM2RHBIYmdwaUpW?= =?utf-8?B?NFBaRG0vRVhuczJidTZGOUQzTGF5WlFuN0xvNENTSDk4S2FvZy9wZVFnKzE5?= =?utf-8?B?V1pRQ3RqNnlJcUI0S0VlT3ptc3p2V05SRHlnODNja3JiWjlhVGJEa1RDblpQ?= =?utf-8?B?WklRaUhKQUtoV1diYnJyNlVPWU1yaVlQR1AyMnpWTzAvUUpXYmVBTTdmdzVJ?= =?utf-8?B?Vjdvb1U5eXpKVk51cnJaS1NiNnEyWi8zSmw4bStEZzRRSDdQN1VoL3k1ME90?= =?utf-8?B?UzVDZzI4SDFXYkV3Z0lmNDlrRW5xQ29XRCtHZkFlek4yZGtUNmNDcUF1K0tk?= =?utf-8?B?UGhMTmZHTGhkNTYxNHppUXhZcWxPOERzYUtWUjdIblc1OGdqWS8ycmd6NnFr?= =?utf-8?B?RFMvc09nUjMvdjg2SDVlSHdJMm1iaVBtQURkSmZERXBURGNmWTJYcmNiQVNI?= =?utf-8?B?RkZXV1VvQm9pTzEyRG9ubmhORUkvbWtFME5pakxOWUQwVW1TL2NrVnNjakdm?= =?utf-8?B?dWNEemxPSVJJWndwaWVrQm0yTnhZdjFXZ1RDRm9uMzRYdnR3U3FDRDd6Um5h?= =?utf-8?B?M0dyYzJ2QjZRUExwa1dEOFFkekRVc3lIby9ueFh2Tnc0SVlEOXMvSGkzRkl1?= =?utf-8?B?Mzl5aWFRWWVBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0131; 5:U0HnWxf/zOqlW+aEOc2VZQ+Rr1TEcsdZ+z8l+K+5CwjIHpI9Ey8esyyL932fAE6foz3EiHYb9H+Ptea6qpFQjS2hPFQrY/ZSbdhkdr8mkJagJtGyMcM2ACmOlPX7A2XspQG3ZbYTAMYaz0x+QUY11Q==; 24:ZOGbpd+GgFqO9Ti6lUICQv3R+9WoGEi/h4/pdrfkeuJ6rbDOzKrPY8nOlBOxninBg15jv9tWtVJ4ArQzfO2CT+OWj0S0yxm0NYiPGkkHl+Q= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2016 05:53:40.4723 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0131 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7303 (4578) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 05:53:51 -0000 Hello Chris, On 2016/01/05 21:02, Chris Lilley wrote: > Hello RFC Errara System, > > Tuesday, January 5, 2016, 2:42:45 AM, you wrote: > >> The following errata report has been submitted for RFC7303, >> "XML Media Types". > > I believe that the original text is correct, because W3C is change > controller not only of the +xml suffic but also of application/xml and > related types. It's certainly true that W3C is the change controller not only of the +xml suffix but also of application/xml and related types. But the sentence in question is placed at the end of Section 4.2 (which is entitled "Using '+xml' when Registering XML-Based Media Types" and followed by another subsection). Therefore, reading it as applying to +xml suffixed types is somewhat understandable. So the question is how could the sentence be changed (or moved?) so that it would be clear that it applies to the +xml suffix registration and application/xml and related types, but NOT to subtypes using the +xml convention. Chris, Henry, any ideas? Regards, Martin. > Henry, do you agree? > >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7303&eid=4578 > >> -------------------------------------- >> Type: Technical >> Reported by: Martin Dürst > >> Section: 4.2 > >> Original Text >> ------------- >> In addition to the changes described above, the change controller has >> been changed to be the World Wide Web Consortium (W3C). > > >> Corrected Text >> -------------- >> In addition to the changes described above, the change controller for >> the '+xml' Structured Syntax Suffix has been changed to be the World >> Wide Web Consortium (W3C). > > >> Notes >> ----- >> At >> https://mailarchive.ietf.org/arch/msg/lager/hRVFkda9GKFTYeBcmK2Ge9OdvoA, >> the sentence was misread to apply to all registrations with a +xml >> suffix, rather than only to the registration of the suffix itself. > >> 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 (IESG) >> can log in to change the status and edit the report, if necessary. > >> -------------------------------------- >> RFC7303 (draft-ietf-appsawg-xml-mediatypes-10) >> -------------------------------------- >> Title : XML Media Types >> Publication Date : July 2014 >> Author(s) : H. Thompson, C. Lilley >> Category : PROPOSED STANDARD >> Source : Applications Area Working Group APP >> Area : Applications >> Stream : IETF >> Verifying Party : IESG > > > > From nobody Wed Jan 6 04:47:43 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23A01B2B10 for ; Wed, 6 Jan 2016 04:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4OWRP8G7YrAu for ; Wed, 6 Jan 2016 04:47:39 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC01B2B0D for ; Wed, 6 Jan 2016 04:47:38 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id u06ClAsU003369; Wed, 6 Jan 2016 12:47:15 GMT 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 u06Cl5Iq007940; Wed, 6 Jan 2016 12:47:06 GMT 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 u06Cl7Sf011562; Wed, 6 Jan 2016 12:47:07 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u06Cl4fI011559; Wed, 6 Jan 2016 12:47:04 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Chris Lilley References: <20160105014245.88C5A18000C@rfc-editor.org> <1707442344.20160105140217@w3.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 06 Jan 2016 12:47:04 +0000 In-Reply-To: <1707442344.20160105140217@w3.org> (Chris Lilley's message of "Tue\, 5 Jan 2016 14\:02\:17 +0200") 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 nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: apps-discuss@ietf.org, barryleiba@computer.org, RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7303 (4578) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 12:47:42 -0000 Chris Lilley writes: >> The following errata report has been submitted for RFC7303, >> "XML Media Types". > > I believe that the original text is correct, because W3C is change > controller not only of the +xml suffic but also of application/xml and > related types. > > Henry, do you agree? No, I think Martin's change is OK -- this change is in section 4.2, which is specifically a takeover of the '+xml' suffix registration from RFC6839. That W3C is the change controller for application/xml etc. is not a change, it was true in 3023. 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 Wed Jan 6 06:13:44 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5259A1B2BE6 for ; Wed, 6 Jan 2016 06:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN_XYK2W4gD2 for ; Wed, 6 Jan 2016 06:13:37 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 CEAD11B2BED for ; Wed, 6 Jan 2016 06:13:37 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u06E9KtQ025160 for ; Wed, 6 Jan 2016 09:13:37 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2069mftpr9-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 06 Jan 2016 09:13:37 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u06EDaD3031681 for ; Wed, 6 Jan 2016 09:13:36 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u06EDQ59031577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 Jan 2016 09:13:29 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Wed, 6 Jan 2016 14:13:09 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id u06ED9Zh003916 for ; Wed, 6 Jan 2016 09:13:09 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id u06ED3mJ003457 for ; Wed, 6 Jan 2016 09:13:03 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.247](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20160106141301gw100dvbvee>; Wed, 6 Jan 2016 14:13:02 +0000 X-Originating-IP: [135.110.241.247] References: <20160105014245.88C5A18000C@rfc-editor.org> <1707442344.20160105140217@w3.org> From: Tony Hansen X-Enigmail-Draft-Status: N1110 Message-ID: <568D20ED.6010702@att.com> Date: Wed, 6 Jan 2016 09:13:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-01-06_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601060250 Archived-At: Cc: apps-discuss@ietf.org, RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7303 (4578) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 14:13:43 -0000 On 1/6/16 7:47 AM, Henry S. Thompson wrote: > Chris Lilley writes: > >>> The following errata report has been submitted for RFC7303, >>> "XML Media Types". >> I believe that the original text is correct, because W3C is change >> controller not only of the +xml suffic but also of application/xml and= >> related types. >> >> Henry, do you agree? > No, I think Martin's change is OK -- this change is in section 4.2, > which is specifically a takeover of the '+xml' suffix registration from= > RFC6839. > > That W3C is the change controller for application/xml etc. is not a > change, it was true in 3023. As one of the authors of RFC6839, I agree with the above comments, and support Martin's improved wording. W3C is not supposed to be the change controller for application/example+xml, and reading this sentence to mean that W3C does become such is definitely a mistake. Martin's improved wording eliminates any such confusion. Tony Hansen =20 From nobody Thu Jan 7 05:58:19 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEAB1A8A3F; Thu, 7 Jan 2016 05:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 KmGjd6_mharD; Thu, 7 Jan 2016 05:58:12 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 77FFE1A8A09; Thu, 7 Jan 2016 05:58:12 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id k1so174092629vkb.2; Thu, 07 Jan 2016 05:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UarKi31P3B6bMnEQ7f6vA/WRYgMXGuaAha6+XcBoE5Q=; b=ATXHKOALl2TgprWAm7QB26HtsN7RQEq7Z/2lU2c8DNfZvFwRoLS/rjF8fLqiCeeg+Y BD45DvoDpIRINe4ik9MMNPy7XEYlPt4JjnnqMIietQ6EZogcU1HOL8KpUoaWO/ucG7T/ ozSVUOS+7INVedGXyuTnCmHC6yYLC9TeoJ2Rt/SvCmo32Si0Vsh554pRnG3FzA9VMZsi 0g0GjJBXcba8PrUhVA/XxP/fnoSwcp9d7o4/xnD8LCYf9bS/5xZ1qJazkPxnbfkiMCMU Opbyzb9OAia/JIlKsT0ndyWop0ATCVpgR+A3Aw7BtAczNRxjm7S5RNNoj0LNAzOCwRRZ tbKQ== MIME-Version: 1.0 X-Received: by 10.31.165.71 with SMTP id o68mr66687188vke.67.1452175091586; Thu, 07 Jan 2016 05:58:11 -0800 (PST) Received: by 10.31.182.75 with HTTP; Thu, 7 Jan 2016 05:58:11 -0800 (PST) In-Reply-To: References: <20151217143841.8732.14093.idtracker@ietfa.amsl.com> Date: Thu, 7 Jan 2016 07:58:11 -0600 Message-ID: From: Spencer Dawkins at IETF To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a1141600a7c5da90528bedc45 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Spencer Dawkins' Discuss on draft-ietf-appsawg-http-problem-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:58:15 -0000 --001a1141600a7c5da90528bedc45 Content-Type: text/plain; charset=UTF-8 Hi, Mark, On Thu, Dec 17, 2015 at 6:05 PM, Mark Nottingham wrote: > Hi Spencer, > > On 18 Dec 2015, at 1:38 am, Spencer Dawkins > wrote: > > > I'm elevating this to a (late) Discuss, because I haven't heard anything > > back, and didn't want the document approved without having a (short) > > discussion. I'll be back to Yes after that. > > > > In this text, > > > > The "status" member duplicates the information available in the HTTP > > status code itself, thereby bringing the possibility of disagreement > > between the two. Their relative precedence is not clear, since a > > disagreement might indicate that (for example) an intermediary has > > modified the HTTP status code in transit. As such, those defining > > problem types as well as generators and consumers of problems need to > > be aware that generic software (such as proxies, load balancers, > > firewalls, virus scanners) are unlikely to know of or respect the > > status code conveyed in this member. > > > > I understand what you're saying about a mismatch being possible, and some > > of the possible reasons why that might happen, but isn't this saying that > > anyone who can understand the "status" member should prefer its value > > when there's a mismatch (because it's less likely to have been dorked > > with by an intermediary - or is that even true)? > > It really depends on what their purpose is. The HTTP status might be > updated because of legitimate HTTP machinery -- e.g., by a cache (304), or > a proxy (various things like proxy auth, disconnected operation). The > status member is there to preserve the original intent of the author, and > also for convenience (e.g., when a message is persisted, often the status > is lost). > > > > So, the situation looks to me, like there's a MUST > > > > The status member, if present, is only advisory; it conveys the HTTP > > status code used for the convenience of the consumer. Generators > > MUST use the same status code in the actual HTTP response, to assure > > that generic HTTP software that does not understand this format still > > behaves correctly. > > > > that some intermediary can dork with, so the result violates the MUST, > > and we really can't tell the receiver what you should do at that point. > > "Gee, I guess you're gonna have to flip a coin to decide who to believe" > > would be sad, but it would be more guidance than the document has now :-) > > If you're implementing generic HTTP software, you're going to be using the > HTTP status. If you're interpreting the HTTP problem itself, you're > probably going to pay attention to the one in-document, IF you pay > attention to it at all. Thanks for the explanations. I'll clear this Discuss, but would love it if you could say something like what you've told me in the document. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I've wished this mechanism was available, a few times already. > > > > In this text, > > > > If such additional members are defined, their names SHOULD start with > > a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist > > of characters from ALPHA, DIGIT (Ibid.), and "_" (so that it can be > > serialized in formats other than JSON), and SHOULD be three > > characters or longer. > > > > are there any benefits to not conforming to these SHOULDs? For example, > > would you really need to have a two-character member name, and you'd fail > > if the member name was three characters long? ("Why are these not > > MUSTs?") > > Those requirements are to make it compatible with the XML mapping. They're > SHOULDs because someone might be really, really sure that their problems > will never be used in XML. > > Cheers, > > > > -- > Mark Nottingham https://www.mnot.net/ > > --001a1141600a7c5da90528bedc45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Mark,

On Thu, Dec 17, 2015 at 6:05 PM, Mark Nottingham <mnot@mnot.net&g= t; wrote:
Hi Spencer,

On 18 Dec 2015, at 1:38 am, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

> I'm elevating this to a (late) Discuss, because I haven't hear= d anything
> back, and didn't want the document approved without having a (shor= t)
> discussion. I'll be back to Yes after that.
>
> In this text,
>
>=C2=A0 =C2=A0The "status" member duplicates the information a= vailable in the HTTP
>=C2=A0 =C2=A0status code itself, thereby bringing the possibility of di= sagreement
>=C2=A0 =C2=A0between the two.=C2=A0 Their relative precedence is not cl= ear, since a
>=C2=A0 =C2=A0disagreement might indicate that (for example) an intermed= iary has
>=C2=A0 =C2=A0modified the HTTP status code in transit.=C2=A0 As such, t= hose defining
>=C2=A0 =C2=A0problem types as well as generators and consumers of probl= ems need to
>=C2=A0 =C2=A0be aware that generic software (such as proxies, load bala= ncers,
>=C2=A0 =C2=A0firewalls, virus scanners) are unlikely to know of or resp= ect the
>=C2=A0 =C2=A0status code conveyed in this member.
>
> I understand what you're saying about a mismatch being possible, a= nd some
> of the possible reasons why that might happen, but isn't this sayi= ng that
> anyone who can understand the "status" member should prefer = its value
> when there's a mismatch (because it's less likely to have been= dorked
> with by an intermediary - or is that even true)?

It really depends on what their purpose is. The HTTP status might be= updated because of legitimate HTTP machinery -- e.g., by a cache (304), or= a proxy (various things like proxy auth, disconnected operation). The stat= us member is there to preserve the original intent of the author, and also = for convenience (e.g., when a message is persisted, often the status is los= t).


> So, the situation looks to me, like there's a MUST
>
>=C2=A0 =C2=A0The status member, if present, is only advisory; it convey= s the HTTP
>=C2=A0 =C2=A0status code used for the convenience of the consumer.=C2= =A0 Generators
>=C2=A0 =C2=A0MUST use the same status code in the actual HTTP response,= to assure
>=C2=A0 =C2=A0that generic HTTP software that does not understand this f= ormat still
>=C2=A0 =C2=A0behaves correctly.
>
> that some intermediary can dork with, so the result violates the MUST,=
> and we really can't tell the receiver what you should do at that p= oint.
> "Gee, I guess you're gonna have to flip a coin to decide who = to believe"
> would be sad, but it would be more guidance than the document has now = :-)

If you're implementing generic HTTP software, you're going t= o be using the HTTP status. If you're interpreting the HTTP problem its= elf, you're probably going to pay attention to the one in-document, IF = you pay attention to it at all.

Thanks for = the explanations.

I'll clear this Discuss, but= would love it if you could say something like what you've told me in t= he document.
=C2=A0
> -------------------------------------------------------------= ---------
> COMMENT:
> ----------------------------------------------------------------------=
>
> I've wished this mechanism was available, a few times already.
>
> In this text,
>
>=C2=A0 =C2=A0If such additional members are defined, their names SHOULD= start with
>=C2=A0 =C2=A0a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOUL= D consist
>=C2=A0 =C2=A0of characters from ALPHA, DIGIT (Ibid.), and "_"= (so that it can be
>=C2=A0 =C2=A0serialized in formats other than JSON), and SHOULD be thre= e
>=C2=A0 =C2=A0characters or longer.
>
> are there any benefits to not conforming to these SHOULDs? For example= ,
> would you really need to have a two-character member name, and you'= ;d fail
> if the member name was three characters long? ("Why are these not=
> MUSTs?")

Those requirements are to make it compatible with the XML mapping. T= hey're SHOULDs because someone might be really, really sure that their = problems will never be used in XML.

Cheers,



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


--001a1141600a7c5da90528bedc45-- From nobody Thu Jan 7 05:59:38 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAC21A8A27; Thu, 7 Jan 2016 05:59:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107135937.936.70632.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 05:59:37 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-http-problem-02: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:59:37 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-appsawg-http-problem-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for helping me resolve my Discuss. From nobody Mon Jan 11 11:05:42 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED021A9055; Mon, 11 Jan 2016 11:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 1SyT62QmQHly; Mon, 11 Jan 2016 11:05:35 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 D6E061A9059; Mon, 11 Jan 2016 11:05:34 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id 6so332063141qgy.1; Mon, 11 Jan 2016 11:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qy/CUEA8eKFKv4G+oY7IyrdRj5/H86BVdsDZD7g/7wo=; b=jTR5LERC+d6WrzHfKyU2qQ2YIGbwOXVSjs8ZQKLlpYXv4LU9sql0tkVFXbwVPC+wFJ IRgwDbtGoKkWwaiq5CfIYBjQ4WlNf4AiovxiiShyT+ChcGflEL4MOgJqnkETUUnuidkq I20V8c7a9WCfZ36utb++w3/xmbBJQmMocq52hzCFqDiaptNY8jy+Q7UTtWA27KIMRzpp TxvdA0hcl5bjvJXIh5CB6iXCcYEzJoUV8J0qM0BvVNh+fICPLkjvtQ8wNs7dj0os6+zi hqpyRcWytEExQ5eZ0CUq1qYuOzy1DxZZr2fuzFlthOLvGMF8AQNRKxUeaQyLmgEo952q I6Pg== X-Received: by 10.140.163.6 with SMTP id j6mr43598750qhj.36.1452539134000; Mon, 11 Jan 2016 11:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Mon, 11 Jan 2016 11:05:14 -0800 (PST) In-Reply-To: <5693396D.7080900@redhat.com> References: <5693396D.7080900@redhat.com> From: Ted Hardie Date: Mon, 11 Jan 2016 11:05:14 -0800 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=001a1139d3fc1ae20e0529139fff Archived-At: Cc: dnsop@ietf.org, draft-ietf-dnsop-edns-chain-query.all@ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPS-Dir review of draft-ietf-dnsop-edns-chain-query-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:05:38 -0000 --001a1139d3fc1ae20e0529139fff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, Some discussion below, mostly snipping things where things are clear. On Sun, Jan 10, 2016 at 9:11 PM, Paul Wouters wrote: > On 11/23/2015 03:24 PM, Ted Hardie wrote: > > (added CC: to dnsop list for feedback) > > Thanks for your review Ted! > > > Major Issues: > > > > The effort to avoid amplification attacks is appropriate, but > justification > > of the UDP option, even with the EDNS option for a DNS cookie, is not > well > > supported in the draft. > > I'm a little confused. Do you mean the justification of the COOKIE > requirement needs more justification, or > the edns-query-chain option itself needs more justification. I would hope > the latter is clear - it reduces the > need for either multiple latency bound round trips or many parallel > queries and their callbacks. > > =E2=80=8BSorry that I wasn't clear enough here. I'm not asking for a justi= fication of the COOKIE, I'm wondering how often this will work over UDP. Since the basic issue is that response sizes needed for validation =E2=80=8Bmay be la= rge, and the cookie will add between 15-40 bytes, it's not clear to me what range of UDP payload sizes would actually allow you to use this mechanism over UDP. If I understand your answer correctly, you are saying that the small number of bytes here doesn't change distribution of responses that fit into UDP significantly. ("The additional size of the COOKIE is not really a problem here. Those would be very few bytes compared to an abusive long chain that an attacker could be asking for.") If the working group believes that's the case, that's fine. It might be useful to include a bit of text in the introduction indicating that this is the expectation, but that sort of text in archival documents is definitely a matter of taste. > > Is there a > =E2=80=8B =E2=80=8B > reason for limiting partial answers to the top-most hierarchical > > responses? If so, could the document include it? > > The reason for limiting the answer from the top down is that it enables > the querying > client to extend its own chain further down, and send a new query for the > same data > with the updated Closest Trust Point further down. This method guarantees > that the > DNS client can work its way to the answer. > > If the server decides to send other parts of the chain, the client has to > modify its > query target in an attempt to get the top part of the chain it did not > get. And it has > no guarantee that the next query will give it another useful hunk of the > chain. > > Additionally, assuming the DNS client to DNS server connection is of high > latency, and > the DNS server itself has a low latency uplink, it might actually do the > DNS client a > disservice giving it part of the chain instead of querying to create the > full chain. It > would also be guessing as to whether the full chain is likely to fit or > not. > > To me, such strategies seem overly complicated, and require more code on > the DNS client > implementing handling unexpected partial answers. The top down cut-off > seems much simpler > to me. But let's ask the working group as well what they think. > > =E2=80=8BI think a short statement like "This strategy somewhat limits the opportunity to use cached data but results in lower code complexity for clients by allowing them to retain a common query target after a partial answer" would cover this an= d might be useful. > > > > > > To resolve this, the client would have to be able to detect when the > ENDS0 > > option is suppressed by the path, versus not offered by a Recursive > > Resolver. Some further text on how this is discerned would be useful; > > absent a method, I believe the text in 5.3 is sufficient and 6.5 not > useful > > beyond the points made in RFC 6891. > > How about removing section 6.5, but moving the one sentence in there: > > A fallback strategy similar to that described in [RFC6891] section > 6.2.2 SHOULD be employed to avoid persistent interference due to non- > clean paths. > > to the end of section 5.3? Would that resolve your issue? > > =E2=80=8BYes, that seems to work.=E2=80=8B > > > > Nits: > > > > The abstract uses the term "security aware validating Resolver". This > use > > of "security aware" appears to be the term of art used in RFC 4033, but > > that may not be obvious; perhaps "DNSSEC validating resolver" would be > more > > clear for an abstract? > > RFC-7719 DNS Terminology marks all of these terms as "have caused > confusion". I am fine with DNSSEC validating resolver", but I would like = to > punt this question > to the authors of RFC-7719. I'll ping them offlist if they miss this > message on the dnsop list. > > =E2=80=8BFair enough; I'm happy to go along with their advice, whatever it = may be.=E2=80=8B > > In section 6.3, the document says: > > > > In the event that there is greater demand for Chain Queries than can > > be accommodated, DNS servers may stop advertising the CHAIN option i= n > > successive DNS messages. This allows, for example, clients with > > other candidate servers to query to establish new sessions with > > different servers in expectation that those servers might still allo= w > > Chain Queries. > > > > Given that this would also apply to UDP CHAIN queries, it is not clear > why > > this is in the TCP Session Management section. > > Correct. How about renaming section 6.3 from "TCP session management" to > "session management" ? > > =E2=80=8BSounds good. =E2=80=8B =E2=80=8BThanks for all your work on this, Ted=E2=80=8B --001a1139d3fc1ae20e0529139fff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Some discussion below, m= ostly snipping things where things are clear.

On Sun, Jan 10, 2016 at 9:11 PM, Paul= Wouters <pwouters@redhat.com> wrote:
On 11/23/2015 03:24 PM, Ted Hardie wrote:<= br>
(added CC: to dnsop list for feedback)

Thanks for your review Ted!

> Major Issues:
>
> The effort to avoid amplification attacks is appropriate, but justific= ation
> of the UDP option, even with the EDNS option for a DNS cookie, is not = well
> supported in the draft.

I'm a little confused. Do you mean the justification of the COOK= IE requirement needs more justification, or
the edns-query-chain option itself needs more justification. I would hope t= he latter is clear - it reduces the
need for either multiple latency bound round trips or many parallel queries= and their callbacks.


=E2=80=8BSorry tha= t I wasn't clear enough here.=C2=A0 I'm not asking for a justificat= ion of the COOKIE, I'm wondering how often this will work over UDP.=C2= =A0=C2=A0 Since the basic issue is that response sizes needed for validatio= n =E2=80=8Bmay be large, and the cookie will add between 15-40 bytes, it= 9;s not clear to me what range of UDP payload sizes would actually allow yo= u to use this mechanism over UDP.

If I understand your= answer correctly, you are saying that the small number of bytes here doesn= 't change distribution of responses that fit into UDP significantly.=C2= =A0 ("The additional size of the COOKIE is not really a problem here. = Those would be very few bytes compared to an abusive long chain that an att= acker could be asking for.")=C2=A0 If the working group believes that&= #39;s the case, that's fine.=C2=A0 It might be useful to include a bit = of text in the introduction indicating that this is the expectation, but th= at sort of text in archival documents is definitely a matter of taste.
<= /div>



> Is there a
=E2=80=8B =E2=80=8B
reason for li= miting partial answers to the top-most hierarchical
> responses?=C2=A0 If so, could the document include it?

The reason for limiting the answer from the top down is that it enab= les the querying
client to extend its own chain further down, and send a new query for the s= ame data
with the updated Closest Trust Point further down. This method guarantees t= hat the
DNS client can work its way to the answer.

If the server decides to send other parts of the chain, the client has to m= odify its
query target in an attempt to get the top part of the chain it did not get.= And it has
no guarantee that the next query will give it another useful hunk of the ch= ain.

Additionally, assuming the DNS client to DNS server connection is of high l= atency, and
the DNS server itself has a low latency uplink, it might actually do the DN= S client a
disservice giving it part of the chain instead of querying to create the fu= ll chain. It
would also be guessing as to whether the full chain is likely to fit or not= .

To me, such strategies seem overly complicated, and require more code on th= e DNS client
implementing handling unexpected partial answers. The top down cut-off seem= s much simpler
to me. But let's ask the working group as well what they think.


=E2=80=8BI think a= short statement like "This strategy somewhat limits the opportunity t= o
use cached data but results in lower code complexity for= clients by allowing them
to retain a common query target = after a partial answer" would cover this and
might be = useful.


=C2=A0


>
> To resolve this, the client would have to be able to detect when the E= NDS0
> option is suppressed by the path, versus not offered by a Recursive > Resolver.=C2=A0 =C2=A0Some further text on how this is discerned would= be useful;
> absent a method, I believe the text in 5.3 is sufficient and 6.5 not u= seful
> beyond the points made in RFC 6891.

How about removing section 6.5, but moving the one sentence in there= :

=C2=A0 =C2=A0A fallback strategy similar to that described in [RFC6891] sec= tion
=C2=A0 =C2=A06.2.2 SHOULD be employed to avoid persistent interference due = to non-
=C2=A0 =C2=A0clean paths.

to the end of section 5.3? Would that resolve your issue?

=E2=80=8BYes, that see= ms to work.=E2=80=8B

=C2=A0
>
> Nits:
>
> The abstract uses the term "security aware validating Resolver&qu= ot;.=C2=A0 This use
> of "security aware" appears to be the term of art used in RF= C 4033, but
> that may not be obvious; perhaps "DNSSEC validating resolver"= ; would be more
> clear for an abstract?

RFC-7719 DNS Terminology marks all of these terms as "have caus= ed confusion". I am fine with DNSSEC validating resolver", but I = would like to punt this question
to the authors of RFC-7719. I'll ping them offlist if they miss this me= ssage on the dnsop list.


=E2=80=8BFair enou= gh; I'm happy to go along with their advice, whatever it may be.=E2=80= =8B

=C2=A0
= > In section 6.3, the document says:
>
>=C2=A0 =C2=A0 In the event that there is greater demand for Chain Queri= es than can
>=C2=A0 =C2=A0 be accommodated, DNS servers may stop advertising the CHA= IN option in
>=C2=A0 =C2=A0 successive DNS messages.=C2=A0 This allows, for example, = clients with
>=C2=A0 =C2=A0 other candidate servers to query to establish new session= s with
>=C2=A0 =C2=A0 different servers in expectation that those servers might= still allow
>=C2=A0 =C2=A0 Chain Queries.
>
> Given that this would also apply to UDP CHAIN queries, it is not clear= why
> this is in the TCP Session Management section.

Correct. How about renaming section 6.3 from "TCP session manag= ement" to "session management" ?


=E2= =80=8BSounds good.
=E2=80=8B
=C2=A0

=E2=80=8BThanks= for all your work on this,

Ted=E2=80=8B

--001a1139d3fc1ae20e0529139fff-- From nobody Mon Jan 11 20:06:34 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ABD1A86FC; Sun, 10 Jan 2016 21:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 fZLUUqMSt47n; Sun, 10 Jan 2016 21:11:12 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED12A1A86FB; Sun, 10 Jan 2016 21:11:11 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 340108E225; Mon, 11 Jan 2016 05:11:11 +0000 (UTC) Received: from thinkpad.nohats.ca (vpn-63-135.rdu2.redhat.com [10.10.63.135]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0B5BAIG008271; Mon, 11 Jan 2016 00:11:10 -0500 To: Ted Hardie , apps-discuss@ietf.org, draft-ietf-dnsop-edns-chain-query.all@ietf.org References: From: Paul Wouters X-Enigmail-Draft-Status: N1110 Message-ID: <5693396D.7080900@redhat.com> Date: Mon, 11 Jan 2016 00:11:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: X-Mailman-Approved-At: Mon, 11 Jan 2016 20:06:33 -0800 Cc: dnsop@ietf.org, IESG Subject: Re: [apps-discuss] APPS-Dir review of draft-ietf-dnsop-edns-chain-query-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 05:11:14 -0000 On 11/23/2015 03:24 PM, Ted Hardie wrote: (added CC: to dnsop list for feedback) Thanks for your review Ted! > Major Issues: > > The effort to avoid amplification attacks is appropriate, but justification > of the UDP option, even with the EDNS option for a DNS cookie, is not well > supported in the draft. I'm a little confused. Do you mean the justification of the COOKIE requirement needs more justification, or the edns-query-chain option itself needs more justification. I would hope the latter is clear - it reduces the need for either multiple latency bound round trips or many parallel queries and their callbacks. One major driver for the work is that the total > response size needed for validation may be large. You mean the driver for the COOKIE? Because the driver for the option is not related to response size. I'm assuming that the amount of data the DNS client will receive is about equal. It's only a matter of whether it comes in via one DNS query, or multiple DNS queries. Using DNS cookies will > add between 15 and 40 bytes (presuming both client and server cookies are > used), thus further swelling the response. Some description of when the > requester/responder's UDP payload size is likely to be sufficient here > would be a valuable addition. If the data is not available now, perhaps it > could be gathered during the course of experimentation? If that data shows > the intersection of "fits within UDP" and "answers at least a partial > chain" is small, then reverting this to TCP-only looks sensible. The amplification is really only a concern when the source IP is not confirmed, and the packet could be a spoofed source ip packet. Once you have a DNS COOKIE, it is a confirmed client with source IP, so if it is abusive, it can be blacklisted or ratelimited. The additional size of the COOKIE is not really a problem here. Those would be very few bytes compared to an abusive long chain that an attacker could be asking for. > Minor Issues: > > In 5.4, the document currently describes the process of returning a partial > chain: > > If a CHAIN answer would be bigger than the Recursive Resolver is > willing to serve, it SHOULD send a partial chain starting with the > data closest to the top of the chain. The client MAY re-send the > query with an updated Closest Trust Point until it has received the > full chain. The CHAIN response will contain the lowest Closest Trust > Point that was included in the CHAIN answer. > > This describes the intersection of one particular resource constraint and > the operation of this option. It seems possible, however that a resolver > might see other resource constraints which might allow it to answer a > partial chain from something other than the data closest to the top of the > chain. Imagine, for example, that it has cached data for some parts of the > chain but needs to refresh the cache on some other part. If the cache fill > operation is taking significant time, it might prefer to send what data it > has, and fill the cache in anticipation of the follow-up query. Is there a > reason for limiting partial answers to the top-most hierarchical > responses? If so, could the document include it? The reason for limiting the answer from the top down is that it enables the querying client to extend its own chain further down, and send a new query for the same data with the updated Closest Trust Point further down. This method guarantees that the DNS client can work its way to the answer. If the server decides to send other parts of the chain, the client has to modify its query target in an attempt to get the top part of the chain it did not get. And it has no guarantee that the next query will give it another useful hunk of the chain. Additionally, assuming the DNS client to DNS server connection is of high latency, and the DNS server itself has a low latency uplink, it might actually do the DNS client a disservice giving it part of the chain instead of querying to create the full chain. It would also be guessing as to whether the full chain is likely to fit or not. To me, such strategies seem overly complicated, and require more code on the DNS client implementing handling unexpected partial answers. The top down cut-off seems much simpler to me. But let's ask the working group as well what they think. > In section 6.5, the document says: > > Many paths between DNS clients and Recursive Resolvers suffer from > poor hygiene, limiting the free flow of DNS messages that include > particular EDNS0 options, or messages that exceed a particular size. > A fallback strategy similar to that described in [RFC6891 > ] section > > 6.2.2 > SHOULD be employed to avoid persistent interference due to non- > clean paths. That section link is definitely pointing to the wrong document (this draft instead of RFC6891). Fixed. > This seems to conflict with the advice in 5.3: > > However, it is RECOMMENDED that Forwarders remember which > upstream Recursive Resolvers did not return the option (and > additional data) with their response. The Forwarder SHOULD fallback > to regular DNS for subsequent queries to those Recursive Resolvers. > It MAY switch to another Recursive Resolver that does support the > CHAIN option or try again later to see if the server has become less > loaded and is now willing to answer with Query Chains. > > To resolve this, the client would have to be able to detect when the ENDS0 > option is suppressed by the path, versus not offered by a Recursive > Resolver. Some further text on how this is discerned would be useful; > absent a method, I believe the text in 5.3 is sufficient and 6.5 not useful > beyond the points made in RFC 6891. How about removing section 6.5, but moving the one sentence in there: A fallback strategy similar to that described in [RFC6891] section 6.2.2 SHOULD be employed to avoid persistent interference due to non- clean paths. to the end of section 5.3? Would that resolve your issue? > > Nits: > > The abstract uses the term "security aware validating Resolver". This use > of "security aware" appears to be the term of art used in RFC 4033, but > that may not be obvious; perhaps "DNSSEC validating resolver" would be more > clear for an abstract? RFC-7719 DNS Terminology marks all of these terms as "have caused confusion". I am fine with DNSSEC validating resolver", but I would like to punt this question to the authors of RFC-7719. I'll ping them offlist if they miss this message on the dnsop list. > In section 6.3, the document says: > > In the event that there is greater demand for Chain Queries than can > be accommodated, DNS servers may stop advertising the CHAIN option in > successive DNS messages. This allows, for example, clients with > other candidate servers to query to establish new sessions with > different servers in expectation that those servers might still allow > Chain Queries. > > Given that this would also apply to UDP CHAIN queries, it is not clear why > this is in the TCP Session Management section. Correct. How about renaming section 6.3 from "TCP session management" to "session management" ? > In section 6.4, the document says "partian CHAIN up" where it should say > "partial CHAIN up". Fixed. > In section 6.6, this text was quite hard to parse: > > > Changes in network topology between clients and anycast servers may > cause disruption to TCP sessions making use of CHAIN more often than > with TCP sessions that omit it, since the TCP sessions are expected > to be longer-lived. > > Perhaps: > > Since DNS queries using CHAIN may result in longer TCP sessions, > network topology changes may disrupt them more frequently. Changed. Paul From nobody Mon Jan 11 20:07:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3835A1A893C; Mon, 11 Jan 2016 11:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 HQgSXYuoseb8; Mon, 11 Jan 2016 11:43:23 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3C31A8940; Mon, 11 Jan 2016 11:43:23 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 08C9DABBAD; Mon, 11 Jan 2016 19:43:23 +0000 (UTC) Received: from bofh.nohats.ca (vpn-225-181.phx2.redhat.com [10.3.225.181]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0BJhMMQ006615; Mon, 11 Jan 2016 14:43:22 -0500 To: Ted Hardie References: <5693396D.7080900@redhat.com> From: Paul Wouters X-Enigmail-Draft-Status: N1110 Message-ID: <569405DA.7000403@redhat.com> Date: Mon, 11 Jan 2016 14:43:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: X-Mailman-Approved-At: Mon, 11 Jan 2016 20:07:05 -0800 Cc: dnsop@ietf.org, draft-ietf-dnsop-edns-chain-query.all@ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPS-Dir review of draft-ietf-dnsop-edns-chain-query-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:43:25 -0000 On 01/11/2016 02:05 PM, Ted Hardie wrote: >> I'm a little confused. Do you mean the justification of the COOKIE >> requirement needs more justification, or >> the edns-query-chain option itself needs more justification. I would hope >> the latter is clear - it reduces the >> need for either multiple latency bound round trips or many parallel >> queries and their callbacks. >> >> > ​Sorry that I wasn't clear enough here. I'm not asking for a justification > of the COOKIE, I'm wondering how often this will work over UDP. Since the > basic issue is that response sizes needed for validation ​may be large, and > the cookie will add between 15-40 bytes, it's not clear to me what range of > UDP payload sizes would actually allow you to use this mechanism over UDP. Oh I see. I would expect most chains to be only 1-2 segments long, so I think those will fit in a UDP packet, but I have not yet done any careful calculations of that. Obviously, this option fits much better with edns-tcp-keepalive based (long lived) connections, but I think a lot of the time UDP will work fine, even with the COOKIE. > If I understand your answer correctly, you are saying that the small number > of bytes here doesn't change distribution of responses that fit into UDP > significantly. ("The additional size of the COOKIE is not really a problem > here. Those would be very few bytes compared to an abusive long chain that > an attacker could be asking for.") If the working group believes that's > the case, that's fine. It might be useful to include a bit of text in the > introduction indicating that this is the expectation, but that sort of text > in archival documents is definitely a matter of taste. That answer was more in reply to amplification abuse, and not so much in response to regular operation. > > >>> Is there a >> ​ ​ >> reason for limiting partial answers to the top-most hierarchical >>> responses? If so, could the document include it? >> >> The reason for limiting the answer from the top down is that it enables >> the querying >> client to extend its own chain further down, and send a new query for the >> same data >> with the updated Closest Trust Point further down. This method guarantees >> that the >> DNS client can work its way to the answer. >> >> If the server decides to send other parts of the chain, the client has to >> modify its >> query target in an attempt to get the top part of the chain it did not >> get. And it has >> no guarantee that the next query will give it another useful hunk of the >> chain. >> >> Additionally, assuming the DNS client to DNS server connection is of high >> latency, and >> the DNS server itself has a low latency uplink, it might actually do the >> DNS client a >> disservice giving it part of the chain instead of querying to create the >> full chain. It >> would also be guessing as to whether the full chain is likely to fit or >> not. >> >> To me, such strategies seem overly complicated, and require more code on >> the DNS client >> implementing handling unexpected partial answers. The top down cut-off >> seems much simpler >> to me. But let's ask the working group as well what they think. >> >> > ​I think a short statement like "This strategy somewhat limits the > opportunity to > use cached data but results in lower code complexity for clients by > allowing them > to retain a common query target after a partial answer" would cover this and > might be useful. Are there any others that would think this paragraph would be useful to add? I have no objection to it, but also don't really see the need to write this out. >>> To resolve this, the client would have to be able to detect when the >> ENDS0 >>> option is suppressed by the path, versus not offered by a Recursive >>> Resolver. Some further text on how this is discerned would be useful; >>> absent a method, I believe the text in 5.3 is sufficient and 6.5 not >> useful >>> beyond the points made in RFC 6891. >> >> How about removing section 6.5, but moving the one sentence in there: >> >> A fallback strategy similar to that described in [RFC6891] section >> 6.2.2 SHOULD be employed to avoid persistent interference due to non- >> clean paths. >> >> to the end of section 5.3? Would that resolve your issue? >> >> ​Yes, that seems to work.​ Great, done in my draft. (Still waiting on Tim or Joel to tell me if I should wait or push a new version now we are in the middle of the LC) > > >>> >>> Nits: >>> >>> The abstract uses the term "security aware validating Resolver". This >> use >>> of "security aware" appears to be the term of art used in RFC 4033, but >>> that may not be obvious; perhaps "DNSSEC validating resolver" would be >> more >>> clear for an abstract? >> >> RFC-7719 DNS Terminology marks all of these terms as "have caused >> confusion". I am fine with DNSSEC validating resolver", but I would like to >> punt this question >> to the authors of RFC-7719. I'll ping them offlist if they miss this >> message on the dnsop list. >> >> > ​Fair enough; I'm happy to go along with their advice, whatever it may be.​ Ok, I have this item pending hearing from some more people. >>> In section 6.3, the document says: >>> >>> In the event that there is greater demand for Chain Queries than can >>> be accommodated, DNS servers may stop advertising the CHAIN option in >>> successive DNS messages. This allows, for example, clients with >>> other candidate servers to query to establish new sessions with >>> different servers in expectation that those servers might still allow >>> Chain Queries. >>> >>> Given that this would also apply to UDP CHAIN queries, it is not clear >> why >>> this is in the TCP Session Management section. >> >> Correct. How about renaming section 6.3 from "TCP session management" to >> "session management" ? >> >> > ​Sounds good. Done on my copy as well. Thanks for the prompt reply! Paul From nobody Wed Jan 13 14:31:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4861A8742 for ; Wed, 13 Jan 2016 14:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzMHNWUCBwb8 for ; Wed, 13 Jan 2016 14:31:08 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 A30241A873C for ; Wed, 13 Jan 2016 14:31:07 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id x4so42418822lbm.0 for ; Wed, 13 Jan 2016 14:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=bwO3meZdpAm5YR7bt4f9G7cJ0v7lBdHIID9ryxtCdrU=; b=kWNDY4CUMHp3VmrGWdqMOIOUseqnX8SKJWO1dAElqBWO9ULW0Ci9Y/A5s2kpJyQ2cg Iww1ih9bHP442qX4wj6jtsnH34GdaoRl8hCHkk6tNnFlDyfb3m9447kNEpsqpDQY4Eid DiJp1N96H0JvcszD3MCVlMGZ9MX5FNlAb/ZkM2FnC4GWMA4p6GO+Zv7nDFtkgTSC080n KtXcxOnyUqvpEyCqFNFWGYNZYFWbuewure3ewm5nEm1XHRIO7AQTAKVhHpATU0lm1LEe QAGX85IbHR6yJsbQ2ZEypJzlmzUEsuUWUabdOOTY3dqVjuqOfeh/dawkutYdnUAcgGI/ EARQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=bwO3meZdpAm5YR7bt4f9G7cJ0v7lBdHIID9ryxtCdrU=; b=NHdTtoAvrH0zttiywuRFmNlHZhaMFpCI6hi49zZKZm/A9FfW6JkDX/5k/cKid4ITC0 bTReSawBcPOPg4S1ywwd2O/6y6Way0PGwiclbntZNNpNb3jyc520xD7X8S7zDj3CK/xi APuGoukdVjtjsWa4ro2OgDdoZGGA0fMUtRm2qB3VDk+ZnYa57fnrQqAO9IQ51YvU6wmd Xt5dN4Y37hI/HoErx48v3e4PlyHvckGXkboNJ5sC5PSYXXF+lMUrNb5bWYXaq84SSM/H AmPA5SKFF+AQCWfV3ru1m0XY40fj4PH42SgHoBD+jVjAdJ4Nr6PHisNpQBL/kU9Gi7Oj r0iQ== X-Gm-Message-State: ALoCoQlyulZ0Ryz8T7BjxER4XtS37ijk2Ht2ZNWdBefL2xldpndUKcsQ9xt3+7opOxfEKqrtVQrlHPO2qzuO6UDslflpCppNIA== MIME-Version: 1.0 X-Received: by 10.112.199.197 with SMTP id jm5mr171811lbc.109.1452724265602; Wed, 13 Jan 2016 14:31:05 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Wed, 13 Jan 2016 14:31:05 -0800 (PST) Date: Wed, 13 Jan 2016 17:31:05 -0500 X-Google-Sender-Auth: JPNRISRmdEYkMW6O8IXyUiWY7k8 Message-ID: From: Phillip Hallam-Baker To: General discussion of application-layer protocols Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 22:31:09 -0000 Last week I released my set of build tools for specifications and services on sourceforge. https://sourceforge.net/projects/phb-build-tools/ One of the tools is a JSON protocol compiler. This makes it really easy to write a Web Service, all the code required to map API data to HTTP messages is done for the programmer. The tools also create entries for the reference section in the spec. I am just writing a note on the conventions that are used to perform this mapping which I will forward to the list in due course. In short I could not care less what the mapping is but I do care that everything does things in the exact same way and the approach respects sound principles of layer abstraction etc. Now for the problem. This is how I describe the discovery process: "Beginning with a DNS address of the service (e.g. example.com), the client identifies a specific HTTP URL at which to access the service. The DNS SRV record [!RFC2782] and Well Known Service [!RFC5785] mechanisms are used for this purpose." So the basic idea is that given an address 'example.com' and a protocol 'mmm', the client first attempts to resolve a host using an SRV lookup: _mmm._tcp.example.com 0 5 80 host1.example.com Having found our host, we now use it to construct the web service endpoint: To: host1.example.com POST /.well-known/mmm/ Host: example.com OK, so the spec is all well and good. The problem is that to make this work, I need two separate registrations. One for the SRV record and a second for the Well Known. That might be acceptable but the next bit really is not, getting an SRV record is first come first served, getting a Well Known is specification required. This is an inconsistency in approach for a start. The two registrations serve essentially the same purpose, there should be essentially the same approach to registration. I attempted to bring this up with the author but the response was 'people decided different'. Well now I am pointing out that the result is inconsistent. In general we should encourage as many people as possible to be using the IANA registries and put as few obstacles in their way as possible. We should not worry about the possibility of 'damaging the Internet'. The people I deal with on a daily basis have been actively attempting to destroy it for two decades without much success. And the biggest potential for causing problems in this particular case is two people attempting to use the same identifier - the very problem that the registry is there to avoid. I will also note that the use of the .well-known registry has been negligible to date http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml I suggest we adopt one of two solutions to this: 1) Make the criteria for listing the same as SRV (first come) 2) Delete the registry completely and fold it into the Well Known protocols registry used for SRV so that anyone registering an SRV protocol access prefix will get the Well Known automatically. From nobody Wed Jan 13 19:36:07 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BED1A8942 for ; Wed, 13 Jan 2016 19:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PpprP9uaELUZ for ; Wed, 13 Jan 2016 19:36:03 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4FD1A893C for ; Wed, 13 Jan 2016 19:36:03 -0800 (PST) Received: from [192.168.1.57] (unknown [115.70.207.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 114B322E200; Wed, 13 Jan 2016 22:36:00 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Thu, 14 Jan 2016 14:35:57 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 03:36:06 -0000 SRV isn't used by HTTP, so I'm not seeing a strong motivation for = aligning the policies. Given that .well-known is a mechanism for = allocating a URL on *every* Web server on the planet, and that space is = ceded to standard uses by server authorities (the actual owners of that = name space), having a higher bar to entry than FCFS seems like a good = idea.=20 > On 14 Jan 2016, at 9:31 am, Phillip Hallam-Baker = wrote: >=20 > Last week I released my set of build tools for specifications and > services on sourceforge. > https://sourceforge.net/projects/phb-build-tools/ >=20 > One of the tools is a JSON protocol compiler. This makes it really > easy to write a Web Service, all the code required to map API data to > HTTP messages is done for the programmer. The tools also create > entries for the reference section in the spec. >=20 > I am just writing a note on the conventions that are used to perform > this mapping which I will forward to the list in due course. In short > I could not care less what the mapping is but I do care that > everything does things in the exact same way and the approach respects > sound principles of layer abstraction etc. >=20 >=20 > Now for the problem. This is how I describe the discovery process: >=20 > "Beginning with a DNS address of the service (e.g. example.com), the > client identifies a specific HTTP URL at which to access the service. > The DNS SRV record [!RFC2782] and Well Known Service [!RFC5785] > mechanisms are used for this purpose." >=20 >=20 > So the basic idea is that given an address 'example.com' and a > protocol 'mmm', the client first attempts to resolve a host using an > SRV lookup: >=20 > _mmm._tcp.example.com 0 5 80 host1.example.com >=20 > Having found our host, we now use it to construct the web service = endpoint: >=20 > To: host1.example.com > POST /.well-known/mmm/ > Host: example.com >=20 > OK, so the spec is all well and good. The problem is that to make this > work, I need two separate registrations. One for the SRV record and a > second for the Well Known. That might be acceptable but the next bit > really is not, getting an SRV record is first come first served, > getting a Well Known is specification required. >=20 > This is an inconsistency in approach for a start. The two > registrations serve essentially the same purpose, there should be > essentially the same approach to registration. >=20 > I attempted to bring this up with the author but the response was > 'people decided different'. Well now I am pointing out that the result > is inconsistent. >=20 > In general we should encourage as many people as possible to be using > the IANA registries and put as few obstacles in their way as possible. > We should not worry about the possibility of 'damaging the Internet'. > The people I deal with on a daily basis have been actively attempting > to destroy it for two decades without much success. And the biggest > potential for causing problems in this particular case is two people > attempting to use the same identifier - the very problem that the > registry is there to avoid. >=20 > I will also note that the use of the .well-known registry has been > negligible to date > http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml >=20 >=20 > I suggest we adopt one of two solutions to this: >=20 > 1) Make the criteria for listing the same as SRV (first come) >=20 > 2) Delete the registry completely and fold it into the Well Known > protocols registry used for SRV so that anyone registering an SRV > protocol access prefix will get the Well Known automatically. >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 13 19:43:44 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7868F1A897D for ; Wed, 13 Jan 2016 19:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sV-VRVBiceYT for ; Wed, 13 Jan 2016 19:43:40 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F97E1A897A for ; Wed, 13 Jan 2016 19:43:40 -0800 (PST) Received: from [192.168.1.118] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id D4E20200AE; Thu, 14 Jan 2016 04:43:38 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Mark Nottingham" Date: Thu, 14 Jan 2016 04:43:38 +0100 Message-ID: <3031216E-42F9-4A5E-BB39-ABC9BE59B724@frobbit.se> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_ED3721C2-F7FC-41A2-9519-97E576B0CD86_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: Daniel Stenberg , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 03:43:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_ED3721C2-F7FC-41A2-9519-97E576B0CD86_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This goes back to the preference of one group of people to have things in= DNS (like the URI resource record) and via DNS lookup know what URI to f= etch over HTTP, and the preference from another group of people to have t= he redirect in HTTP from a well known URI to whatever URI to fetch over H= TTP. And we have had this discussion the now last 20 years. Without reall= y resolving it. We all use our favorite tools, right? ;-) My point is that regardless of whether method A or method B is in use, ea= ch one of them should be allowed to in the IETF to be designed properly. What is actually deployed is what Daniel implements in libcurl anyway, ri= ght? :-D Patrik On 14 Jan 2016, at 4:35, Mark Nottingham wrote: > SRV isn't used by HTTP, so I'm not seeing a strong motivation for align= ing the policies. Given that .well-known is a mechanism for allocating a = URL on *every* Web server on the planet, and that space is ceded to stand= ard uses by server authorities (the actual owners of that name space), ha= ving a higher bar to entry than FCFS seems like a good idea. > > > >> On 14 Jan 2016, at 9:31 am, Phillip Hallam-Baker wrote: >> >> Last week I released my set of build tools for specifications and >> services on sourceforge. >> https://sourceforge.net/projects/phb-build-tools/ >> >> One of the tools is a JSON protocol compiler. This makes it really >> easy to write a Web Service, all the code required to map API data to >> HTTP messages is done for the programmer. The tools also create >> entries for the reference section in the spec. >> >> I am just writing a note on the conventions that are used to perform >> this mapping which I will forward to the list in due course. In short >> I could not care less what the mapping is but I do care that >> everything does things in the exact same way and the approach respects= >> sound principles of layer abstraction etc. >> >> >> Now for the problem. This is how I describe the discovery process: >> >> "Beginning with a DNS address of the service (e.g. example.com), the >> client identifies a specific HTTP URL at which to access the service. >> The DNS SRV record [!RFC2782] and Well Known Service [!RFC5785] >> mechanisms are used for this purpose." >> >> >> So the basic idea is that given an address 'example.com' and a >> protocol 'mmm', the client first attempts to resolve a host using an >> SRV lookup: >> >> _mmm._tcp.example.com 0 5 80 host1.example.com >> >> Having found our host, we now use it to construct the web service endp= oint: >> >> To: host1.example.com >> POST /.well-known/mmm/ >> Host: example.com >> >> OK, so the spec is all well and good. The problem is that to make this= >> work, I need two separate registrations. One for the SRV record and a >> second for the Well Known. That might be acceptable but the next bit >> really is not, getting an SRV record is first come first served, >> getting a Well Known is specification required. >> >> This is an inconsistency in approach for a start. The two >> registrations serve essentially the same purpose, there should be >> essentially the same approach to registration. >> >> I attempted to bring this up with the author but the response was >> 'people decided different'. Well now I am pointing out that the result= >> is inconsistent. >> >> In general we should encourage as many people as possible to be using >> the IANA registries and put as few obstacles in their way as possible.= >> We should not worry about the possibility of 'damaging the Internet'. >> The people I deal with on a daily basis have been actively attempting >> to destroy it for two decades without much success. And the biggest >> potential for causing problems in this particular case is two people >> attempting to use the same identifier - the very problem that the >> registry is there to avoid. >> >> I will also note that the use of the .well-known registry has been >> negligible to date >> http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml >> >> >> I suggest we adopt one of two solutions to this: >> >> 1) Make the criteria for listing the same as SRV (first come) >> >> 2) Delete the registry completely and fold it into the Well Known >> protocols registry used for SRV so that anyone registering an SRV >> protocol access prefix will get the Well Known automatically. >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=_MailMate_ED3721C2-F7FC-41A2-9519-97E576B0CD86_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlaXGWoACgkQrMabGguI183WvwCffYGCzwbeNIjwXirIDVMMcGd4 LhcAnib4Ls5jU2uC7n8I7rvtIWy/DIDb =9I3q -----END PGP SIGNATURE----- --=_MailMate_ED3721C2-F7FC-41A2-9519-97E576B0CD86_=-- From nobody Wed Jan 13 21:26:07 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F781A90A0 for ; Wed, 13 Jan 2016 21:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXIHoTkWJdqk for ; Wed, 13 Jan 2016 21:26:04 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 978DA1A886D for ; Wed, 13 Jan 2016 21:26:04 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id l65so322738015wmf.1 for ; Wed, 13 Jan 2016 21:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Z/VfROVy5+g2xzfWUbQFXfEa4l7G1VhML72F0uuowZs=; b=emF+KOfgVbKv6LxbzonKwnk0VxxMTnsIHs364ZbO5xIp3QwuhXBJEIfls+n7iIqzCf 4akp3TKIgxNuWmElJx9ak02AIcb0hJr6OY+AYDijVbQGC4He7+0WHAoxWJAF+K7j8Mp+ wsx51PqgQIqs/YFD9KKP1O6rvLI6WSUpUrIEl8D53fp2vmbkg6TDyGR1rolhnjVs8Krs njgiM6u5i+suCa336NCbADtkB/KohefuZBNM58okQNVbpFJzkZW7Z2IDYKUrnmDI4/Sj NQDjO0/XXl7+2+6D/wzRteRgHJ6aUn6JRM3AI04lptbP2vpOpQCPC8OIbmZKnnORK44/ Vsnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z/VfROVy5+g2xzfWUbQFXfEa4l7G1VhML72F0uuowZs=; b=HJPFcyBNvqGdcFCCajMMJ2dNmLq8FfSIFNAMKs9/adq/p7CI5mHV8Aq15qwAa6+pYY 9uNMyxRFV/F8K9x8rod9FSVlBtVG8gBvbqr1ATld7kGSePT0plI6cbGUS/VX4ofkbalO ZryQ7mSjyVXU36qH3G35fA1+AyWDWcEtd3DVzPuaqR2fYhYzMMLC/D6QZR9eoaaP169F aoPPHjvq4md6aRcN7kSVYJTgdUtdVCns5U5Eps4YxDYw0oQ0kM76gbhYL6V8L1+GDiqB +y+VGgbmQFI+x/ESa/stbe9DIbIHt/JnLUU7nMS8LuOLTOWx+R/xwJ2FscKRhcrlQju4 SLlw== X-Gm-Message-State: ALoCoQlGM+3aYh1bUWlzdEaecUBJfXeIMelsEd62OhVU/wzDcfnU0GEi6TGw+ReRgmx/JgW0J1FG9biTPT2V4FclDyZPQbw46g== MIME-Version: 1.0 X-Received: by 10.25.168.15 with SMTP id r15mr508550lfe.166.1452749163203; Wed, 13 Jan 2016 21:26:03 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Wed, 13 Jan 2016 21:26:03 -0800 (PST) In-Reply-To: References: Date: Thu, 14 Jan 2016 00:26:03 -0500 X-Google-Sender-Auth: ic2d7hdvhr6R0Tk4vHoDSA7k0SM Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 05:26:06 -0000 On Wed, Jan 13, 2016 at 10:35 PM, Mark Nottingham wrote: > SRV isn't used by HTTP, so I'm not seeing a strong motivation for alignin= g the policies. Given that .well-known is a mechanism for allocating a URL = on *every* Web server on the planet, and that space is ceded to standard us= es by server authorities (the actual owners of that name space), having a h= igher bar to entry than FCFS seems like a good idea. SRV is used for discovery of many Web Services. The obvious pattern being: 1) Resolve the DNS address to a host using the SRV record 2) Use the .well-known convention to identify the service endpoint on the specified host. I do not see the logic in your assertion that space is being reserved on every Web server on the planet. That was already done when .well-known was allocated in the first place. The question now being how to best prevent conflicts within that space. Having to pass through a review to get a code point allocation is empirically the least effective way of avoiding conflict. Since I have a code generator I can simply write something into the tool to generate the request for the code point allocation and send it to the registry review expert but I suspect that would not be appreciated. From nobody Wed Jan 13 21:34:30 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899F71A90F1 for ; Wed, 13 Jan 2016 21:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EplbkKbozrCq for ; Wed, 13 Jan 2016 21:34:27 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4801A90F4 for ; Wed, 13 Jan 2016 21:34:27 -0800 (PST) Received: from [192.168.1.57] (unknown [115.70.207.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B75F922E1F4; Thu, 14 Jan 2016 00:34:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Thu, 14 Jan 2016 16:34:22 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 05:34:29 -0000 You can also register /.well-known/phks-protocols/ and do whatever you = like under it. > On 14 Jan 2016, at 4:26 pm, Phillip Hallam-Baker = wrote: >=20 > On Wed, Jan 13, 2016 at 10:35 PM, Mark Nottingham = wrote: >> SRV isn't used by HTTP, so I'm not seeing a strong motivation for = aligning the policies. Given that .well-known is a mechanism for = allocating a URL on *every* Web server on the planet, and that space is = ceded to standard uses by server authorities (the actual owners of that = name space), having a higher bar to entry than FCFS seems like a good = idea. >=20 > SRV is used for discovery of many Web Services. The obvious pattern = being: >=20 > 1) Resolve the DNS address to a host using the SRV record >=20 > 2) Use the .well-known convention to identify the service endpoint on > the specified host. >=20 > I do not see the logic in your assertion that space is being reserved > on every Web server on the planet. That was already done when > .well-known was allocated in the first place. The question now being > how to best prevent conflicts within that space. >=20 > Having to pass through a review to get a code point allocation is > empirically the least effective way of avoiding conflict. >=20 > Since I have a code generator I can simply write something into the > tool to generate the request for the code point allocation and send it > to the registry review expert but I suspect that would not be > appreciated. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 13 21:37:47 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8B1A9100 for ; Wed, 13 Jan 2016 21:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtxA-FEzdAoK for ; Wed, 13 Jan 2016 21:37:45 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 2D6061A90FD for ; Wed, 13 Jan 2016 21:37:45 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id f206so323947017wmf.0 for ; Wed, 13 Jan 2016 21:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=p8hYwOgpV4+xsG6/2CmEByKugeZkZ2Dmx+JF4jobeQY=; b=Q/TRtQu90cid6Kyqq+A1MWxzMg/coTeeM8iJc9+2dN9Hm0xUxTGy9k7lspia3TYLxy kLJ6aQ6EuSzS/LRAiPN7JJ/ElFDPMTTjfqVfvqIdSCFcx1tNxcgzjLzBMRgyDU9Pdj/o lkFLFjzC6QZYp+fey15y208iJfCAVmwjfkKtAyoJYyyRRdePaold5IfBWQHDbxu6zZo9 aort4aJsSjQZ04x4mxvyAAvQ6/Zc2VvUm3H2POUtZaZ7PUmTiNPJi1ffPRTiCn46e+V1 cbMTsZpx1E6iQgh8aYSDhw4MmHYmpdiwKeqv2eiI8Cnm/riwXraMt08g6gBvGDtYbwQn Dbaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p8hYwOgpV4+xsG6/2CmEByKugeZkZ2Dmx+JF4jobeQY=; b=QUFLD5I6Kx3P49eXvO5UN4uxgtrs3V8FHgWIQog/jJU2SfDZ/ZjUFFM+IL//dAFYmD YoXmaUgbxt9KVP0Zf30+PS92kq5/KeUoW9UE82oB3/eNVCeq8DdadokD5Dh/0oizTZIT 49sa+y426d6c7X+Yrer7GiLz3xBt1tg11YeRCibKRCrRiOs5JFdYBz/YgCOB/Y+CcO/E qf4qpWpqcjUIvCSTvrYBttGXyvswWS2PRToHaRivJmF0BDETbre0m5gQmpENyEW47YJ7 EULqKTzlBqlTRAM/4u7lS7tNvNDrdPoLMXXdOKvhTsAdJvH/YoIHMzPdkz7h868T0Fil /dtQ== X-Gm-Message-State: ALoCoQkqZw0A9P6jvnmE8OEX5ZYPYrX3feLexOOmasTHqsrpcw3Qn3v0z04aEjE0S64dLU6HZfTIC4Y0oBlXFAmcN02+E0r07Q== MIME-Version: 1.0 X-Received: by 10.112.166.100 with SMTP id zf4mr617164lbb.58.1452749863731; Wed, 13 Jan 2016 21:37:43 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Wed, 13 Jan 2016 21:37:43 -0800 (PST) In-Reply-To: <3031216E-42F9-4A5E-BB39-ABC9BE59B724@frobbit.se> References: <3031216E-42F9-4A5E-BB39-ABC9BE59B724@frobbit.se> Date: Thu, 14 Jan 2016 00:37:43 -0500 X-Google-Sender-Auth: JYVGk6ATgJ5suSE26piTKMuB2aw Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mark Nottingham , Daniel Stenberg , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 05:37:46 -0000 On Wed, Jan 13, 2016 at 10:43 PM, Patrik F=C3=A4ltstr=C3=B6m wrote: > This goes back to the preference of one group of people to have things in >DNS (like the URI resource record) and via DNS lookup know what URI to >fetch over HTTP, and the preference from another group of people to have >the redirect in HTTP from a well known URI to whatever URI to fetch over >HTTP. And we have had this discussion the now last 20 years. Without >really resolving it. There are two models of Internet development. One is to let chaos reign and the other is to keep control at all costs. The first invariably wins in the end. Existing practice is that most developers simply ignore the registration process unless they are proposing the protocol to the IETF. I know about the URI record of course. I just can't use it with my service provider which is a very large one using the same DNS configuration tool used by most of the other service providers. Deployment of new DNS record types remains a challenge. > We all use our favorite tools, right? ;-) No, I use the tools that are expedient and get the job done. Since I want to make use of service identifiers inside other identifiers, there is actually a real difference to me between example.com and http://example.com/foo/bar. I can use the first to construct a reasonable account identifier for the service: alice@example.com I really don't think people will accept identifiers of the form alice@http://example.com/foo/bar And no, that isn't as far fetched as it might sound. The original OpenID proposal was to use URLs for user identifiers. And the people involved were utterly wedged on that lunacy (someone had a patent on a scheme to make the names friendly). > My point is that regardless of whether method A or method B is in use, ea= ch one of them should be allowed to in the IETF to be designed properly. +1 absolutely. > What is actually deployed is what Daniel implements in libcurl anyway, ri= ght? :-D Not in this case as these are all Web Services that are built way above the level of 'fetch data'. From nobody Wed Jan 13 21:44:47 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B101A910E for ; Wed, 13 Jan 2016 21:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCRgx_F9IBH8 for ; Wed, 13 Jan 2016 21:44:44 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 084541A910B for ; Wed, 13 Jan 2016 21:44:44 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f206so324156970wmf.0 for ; Wed, 13 Jan 2016 21:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8GGHA3xAFbMySNnhz07WlfrbzDPHoprEEz3j5z5utRk=; b=a5pyXFH88P+qlC2mP5V5YHR24zYoyyfbWq+NbKG/a0JDZgCM+15Xt3DoEQfYKxeu0Y Q82LLc6DWAF+PUHRX3yQKG7+XhbwgbOenhKA/Kq0ZD2rjKeti1/+UASyrm2oLwkSXxWN koI56YXc/Bffw/CvV+5OxZ9sV4/AkvRY8eQ9IX3DlrNNeHnk5Vz5EU9BKsoMoOZvFjNz ZZaZy2TWWZ1Ybw9w58Vwj+KLil6knibXWBGMo/qdrNKdMO1OWF3MgnRb4Mgt7tNK+Ogy lDyjTZ9mhUBrnyPnu0tVJKv4Ys22OjXFZ8s3cHdMifuUUK+/Vx8+EMHfkS6qidOyL3Dz ZQ1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8GGHA3xAFbMySNnhz07WlfrbzDPHoprEEz3j5z5utRk=; b=BTT+jqcf9CadNFH5Sk+yaC/R43Qq3IzqcrmYKMkRa8DSDeoZZBxhskTqKDQEGmiUDW Un4/JhAlxPTWcXVxT57CmLTouUIM4XLHLHDP7f/3ernSiphs487RpgI0b/vD3RWUDXVy 1bh+sLY3HE5OnkbNXhfhR6J334qIf/4CPvNi87gKxZnzrZMFaY1vhAzPcUoOulXdEebz YSHM1+X99FLWgqsi7joHaBpfdFVh3/WE0rDD2fdGOQbwPfb2vKB6dIjuqUcBCskhzvf6 GafA3qqIb13o7RzFItJ0agtbeyYOnacxSGIoUGXyKRB7exK59+joVl7j29fDUtOwbRbU 8VfA== X-Gm-Message-State: ALoCoQkNnaiysxud/THaCHhGOn5fJ1jsoVlIwv8Qxoph7Nu81iZWCyJJNFcLU9BEQOB4t6ofQrQUTjG88avfru3sIwFM5TupQA== MIME-Version: 1.0 X-Received: by 10.25.156.198 with SMTP id f189mr623753lfe.70.1452750282654; Wed, 13 Jan 2016 21:44:42 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Wed, 13 Jan 2016 21:44:42 -0800 (PST) In-Reply-To: References: Date: Thu, 14 Jan 2016 00:44:42 -0500 X-Google-Sender-Auth: 9OSomc-SCvgxyVflPK75pIYh5Ok Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 05:44:45 -0000 I would prefer something shorter, how about /.well-known/phb/ And since I would fill it with the well known services registry, shouldn't it be as short as possible. And isn't phb a little ego centric. I suggest /.well-known// That does exactly what I want (after canonicalization). Seriously, I am not buying the need to review here. On Thu, Jan 14, 2016 at 12:34 AM, Mark Nottingham wrote: > You can also register /.well-known/phks-protocols/ and do whatever you li= ke under it. > > >> On 14 Jan 2016, at 4:26 pm, Phillip Hallam-Baker = wrote: >> >> On Wed, Jan 13, 2016 at 10:35 PM, Mark Nottingham wrote: >>> SRV isn't used by HTTP, so I'm not seeing a strong motivation for align= ing the policies. Given that .well-known is a mechanism for allocating a UR= L on *every* Web server on the planet, and that space is ceded to standard = uses by server authorities (the actual owners of that name space), having a= higher bar to entry than FCFS seems like a good idea. >> >> SRV is used for discovery of many Web Services. The obvious pattern bein= g: >> >> 1) Resolve the DNS address to a host using the SRV record >> >> 2) Use the .well-known convention to identify the service endpoint on >> the specified host. >> >> I do not see the logic in your assertion that space is being reserved >> on every Web server on the planet. That was already done when >> .well-known was allocated in the first place. The question now being >> how to best prevent conflicts within that space. >> >> Having to pass through a review to get a code point allocation is >> empirically the least effective way of avoiding conflict. >> >> Since I have a code generator I can simply write something into the >> tool to generate the request for the code point allocation and send it >> to the registry review expert but I suspect that would not be >> appreciated. > > -- > Mark Nottingham https://www.mnot.net/ > > > > From nobody Thu Jan 14 04:07:51 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A971B33A0 for ; Thu, 14 Jan 2016 04:07:50 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 6G6qQt03zuKY for ; Thu, 14 Jan 2016 04:07:46 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0971B33A1 for ; Thu, 14 Jan 2016 04:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CeLmcz8anovgM5EIbn9eOhAPNOMePQXcko2qzqMJ+X8=; b=FtTTfYKiUvfrOjmAKdH7ZO/J6FDFQF4Vq20d1opOChmfQYO7vA89wMjH7yU9G+TBSFlhCBm462RNTwvX49z2z59EXvLCM4jBvE5nCp6IgHRK0e7hRTm+03z0MZxwjIUeHw5O3OtzYj9O6ix6uK0ePpOp5TG73bQc2ZKBTyIae0Q= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 14 Jan 2016 12:07:27 +0000 Message-ID: <048b01d14ec3$c4c52a20$4001a8c0@gateway.2wire.net> From: t.petch To: Phillip Hallam-Baker , Mark Nottingham References: Date: Thu, 14 Jan 2016 12:04:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: HE1PR08CA0009.eurprd08.prod.outlook.com (25.161.112.19) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB055; 2:WAaJFCoFqTTtYn5PoM3I0/pAtsmEtCpLw+hyKj90LWMRhhPOYSoEzL3JEd66HqTMyROqQ8jkQUSqmRhS4IcxL/YgO6HbhDxBxr25Z6lvvchezwf9UR5IQkSMbCP2TeYrbAzg7JAniT4i9SarOI+nvQ==; 3:hExb7kdrmtb1TTAxVbHPHCG1JdYi9n1CSgOWPOEQetmIPgYSGYvnqx8n9eJRCHFyvUE30Fe3hUZJwhxbZZMGvZgpbNlOY7UBlqCoIDlLUFg7GR2i/0e17v51OqEdQzlM; 25:xkaHu5bsOJZYmgym5RUlOubg6YEsobP8ed1JAmJYuyk7snJkkrFHucRqeCT4Q8tDlKxA+jVk5uOQmhHtlbmj4YVZbltws+rgYiCb7ZuklhxHjZwPkgsuttM7EnkXQZS5ipRpbjRxSKP6ahORQhHiiReiGzbhFScyE/4TyFh6Q7n10nS/rEGfNONFiXz9iSNTtPKra5PeSvVDGZHSfzz+hIfb99JJtYQwngitpfDGjeugGezNUNvHZn63AUii/Xdg; 4:GgAWcoyr8GBRXwbWdxL2M2DFB7KWMB8M8B04uozcv2p/jypKYwxljN4fRclSAusGhnbobArQnlla/w0MErvbSY6t3hmIYqj5TB9CLPS5vMcrsFZpl5KebEA90Fnrh+8IrWhkUnQiVBPRexi6RT5BLdUUVlsrVg2N6OEFsKqigSTsa8tDldcE4Ug7nzcVTAOwUDyRGdQEx5KBHxntcF+M8ouMz/E4Rd9z74vVBhcGRrGPHDAKztDnctMKAHBIORJ2Xwe+Rnz8i8cEUkF9uwn0V0/EEYRqdiaoK7wj81dY4OtvtUKQHQ2MwDyHVeRo3V2mrY23IyPlNyrr7wf2kjqhU98WZS0i4HX2yNr+og92T471o7zrsFOpBgRCUGHEqSOG X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-MS-Office365-Filtering-Correlation-Id: 6d9ed957-b256-4eea-481e-08d31cdb45d3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMXPR07MB055; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB055; X-Forefront-PRVS: 08213D42D3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(199003)(189002)(44736004)(92566002)(93886004)(33646002)(87976001)(81816999)(76176999)(81686999)(50466002)(86362001)(47776003)(50226001)(101416001)(19580405001)(66066001)(61296003)(106356001)(105586002)(19580395003)(1556002)(6116002)(42186005)(3846002)(5001960100002)(586003)(1096002)(5008740100001)(50986999)(62236002)(44716002)(1456003)(2906002)(97736004)(5004730100002)(5001770100001)(116806002)(15975445007)(14496001)(77096005)(40100003)(84392002)(189998001)(81156007)(230700001)(122386002)(4326007)(23756003)(74416001)(142923001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMXPR07MB055; 23:NrFftY4fWT5PuiJciPQWJO8SXF5qbFPYDSrsic7a?= =?iso-8859-1?Q?o99Nyvx2bESfAIl9lr3e3D2ve0UTDO8v1NHI+/SbQX8G63OUhzWs1BM7WE?= =?iso-8859-1?Q?kLJZ5nPfyy9EjGSzOJOuulNeCQ1Cl/c7/7fsrnDQNcq7fu7eiezlbrqGzi?= =?iso-8859-1?Q?2HUrXSi+M7grjkmtSnYd1JZu9MpSlYSt9DmPjwM5DLlFZzjmJOA71kF5LB?= =?iso-8859-1?Q?T1b8Kx7YilNOHJ3f7CUFe4Ie8sfembbd1Rnz3+ozEy7gZg1SNklvoemqmY?= =?iso-8859-1?Q?D/6EJihunEYRrtUjsopkZMHKuhbF6iDyjdnbd0mUo8TrWESx5MiDdefRne?= =?iso-8859-1?Q?p25Hjtkp0S1Sxqk1SQq3Z0S2cYbwdpwYmKM9sLu5I9loFUmoOZ0Uvchrh0?= =?iso-8859-1?Q?6GseZ0of3/6nMBMSwvMXwFJEYwNSowOxoKNgV4bH71PnWsf9uqI8DUSWrx?= =?iso-8859-1?Q?oDny5VT5oFJCkDJDKsBJEjMuRJ0t2iJ84LWJnc4SRjxSODUbT9fpBHNyKF?= =?iso-8859-1?Q?1UBTDSnMw4xKvZcjXac19t/wy3gBnq+V2PrvwzkvtWaja4Z6YCNA9hn5W6?= =?iso-8859-1?Q?6oK/gQO2jn4M0eIeUdBvWp3T4VOcW4K/iPL7PIwrde253NyDsUUaSZvUpV?= =?iso-8859-1?Q?13emVjqetVv9qHiDVoV/rvXwmwlV04GN8WCz3ccYQZRNUvRA185sxgVkB+?= =?iso-8859-1?Q?R8ImAoHFkr1FduLBB3vf9s1pKUMsq2kX+APPTVQQNJX1IgfFSfbjxfhSp7?= =?iso-8859-1?Q?R0mAc1HUbXMG8+WN5sGJ/QBtRQIlk3jvSwa8Kp0Vmr7md2yV1VhFc2AWpt?= =?iso-8859-1?Q?zc+Skw6QD2gLGO26Xb7XTvFzgWvfF1/vdXgkvcESTMqweB5vZLjSeW5KAe?= =?iso-8859-1?Q?jMSfF5K7BXUXbJdjJxus2rpcOjPwARkz3yN7JsVPXHTFPfj6SmPoDhBAqh?= =?iso-8859-1?Q?B9HS0gwR2TOPhLd9P0u4qCrgAYiPSL2fcIGL8/lsRqKR9f2+EHaDR8Nq3q?= =?iso-8859-1?Q?v8fTNKKUnOEVlJMtIIAXzfgJf7IiqeQcmExLVHEAybm64ox0flg/soYdYx?= =?iso-8859-1?Q?w0lp1sDn16tC0hSbeh/WyDjLlfIj54mc0H5wXnrP2bTb1hotC8eA+gspxv?= =?iso-8859-1?Q?mtGmfAJnKMGF/HLsiI/4Ux/3zDT44VRpAmvVTYXad2EwWx7uVZbB6N2xEE?= =?iso-8859-1?Q?zL+ypjwQCURSeDm8zsOgGFxwv1IveRBs6k1Q4ll7fQyuzdnAbFpv7ALdwa?= =?iso-8859-1?Q?y7e4+LSPNUDX73o22zk28EOYNdtjuGEKHx9rV0KPWwhT82+IW9EgiBWwn4?= =?iso-8859-1?Q?lcoNEUT0x3/dmGuUQy7MeJB6V8dwRzsN9qqe24Y76FvNJlRNV/smw6FJOd?= =?iso-8859-1?Q?UVdy9eKDAtjuocQtfwm78npF1z6NHYUN3nRJGKV16oOx0wCGvWwHh3nERT?= =?iso-8859-1?Q?fTlkH0Gcy58sheZzcqU1F9TZTRi8JHTPCl?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB055; 5:oVsoHCqxvvgmWEkZbOQ3X0lIngdOT0h+obX7nRejKYvdPsxCXOPSIE5WqBKdX5+J30bt+5t9B376LTjZ3o3NxK3AEs9Xe6qhPjQY9u4pWXZ1ihZfEn0hVNGO4xz1krVAMpO3ZLcX6jh4Krv1T21yww==; 24:gCJDJzUDs4aDB6qMgEDJwd3JcT34EvA8y49QxrFykCY1kKE0aZOGl1qHzcKZCm5JKtKY8cmR426b3dxm6yAoyKXuNsa//0RsUvGjnLJl7hM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2016 12:07:27.9737 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 12:07:51 -0000 ----- Original Message ----- From: "Phillip Hallam-Baker" To: "Mark Nottingham" Cc: "General discussion of application-layer protocols" Sent: Thursday, January 14, 2016 5:44 AM > I would prefer something shorter, how about /.well-known/phb/ > > And since I would fill it with the well known services registry, > shouldn't it be as short as possible. And isn't phb a little ego Per Hop Behavior? // is fine until it becomes /// or //// as in file:////// so I would prefer something short and pronounceable rather than just // such as /id/ /et/ etc Tom Petch > centric. I suggest /.well-known// That does exactly what I want (after > canonicalization). > > > Seriously, I am not buying the need to review here. > > > On Thu, Jan 14, 2016 at 12:34 AM, Mark Nottingham wrote: > > You can also register /.well-known/phks-protocols/ and do whatever you like under it. > > > > > >> On 14 Jan 2016, at 4:26 pm, Phillip Hallam-Baker wrote: > >> > >> On Wed, Jan 13, 2016 at 10:35 PM, Mark Nottingham wrote: > >>> SRV isn't used by HTTP, so I'm not seeing a strong motivation for aligning the policies. Given that .well-known is a mechanism for allocating a URL on *every* Web server on the planet, and that space is ceded to standard uses by server authorities (the actual owners of that name space), having a higher bar to entry than FCFS seems like a good idea. > >> > >> SRV is used for discovery of many Web Services. The obvious pattern being: > >> > >> 1) Resolve the DNS address to a host using the SRV record > >> > >> 2) Use the .well-known convention to identify the service endpoint on > >> the specified host. > >> > >> I do not see the logic in your assertion that space is being reserved > >> on every Web server on the planet. That was already done when > >> .well-known was allocated in the first place. The question now being > >> how to best prevent conflicts within that space. > >> > >> Having to pass through a review to get a code point allocation is > >> empirically the least effective way of avoiding conflict. > >> > >> Since I have a code generator I can simply write something into the > >> tool to generate the request for the code point allocation and send it > >> to the registry review expert but I suspect that would not be > >> appreciated. > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Jan 14 07:01:17 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC11B3541 for ; Thu, 14 Jan 2016 07:01:15 -0800 (PST) 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_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2Fz6wf0jYfHP for ; Thu, 14 Jan 2016 07:01:11 -0800 (PST) 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 0CB821B3538 for ; Thu, 14 Jan 2016 07:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1913; q=dns/txt; s=iport; t=1452783671; x=1453993271; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=tGZb4IKb06jATz3EZ8gj/6PcUNa3ryGJaUhN1bwahTA=; b=i2YFpr9mobcX8OfEf6gfoYU9VzN05Orzsd5mYTa+mcMDrIAVUVgKUw2v ykzgWw54lha1wezURWLySETwmC3AuLuFg5u3EB2ZYqCBp3YOzl8RhA906 aHbqZiSAE97/KODKTBoMdQ/UtZx+h+jzyngK7gcRfzF+BGmqvNq5VjPCL 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBADVtpdW/xbLJq1ehAyJSLEDhAWGD?= =?us-ascii?q?wKCAgEBAQEBAYELhDUBAQQjVQEQCw4KCRYLAgIJAwIBAgFFBgEMCAEBiCqwDJA?= =?us-ascii?q?9AQEBAQEBAQEBAQEBAQEBAQEBAREJi1WBPIY4gUkFjUGJVYJ0gWaJAYFeh0yFV?= =?us-ascii?q?4pmg3Nkgh4sgUE9hmUBAQE?= X-IronPort-AV: E=Sophos;i="5.22,294,1449532800"; d="asc'?scan'208";a="623493795" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2016 15:01:09 +0000 Received: from [10.61.201.9] ([10.61.201.9]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0EF18Hx023096; Thu, 14 Jan 2016 15:01:08 GMT To: Mark Nottingham , Phillip Hallam-Baker References: From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <5697B833.3000703@cisco.com> Date: Thu, 14 Jan 2016 16:01:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hcP1kjMKCLv2qN3WtUEpLcK7FSMr1gbIK" Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:01:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hcP1kjMKCLv2qN3WtUEpLcK7FSMr1gbIK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mark, On 1/14/16 6:34 AM, Mark Nottingham wrote: > You can also register /.well-known/phks-protocols/ and do whatever you = like under it. By your own words, that's simply not true unless there is a specification tied to it, and personally I think that's a very high bar. On the one hand this is not like port numbers- there are a near infinite number of possible subtrees under .well-known, as compared to the somewhat constrained port number space. On the other hand, one doesn't want to create a land rush on mnemonics. IMHO this is possible to fix. Simply allocate a random string of 8 characters or so for a developer to use (not for them to choose). This should suit developers who do not wish to publish their specifications or otherwise have reason to apply more meaning or structure as you mention in Section 3 of 5785, but otherwise do not wish to produce specifications. For those who still want a mnemonic, they can produce a spec. Eliot --hcP1kjMKCLv2qN3WtUEpLcK7FSMr1gbIK 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 iQEcBAEBCAAGBQJWl7g0AAoJEIe2a0bZ0noz1psIAJuZqBiNgE3jcVYSw3oraH9F yQlppiXAJFDXASVgagCuk3SH4+v8x/rd1VA8csa33sm1r8vqVQhl6OTyVgax+nI/ 1sp2q44EVspZZy0041ld1/GhCpPXAHIBHK1/MrZaR9KNvnWPAFjbfnKghw18W+bO tm35iaJpt2/U7jpMhIzFvCdIMnaKc4PrWs8ZbPApqAkTXPDCeeXnmOE8oLr3F0W/ iwRed45/CziG4GNoCJuhi2CBugPbgtFUotVrBArTbS5Q8kDLxY8mjeWFreh2isM8 wag4RafTx7WecaEqMvBCKfGcE9uXlwPEw4MUNOnNYmEjgon7Db4Pub9LCQyB8Ow= =lZji -----END PGP SIGNATURE----- --hcP1kjMKCLv2qN3WtUEpLcK7FSMr1gbIK-- From nobody Thu Jan 14 10:15:38 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60DA1A8789 for ; Thu, 14 Jan 2016 10:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 bHplLS8AQbqx for ; Thu, 14 Jan 2016 10:15:35 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3451A8785 for ; Thu, 14 Jan 2016 10:15:35 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 7096840133B1B; Thu, 14 Jan 2016 10:15:28 -0800 (PST) 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=0urHgeEZj1VPM+42zPK9PPiXm80=; b=hBkgIh/JzRSG8GlEzIQ7Q+sG3hGs eOxPGmGbFuophQrdSrPsY8F/mPgO/QN/o9KkC4N5gK7mvijraeGbWTRMAk/RZonq BE0ppRDOWA3rbscbj8txiuYMyDR2LgkK1inF2tt8qD2qdCQCTnrs83sCUBlp95Cm XKgg/AhLei32h5s= Received: from [192.168.1.2] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id E790640133B0D; Thu, 14 Jan 2016 10:15:26 -0800 (PST) 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: <5697B833.3000703@cisco.com> Date: Thu, 14 Jan 2016 10:15:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5697B833.3000703@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 18:15:37 -0000 > On Jan 14, 2016, at 7:01 AM, Eliot Lear wrote: >=20 > Mark, >=20 > On 1/14/16 6:34 AM, Mark Nottingham wrote: >> You can also register /.well-known/phks-protocols/ and do whatever = you like under it. >=20 > By your own words, that's simply not true unless there is a > specification tied to it, and personally I think that's a very high > bar. Why is it a high bar to require a written description of the identified space? It doesn't require an IETF spec. Mark is right -- if there is a spec of why the identifier exists, the owner can do anything with = further identifiers under that space. A review is desired because almost half = of all proposed uses of .well-known are poorly conceived and more = effectively accomplished with a single link. But the review does not require = consent. For example, PHB wants to do a standard name search of SRV after doing a DNS lookup and then use the SRV record to redirect to a reserved URI = space. Sorry, that is brain-numbingly poor use of those protocols. If the standard name is standard enough to use under .well-known, then it is standard enough to assign directly within DNS (just like www) by the same admin that would have crafted an SRV record, which saves two completely useless application redirects and a whole lot of ridiculous discussion on IETF registration lists. The discussion does not prevent a person from registering the space anyway, if they happen to be as stubborn as any one of us, but at least it gives us a record of why the identifier exists and maybe some legacy understanding of bad uses of that space. ....Roy From nobody Thu Jan 14 11:18:17 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BEB1AC3B3 for ; Thu, 14 Jan 2016 11:18:15 -0800 (PST) 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_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 PCnyOvgwiQNp for ; Thu, 14 Jan 2016 11:18:13 -0800 (PST) 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 B11581AC3B8 for ; Thu, 14 Jan 2016 11:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3391; q=dns/txt; s=iport; t=1452799090; x=1454008690; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=K6PyfZwNU+EwVLQEEzZpEnJOT+T6l/wshm1yU1RStgk=; b=AFg8d86YnHpaaQFJihiiPTqqXbtOZG0WzCBSDrtUO/S820qpZzIq38Cc +Rb+L/50STFZTVvg/hAAsxmfdvEeosWRzHd0ZKcFplXK+QSYZVSpuphEz O+/CqBww8c09e6+qjkrI9+fNqjEuTzzfPmW6VgZpgHz5vgxjv2GQFUHWz 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBAD685dW/xbLJq1ehAxtiFuxBIQFh?= =?us-ascii?q?g8CggkBAQEBAQGBC4Q0AQEBAwEjSA0BBQsLGAkWCwICCQMCAQIBRQYNBgIBAYg?= =?us-ascii?q?iCLAekEEBAQEBAQEBAQEBAQEBAQEBAQESCYtVgTyGOIFJBY1CiVSCdIFmiQGBX?= =?us-ascii?q?odMhVeKZoNzZIIeLIFBPTSGMQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,295,1449532800"; d="asc'?scan'208";a="623501284" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2016 19:18:08 +0000 Received: from [10.61.201.9] ([10.61.201.9]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0EJI8FM020490; Thu, 14 Jan 2016 19:18:08 GMT To: "Roy T. Fielding" References: <5697B833.3000703@cisco.com> From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <5697F46F.5050201@cisco.com> Date: Thu, 14 Jan 2016 20:18:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t87ktQmht2GiPUkc2KCjGVo4g3MNxW3q6" Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 19:18:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t87ktQmht2GiPUkc2KCjGVo4g3MNxW3q6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roy, On 1/14/16 7:15 PM, Roy T. Fielding wrote: >> On Jan 14, 2016, at 7:01 AM, Eliot Lear wrote: >> >> Mark, >> >> On 1/14/16 6:34 AM, Mark Nottingham wrote: >>> You can also register /.well-known/phks-protocols/ and do whatever yo= u like under it. >> By your own words, that's simply not true unless there is a >> specification tied to it, and personally I think that's a very high >> bar. > Why is it a high bar to require a written description of the identified= > space? It doesn't require an IETF spec. Quoting RFC 5785: > Well-known URIs are registered on the advice of one or more > Designated Experts (appointed by the IESG or their delegate), with a= > Specification Required (using terminology from [RFC5226]). However,= > to allow for the allocation of values prior to publication, the > Designated Expert(s) may approve registration once they are satisfie= d > that such a specification will be published. > That to me is problematic. And so a spec does have to exist, and then expert review has to happen. > Mark is right -- if there is a > spec of why the identifier exists, the owner can do anything with furth= er > identifiers under that space. A review is desired because almost half = of > all proposed uses of .well-known are poorly conceived and more effectiv= ely > accomplished with a single link. But the review does not require conse= nt. I don't exactly know what you mean by that last sentence. > > For example, PHB wants to do a standard name search of SRV after doing = a > DNS lookup and then use the SRV record to redirect to a reserved URI sp= ace. > Sorry, that is brain-numbingly poor use of those protocols. If the > standard name is standard enough to use under .well-known, then it is > standard enough to assign directly within DNS (just like www) by the > same admin that would have crafted an SRV record, which saves two > completely useless application redirects and a whole lot of ridiculous > discussion on IETF registration lists. > > The discussion does not prevent a person from registering the space > anyway, if they happen to be as stubborn as any one of us, but at least= > it gives us a record of why the identifier exists and maybe some legacy= > understanding of bad uses of that space. > Maybe that is the practice but that is not typical of other expert reviews, Roy. Eliot --t87ktQmht2GiPUkc2KCjGVo4g3MNxW3q6 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 iQEcBAEBCAAGBQJWl/RwAAoJEIe2a0bZ0nozVmwH/iSQh/NMKXqHQbN3mh3BeXMm iC4fpOb8Is88KDi7dTzBg8HCBQ17IqvqwPOQxYJN2xKZFtp2nA0JgJewTA+j+UH3 dScJSDV3AEY2XhVD5uSYEwWbWPV8j9pDj7yT5+c9au9y8awuIeDdczKh+LUnGnsT lZikQ4to1EfHEp4XkG3I+yDEoOxafvMhMwzywPt14GwjAgMj1mj8N7+iRnqXWZoN 1hG2qS1bzgg0mETJg7TUwmDXPGM43X4nCfrem1y5BqJfPwSaeXFFs+114jPXMqFY p7/d69N4G8i6uVV/mblsGaSID7T3Int8sSNenkp2iyzeJSW5KPNrsvYr+EsaFQc= =P7mD -----END PGP SIGNATURE----- --t87ktQmht2GiPUkc2KCjGVo4g3MNxW3q6-- From nobody Thu Jan 14 11:51:39 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283391AC427 for ; Thu, 14 Jan 2016 11:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d8XE8XjRXq5 for ; Thu, 14 Jan 2016 11:51:36 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 5EB611AC426 for ; Thu, 14 Jan 2016 11:51:36 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id m198so122439746lfm.0 for ; Thu, 14 Jan 2016 11:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dsnvAtPwhp3rfISOQhUXCb/lcnJThCUTNVzGGobrYtU=; b=awfxKy1eLx5GtYmho0m2mgVRC/pmz5QsDcV8yOQRl1NzogxfC6tkznHRVEGegB2Vk5 YWRfIgvuM153vK2k4pgdwCOgXSBZbS9FqRjuN9qD4JgSJni2077MaAu6Pi1nyKl4XTHZ w/2BiLUZlnUmhHDMVm6mQDU5bHg3EWkKYhYRQCDXbD32GM8rYmatpvJu7GNbYT28tH/W 1KciHLEcakbq0znlitHiVerYOGShZqw1E4zHsH2MK+X4K2NXDE2hgX+QEP/w1HDkPrnZ cFNpIhsk/TdOf+n72nOxGK05cTjfp2gx1EIzT5Qqw7DYi6KTKPQkBMf2W8OijWSEYUPN +YKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dsnvAtPwhp3rfISOQhUXCb/lcnJThCUTNVzGGobrYtU=; b=C12Pcsp+NLtB4VuxtcwN87QBxZLu1bMxq2tN0lZPv9hoSXobP5fxpDffKsZ8brr5yQ qfQt3IK8IDICBA7AfFVjzZ9AnZuqQkWVNON9hJ7Qpxla9HFDsn+ZqtGHpl8me80TVVtQ GkoXEsfHccg0VUO7BiUBGJUp3ZFWAPllwq1aLXKrqZQxlalrG6f3TSd/e1DUwVG3teMK GsxQ4QvRv6n0AUSpz+w3QSGbN8D62lsNqJ4E6MuPPCrthPKZohDb5FKUxqnHqyFi0erD RqIRSbTJD6cXKFEAZekABBn4PemaKHGv2SUwpuxE/ZLiviw6ih4rJcpKS2FytoPxGi4O B4hQ== X-Gm-Message-State: AG10YOSk/99/w04fhMER0WAh20esbkPIuNk3SqRIcpuNqkQdAyf7Fw6zOX6sofIYXF8i0re2zBj+gyBM1PDh9Q== MIME-Version: 1.0 X-Received: by 10.25.170.203 with SMTP id t194mr967335lfe.48.1452801094530; Thu, 14 Jan 2016 11:51:34 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Thu, 14 Jan 2016 11:51:34 -0800 (PST) In-Reply-To: References: <5697B833.3000703@cisco.com> Date: Thu, 14 Jan 2016 14:51:34 -0500 X-Google-Sender-Auth: 1iFlxY3gNLqyYZCcrgc67hird6Y Message-ID: From: Phillip Hallam-Baker To: "Roy T. Fielding" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 19:51:38 -0000 On Thu, Jan 14, 2016 at 1:15 PM, Roy T. Fielding wrote: > >> On Jan 14, 2016, at 7:01 AM, Eliot Lear wrote: >> >> Mark, >> >> On 1/14/16 6:34 AM, Mark Nottingham wrote: >>> You can also register /.well-known/phks-protocols/ and do whatever you like under it. >> >> By your own words, that's simply not true unless there is a >> specification tied to it, and personally I think that's a very high >> bar. > > Why is it a high bar to require a written description of the identified > space? It doesn't require an IETF spec. Mark is right -- if there is a > spec of why the identifier exists, the owner can do anything with further > identifiers under that space. A review is desired because almost half of > all proposed uses of .well-known are poorly conceived and more effectively > accomplished with a single link. But the review does not require consent. > > For example, PHB wants to do a standard name search of SRV after doing a > DNS lookup and then use the SRV record to redirect to a reserved URI space. > Sorry, that is brain-numbingly poor use of those protocols. How about you apologize for the insult and try again? You are certainly not expert enough in this space to be calling anyone or their proposal mind numbingly stupid. In fact it is precisely the attitude you are demonstrating here that is the reason why I want to eliminate the registry troll from this particular process. No, being a designated expert is not an excuse to piss over other people's proposals from a great height. I will explain the reason for my architecture after you have apologized. If the > standard name is standard enough to use under .well-known, then it is > standard enough to assign directly within DNS (just like www) by the > same admin that would have crafted an SRV record, which saves two > completely useless application redirects and a whole lot of ridiculous > discussion on IETF registration lists. > > The discussion does not prevent a person from registering the space > anyway, if they happen to be as stubborn as any one of us, but at least > it gives us a record of why the identifier exists and maybe some legacy > understanding of bad uses of that space. > > ....Roy > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Jan 14 12:00:45 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3771ACCD9 for ; Thu, 14 Jan 2016 12:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 On3DJc3O-5lx for ; Thu, 14 Jan 2016 12:00:42 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3D61ACD9F for ; Thu, 14 Jan 2016 12:00:36 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 9378D20070E36; Thu, 14 Jan 2016 12:00:25 -0800 (PST) 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=zp+vbNr6To85AAtq3W1aCKIR9jE=; b=pJn//wFJ9oa6n9uOLn8GnHxuvHam VqlCbBOQ0OiP/l+3HpwnxDez2XLy3CwDQa6QrFfj9vetMRsIhR+pJxbzvwHTfINh LcXGS4pZkbhsDdcZ1KyZwE6wD4t0dZXGFMctvQej1H1s08W97mbzn2hae6jDE5ea 9Aszwf8ulA/bnC8= Received: from [192.168.1.2] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 81A8E20069106; Thu, 14 Jan 2016 12:00:24 -0800 (PST) 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: Thu, 14 Jan 2016 12:00:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5697B833.3000703@cisco.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 20:00:44 -0000 > On Jan 14, 2016, at 11:51 AM, Phillip Hallam-Baker = wrote: >=20 > On Thu, Jan 14, 2016 at 1:15 PM, Roy T. Fielding = wrote: >>=20 >>> On Jan 14, 2016, at 7:01 AM, Eliot Lear wrote: >>>=20 >>> Mark, >>>=20 >>> On 1/14/16 6:34 AM, Mark Nottingham wrote: >>>> You can also register /.well-known/phks-protocols/ and do whatever = you like under it. >>>=20 >>> By your own words, that's simply not true unless there is a >>> specification tied to it, and personally I think that's a very high >>> bar. >>=20 >> Why is it a high bar to require a written description of the = identified >> space? It doesn't require an IETF spec. Mark is right -- if there = is a >> spec of why the identifier exists, the owner can do anything with = further >> identifiers under that space. A review is desired because almost = half of >> all proposed uses of .well-known are poorly conceived and more = effectively >> accomplished with a single link. But the review does not require = consent. >>=20 >> For example, PHB wants to do a standard name search of SRV after = doing a >> DNS lookup and then use the SRV record to redirect to a reserved URI = space. >> Sorry, that is brain-numbingly poor use of those protocols. >=20 > How about you apologize for the insult and try again? >=20 >=20 > You are certainly not expert enough in this space to be calling anyone > or their proposal mind numbingly stupid. I didn't. You read it that way. I am sorry that you read it that way, = given that I know you quite well to be extremely smart. That does not, = however, prevent you from using a protocol in a brain-numbingly poor way. The brain, in = question, is mine. Please, Phillip, don't for a second believe that you can abuse social = etiquette police as a way to silence criticism. That isn't a skill worth = displaying given the amount of criticism you have poured on others. ....Roy From nobody Thu Jan 14 19:08:09 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4128B1A88AE for ; Thu, 14 Jan 2016 19:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zFIbh8hJ0lA for ; Thu, 14 Jan 2016 19:08:05 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 3C4151A88A9 for ; Thu, 14 Jan 2016 19:08:05 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id cl12so90602488lbc.1 for ; Thu, 14 Jan 2016 19:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=vEaAEizepSpP7RuBAYSBm2P1oofD+NOy9zvpR0ARa6A=; b=k2rMoli7KWni964cmXQ3ho9Pa93D7XpA9Se3jeNpj5HUtk802aizmhd1g7lUrmmLzD SpQCrzTejcSECeIeWtMWabzoD0rugay9Tifc810XPjo3taNdAb5k10Tkg+ypfEMyrjA5 7l5aZi223TM4p3xdyi+UVFps3l7hF2f1JvROAeDT4dKIUTywGftkv+39sledZ0FVNKVa MlLWrxQrKXRCwjwHiHCv4yoqqra6fjUmCim3oZuNMZ7eJgi66XLwdzIvAFeDd29vavtQ JRRsdxQqkauuEsXBdabQbf6EJ04yNmI162A/h+UOt61p2DyhNa7UpBVoevWcrB5HzbtH UOUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vEaAEizepSpP7RuBAYSBm2P1oofD+NOy9zvpR0ARa6A=; b=OAvGpMjP+2gA6RnAxHhD56RTWMtlI5KUQAhu6SzZ/W3oB9Q2qNWoqR+DvL9me8q1ZJ Z7UltrAyJB3VNDFYIewqepWqhTtyQJb5sUOt7TC37MLiEV1of44XtvGQkl/ssJ7DElUS JxkvkTCba+xibxmJmDpbjo6tnBk53O3PsTY3PEXwKpBs8y8TOoclFYqudEFD+z4J7d57 043WL2LGt7nnO64rQtdJdLfbmis9TOGkzx+WU8JTfWXnoUT0018HtmIqzmiwXYWMSbp0 coFVLfyV9OKPQYN+Xau8Tt4Sj0BK+uuCBHYQJzXngWNRILjyfsu6lNg9pW8VJNj56ATu KXHQ== X-Gm-Message-State: ALoCoQllRL6ns++jjolDR/O9EZG2MsCSViaMzEoWEiU7RxJuBG99NJEH/eLMAQnes8Gf6+nmlBnkrWKcluxXkeO5I55D7iZtGA== MIME-Version: 1.0 X-Received: by 10.112.166.100 with SMTP id zf4mr2215574lbb.58.1452827283502; Thu, 14 Jan 2016 19:08:03 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Thu, 14 Jan 2016 19:08:03 -0800 (PST) In-Reply-To: <5697B833.3000703@cisco.com> References: <5697B833.3000703@cisco.com> Date: Thu, 14 Jan 2016 22:08:03 -0500 X-Google-Sender-Auth: QzFoTqOWXC9mymtq82cfvy6ldLU Message-ID: From: Phillip Hallam-Baker To: General discussion of application-layer protocols Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 03:08:07 -0000 On Thu, Jan 14, 2016 at 10:01 AM, Eliot Lear wrote: > Mark, > > On 1/14/16 6:34 AM, Mark Nottingham wrote: >> You can also register /.well-known/phks-protocols/ and do whatever you like under it. > > By your own words, that's simply not true unless there is a > specification tied to it, and personally I think that's a very high > bar. On the one hand this is not like port numbers- there are a near > infinite number of possible subtrees under .well-known, as compared to > the somewhat constrained port number space. On the other hand, one > doesn't want to create a land rush on mnemonics. IMHO this is possible > to fix. Simply allocate a random string of 8 characters or so for a > developer to use (not for them to choose). This should suit developers > who do not wish to publish their specifications or otherwise have reason > to apply more meaning or structure as you mention in Section 3 of 5785, > but otherwise do not wish to produce specifications. For those who > still want a mnemonic, they can produce a spec. Actually SRV and .well-known are both very much like ports in that they serve different aspects of the same function without the port number restriction. The original Internet discovery mechanism had two steps: 1) Conversion of the DNS name of the service to a network host (identified by IP address) via DNS A record lookup 2) Identifying the protocol to the host at the specified address. The SRV record was originally proposed as a replacement for both parts of this problem and equally importantly, to provide the fault tolerance and load balancing capabilities that the MX record provided. The fact that HTTP does not use SRV records is irrelevant because Web Services have used SRV since the very first Web Services standards were written. I know because I wrote those parts of the specs. People developing Web Services certainly want to use a mechanism like SRV records to get the benefits of the fault tolerance mechanism. Using an SRV record we specify the priority, wieghting, port number and host name of each server providing a service: _mmm._tcp.example.com 0 20 80 host1.example.com _mmm._tcp.example.com 0 80 80 host2.example.com _mmm._tcp.example.com 1 5 80 voldemort.example.com This specifies three hosts that can provide service for the domain. When host1 and host2 are both available, host2 gets 80% of the requests and host1 gets the rest. If a client can't connect to either, they connect to voldemort. The reason SRV isn't sufficient for Web services by itself is that Web Service hosts typically host multiple services and it would be really inconvenient (and inefficient) to separate them by port number. Some other means of separating the Web Services is required. Some time ago now Patrik suggested the URI scheme which is a perfectly sensible way to achieve the objective but it does introduce other problems. One of these is that there are now two different mechanisms for discovery and the person configuring the protocol has to know which one to use. Another is that many ISPs do not provide a means to configure URI records, only SRV is supported. So just as Netscape discovered that it was necessary to add the Host: header to the original HTTP protocol, there is now a need to add the SRV prefix which serves the equivalent function. The most straightforward way to do that is to use the .well-known convention. The logic of this approach over the URI RR becomes apparent when the design of a HTTP successor protocol that is specifically for Web Services is considered. Most Web services make almost no use of HTTP features beyond the protocol identification described above and the message framing. If one was developing a protocol that was only for Web Services, it would not have features such as caching which are almost never desirable. Such a protocol would probably treat URLs that are outside the .well-known set as the exceptions. So far I have not seen a single technical argument been made against this approach. It quite definitely works and it is certainly as well founded as a published RFC written by someone who was an IAB member at the time. The only arguments I have seen are about the need for gatekeepers to protect the integrity of the Internet. Which in this case are being made by the gatekeeper in question. I think that we need to know the following: * Approximately how many requests are made each year? * Of these what proportion are accepted / rejected / abandoned? * In what cases have changes been made to a protocol in order to make it acceptable? But regardless of the answers to these questions, there is a much larger policy question which is what should be the IETF policy for assignment of code points in registries that have an effectively unlimited supply? I am genuinely troubled by a situation in which being a domain expert for an IANA registry seems to be giving one individual a degree of power we do not afford the IESG. When the response to raising such issues is personal attacks, then I take offense. In answer to Eliot's issue, I do not see SRV prefix squatting as being a problem. It certainly hasn't been a problem to date. The worst that can happen is that we run out of easy to remember prefixes and people have to use unmemorable ones. But the only practical alternative being to start with unmemorable ones, I can't see it helping. From nobody Fri Jan 15 06:55:11 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145101ACE82 for ; Fri, 15 Jan 2016 06:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VA_NoWYEeJx for ; Fri, 15 Jan 2016 06:55:09 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 A6EFF1ACE80 for ; Fri, 15 Jan 2016 06:55:08 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id bc4so315214417lbc.2 for ; Fri, 15 Jan 2016 06:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Fy10XWM5s9OJgHCndHyeQeeU6Rfn5H7DfsV+32nuG4Y=; b=kLfg2chBiNhXvS/QmZVQYwM4Xc7IdcaXN9DFt3At8adrQ2aynPEP0yxgPRGj1QE9ha U6zGO0p75Sw0X/Hp8ouSO2sTsASMTcSShDSRUhAF12JYLEbBMzMwdTRAy/9Zu9cuFHUk 1pHM6QFCtAlsv/g3/mWBhhIEs0koFGWJzV+BpBh8sjClUyVNLJ66beVy4yJ0TrWc08w0 5VAQopkSyhiuvgZ4McHxvuK/psTJVcS9MueGl1LFYxk3YpyuqvcuYLyJHQvwWQcTHXQF erbMB7m5pqUEZwmVS3arq8W9VTJK0VIxxFh4abu8TNxcDuZmIsJA6FGqjRz3XT2fwwYx E5fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Fy10XWM5s9OJgHCndHyeQeeU6Rfn5H7DfsV+32nuG4Y=; b=F7N+0mV1yvi/BuXs4iwfBF971AU2pfeYjyrqWBy9TytMvmG8l8zd30C6UvQOsGio0M lA4yn0FUOl61VJRtCfYHwWgkyCqfR17FbOVXnZPVHxjP1gsnCOA51Opn5UAbpZpkQSc9 r7Dy1vRdKn31I7osgegpHjerSmy7H/YOODkR1wkG5MCOEyS1vkS9prs7xvqf/frlHzmL BK3Rg5dK2THctmbJH63xaJpGrkjTqauw5TPCiLnhKk2YsjBzjSQ38KShGPm6N/HXviru pLtGz3+fyDnJDkjgbajXPUTDha6v7R04xxXMf3nnLKjF0u0+X+elX1OShj8P4j9gGUOW AJSQ== X-Gm-Message-State: ALoCoQmUwrrUcK9mDpbXV3hjh2udtBrLnLDxHgO2YvnC4QYsQCPIofHBKl7b7drCqlo7MM4dF6tHGKqtL+kqyP2Do46TRW49NQ== MIME-Version: 1.0 X-Received: by 10.112.198.72 with SMTP id ja8mr3423654lbc.142.1452869706564; Fri, 15 Jan 2016 06:55:06 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Fri, 15 Jan 2016 06:55:06 -0800 (PST) In-Reply-To: References: <5697B833.3000703@cisco.com> Date: Fri, 15 Jan 2016 09:55:06 -0500 X-Google-Sender-Auth: JIyoHU19DuXEX1XRBvijjZ0VkNw Message-ID: From: Phillip Hallam-Baker To: General discussion of application-layer protocols Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:55:10 -0000 Just to clarify a point people have brought up with me in private. Yes, I am aware that Mark Nottingham is the DE for assignment of .well-known URIs and not Mr Fielding. That is something I was hoping Mark would point out himself. The information is public, but it isn't necessarily something people reading the conversation are aware of. The reason I originally brought this up is because of complaints about IETF process that I have received. The external perception of IETF is that there is an inside clique who effectively gets to decide everything through control of registration of code points. And right now I have to agree with them. I want this registry gone because I think it is an anathema to what the IETF claims to stand for. Review by a Designated Expert is not an open process. Review by a DE is not a consensus process. Review by a DE is a distinctly unequal situation in which one party is Pope, the other a supplicant. Now there are cases where DE review is necessary because the code points are limited. But this is not one of those cases and those cases simply should not exist above the Transport layer. The way to get architectural consistency is to describe an architecture with sufficient clarity that people follow it as the natural and easiest course to follow. My experience of multiple DE reviews of URIs is that each has made demands that are completely the opposite of the previous reviewers. There is also a policy issue here which I think we are going to need to discuss on the IETF list rather than here which is what level policy should be set on such issues. Introducing a gatekeeper into the process of deploying Internet applications is not a matter for one working group or even one area. From nobody Fri Jan 15 07:18:59 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227B61B2F2C for ; Fri, 15 Jan 2016 07:18:59 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 50j7qspnh3Ah for ; Fri, 15 Jan 2016 07:18:53 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 B63501B2F2B for ; Fri, 15 Jan 2016 07:18:53 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 1so442362251ion.1 for ; Fri, 15 Jan 2016 07:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=u+gn6ZuKyPIXnjKI7xvIUZ+nCW6ZfsLzaP0yuan0hRk=; b=l/Y9v1YYLCUf7CoW7tvUWAIYQCipooliDQToVCv5E+53mE7jCTRLQCP7WcRScY8gnF vDWTQIYBuno9eh2GmPI+2/qfPiYQf6nRNZKPyepXeff1NoyarDTvzn8Mesp1tnT0RRd5 Rove39Jd+kSmM2k25cNbB2ovnRZc98ll2KC1RzDxXSTD9zBcSH/EFx6hQH2m4hkbQjvA OA4VjyQHJS3sxVeTHIFcNhR23lUQQTqgBiIKY44Co3MaqXnXb18uF/jifVNNVCqWCqT4 XPOATZNiiBl6OBFMewL6L9ucCDoWuTylpKMBu+C5RN/taT6QnMC9HdW9Jkun7PxE6c6h wgOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=u+gn6ZuKyPIXnjKI7xvIUZ+nCW6ZfsLzaP0yuan0hRk=; b=GIHjG7l/rn+jo62i0ducuhsmoM8CxooiUJ0PaWabdGjRJNrcwDlhOJgiztLUleY2iX 0ulAkd5doTxHnReZVMEt3onChN4nKEMEpN+sl9GPsorGohh1hgaKv+yJASW5hUGWplRO CB5G4+tZ4cUvcUJkxbJm2FNrQ2QhIlurbYJw0xKZm+nQkPXWMUsJQSiZNBFz0IHCTPf8 NyCWKSvT6OTNuZrl7w+Isx+6/RlJ5VCO5jPq5Xj++5QpVzlPXMt0zJzBx4tjw4O+cXgp lijjPiHVQ6eqCdO7TzPRxoRXFbn8Oj/bIve9+I1hDxhFXflt8L1uK1U7NxTH45TYAXN3 VsJg== X-Gm-Message-State: ALoCoQk8o1g+liu7/oYhrnGQf2z0z/2A4G/7l0j9QizC3Th+kEwbY6JaWVheWLhn9gBYLb99AZcORNpAd8t9DNREsu755S8O7Q== X-Received: by 10.107.19.203 with SMTP id 72mr12434750iot.41.1452871133162; Fri, 15 Jan 2016 07:18:53 -0800 (PST) Received: from Pecan ([69.157.254.46]) by smtp.gmail.com with ESMTPSA id wd7sm980067igb.13.2016.01.15.07.18.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2016 07:18:52 -0800 (PST) From: "Darrel Miller" To: "'Phillip Hallam-Baker'" , "'General discussion of application-layer protocols'" References: <5697B833.3000703@cisco.com> In-Reply-To: Date: Fri, 15 Jan 2016 10:18:43 -0500 Message-ID: <007301d14fa8$05d15540$1173ffc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIBJAH98aSFpA/7hZmA2YNd3pJiLANA0KesAeaSxG0C9YhLSgJdD5XaAiSFxFOeOA7wYA== Content-Language: en-us Archived-At: Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 15:18:59 -0000 Philip, > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker > > Most Web services make almost no use of HTTP features beyond the protocol identification described above > and the message framing. If one was developing a protocol that was only for Web Services, it would not have > features such as caching which are almost never desirable. I believe the assertion you make here is evidence that a designated expert is required. You and I obviously live in very different parts of the web. My role on a daily basis is to interact with developers who are building services on the web. My experience over the last two years is that developers are attempting to make more use of HTTPs capabilities as an application protocol and are shunning the use of HTTP simply as tunnel for bytes. I fully support the use of designated experts to control what becomes part of standard registries even though I have seen registrations refused that I believed should have been accepted. I would much rather the bar be set high than see registries filled with poor practices. Darrel From nobody Fri Jan 15 09:20:56 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6F01B302D for ; Fri, 15 Jan 2016 09:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3-8nxknGgOv for ; Fri, 15 Jan 2016 09:20:53 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 5B4631B3029 for ; Fri, 15 Jan 2016 09:20:53 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id 17so84691781lfz.1 for ; Fri, 15 Jan 2016 09:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qfLq90gKRnn1dfmIWKBa79ZDAH9tSTI9CxayScLNv90=; b=BR7HeSAHavzqmZkz1RZNWHJDDG+4GIZc7l7g0biB5DxlvKRFeGCDEQwj+3A6cOjuxS ROhghTZlG2GhAFu48UfzckV74TS1ojBAm6mQqHX+oz8C8gDsOryEDlvilNnYwn3ouyx7 lKxo1YaA7+fg3fwZoiSzFpB0e8JKbNFmDOPf7KSxqq7KwMqpL5SweWHTswDJUsRVay4x JdX7oC+yMMoT5nNQzCA+JFK0LM8ZzBIDtFeO9ssNHZb8Wt+16HTf0dsdKOOqPkT65jGJ 2sckYT+Y7to1a7ESZFpyZNjjVt385HSU10YqTFDIxvZDkubp9DCEBZOe1MLqZlfx1xsB XELg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qfLq90gKRnn1dfmIWKBa79ZDAH9tSTI9CxayScLNv90=; b=fjULPZWLgnFbCwLIYHyLWSGqDJNDhppgu0VcoLKkzWa7TIC3TbnGJ5YQTu/vX3BZRL hV9pDsjCIHGH6ePPXMD4vfcGsbsOcttu0o1B6ov202trJlkAhq7grBNK3JY1MjmHeha1 O3mfEtkWgoccQ2JPDrxpaY+x0Z+ZEvVbbEoBWn91foIl3fVbWp1b7sZWcvweZTka1ZHo jIM5aBxk5l84Bd89MCma5nXKDZKQb3O4cpxW4PWX2E0MosfPpNHUnAdM9x9qGkat5t9M B4VrOy0fbtDpIqGQc+Vs1SgmKaGFxhoPv93ubJCSVA9pQHfsXEu2cVTE6Tw0iyvymbLV lYIQ== X-Gm-Message-State: ALoCoQlGS7sudfMeu/xCmaGX5SNnnoa3OlHIU0vg9b9HGu4KObAR7GKkgbPjvTrDi0yhXBPlyXiL3hTXTVKbs2pa8r9JbUlDZw== MIME-Version: 1.0 X-Received: by 10.25.168.15 with SMTP id r15mr3182923lfe.166.1452878451641; Fri, 15 Jan 2016 09:20:51 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Fri, 15 Jan 2016 09:20:51 -0800 (PST) In-Reply-To: <007301d14fa8$05d15540$1173ffc0$@gmail.com> References: <5697B833.3000703@cisco.com> <007301d14fa8$05d15540$1173ffc0$@gmail.com> Date: Fri, 15 Jan 2016 12:20:51 -0500 X-Google-Sender-Auth: 32rXvPgRsY6l0mNTCJ8ZIVw8Y3o Message-ID: From: Phillip Hallam-Baker To: Darrel Miller Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 17:20:54 -0000 On Fri, Jan 15, 2016 at 10:18 AM, Darrel Miller wrote: > Philip, > >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of > Phillip Hallam-Baker >> >> Most Web services make almost no use of HTTP features beyond the protocol > identification described above > and the message framing. If one was > developing a protocol that was only for Web Services, it would not have > > features such as caching which are almost never desirable. > > I believe the assertion you make here is evidence that a designated expert > is required. You and I obviously live in very different parts of the web. > My role on a daily basis is to interact with developers who are building > services on the web. My experience over the last two years is that > developers are attempting to make more use of HTTPs capabilities as an > application protocol and are shunning the use of HTTP simply as tunnel for > bytes. People keep making such assertions. I have yet to see anyone make a specific example. When I make a proposal, I give the technical basis for it. I do not say that people should do it my way because I am the expert which is essentially what you are doing here. Now the inexperienced designer might take your claim to expertise at face value and accept it. However the fact that you are trying to one-up one of the original designers of HTTP by pulling rank suggests that you are rather less expert than you might imagine. This is yet another example of the insider clique behavior that I want to see ended. > I fully support the use of designated experts to control what becomes part > of standard registries even though I have seen registrations refused that I > believed should have been accepted. I would much rather the bar be set high > than see registries filled with poor practices. Again, no specifics. The bar to participation in this forum is an opinion and a keyboard. It is deliberately set low because that is how the Internet emerged in the first place. There were plenty of people telling Clark, Cerf et al that their design was 'mindnumbingly stupid' and the people telling them that considered themselves to be the experts. What you are proposing is actually contrary to one of the canons of layered architecture. Dependencies between layers should be kept to a minimum. I do not want a presentation layer that interacts with my application layer. I want to decouple the two to the maximum extent possible. I suggest that you consider your arguments more carefully before this discussion moves to the IETF list. From nobody Fri Jan 15 15:26:57 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106981B33B9 for ; Fri, 15 Jan 2016 15:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2SuwpTWWRAm for ; Fri, 15 Jan 2016 15:26:53 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 4276E1B33B6 for ; Fri, 15 Jan 2016 15:26:53 -0800 (PST) Received: by mail-qg0-x22b.google.com with SMTP id 6so441128497qgy.1 for ; Fri, 15 Jan 2016 15:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=iT68fnxajWFa/vTcSi66lsj8rY0xCuDhtshkdeBvpFE=; b=XieMo0XwhTVVlaY0icTSPIJ1cb9Xqxsd8qkDYblmEwooqdOYkR+L3lkWGw926FvU9j ksFoXaErAV4eJxT/ymGzIoA/LZdUdOEWdPxIUBAjr69Be1uGbjTzxK4xSPROJV/JK8vx 7W5GwT1xHXF+ucl0I9d4UavzmnmvacGVogFzB5g31p5El7+o1JWF3IZaJnEkmqAt948a NqDrJYusOmJy7pATZkGTT/z3c1hQz5tgSZyDj6P0oe5uz+HBMZCmj6W/kP60JLxLd4Wm 5jl5NvRQj7GBDCK9WYJu11nYbUOWHR22YJypKXyhQ9lYoSz8378/wZsuOIISNPPeT2B2 nrhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=iT68fnxajWFa/vTcSi66lsj8rY0xCuDhtshkdeBvpFE=; b=e0mOrNXsqqdLaEWDfhkKxhta8PIfk5VEml6IDNFxjYiduCUNiTC0FcT84lu05rf9Jg K3XuQdB2DxgX6HWtquzqNL71GQ/ZxR3b/mNxauywMW+avPPCNrOD0kqHUJWn0mXu+dBp uewA3EHCPWOkiKqM5TA+7D1ONRP2WTrelvXNpcem4vlNh5bB+PMEEcIyk0CZDrmsrkzO vsWFfCs12va2xVr6wJuznOKU7lDAOIMiTXhfSmEMekK66sf2F0kdkNIjPhwUt5Wiv3Gh FLKEULov0gKM+KuxCRf9pXSL0k1nvVf/9pSfWQ980FA//l4XwI3QNjSW9jkHrufpASB2 aBWw== X-Gm-Message-State: ALoCoQlgTjpactWIfsyY+pLox9a8i3NPTMPl3CTaGqqGCK0twJNA2Z8YWkeUFHBNlBZIFp2IDUguSAP4R3I5EYxyRto5pc1ILQ== MIME-Version: 1.0 X-Received: by 10.140.93.166 with SMTP id d35mr16584812qge.29.1452900412526; Fri, 15 Jan 2016 15:26:52 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.55.155.2 with HTTP; Fri, 15 Jan 2016 15:26:52 -0800 (PST) Received: by 10.55.155.2 with HTTP; Fri, 15 Jan 2016 15:26:52 -0800 (PST) In-Reply-To: References: <5697B833.3000703@cisco.com> <007301d14fa8$05d15540$1173ffc0$@gmail.com> Date: Sat, 16 Jan 2016 09:26:52 +1000 X-Google-Sender-Auth: 6oGTFJrdvaD9Iyg7fJT9lM13rEc Message-ID: From: Matthew Kerwin To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a11395a22fb95bc052967bc2b Archived-At: Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 23:26:56 -0000 --001a11395a22fb95bc052967bc2b Content-Type: text/plain; charset=UTF-8 I'm not quoting any previous discussion, I just want to make an observation: wasn't .well-known acknowledged to be an anti-pattern when it was set up? And isn't the DE role therefore to turn proposals away which would be better served by a (positive) pattern elsewhere, along with that explanation? The bar for .well-known should be very high because http != gopher, nor should it ever be. --001a11395a22fb95bc052967bc2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm not quoting any previous discussion, I just want to = make an observation: wasn't .well-known acknowledged to be an anti-patt= ern when it was set up? And isn't the DE role therefore to turn proposa= ls away which would be better served by a (positive) pattern elsewhere, alo= ng with that explanation?

The bar for .well-known should be very high because http != =3D gopher, nor should it ever be.

--001a11395a22fb95bc052967bc2b-- From nobody Fri Jan 15 16:19:34 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05831ACD84 for ; Thu, 14 Jan 2016 12:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 DTYR5UFbmlgA for ; Thu, 14 Jan 2016 12:51:47 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 686981ACD82 for ; Thu, 14 Jan 2016 12:51:47 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id e65so105717401pfe.0 for ; Thu, 14 Jan 2016 12:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=KMNtWl8SD1SHXLtem09b3Mslx5E6fxFdqeQm/LfGBcM=; b=whgSvx1TZO3Us2ZHgy1hXL3jjEuUgf3k3eDSV3g2961XAImBIy+EMRl3v4tg3A8iW2 xOu81GZV+/yT9g4aW5zRQtg04pjogES0YR8b6LnJS7p3ng9u4jSaN4Rkwtuwl2QauUNg vYX570259GWW2kdUB7I+q4QLa/uHmi02QznEcHDXen3S8eVxJ98jr+wvNdYUABd17IyM dsB4JAn1rR1Iu7ZHrEEDJ/RKdQaTQcVk8ESSwtldhSK84q38KRdZjvu/omYPy3wCO4KI /5biKXG7V+A36zA2F7kUILRmwDwLdJ5IpzBsxdifi5v2NkMeWZasRzxgSqElYz/QxPqt rEow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=KMNtWl8SD1SHXLtem09b3Mslx5E6fxFdqeQm/LfGBcM=; b=KqxGbS+mtXLZFyBljJg1cdNFFqr4BldQ1siKg8SQxNBGdmZLsUzvp0SY4JqDNaVqkx IRNJZ6SWUeaQKLB8KBpUGIctIGq1JbCdUEuVL7oeIuUFKk6UoK5GoWlP8TkWQcAHmMGa ZFR5HYC7OY6M2hr6V/bbVn+e3Swf89MZo0Vp/vSwpMiSDOlYrzd09UmCTt/wLL1Mt5nS EkrC6Kx1YJmn9AW5qUCOG7muXIFRehiFwdvCcngUOBzDHSMh/x1XbAlUpdaoUw2jGMgN E7wDHeWuUS9siiAixmnN+V+mAGRGjj0vdjn+b4A7pvdwZ01VSs2i3FyTLwpDiHDwL7LQ GvGw== X-Gm-Message-State: ALoCoQlvvCw0SwGeJYDqHbNXwk5BfGR1cvBJK6Paw7R2ROFxYBEZCbbVDLBtKfD1F5O6bAJ0AlmhRCD0HbMmZc7rT9dr2D4jag== X-Received: by 10.98.16.139 with SMTP id 11mr9312548pfq.128.1452804707065; Thu, 14 Jan 2016 12:51:47 -0800 (PST) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id q8sm11166789pap.45.2016.01.14.12.51.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jan 2016 12:51:44 -0800 (PST) Date: Thu, 14 Jan 2016 20:51:43 +0000 (UTC) From: Phillip Hallam-Baker To: Jari Arkko , Barry Leiba , Phillip Hallam-Baker , "Roy T. Fielding" Message-ID: <994C5976EA09B556.9548FC87-9631-41AA-8527-A17BAF9B94CA@mail.outlook.com> In-Reply-To: References: <5697B833.3000703@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10743_1125064222.1452804703058" X-Mailer: Outlook for iOS and Android Archived-At: X-Mailman-Approved-At: Fri, 15 Jan 2016 16:19:32 -0800 Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 20:51:49 -0000 ------=_Part_10743_1125064222.1452804703058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Roy, That is not acceptable behavior to me and I hope it is not acceptable to th= e AD or Jari (Ccd) Using that type of language to describe a proposal is creating an environme= nt that =C2=A0I consider to be hostile. Now given that I have done at least= as much in the field as you, I am not likely to be intimidated. But plenty= of folk would be if they received a message like that from you and then ca= reful avoidance of an apology that followed. I see this type of behavior as being a type of bullying. I do not like bull= ying. Trying to bully people and then accusing them of being in the wrong f= or complaining about it is a very common pattern. You are going to treat everyone and their proposals with respect. The fact = that you do not understand a proposal does not make it stupid. Sent from Outlook Mobile _____________________________ From: Roy T. Fielding Sent: Thursday, January 14, 2016 3:00 PM Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services = under HTTP to First Come To: Phillip Hallam-Baker Cc: Mark Nottingham , Eliot Lear , General d= iscussion of application-layer protocols > On Jan 14, 2016, at 11:51 AM, Phillip Hallam-Baker = wrote: >=20 > On Thu, Jan 14, 2016 at 1:15 PM, Roy T. Fielding wrot= e: >>=20 >>> On Jan 14, 2016, at 7:01 AM, Eliot Lear wrote: >>>=20 >>> Mark, >>>=20 >>> On 1/14/16 6:34 AM, Mark Nottingham wrote: >>>> You can also register /.well-known/phks-protocols/ and do whatever you= like under it. >>>=20 >>> By your own words, that's simply not true unless there is a >>> specification tied to it, and personally I think that's a very high >>> bar. >>=20 >> Why is it a high bar to require a written description of the identified >> space? It doesn't require an IETF spec. Mark is right -- if there is a >> spec of why the identifier exists, the owner can do anything with furthe= r >> identifiers under that space. A review is desired because almost half o= f >> all proposed uses of .well-known are poorly conceived and more effective= ly >> accomplished with a single link. But the review does not require consen= t. >>=20 >> For example, PHB wants to do a standard name search of SRV after doing a >> DNS lookup and then use the SRV record to redirect to a reserved URI spa= ce. >> Sorry, that is brain-numbingly poor use of those protocols. >=20 > How about you apologize for the insult and try again? >=20 >=20 > You are certainly not expert enough in this space to be calling anyone > or their proposal mind numbingly stupid. I didn't. You read it that way. I am sorry that you read it that way, giv= en that I know you quite well to be extremely smart. That does not, however, = prevent you from using a protocol in a brain-numbingly poor way. The brain, in que= stion, is mine. Please, Phillip, don't for a second believe that you can abuse social etiqu= ette police as a way to silence criticism. That isn't a skill worth displaying = given the amount of criticism you have poured on others. ....Roy =20 ------=_Part_10743_1125064222.1452804703058 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Roy,

That is not acceptable behavior to me and I hope it is not acceptable= to the AD or Jari (Ccd)

Using that type of langua= ge to describe a proposal is creating an environment that  I consider = to be hostile. Now given that I have done at least as much in the field as = you, I am not likely to be intimidated. But plenty of folk would be if they= received a message like that from you and then careful avoidance of an apo= logy that followed.

I see this type of behavior as= being a type of bullying. I do not like bullying. Trying to bully people a= nd then accusing them of being in the wrong for complaining about it is a v= ery common pattern.

You are going to treat everyon= e and their proposals with respect. The fact that you do not understand a p= roposal does not make it stupid.


Sent from Outlook Mobile
_____________________________
From: Roy T= . Fielding <fielding@gbiv.com>
Sent: Thursday, January 14,= 2016 3:00 PM
Subject: Re: [apps-discuss] RFC 5785: Registration of .wel= l-known services under HTTP to First Come
To: Phillip Hallam-Baker <<= a dir=3D"ltr" href=3D"mailto:ietf@hallambaker.com" x-apple-data-detectors= =3D"true" x-apple-data-detectors-type=3D"link" x-apple-data-detectors-resul= t=3D"4">ietf@hallambaker.com>
Cc: Mark Nottingham <mnot@mnot.n= et>, Eliot Lear <lear@cisco.com>, General discussion of a= pplication-layer protocols <apps-discuss@ietf.org>

> On Jan 14, 2016, at 11:51 AM, Phillip Hallam-Baker <ie= tf@hallambaker.com> wrote:
>
> On Thu, Jan 14, 2016 at = 1:15 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>&= gt;
>>> On Jan 14, 2016, at 7:01 AM, Eliot Lear <lear@cis= co.com> wrote:
>>>
>>> Mark,
>>>= ;
>>> On 1/14/16 6:34 AM, Mark Nottingham wrote:
>>&g= t;> You can also register /.well-known/phks-protocols/ and do whatever y= ou like under it.
>>>
>>> By your own words, that'= s simply not true unless there is a
>>> specification tied to i= t, and personally I think that's a very high
>>> bar.
>&g= t;
>> Why is it a high bar to require a written description of th= e identified
>> space? It doesn't require an IETF spec. Mark is = right -- if there is a
>> spec of why the identifier exists, the o= wner can do anything with further
>> identifiers under that space.= A review is desired because almost half of
>> all proposed uses = of .well-known are poorly conceived and more effectively
>> accomp= lished with a single link. But the review does not require consent.
>= ;>
>> For example, PHB wants to do a standard name search of S= RV after doing a
>> DNS lookup and then use the SRV record to redi= rect to a reserved URI space.
>> Sorry, that is brain-numbingly po= or use of those protocols.
>
> How about you apologize for the= insult and try again?
>
>
> You are certainly not expe= rt enough in this space to be calling anyone
> or their proposal mind= numbingly stupid.

I didn't. You read it that way. I am sorry that= you read it that way, given
that I know you quite well to be extremely = smart. That does not, however, prevent
you from using a protocol in a b= rain-numbingly poor way. The brain, in question, is mine.

Please, P= hillip, don't for a second believe that you can abuse social etiquette
p= olice as a way to silence criticism. That isn't a skill worth displaying g= iven
the amount of criticism you have poured on others.

....Roy


=20 ------=_Part_10743_1125064222.1452804703058-- From nobody Sat Jan 16 19:40:14 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A901B2B03 for ; Sat, 16 Jan 2016 19:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aU0dBkyVxFrN for ; Sat, 16 Jan 2016 19:40:11 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E361B2B02 for ; Sat, 16 Jan 2016 19:40:10 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1F74222E262; Sat, 16 Jan 2016 22:40:06 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Sun, 17 Jan 2016 14:40:04 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> References: <5697B833.3000703@cisco.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 03:40:13 -0000 On 16 Jan 2016, at 1:55 am, Phillip Hallam-Baker = wrote: >=20 > The reason I originally brought this up is because of complaints about > IETF process that I have received. The external perception of IETF is > that there is an inside clique who effectively gets to decide > everything through control of registration of code points. And right > now I have to agree with them. Speaking personally: I'm very interested in improving the operation of Web-related = registries, because some in those communities think that we shouldn't = have registries at all, and any issues encountered only bolster that = argument. So while I've heard complaints as well, I've chosen to attempt to = improve things constructively (e.g., the HAPPYIANA list, the "custodian" = draft, experiments in the 5988bis draft).=20 Unfortunately, you appear to be wanting to rearrange the registry = operation for your personal convenience and alignment with your specific = view of how the Internet works, rather than the overall good of the = community. If that's not the case, please show us how. =20 Speaking as DE for the registry under discussion: If you have a complaint about the actual operation of the registry, I'd = love to hear it so I can address it, and escalate the issue if that = fails. If you have a suggestion for how to improve the registry process, = perhaps an I-D and a constructive discussion is in order. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jan 16 20:59:33 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A181B2BCF for ; Sat, 16 Jan 2016 20:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3970fiAFsalz for ; Sat, 16 Jan 2016 20:59:30 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 DBB141B2BCE for ; Sat, 16 Jan 2016 20:59:29 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id n128so139359434pfn.3 for ; Sat, 16 Jan 2016 20:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=astyE7RTxQSHWkth9hvPEpCHDMr/FwxvBkYn/5gwcDM=; b=jyLSttVd7jdoRGB1HpjTRz+hANBhGxb48ghsoxiFnuEtaR5eH6KqgsT3zjOZTMOqwI g3iLPNZPk1m+tNh2bHK7Hk0YSZdC5CmqO9b6EltMt0njwnGg9e94H1xnwQ8KuylOp0Z9 lwz3eJKzWyJodqMisr6DU9eT38lFVax2crCfOCKlweShXEUJIb9NiyvpId1a26fYY5XJ Gt7IljtyoOzKyKj8TTiJWTnwBYMDM/zko+P32Tau9PiDxz6JqqBuB6wZ+nFWvKcP2xQ0 GKfRoBo6HbVwjTGQQ94UmOUJdDwDcZG2cKdtgTl3hcP0OxaHB/y7plOiHAFtiVwvl0jq 2tMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=astyE7RTxQSHWkth9hvPEpCHDMr/FwxvBkYn/5gwcDM=; b=D7p+RWT0wVrAz7kaO22QoCOBDuTcA+M1nqMo5L7KhmFimVaeEX8eFaWCIaO4uEj2kX 84EXNBTSo0jyme/haiOY1UqTKYHjI8qUpju6HBrznQCdxUnwAkvHHFAh7JujejC2DEyR 9L7R1/ybGRo4NzTHYoyZ4LkZwdCH/ZNNiwCGEA8mLeb+FwH3DhgZaL8ZdsS3c6GcQdJH n/gCxabIhpZzA+2VZVdsnxHT2xiik+o+5X64pk4CpxqjW+sGUHaDz9XISw07xkE+56Ke vmxatTrzp1UXZv1toR2RwgyeZISGXxc7N89e/etYfxGy81atozH/wG6ovNE9lGWrPGuu 4PfA== X-Gm-Message-State: ALoCoQmE44GbUSpjtNvXF2tnA6Uf0dft1Q1kMmkajGTn+nK+5QoDvo2wzNIHRIdAz3StFyq4hUsh8hSmfOeLvzxVZ5DkMqVuEA== X-Received: by 10.98.72.87 with SMTP id v84mr26602948pfa.15.1453006769578; Sat, 16 Jan 2016 20:59:29 -0800 (PST) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id xr8sm25042119pab.26.2016.01.16.20.59.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Jan 2016 20:59:26 -0800 (PST) Sender: Phillip Hallam-Baker Date: Sun, 17 Jan 2016 04:59:25 +0000 (UTC) From: Phillip Hallam-Baker To: Mark Nottingham Message-ID: <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> In-Reply-To: <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> References: <5697B833.3000703@cisco.com> <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_25759_1943311649.1453006765436" X-Mailer: Outlook for iOS and Android Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 04:59:32 -0000 ------=_Part_25759_1943311649.1453006765436 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think you are projecting here. I did not accuse you of protecting your own position as DE. In fact I only = brought it up because other people thought I should I think that the community would be best served by removing you from this p= rocess. I have repeatedly asked for specifics of the benefit you provide. Y= ou have ignored them and have just accused me of a personal agenda.=C2=A0 What really worries me is that you attempt to claim both the benefit of pro= tecting the Iternet from other people's folly and claim not to be an obstac= le. Well which is it? Those are incompatible=C2=A0 This is not an open process. Therefore the process must change.=C2=A0 Sent from Outlook Mobile On Sat, Jan 16, 2016 at 7:40 PM -0800, "Mark Nottingham" wr= ote: On 16 Jan 2016, at 1:55 am, Phillip Hallam-Baker wrote: >=20 > The reason I originally brought this up is because of complaints about > IETF process that I have received. The external perception of IETF is > that there is an inside clique who effectively gets to decide > everything through control of registration of code points. And right > now I have to agree with them. Speaking personally: I'm very interested in improving the operation of Web-related registries, b= ecause some in those communities think that we shouldn't have registries at= all, and any issues encountered only bolster that argument. So while I've heard complaints as well, I've chosen to attempt to improve t= hings constructively (e.g., the HAPPYIANA list, the "custodian" draft, expe= riments in the 5988bis draft).=20 Unfortunately, you appear to be wanting to rearrange the registry operation= for your personal convenience and alignment with your specific view of how= the Internet works, rather than the overall good of the community. If tha= t's not the case, please show us how. =20 Speaking as DE for the registry under discussion: If you have a complaint about the actual operation of the registry, I'd lov= e to hear it so I can address it, and escalate the issue if that fails. If = you have a suggestion for how to improve the registry process, perhaps an I= -D and a constructive discussion is in order. Regards, -- Mark Nottingham https://www.mnot.net/ ------=_Part_25759_1943311649.1453006765436 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I think you are projecting here.

I did not accuse you of protecting your own position as DE. In fact I only brought it up because other people thought I should

I think that the community would be best served by removing you from this process. I have repeatedly asked for specifics of the benefit you provide. You have ignored them and have just accused me of a personal agenda. 

What really worries me is that you attempt to claim both the benefit of protecting the Iternet from other people's folly and claim not to be an obstacle. Well which is it? Those are incompatible 

This is not an open process. Therefore the process must change. 

Sent from Outlook Mobile




On Sat, Jan 16, 2016 at 7:40 PM -0800, "Mark Nottingham" <mnot@mnot.net> wrote:

On 16 Jan 2016, at 1:55 am, Phillip Hallam-Baker  wrote:
> 
> The reason I originally brought this up is because of complaints about
> IETF process that I have received. The external perception of IETF is
> that there is an inside clique who effectively gets to decide
> everything through control of registration of code points. And right
> now I have to agree with them.

Speaking personally:

I'm very interested in improving the operation of Web-related registries, because some in those communities think that we shouldn't have registries at all, and any issues encountered only bolster that argument.

So while I've heard complaints as well, I've chosen to attempt to improve things constructively (e.g., the HAPPYIANA list, the "custodian" draft, experiments in the 5988bis draft). 

Unfortunately, you appear to be wanting to rearrange the registry operation for your personal convenience and alignment with your specific view of how the Internet works, rather than the overall good of the community.  If that's not the case, please show us how.
 
Speaking as DE for the registry under discussion:

If you have a complaint about the actual operation of the registry, I'd love to hear it so I can address it, and escalate the issue if that fails. If you have a suggestion for how to improve the registry process, perhaps an I-D and a constructive discussion is in order.

Regards,



--
Mark Nottingham   https://www.mnot.net/
------=_Part_25759_1943311649.1453006765436-- From nobody Sat Jan 16 21:16:58 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0F31B2BFB for ; Sat, 16 Jan 2016 21:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 yzlwQ0orO-xe for ; Sat, 16 Jan 2016 21:16:55 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915FA1B2BFA for ; Sat, 16 Jan 2016 21:16:55 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB69B22E1F4; Sun, 17 Jan 2016 00:16:53 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> Date: Sun, 17 Jan 2016 16:16:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5697B833.3000703@cisco.com> <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 05:16:57 -0000 > On 17 Jan 2016, at 3:59 pm, Phillip Hallam-Baker = wrote: >=20 > I think you are projecting here. OK. > I did not accuse you of protecting your own position as DE. In fact I = only brought it up because other people thought I should Good to hear. > I think that the community would be best served by removing you from = this process. I have repeatedly asked for specifics of the benefit you = provide. You have ignored them and have just accused me of a personal = agenda.=20 As pointed out, there is a process for changing a registry, and that = process was followed when this one was set up. If it's to change, that = process should be followed too. > What really worries me is that you attempt to claim both the benefit = of protecting the Iternet from other people's folly and claim not to be = an obstacle. Well which is it? Those are incompatible=20 Where did I make such claims? > This is not an open process. Therefore the process must change.=20 That seems like a very premature conclusion. >=20 > Sent from Outlook Mobile >=20 >=20 >=20 >=20 > On Sat, Jan 16, 2016 at 7:40 PM -0800, "Mark Nottingham" = wrote: >=20 > On 16 Jan 2016, at 1:55 am, Phillip Hallam-Baker=20 > wrote: > >=20 > > The reason I originally brought this up is because of complaints = about > > IETF process that I have received. The external perception of IETF = is > > that there is an inside clique who effectively gets to decide > > everything through control of registration of code points. And right > > now I have to agree with them. >=20 > Speaking personally: >=20 > I'm very interested in improving the operation of Web-related = registries, because some in those communities think that we shouldn't = have registries at all, and any issues encountered only bolster that = argument. >=20 > So while I've heard complaints as well, I've chosen to attempt to = improve things constructively (e.g., the HAPPYIANA list, the "custodian" = draft, experiments in the 5988bis draft).=20 >=20 > Unfortunately, you appear to be wanting to rearrange the registry = operation for your personal convenience and alignment with your specific = view of how the Internet works, rather than the overall good of the = community. If that's not the case, please show us how. > =20 > Speaking as DE for the registry under discussion: >=20 > If you have a complaint about the actual operation of the registry, = I'd love to hear it so I can address it, and escalate the issue if that = fails. If you have a suggestion for how to improve the registry process, = perhaps an I-D and a constructive discussion is in order. >=20 > Regards, >=20 >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jan 16 22:02:53 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A521B2C6D for ; Sat, 16 Jan 2016 22:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJBdYASq37vT for ; Sat, 16 Jan 2016 22:02:51 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 2250D1B2C6C for ; Sat, 16 Jan 2016 22:02:51 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id cl12so115226462lbc.1 for ; Sat, 16 Jan 2016 22:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pWQQz938wpxfVmo5QjIe4ZCLSptCAWurXGpo8CrLknM=; b=c2z4hRDv9a8kXZbY+Uxy7fk49P5m5L4SMe1qSJBuT6dhhxaCnE7SONkKxjlZAeY2KP d7vHp/S7w8dtHHtQxQ5056I8XBu+0kOzdDB1eOQ1czZ9kwss/Re+XYRQbie2yzg4XquG /irN/Q5YBQ9sTq9tZ2+30lR1BoW2aGqouyguAJr3nfaa0gED6DeJZMb327VK1UbZLpXB balxQsE29TsIf5A4X0bXuVFg+uBOIRlW2JLIEQcc+EuagDWigCUTkXe73cknUZs3qeRn y1cFoMPKBKbtOHGeplPiwdQfpaNLeVgGM6hYoLcMxB/C6118HrahQItytjHK7AYGvHP/ QehQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pWQQz938wpxfVmo5QjIe4ZCLSptCAWurXGpo8CrLknM=; b=B2Y0Pod4AsX9d7000BDTGpf1XgKMn9jpaTiKRmFN+UNqwsKze12+vHgmgSImC51Yj7 jb5zfHdkjsW0GTHICi0iBDVXCBjvJOvk1FeSsy6gwT7LkBcLrTE/fMPZmSM0mtsUf4WV gl4u6qjbUK/VcjAJMVxlv+6a3gBBOmKC7mkU7yzQnUVuZiJwav8svtcf+F7lmBpdcpai LP6a1rgrmpl3EsLUoIEtCQLt7DzbKi/zdPtWwWqriRIFBWwGUt1PjzHMtIRXXft49/ie uyQcamuSgyO0xKcdi5xV/uH9ka9POz4od7mZn02j5g66wnam1WKcdmcd4sW8B7MddxTJ puZA== X-Gm-Message-State: ALoCoQnmUv52OUkGgkCcCTCUfefFNz4qiC85lFX+op6sSzbViWMm1qz2sjoS/27FGtU8EE+Q6JQI9dPKfb+0xqOBUYhN1O0hNA== MIME-Version: 1.0 X-Received: by 10.112.166.100 with SMTP id zf4mr6090569lbb.58.1453010569326; Sat, 16 Jan 2016 22:02:49 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Sat, 16 Jan 2016 22:02:49 -0800 (PST) In-Reply-To: References: <5697B833.3000703@cisco.com> <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> Date: Sun, 17 Jan 2016 01:02:49 -0500 X-Google-Sender-Auth: ZBLCFpFboDuKRUK5qqwfkbFYMH0 Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 06:02:53 -0000 On Sun, Jan 17, 2016 at 12:16 AM, Mark Nottingham wrote: > >> On 17 Jan 2016, at 3:59 pm, Phillip Hallam-Baker wrote: >> >> I think you are projecting here. > > OK. > >> I did not accuse you of protecting your own position as DE. In fact I only brought it up because other people thought I should > > Good to hear. > >> I think that the community would be best served by removing you from this process. I have repeatedly asked for specifics of the benefit you provide. You have ignored them and have just accused me of a personal agenda. > > As pointed out, there is a process for changing a registry, and that process was followed when this one was set up. If it's to change, that process should be followed too. > >> What really worries me is that you attempt to claim both the benefit of protecting the Iternet from other people's folly and claim not to be an obstacle. Well which is it? Those are incompatible > > Where did I make such claims? > >> This is not an open process. Therefore the process must change. > > That seems like a very premature conclusion. Well despite me asking you repeatedly to give concrete examples of the benefits you claim you have ignored these requests. Similarly you have not responded when I asked how many requests were made, how many refused, how many abandoned, etc. Yes there is a process, but the first part of any IETF process is discussion. The problem is that you seem to have a very different idea of what your role should be than the Tao of the IETF suggests. You are arguing that you add value as a gatekeeper. Yet you aren't actually explaining what the criteria you are using are. Then there are your supporters. The first of which tried to shut down any discussion. I would be really disappointed if the price for getting approval was to align protocols with the particular ideology of protocol design he is known for. Because as his behavior in this thread demonstrates, considering other people's ideas or points of view is not something he is good at. Finally, no, this is not about my convenience, far from it. I keep making technical arguments and you utterly refuse to engage on them. The idea of using SRV + .well-known together to resolve identifiers of the form alice@example.com is well founded and fairly obvious. Other approaches are possible (e.g. Patrik's URI scheme) but the only mechanism that is compatible with the legacy infrastructure is SRV + .well-known The fact that you ignore my many technical arguments and then demand more technical justification is the reason I can't take your statements seriously. I do not think your request for an ID here is made in good faith. This is not the venue that we will be discussing this issue. Make sure that you have better arguments for the wider IETF community. From nobody Sat Jan 16 22:26:07 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53331B2CA0 for ; Sat, 16 Jan 2016 22:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 800B-OV3yrNP for ; Sat, 16 Jan 2016 22:26:02 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADAC1B2C9E for ; Sat, 16 Jan 2016 22:26:02 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 99F1722E25F; Sun, 17 Jan 2016 01:25:56 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Sun, 17 Jan 2016 17:25:53 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5189DA31-AAB7-41D4-97D7-0702F762124D@mnot.net> References: <5697B833.3000703@cisco.com> <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 06:26:04 -0000 On 17 Jan 2016, at 5:02 pm, Phillip Hallam-Baker = wrote: >=20 > Well despite me asking you repeatedly to give concrete examples of the > benefits you claim you have ignored these requests. Similarly you have > not responded when I asked how many requests were made, how many > refused, how many abandoned, etc. When (as in, message IDs)? I received no such requests from you or = anyone else - neither once nor "repeatedly". But to answer regardless -- the DE isn't required to gather such = statistics, nor to present them upon demand. Your best bet would be to = ask IANA, or the check the mailing list yourself. > Yes there is a process, but the first part of any IETF process is = discussion. >=20 > The problem is that you seem to have a very different idea of what > your role should be than the Tao of the IETF suggests. You are arguing > that you add value as a gatekeeper. Yet you aren't actually explaining > what the criteria you are using are. This discussion would be much more productive if you stopped making this = about me and started making it about the registry policy. There was = consensus for the current policy, so the burden is upon you to convince = people if you want it changed. > Then there are your supporters. The first of which tried to shut down > any discussion. I would be really disappointed if the price for > getting approval was to align protocols with the particular ideology > of protocol design he is known for. Because as his behavior in this > thread demonstrates, considering other people's ideas or points of > view is not something he is good at. Um, Roy didn't refer to me at all. I haven't referred to him at all. = Have any requests been refused based upon his argumentation? AFAICT, = he's only posted to the wellknown-uri-review mailing list twice; once to = argue against "dnt-policy.txt" (registered), and once to request "dnt" = (registered). But it's nice to know I have supporters. I'll cherish them. > Finally, no, this is not about my convenience, far from it. >=20 > I keep making technical arguments and you utterly refuse to engage on > them. The idea of using SRV + .well-known together to resolve > identifiers of the form alice@example.com is well founded and fairly > obvious. Other approaches are possible (e.g. Patrik's URI scheme) but > the only mechanism that is compatible with the legacy infrastructure > is SRV + .well-known Perhaps your technical arguments are failing to convince people. > The fact that you ignore my many technical arguments and then demand > more technical justification is the reason=20 When did I do that? > I can't take your statements seriously. That's beginning to be mutual, Phillip. > I do not think your request for an ID here is made in good faith. Since you presume that I'm participating in bad faith here, there's not = much point in my continuing. I'll bow out until the adults decide = something needs to be done. Cheers and Happy New Year, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jan 17 06:25:03 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F221A6F71 for ; Sun, 17 Jan 2016 06:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0In9RQm2dAK for ; Sun, 17 Jan 2016 06:25:01 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 9B45B1A6F6F for ; Sun, 17 Jan 2016 06:25:00 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id z62so10831595lfd.0 for ; Sun, 17 Jan 2016 06:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nLA4TrqRr9MhtgqebVhTYZkJQjNS4ihGUIJJRxJQKes=; b=tEPVOmhhJ8QflRafP/n8ROPqtzXvvzmlKDkILoE/K9/NBhkYSP2Hzd1yoK6xfvbY8k Viz/cy9thbbGDlUEgUZd0Fsga+pVyLfLXw3BG6WuSinltYqZt5qB7XHQimE6RKZSCQ8j R2SV3PMdmut61xTOT1rQqiynmSncviwHmj3z9b9g3zcBB8DKmUVNmkMYkPfhR4W4ngty 4Zh2bTGAlypXuIlt3PwmSrLsgQgT5MnAS9rlhOAzFy3253mNHp4UGRrgQCesyVFx4kwt ZfKMsPrR4x79bmTI/PXTbnITcy4WltVkZSqlzVqVW4aQy+JCBUMgVxXDnkqVyw+oZcZQ NdIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nLA4TrqRr9MhtgqebVhTYZkJQjNS4ihGUIJJRxJQKes=; b=Qcv37UVz6W/JT7Ks4xKyMirrUC3oRTnALKHGW4jmezwDF296rfEzLCQr5dHMM6R8VS qaPz/WrroOD/C5wn1n4BiiuBM7IQHzbvmkdOx+Xz4FXfJIb+88QWSaEc2knk9J//q8bA oC9NcvJ+6pcqaMzAu0HbmrUYmMezis8ZgbV93blOSoA1bAmquA/NnCTFrQPYAyQftCFY 2iNDwDQ1K4zRUdBaY1hXY1Narl3FVxBzrCumVThRuQyObSUT3SY9rjldhxNLUYWK5wzf o5k8KQtWFpskJwPui+QgrUIHcJItsd5aC3XkwQAde6XLndfWlFNNci2ZleqUzLSataj8 3kvg== X-Gm-Message-State: ALoCoQmSwpf1LYFJvJ2fPNMyNT8gRu3nlOT1s3DhpmOfKTSYU0Yz0c0PLCWB2oPSuFsnaj0avNweinVfQN6tkKR4OVEnZNGBAA== MIME-Version: 1.0 X-Received: by 10.25.27.76 with SMTP id b73mr5504483lfb.43.1453040698869; Sun, 17 Jan 2016 06:24:58 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Sun, 17 Jan 2016 06:24:58 -0800 (PST) In-Reply-To: <5189DA31-AAB7-41D4-97D7-0702F762124D@mnot.net> References: <5697B833.3000703@cisco.com> <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> <5189DA31-AAB7-41D4-97D7-0702F762124D@mnot.net> Date: Sun, 17 Jan 2016 09:24:58 -0500 X-Google-Sender-Auth: YM9viLOv2dxtSyL5pR9ZRanUhpA Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 14:25:02 -0000 On Sun, Jan 17, 2016 at 1:25 AM, Mark Nottingham wrote: > On 17 Jan 2016, at 5:02 pm, Phillip Hallam-Baker wrote: >> >> Well despite me asking you repeatedly to give concrete examples of the >> benefits you claim you have ignored these requests. Similarly you have >> not responded when I asked how many requests were made, how many >> refused, how many abandoned, etc. > > When (as in, message IDs)? I received no such requests from you or anyone else - neither once nor "repeatedly". > > But to answer regardless -- the DE isn't required to gather such statistics, nor to present them upon demand. Your best bet would be to ask IANA, or the check the mailing list yourself. That is not an answer, it is a refusal to give an answer. You have asserted that your role is essential to prevent bad things happening. The burden of proof is on you. >> Yes there is a process, but the first part of any IETF process is discussion. >> >> The problem is that you seem to have a very different idea of what >> your role should be than the Tao of the IETF suggests. You are arguing >> that you add value as a gatekeeper. Yet you aren't actually explaining >> what the criteria you are using are. > > This discussion would be much more productive if you stopped making this about me and started making it about the registry policy. There was consensus for the current policy, so the burden is upon you to convince people if you want it changed. You and Roy have both made unprovoked personal attacks on me for merely daring to suggest that the role is unnecessary. I have not attacked you personally. You are the person who has tried to make the issue personal. What you seem to be doing here is attempting to create a situation where nobody can discuss the issue by deliberately making it personal. You and Roy keep making personal attacks, apparently in an attempt to claim that a breach of etiquette prevents you continuing the discussion. All IETF policies are subject to revision. And no, the burden of proof is not on those that want to make change. That is an assertion you made. >> Finally, no, this is not about my convenience, far from it. >> >> I keep making technical arguments and you utterly refuse to engage on >> them. The idea of using SRV + .well-known together to resolve >> identifiers of the form alice@example.com is well founded and fairly >> obvious. Other approaches are possible (e.g. Patrik's URI scheme) but >> the only mechanism that is compatible with the legacy infrastructure >> is SRV + .well-known > > Perhaps your technical arguments are failing to convince people. Or perhaps this isn't about technical issues at all and your demand for technical arguments was not in good faith. You suggested that there was a problem with my technical argument. Then you refused to justify it. I note that there hasn't exactly been a flood of people supporting your position either. >> I do not think your request for an ID here is made in good faith. > > Since you presume that I'm participating in bad faith here, there's not much point in my continuing. I'll bow out until the adults decide something needs to be done. When you make personal attacks, that is the only conclusion I can draw. I note that you have refused to provide evidence for a single one of your assertions. From nobody Sun Jan 17 16:54:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701B51ACE05 for ; Sun, 17 Jan 2016 16:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.277 X-Spam-Level: * X-Spam-Status: No, score=1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, FRT_PROFILE1=2.555, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebr3yuXLSc0s for ; Sun, 17 Jan 2016 16:54:03 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 0A16D1ACE03 for ; Sun, 17 Jan 2016 16:54:03 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id mw1so39602238igb.1 for ; Sun, 17 Jan 2016 16:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=R7L1C1PAfSOzJFWX8EJoV4SlSWd+7/JwCJlaQ7eVaKg=; b=xb6Hi/0o6jQu4vovTA3kiqOAIK8Wnd6CcRMSvcboL7GaAJRRwhSxlvD/isT9F06cYq C23BtaS3Dmr7Gha1Y0U49nHxUNsYQwSPKfqq+0XUfcJPSPTYTiFR2PIr562lJebZrpHk KNR1/BiiolnDVedUUPYTgRTJ7ppmcK1OxCDTF0bM5dd99hg/6fxEm/2bH7rDpaOdD08d tm0iz2NcYfVb3RHEV4JlXBHnot3x/PIl9lYvkEpuQ0YFL5oc3PBaw4h5GpZlnzCW0K3l 921VNIoQiV4pR9JhGZzKrKr3T8mukng3Wjt1wZLXDC6mENneF7XwmFx5v99vonsAp1s5 Aiog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R7L1C1PAfSOzJFWX8EJoV4SlSWd+7/JwCJlaQ7eVaKg=; b=SWKEIGn7XAexWj1EKHvPpuh9LqeSe8y5KHm0oVlaFvi7gq1WpxT3Pa1aKzL9Mrqade z9yqPxCgxZQaZaIiQnAJ4J3/vDKfcXjMSA+xThR2+k9jaToj3mdG5IOUzbxD9XW//RO+ QMQXcdF5zju8pT/31tiI6oEyOWpLHVS30MbAjiT5dajXeOCZpvSjGwTqcC1UyRFRJ1p+ 3aiZNj+Uxy9gW8zm/yIgLhhWzsauSXzSO3/nzahIlqAab+0gWhXQZTpijL60UPBzyZwX V8dMjxRM2Kevs4dHUcBBS4/x75apzHaOf0NeA/QouLru+cP57wH5CUqM5uzUuBAYvxOJ MSfQ== X-Gm-Message-State: AG10YOQJ7r/ZlKuZ4zmo+CkQZmzW2LXaKYX6m4AQrcSbsWj/9z9U5Z4mc8I5Z6R0L0xkNhCQcMIyjJueULMpUA== MIME-Version: 1.0 X-Received: by 10.50.18.50 with SMTP id t18mr8738058igd.90.1453078442348; Sun, 17 Jan 2016 16:54:02 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.181.65 with HTTP; Sun, 17 Jan 2016 16:54:02 -0800 (PST) In-Reply-To: References: <5697B833.3000703@cisco.com> <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> Date: Sun, 17 Jan 2016 19:54:02 -0500 X-Google-Sender-Auth: -xaIWw3mcscrQ-2_33rkz8Hz6ow Message-ID: From: Barry Leiba To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 00:54:05 -0000 I'm going to step in here because I think there's some useful discussion to continue here, amid the upset and the tensions. I'd like to set those latter things aside, and get us to have that useful part of the discussion. You'll note that my comments don't talk about this specific situation, because what's useful, perhaps important, here is how the Expert Review process works in general, not with any specific registry or expert. >>> Well despite me asking you repeatedly to give concrete examples of the >>> benefits you claim you have ignored these requests. Similarly you have >>> not responded when I asked how many requests were made, how many >>> refused, how many abandoned, etc. ... >> But to answer regardless -- the DE isn't required to gather such statistics, >> nor to present them upon demand. Your best bet would be to ask IANA, or >> the check the mailing list yourself. > > That is not an answer, it is a refusal to give an answer. > > You have asserted that your role is essential to prevent bad things > happening. The burden of proof is on you. Actually, I don't think any burden of proof lies with the DE. It's the IETF community, as part of the IETF consensus that backed the approval of the document and its terms for the registries it created, that has stated that they need a designated expert and the value that expert adds. As AD, I have been pushing for all documents that create such registries to provide guidance to the DE, to set community expectations of how the DE will perform her reviews and why her reviews are needed. I think that's an important part of things, and I know that too many registries were created without such guidance (that includes the registry we're talking about here, but see below). Also, as many of us know that, while a DE can handle reviews quietly on her own, interacting only with IANA, it's often better to make the process more open. For that, we often create a public mailing list and require discussion of registration requests on that mailing list (as we've done in the case we're talking about here). If the DE's decision is notably at odds with the discussion on the mailing list, that's a flag for the responsible AD to have a look at the situation and see what happened and why the discrepancy is there (see below for further comments about openness). Formally, IANA tracks all request and the process path they take. So Mark is right that you can get the answers about the statistics you're looking for from IANA. Any DE can, of course, keep her own statistics, but she's not required to... and most don't. > Yes there is a process, but the first part of any IETF process is discussion. > > The problem is that you seem to have a very different idea of what > your role should be than the Tao of the IETF suggests. You are arguing > that you add value as a gatekeeper. Yet you aren't actually explaining > what the criteria you are using are. As I see it, Mark isn't arguing anything of that nature. Discussion needs to happen in public, which it's doing on apps-discuss and which it can also do, in this case, on wellknown-uri-review, and the DE's job is to use that discussion to inform his decision. I'll note that the RFC that controls this case, as do many such RFCs, specifically says that the DE is expected to explain an unfavourable decision and suggest what changes might make the request successful. Again, see below about openness. > All IETF policies are subject to revision. And no, the burden of proof > is not on those that want to make change. I believe it is, in that we have a process that was approved by IETF consensus, and, while IETF consensus can and surely sometimes should change, with new information and experience since the initial consensus, the change has to be proposed by someone, an I-D eventually has to document the proposal, and that I-D has to go through the same consensus process. While IETF rough consensus isn't really a "burden of proof" thing, I do think it's up to those who want things to change to justify their change request and drive the consensus -- we very much *are* (for better or worse) in a world where we have to have rough consensus *for* the change, and things otherwise stay as they are. Of course, not everyone agrees with everyone, and one thing we need to be good at, collectively, is accepting that people who disagree with our ideas are not always (indeed are not usually) stupid, stubborn, obsolete, or harbouring personal agendas and personal grudges. We have to support our cases clearly and firmly, but also graciously accept disagreement and continue to work with each other on other issues. And, of course, on the other side we have to consider others' arguments with the assumption that there might be some good stuff there, and only reject them when we've weighed the technical considerations. (On all that, see the "finally" paragraph below.) Now, on the openness of the Expert Review process, there is an important discussion to be had: *Is* that process sufficiently open for the IETF? Should we, more generally, alter the process to make it more open, with more accountability for the DEs? As I mentioned, there are some registries where the DE just gets a request from IANA and returns a response, and it's up to the registrant to push the issue if things are refused. There are other registries where there's at least some public discussion. Is there still value (in general, not for this particular case) in having registrations in some registries reviewed by DEs? Should we abandon that entirely? Should we limit it to fewer registries, and make more registries FCFS? Or make more registries IETF Review? Or something else? I think that discussion needs to happen, and should be taken to to see where it goes. Finally, let me ask everyone to take a step back and not discuss anyone's motives or attitudes. If you feel that offense has been given you, take the higher ground and don't respond in kind, thus avoiding escalation. If you think someone's suggesting a bad idea, be clear about why you think the idea is not a good one, and avoid using inflammatory terms to describe it... and definitely avoid having that spill out from the idea to the person proposing it. We'll all accomplish more if we can discuss this sensibly, even when we disagree. Barry, ART AD From nobody Sun Jan 17 23:01:42 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2671B314C for ; Sun, 17 Jan 2016 23:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.947 X-Spam-Level: X-Spam-Status: No, score=-11.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_PROFILE1=2.555, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sSNo7Sz2vEDP for ; Sun, 17 Jan 2016 23:01:38 -0800 (PST) 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 0B0401B3150 for ; Sun, 17 Jan 2016 23:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9354; q=dns/txt; s=iport; t=1453100498; x=1454310098; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=u0b938/HbaoIECTG8o3YTzRk1+ZdmH2CIpKsIfr/hCs=; b=l+f5/UuXhqRY9cLWj+bHHEF8VwgU3l8oNmJGvrh320cXkWtYTxB6Sd7n IUhGEkwPxHaLzho6YQ+sO7YMuebXQgW54wah93CMPDwMNTz+6zjiIH5KB req0OU/4c1+0a++g1ekhmS3WP/9IOMFxmJfDprlua6Naf4FjcmBg2AKat s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkBQCFjZxW/xbLJq1ehAxthCqELLUnG?= =?us-ascii?q?AqFbQKBbgEBAQEBAYELhDUBAQQBAQEgSAMKARALGAkWCwICCQMCAQIBFTAGAQw?= =?us-ascii?q?GAgEBEIgHDq47j2sBAQEBAQEBAQEBAQEBAQEBAQEBEQUEilCBBIE8gnWDQ4FJB?= =?us-ascii?q?Y1ChVGEB4J4gWaBVIctgV6HTIVXimyDcWSCEg0PHYFBPTSFVYFKAQEB?= X-IronPort-AV: E=Sophos;i="5.22,311,1449532800"; d="asc'?scan'208";a="623566580" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2016 07:01:35 +0000 Received: from [10.61.199.45] ([10.61.199.45]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0I71ZWN023747; Mon, 18 Jan 2016 07:01:35 GMT To: Barry Leiba , Phillip Hallam-Baker References: <5697B833.3000703@cisco.com> <8B8FE545-8386-41FD-9F33-7A59380D8E95@mnot.net> <994C5976EA09B556.4692A470-BA3D-4729-BF7A-47F2CFA9B387@mail.outlook.com> From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <569C8DCD.8040501@cisco.com> Date: Mon, 18 Jan 2016 08:01:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pQBqet3xtps4jfxJgj08Gq2mWt3LfG2cX" Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 07:01:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pQBqet3xtps4jfxJgj08Gq2mWt3LfG2cX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Barry, Thanks for stepping in. I'd like to make clear that my concern isn't so much about whether expert review is needed but whether a public specification should be required. That is the high bar to which I referred. The latter eliminates the possibility of proprietary uses. As a reviewer for other registries, I entirely recognize the convenience of having a public specification available. However, a specification is not necessary to determine the appropriateness of the use of a proposed use if the application is sufficiently detailed. And to me, given that the TCP/UDP port space is far more constrained than this registry, my question is why such a requirement exists. The classic example of this would be a proprietary web-based management system that has to ensure that there is no conflict with any other name in the space. The people developing the system don't want to publicly expose all of their interfaces, but want to management version control on both ends of the connection. If a specification is required, they simply won't bother doing one and what happens next is that the TCP/UDP port reviewers get a request for a service that is identical to HTTP in all ways, except for its use. We've already seen these sorts of TCP port requests prior to .well-known, and in fact I have raised this issue with Apps ADs in the past. .well-known offers us an opportunity to tackle the problem, but not if "Specification Required" is the bar. Eliot On 1/18/16 1:54 AM, Barry Leiba wrote: > I'm going to step in here because I think there's some useful > discussion to continue here, amid the upset and the tensions. I'd > like to set those latter things aside, and get us to have that useful > part of the discussion. You'll note that my comments don't talk about > this specific situation, because what's useful, perhaps important, > here is how the Expert Review process works in general, not with any > specific registry or expert. > >>>> Well despite me asking you repeatedly to give concrete examples of t= he >>>> benefits you claim you have ignored these requests. Similarly you ha= ve >>>> not responded when I asked how many requests were made, how many >>>> refused, how many abandoned, etc. > ... >>> But to answer regardless -- the DE isn't required to gather such stat= istics, >>> nor to present them upon demand. Your best bet would be to ask IANA, = or >>> the check the mailing list yourself. >> That is not an answer, it is a refusal to give an answer. >> >> You have asserted that your role is essential to prevent bad things >> happening. The burden of proof is on you. > Actually, I don't think any burden of proof lies with the DE. It's > the IETF community, as part of the IETF consensus that backed the > approval of the document and its terms for the registries it created, > that has stated that they need a designated expert and the value that > expert adds. As AD, I have been pushing for all documents that create > such registries to provide guidance to the DE, to set community > expectations of how the DE will perform her reviews and why her > reviews are needed. I think that's an important part of things, and I > know that too many registries were created without such guidance (that > includes the registry we're talking about here, but see below). > > Also, as many of us know that, while a DE can handle reviews quietly > on her own, interacting only with IANA, it's often better to make the > process more open. For that, we often create a public mailing list > and require discussion of registration requests on that mailing list > (as we've done in the case we're talking about here). If the DE's > decision is notably at odds with the discussion on the mailing list, > that's a flag for the responsible AD to have a look at the situation > and see what happened and why the discrepancy is there (see below for > further comments about openness). > > Formally, IANA tracks all request and the process path they take. So > Mark is right that you can get the answers about the statistics you're > looking for from IANA. Any DE can, of course, keep her own > statistics, but she's not required to... and most don't. > >> Yes there is a process, but the first part of any IETF process is disc= ussion. >> >> The problem is that you seem to have a very different idea of what >> your role should be than the Tao of the IETF suggests. You are arguing= >> that you add value as a gatekeeper. Yet you aren't actually explaining= >> what the criteria you are using are. > As I see it, Mark isn't arguing anything of that nature. Discussion > needs to happen in public, which it's doing on apps-discuss and which > it can also do, in this case, on wellknown-uri-review, and the DE's > job is to use that discussion to inform his decision. I'll note that > the RFC that controls this case, as do many such RFCs, specifically > says that the DE is expected to explain an unfavourable decision and > suggest what changes might make the request successful. Again, see > below about openness. > >> All IETF policies are subject to revision. And no, the burden of proof= >> is not on those that want to make change. > I believe it is, in that we have a process that was approved by IETF > consensus, and, while IETF consensus can and surely sometimes should > change, with new information and experience since the initial > consensus, the change has to be proposed by someone, an I-D eventually > has to document the proposal, and that I-D has to go through the same > consensus process. While IETF rough consensus isn't really a "burden > of proof" thing, I do think it's up to those who want things to change > to justify their change request and drive the consensus -- we very > much *are* (for better or worse) in a world where we have to have > rough consensus *for* the change, and things otherwise stay as they > are. > > Of course, not everyone agrees with everyone, and one thing we need to > be good at, collectively, is accepting that people who disagree with > our ideas are not always (indeed are not usually) stupid, stubborn, > obsolete, or harbouring personal agendas and personal grudges. We > have to support our cases clearly and firmly, but also graciously > accept disagreement and continue to work with each other on other > issues. And, of course, on the other side we have to consider others' > arguments with the assumption that there might be some good stuff > there, and only reject them when we've weighed the technical > considerations. (On all that, see the "finally" paragraph below.) > > Now, on the openness of the Expert Review process, there is an > important discussion to be had: *Is* that process sufficiently open > for the IETF? Should we, more generally, alter the process to make it > more open, with more accountability for the DEs? As I mentioned, > there are some registries where the DE just gets a request from IANA > and returns a response, and it's up to the registrant to push the > issue if things are refused. There are other registries where there's > at least some public discussion. Is there still value (in general, > not for this particular case) in having registrations in some > registries reviewed by DEs? Should we abandon that entirely? Should > we limit it to fewer registries, and make more registries FCFS? Or > make more registries IETF Review? Or something else? > > I think that discussion needs to happen, and should be taken to > to see where it goes. > > Finally, let me ask everyone to take a step back and not discuss > anyone's motives or attitudes. If you feel that offense has been > given you, take the higher ground and don't respond in kind, thus > avoiding escalation. If you think someone's suggesting a bad idea, be > clear about why you think the idea is not a good one, and avoid using > inflammatory terms to describe it... and definitely avoid having that > spill out from the idea to the person proposing it. We'll all > accomplish more if we can discuss this sensibly, even when we > disagree. > > Barry, ART AD > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --pQBqet3xtps4jfxJgj08Gq2mWt3LfG2cX 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 iQEcBAEBCAAGBQJWnI3OAAoJEIe2a0bZ0nozhD8H/iS45tNar+oiEyx6WILF/WPv O/P+B8ZkKfxoDpfRj0AAXATigVLmVHYWLDiAwN3NAcixKbCR+jGxkY7Quh4MoCNS TUDO7b5EZU21TW2ibu11YqcLBba88FP72Sl8TgMKPdCsSgYsuhipagZM/0eI4UID NgwuAbJAxWPwtPWa3rF2pijWHdb+5gqkxQ4gqLSXQpHiqyjsYG0OyI1Ltf3oy+6V 3vW/HWtm2MqkQEKz69OBJcTSb0FXA5v0iv7MxyFHENmN/w/Y1zBxRVzBpuN3KDUe jg3ZIWGpgaYZgVHdiQmk0mStw1W6v9D8clOVtknPvpujzhnrwCgbaZtaB17fFfk= =V0/V -----END PGP SIGNATURE----- --pQBqet3xtps4jfxJgj08Gq2mWt3LfG2cX-- From nobody Mon Jan 18 11:22:14 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE99B1B3C31; Mon, 18 Jan 2016 11:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5gNiG5tg62ll; Mon, 18 Jan 2016 11:22:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50111B3C32; Mon, 18 Jan 2016 11:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8055; q=dns/txt; s=iport; t=1453144924; x=1454354524; h=from:to:subject:date:message-id:mime-version; bh=e6IhL4AFQG4veG1fR707MHNmMKzR+edu/KdtmK2Kpt0=; b=ICsYqZop3ulADxyIiYph2YH6/UTOhnT3AQkR1UNyBHuP+/A3wI3cxBDw 9DHNlkm75dv9CmaP7w2FMzJsMD1ggV4F2NiqRmyjpWKrDypMDbXyBXUki qHl0typd5P84ZdCefznv1MEsi/4sFrxO0BxbLvKsLEuKETmlg6LfzAdBl g=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AgAuO51W/5BdJa1egzpSLEEGiFCxM?= =?us-ascii?q?oITDoFiJIVrgTk4FAEBAQEBAQGBCoQ7IwQnPQEcEAEdAjMBJwQBIA8BA4d6DgO?= =?us-ascii?q?uc5AKAQEBAQEFAQEBAQEVCYhkgWyFQjkSgmsugRsFjUKJWAGCd4FmaoIuhWmBX?= =?us-ascii?q?kqDeohfimyDcAEgAUOCEQUWgV1yAYYzgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,313,1449532800"; d="asc'?scan'208";a="68141780" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2016 19:21:48 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0IJLmYD030530 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jan 2016 19:21:48 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Jan 2016 13:21:47 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 18 Jan 2016 13:21:47 -0600 From: "Matt Miller (mamille2)" To: "draft-ietf-l3vpn-end-system.all@ietf.org" , "bess@ietf.org" , "apps-discuss@ietf.org" Thread-Topic: APPDIR Review of draft-ietf-l3vpn-end-system-05 Thread-Index: AQHRUiV53gVx+I3+/kmFDLZltW8T5g== Date: Mon, 18 Jan 2016 19:21:47 +0000 Message-ID: <311A5336-EC6E-40DC-B449-634225F95267@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.81.135] Content-Type: multipart/signed; boundary="Apple-Mail=_B81A6EB9-7439-4478-90AC-7795D60E663C"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: [apps-discuss] APPDIR Review of draft-ietf-l3vpn-end-system-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 19:22:09 -0000 --Apple-Mail=_B81A6EB9-7439-4478-90AC-7795D60E663C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have been selected as the Applications in ART Directorate reviewer = for this draft (for background on appsdir, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDir= ectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-l3vpn-end-system-05 Title: BGP-signaled end-system IP/VPNs Reviewer: Matt Miller Review Date: 2016-01-18 IETF Last Call Date: N/A IESG Telechat Date: N/A Summary: This draft is not ready for publication as a Proposed Standard. Comments: This draft is making assumptions and design decisions that are not = really compatible with XMPP, and these should be resolved before publishing. It's important to note XMPP is an end-to-end application routing protocol. Clients are capable of sending data to other clients, possibly crossing multiple server boundaries. For example: 1) client-a@server-1.example --> 2) server-1.example --> 3) muc.example --> 4) server-2.example --> 5) client-b@server-2.example This document seems to make the assumption that routing is purely between a client and its sever, which I believe has lead to design decisions that are very problematic. Major Issues: (All of which apply to Section 6. XMPP Signaling Protocol) * The addressing scheme for End Systems connecting to the external VPN Forwarder is not explicitly documented anywhere -- the only instance I can deduce is from the external VPN forwarded subscription example, which seems to use a domain JID for the End System. Without a clear XMPP addressing scheme, properly routing stanzas across the XMPP network and mutually authenticating TLS according to RFC 6125 (and possibly [XEP-0178]) seem problematic to me. If End Systems are expected to communicate directly with the Route Server (e.g., End System addresses stanzas to the Route Server, which the VPN Forwarder is expected to relay), the addressing scheme for all components needs to be better defined. For instance, the VPN Forwarder address in XMPP could be a domain JID as it is, while the End System address could be a bare JID derived from that VPN Forwarder's JID (e.g., "end-system@forwarder.example"). This would disambiguate the XMPP routing across the XMPP network. However, if VPN Forwarders are to act as proxies for End Systems, then it should act as a proxy in all cases -- End Systems subscribe to pubsub nodes on the external VPN Forwarder (which could in turn trigger a subscribe of the VPN forwarder to the Route Server), and receive notifications from the VPN Forwarder (which in turn are first received by the VPN Forwarder from the Route Server). * Using a hard-coded JID for the Route Server can be a serious problem = if there is ever a case where individual Route Servers oversee different routing information. If this is never the case, then a single JID for all Route Servers is probably OK, but I think there could be problems with properly authenticating the TLS session. Using a different JID for each Route Server can introduce some difficulties for End Systems utilizing external VPN Forwarders, but I think only in the case where the End System is expected to subscribe to the Route Server directly -- if the End System actually subscribes to the VPN Forwarder, then the End System already knows the VPN Forwarder's JID and would not need to determine the Route Server' JID. Minor Issues: (all apply to Section 6. XMPP Signaling Protocol) * The XEP-0060 PubSub subscription and unsubscription examples are incorrect. Specifically, the 'jid' attribute of the element is the subscriber's JID not the pubsub service, and subscription options are encoded using Data Forms [XEP-0004]. The co-located example then is: 1 The external example could be the following (if there is a single addressing scheme): 100 The unsubscribe example is then: * Requiring pubsub notifications to always go from the Route Server to the VPN Forwarder regardless of what entity subscribed to the pubsub node is counter to how XEP-0060 works. The pubsub subscribe request specifies where the notifications are supposed to go, and the pubsub service is expected to honor that. See above in the addressing discussion for some ideas of how to deal with this. Nits: * (Mostly in Section 6. XMPP Signaling Protocol) The document often uses the term "message" when discussing XMPP communications. The XMPP term of art is "stanza" not "message"; "message" has a specific meaning in XMPP that is not in use here, and can lead to confusion for readers of this document once they follow the references to RFC 6120 and the various XEPs. * In Section 1. Introduction, the use of the term XMPP should be followed by a reference to RFC 6120. * In Section 6. XMPP Signaling Protocol, the seventh paragraph (immediately preceding Figure 1) has an extraneous period (.) at the end of the last sentence. * In Section 6. XMPP Signaling Protocol, I understood the meaning of the following sentence: The VPN Forwarder SHOULD use as JID its hostname, when available, or an unique IP address within the infrastructure network win its string representation. Regardless of how my XMPP addressing concerns are finally resolved, please revisit this sentence. References: [XEP-0004]: Data Forms < http://xmpp.org/extensions/xep-0004.html > [XEP-0030]: Service Discovery < http://xmpp.org/extensions/xep-0030.html = > [XEP-0178]: Best Practices for Use of SASL EXTERNAL with Certificates < = http://xmpp.org/extensions/xep-0178.html > -- - m&m Matt Miller Cisco Systems, Inc. --Apple-Mail=_B81A6EB9-7439-4478-90AC-7795D60E663C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWnTtPAAoJEDWi+S0W7cO1mNgH/3wS66XY4nWnxDv2bJfxYBwm onTffLCXa8AEutixGFlOV7v92wn5z9G7ezHfQ5YQUpusPME8xYIHThUe8DKKrZII KzvGEbV9hKWowh/oBgAWiHXLSL/F9STAncfXZpp9Jq2HWOg7fOirbmdzlqreKoCI C4GAKN6iOSh9TjO0YCbR8kYf2e+b4wmjsi2ESBIkS21rVhDPwLw5NuvouGG9yRCP bBcPWnJGZrADnVwr9yMI0dyaVEb1HpmbyIXY2VqgT+EaPUlgNpbt1mewrV8jjxQy 9FSs1WoGP+p3IUkSbO4x1miPFmfx8evugVIFMpLCbRQJYUHiz1Pq/hJanD4HoVk= =Yma0 -----END PGP SIGNATURE----- --Apple-Mail=_B81A6EB9-7439-4478-90AC-7795D60E663C-- From nobody Tue Jan 19 01:54:23 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2231A9036 for ; Sat, 16 Jan 2016 10:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 1RtHD3V-ox9C for ; Sat, 16 Jan 2016 10:48:52 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 E5F781A9030 for ; Sat, 16 Jan 2016 10:48:51 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id yy13so318765775pab.3 for ; Sat, 16 Jan 2016 10:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type; bh=FTqU0Zi5XKImbD1emWhLMjJrc7R4d6DUZRFNBKuw4F4=; b=VAEnyqQlPV5/qt3OahABRXGYelJ1TGl/+tmUabuI1oXgTDWnVLM+oH6UbZT/D9khZg Jvrlwn8jrn/3B8EkqhrvT7Yo48iOrLC+zpKdR77NDBssvsA2llObC9Hp4GwP583pemB6 /YkHq0WN/gUZXlKV38f3tIm5JVKN+/1IWUvOKrrEFBQFKlhAj40Gh7B85r+qKphgYq6T 4Yuh/wegvwsF2OK+yrCdW3M1rWnyHkTrZ56WpxAsW8KpfCFbsWp78LzRLZkrgIU500aH sB0FHfZZ7vUDNWb3wtKqgZhiq4wGJBIHYNOpjKr43IydG/QBNVGXbkARoujQKztLK/c7 fzmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type; bh=FTqU0Zi5XKImbD1emWhLMjJrc7R4d6DUZRFNBKuw4F4=; b=b98W9EV4PkG0ZyKlMT8DQV6lU4ze9AYJwocSQmcQ3w47GcyMadG/ZFHHBNh3o3ml7u LE602Ma/MRgXcziuCK0E/FCJDrpiiuZ7C8aK93Q9rxFFeW38uJ2/wLpKQoVp376ezOdC +No7SH+XqYjbe/os0EM6Mk6J2VL+LE4iFJWGFm+YsM2IYkjSOQbbYsf3VaZ6DIhVN6rt 3hILPlKa7w0fCISyFKRChREe/039/5DyKaDGQS8m2riJbuMx9IjEdaS5//E4AqVh8M+g HrwtU5lLN8pS9h2YXfHGdtmwaC2JklFDuBCAJtV80fOz3/Ctfx1l/OfV2tyaVh+ESWA0 qj5Q== X-Gm-Message-State: ALoCoQmHOE4QgIJdJKyM/QA8caEFenxEd3kT7M498ocBy5Q/bDrFPLqHe23WzsW/CkG41YuAMWnIbG3KegGv/ykvHWaPTMp9og== X-Received: by 10.66.220.170 with SMTP id px10mr24411331pac.145.1452970131608; Sat, 16 Jan 2016 10:48:51 -0800 (PST) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id by2sm23461270pab.6.2016.01.16.10.48.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Jan 2016 10:48:48 -0800 (PST) Date: Sat, 16 Jan 2016 18:48:47 +0000 (UTC) From: Phillip Hallam-Baker To: , Matthew Kerwin Message-ID: <994C5976EA09B556.00059E8E-F27D-40AE-A32D-879C0AFA1A19@mail.outlook.com> In-Reply-To: References: <5697B833.3000703@cisco.com> <007301d14fa8$05d15540$1173ffc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24506_1904755024.1452970127701" X-Mailer: Outlook for iOS and Android Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2016 01:54:21 -0800 Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 18:48:54 -0000 ------=_Part_24506_1904755024.1452970127701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sent from Outlook Mobile _____________________________ From: Matthew Kerwin Sent: Friday, January 15, 2016 6:27 PM Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services = under HTTP to First Come To: =20 I'm not quoting any previous discussion, I just want to make an observation= : wasn't .well-known acknowledged to be an anti-pattern when it was set up?= And isn't the DE role therefore to turn proposals away which would be bett= er served by a (positive) pattern elsewhere, along with that explanation? = =20 The bar for .well-known should be very high because http !=3D gopher, nor s= hould it ever be. =20 No, it was asserted but never conceded. More importantly, the IETF reviewed= and agreed the RFC which makes no mention of such a position.=C2=A0The pos= ition of DE is not meant to be an opportunity to impose a private view of I= nternet architecture on anyone. It certainly isn't an opportunity to tell p= eople that they should 'do it my way' and especially not when that turns ou= t to be implement someone's 20 year old thesis.I am well aware of the style= of architecture that people are suggesting it is the role of the DE to imp= ose. It is a style that I played as much of a part in creating as anyone el= se did. It is a style that I have used and have since abandoned because I t= hink other approaches are better.=C2=A0 =20 ------=_Part_24506_1904755024.1452970127701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
_____________________________
From: Matth= ew Kerwin <matthew@kerwin.net.au>
Sent: Friday, Januar= y 15, 2016 6:27 PM
Subject: Re: [apps-discuss] RFC 5785: Registration of= .well-known services under HTTP to First Come
To: <apps-dis= cuss@ietf.org>


I'm not quoting any pre= vious discussion, I just want to make an observation: wasn't .well-known ac= knowledged to be an anti-pattern when it was set up? And isn't the DE role = therefore to turn proposals away which would be better served by a (positiv= e) pattern elsewhere, along with that explanation?

The= bar for .well-known should be very high because http !=3D gopher, nor shou= ld it ever be.


No, it was asserte= d but never conceded. More importantly, the IETF reviewed and agreed the RF= C which makes no mention of such a position. 
The position of DE is not meant to be an opportunity to impose a pr= ivate view of Internet architecture on anyone. It certainly isn't an opport= unity to tell people that they should 'do it my way' and especially not whe= n that turns out to be implement someone's 20 year old thesis.
I am well aware of the style of architecture that peopl= e are suggesting it is the role of the DE to impose. It is a style that I p= layed as much of a part in creating as anyone else did. It is a style that = I have used and have since abandoned because I think other approaches are b= etter. 

=20 ------=_Part_24506_1904755024.1452970127701-- From nobody Tue Jan 19 05:32:31 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 752691B2E98; Tue, 19 Jan 2016 05:32:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160119133230.14113.44304.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 05:32:30 -0800 Archived-At: Subject: [apps-discuss] The APPSAWG WG has placed draft-appala-mile-xmpp-grid in state "Call For Adoption By WG Issued" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 13:32:30 -0000 The APPSAWG WG has placed draft-appala-mile-xmpp-grid in state Call For Adoption By WG Issued (entered by Alexey Melnikov) The document is available at https://datatracker.ietf.org/doc/draft-appala-mile-xmpp-grid/ Comment: As discussed with our AD and document editors. From nobody Tue Jan 19 05:34:08 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2189A1B2E96; Tue, 19 Jan 2016 05:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 v8bONX9yYGC5; Tue, 19 Jan 2016 05:33:59 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDE31B2E9E; Tue, 19 Jan 2016 05:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1453210435; d=isode.com; s=selector; i=@isode.com; bh=5hWrSMV8VlO1HS+bwR6hynxbFu9DvNzRDedXeLsa+G4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=BBCE0HZ2q3qhE8b+Y8LwR4nK5bLJFrKvsjAatzwzyF8EjGWVz8rU6Cglhqm0JmFYws5F0W NUlDEpOpV2aNyuPZaAgjG2XdeFPPq2J0AMsZxWxTsVWIbrv7nAF04jh8rN0bOmczbeGARR V+G2VKjrnRYZ9E3Gdh1yVhVr4InFmZ4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 19 Jan 2016 13:33:55 +0000 To: appsawg-chairs@ietf.org, draft-appala-mile-xmpp-grid@ietf.org, apps-discuss@ietf.org References: <20160119133230.14113.44304.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <569E3B37.1040906@isode.com> Date: Tue, 19 Jan 2016 13:33:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <20160119133230.14113.44304.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] The APPSAWG WG has placed draft-appala-mile-xmpp-grid in state "Call For Adoption By WG Issued" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 13:34:01 -0000 On 19/01/2016 13:32, IETF Secretariat wrote: > The APPSAWG WG has placed draft-appala-mile-xmpp-grid in state > Call For Adoption By WG Issued (entered by Alexey Melnikov) > > The document is available at > https://datatracker.ietf.org/doc/draft-appala-mile-xmpp-grid/ > > > Comment: > As discussed with our AD and document editors. Sorry, this is a user/tool error, should have been the MILE WG! From nobody Tue Jan 19 08:43:25 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA81B3236 for ; Tue, 19 Jan 2016 08:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 H90ur6-T2eyd for ; Tue, 19 Jan 2016 08:43:21 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 17CFB1B3235 for ; Tue, 19 Jan 2016 08:43:21 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 9DEC11B40E7; Tue, 19 Jan 2016 08:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; s=gbiv.com; bh=o4EpW/ybRwGt/cFsqTEt7D2KirI=; b=m S2wY/3BxzfAVgpZZD2f5oRv8IsWtoT17Y00XTuxPzP1e5qI8pukhu+200P3lsqrD GHk7dKIx0VWXSX9D3ZrKkXHPFBtHEs+moZhLqxrtYIPkzZIW7KvsMHWnhgvwQ8Vd xIUCCEbTCGAz4cHNu8jlB+rq36RMl0/zU6fsvhPLAQ= Received: from [192.168.1.2] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 65F821B40DC; Tue, 19 Jan 2016 08:43:20 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6859C5BB-8079-4D1E-B199-995009D1A0B9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: <994C5976EA09B556.00059E8E-F27D-40AE-A32D-879C0AFA1A19@mail.outlook.com> Date: Tue, 19 Jan 2016 08:43:14 -0800 Message-Id: References: <5697B833.3000703@cisco.com> <007301d14fa8$05d15540$1173ffc0$@gmail.com> <994C5976EA09B556.00059E8E-F27D-40AE-A32D-879C0AFA1A19@mail.outlook.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:43:24 -0000 --Apple-Mail=_6859C5BB-8079-4D1E-B199-995009D1A0B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 16, 2016, at 10:48 AM, Phillip Hallam-Baker = wrote: > [Matthew Kerwin wrote:] >> wasn't .well-known acknowledged to be an anti-pattern when it was set = up? And isn't the DE role therefore to turn proposals away which would = be better served by a (positive) pattern elsewhere, along with that = explanation? >>=20 >> The bar for .well-known should be very high because http !=3D gopher, = nor should it ever be. >>=20 > No, it was asserted but never conceded. More importantly, the IETF = reviewed and agreed the RFC which makes no mention of such a position.=20= http://tools.ietf.org/html/rfc5785#section-1.1 = > The position of DE is not meant to be an opportunity to impose a = private view of Internet architecture on anyone. It certainly isn't an = opportunity to tell people that they should 'do it my way' and = especially not when that turns out to be implement someone's 20 year old = thesis. The .well-known namespace has nothing whatsoever to do with REST. It is = based on the general idea originally exposed by /robots.txt: a set of well known = resources for which no link is necessary, such that a client can attempt to perform some defined = (standard) prerequisite action before some other "normal" action on that same origin server. http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml > I am well aware of the style of architecture that people are = suggesting it is the role of the DE to impose. It is a style that I = played as much of a part in creating as anyone else did. It is a style = that I have used and have since abandoned because I think other = approaches are better.=20 You have not made a registration request of the DE, nor has anyone = suggested that your poor use of DNS, SRV, and .well-known had anything to do with Web = Services vs REST. Darrel Miller disagreed with your characterization of caching and use of = HTTP as an application tunnel, which is what you should expect when making = statements on a mailing list like apps-discuss that directly contradict all known experience = with an IETF protocol. = https://mailarchive.ietf.org/arch/search/?email_list=3Dwellknown-uri-revie= w = Mark suggested here that you need to pick a name to register, in = accordance with the RFC. = https://mailarchive.ietf.org/arch/msg/apps-discuss/CACiBdiDnlW1X7JsnXdEXW2= 2m1U = = https://mailarchive.ietf.org/arch/msg/apps-discuss/X_MTE2a4xKeaPh2zOSlt4qm= jNmg = =20 I suggested here that you can register a name even if the DE disagrees = with your usage, as there is plenty of actual evidence of that in the mailing list, that = a registration discussion is helpful for preventing misinformed folks from cluttering up the space = when they actually want something else (usually a Link header field), and that such = discussion is also useful for providing a historical record of why registrations are made = regardless of suitability. = https://mailarchive.ietf.org/arch/msg/apps-discuss/s0JohIW0qcr7ajHUDyJD4bJ= P86U = The purpose of a DE is to ensure that the registrations meet the = criteria of the namespace as defined by the relevant RFC. Equating all namespaces with port = numbers is nonsense. Port numbers cannot contain trademarks, offensive slogans, or blatant = categorical errors. The .well-known space would be misused under a first-come first-served = basis. And, no, SRV would not have been used by "http" in 1992, nor would it be = used in 2016, since having multiple independent Web servers per host has always = been a desired feature (to escape the largely MIS-controlled gopher phenomenon) and it = is still common today to identify configuration websites by local host names and IP = addresses. The MX record as architecture is ideal for the social characteristics of = email hosting, not for the comparatively anarchic nature of website deployment. Since then, you have repeatedly misquoted and misrepresented what we = said in your own self-serving arguments. If anyone wants to discuss the larger role of = DEs within the IETF, I hope that they do so based on actual events and not on your = fabrications. ....Roy --Apple-Mail=_6859C5BB-8079-4D1E-B199-995009D1A0B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 16, 2016, at = 10:48 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

[Matthew Kerwin = wrote:]

wasn't .well-known = acknowledged to be an anti-pattern when it was set up? And isn't the DE = role therefore to turn proposals away which would be better served by a = (positive) pattern elsewhere, along with that explanation?

The bar = for .well-known should be very high because http !=3D gopher, nor should = it ever be.

No, it was = asserted but never conceded. More importantly, the IETF reviewed and = agreed the RFC which makes no mention of such a = position. 

http://tools.ietf.org/html/rfc5785#section-1.1
The position of DE is not meant to be an = opportunity to impose a private view of Internet architecture on anyone. = It certainly isn't an opportunity to tell people that they should 'do it = my way' and especially not when that turns out to be implement someone's = 20 year old thesis.

The = .well-known namespace has nothing whatsoever to do with REST.  It = is based on the
general idea originally exposed by = /robots.txt: a set of well known resources for which no = link
is necessary, such that a client can attempt to perform = some defined (standard) prerequisite
action before some other = "normal" action on that same origin server.


I am well aware of = the style of architecture that people are suggesting it is the role of = the DE to impose. It is a style that I played as much of a part in = creating as anyone else did. It is a style that I have used and have = since abandoned because I think other approaches are = better. 

You have = not made a registration request of the DE, nor has anyone suggested that = your
poor use of DNS, SRV, and .well-known had anything to do = with Web Services vs REST.
Darrel Miller disagreed with your = characterization of caching and use of HTTP as an
application = tunnel, which is what you should expect when making statements on a = mailing
list like apps-discuss that directly contradict all = known experience with an IETF protocol.


Mark suggested here = that you need to pick a name to register, in accordance with the = RFC.


I = suggested here that you can register a name even if the DE disagrees = with your usage,
as there is plenty of actual evidence of that = in the mailing list, that a registration discussion
is helpful = for preventing misinformed folks from cluttering up the space when they = actually
want something else (usually a Link header field), = and that such discussion is also useful
for providing a = historical record of why registrations are made regardless of = suitability.


The purpose of a = DE is to ensure that the registrations meet the criteria of the = namespace
as defined by the relevant RFC. Equating all = namespaces with port numbers is nonsense.
Port numbers cannot = contain trademarks, offensive slogans, or blatant categorical = errors.
The .well-known space would be misused under a = first-come first-served basis.

And, = no, SRV would not have been used by "http" in 1992, nor would it be used = in
2016, since having multiple independent Web servers per = host has always been a desired
feature (to escape the largely = MIS-controlled gopher phenomenon) and it is still common
today = to identify configuration websites by local host names and IP = addresses.
The MX record as architecture is ideal for the = social characteristics of email hosting,
not for the = comparatively anarchic nature of website deployment.

Since then, you have repeatedly misquoted and = misrepresented what we said in your own
self-serving = arguments. If anyone wants to discuss the larger role of DEs within the = IETF,
I hope that they do so based on actual events and not on = your fabrications.

....Roy

= --Apple-Mail=_6859C5BB-8079-4D1E-B199-995009D1A0B9-- From nobody Tue Jan 19 09:22:52 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298F91B32EB for ; Tue, 19 Jan 2016 09:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Z4OyvSeoNn2l for ; Tue, 19 Jan 2016 09:22:46 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 B0ED41B32E8 for ; Tue, 19 Jan 2016 09:22:45 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id o11so584678282qge.2 for ; Tue, 19 Jan 2016 09:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :thread-index:content-language:mime-version:content-type; bh=lkED48l5afV/8oVcJfXsm8dnzMoSX6iy7obuLxOMIaM=; b=qDmaBbIIK/Oteac0M/5bkdEMQdEQ1E5sQLdcrfO6q5+OdGCu1Gg0H3d9i0YAahH8jo Of5fvdoHLapSMfuFzTpALOl7+an8lQ8v4ssr4Xc0ykSlC5iNUcvqMHXBz92ni2SoG1Bm nPTqZpflW1QgusiByK7wTRIG/wi8evjo01IevMvNpAO5UvpWGiytfGETGwWqvECyiZiG B26cUZByYBKU+EUHMiK1PIPJYPy638iNWFwmHKPPRXDT2llzAiz3//v8D5DNb3BE25Lj SUhH1Mx8tL/G6cfUjQtkgNNkhM3JaJl6reCRxI+DNGGv0guBbsd1TfS4ltAlQC/Ldyu5 deOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:thread-index:content-language:mime-version :content-type; bh=lkED48l5afV/8oVcJfXsm8dnzMoSX6iy7obuLxOMIaM=; b=jSHSH2Gcw61LZKDiICkE2s8AMHlqNnNtcLFjZuKOb0IsMzaQmzVD08H2Q7Ey0rJd9D b2WU4ynN/gLeR9v5Ixrg53jeAH1nUnlWRPy5Nw3WNunWk9O5e9x3iBXHvKCD4YsrwsUC kTy7gMyyRTjuwhVYx9FH+/gfZdcHXoMtksnbq2+XnFNppmCFIiRDeiqbscAatMMy3hXN 58Tufqlev4tCX4Ob8IhkChpCcXes47hKWOlFuXAC5/D+2nnJDaRoPx2SNKTRvdv2tCjs 2UIN1ZlKM3jxg8E/aDOlbTBjdMwMQxaOTn3tWSIhvJjDhKHLaE5vIjG6ERUaVAXjHtiW e0gA== X-Gm-Message-State: ALoCoQld9/Afj9Ei5zg4rhfIDeWsmaHIzhtL8sxBr5RtvKpbTxQW5UveH5SceI1Yvn/OvChs5Tj7wl5dXP4Smf69S0U5geRdGw== X-Received: by 10.140.132.212 with SMTP id 203mr40486158qhe.102.1453224164488; Tue, 19 Jan 2016 09:22:44 -0800 (PST) Received: from Voodoo (pool-96-230-12-42.bstnma.fios.verizon.net. [96.230.12.42]) by smtp.gmail.com with ESMTPSA id q30sm12687869qkq.11.2016.01.19.09.22.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2016 09:22:40 -0800 (PST) Sender: Phillip Hallam-Baker From: "Phillip Hallam-Baker" To: "'Roy T. Fielding'" References: <5697B833.3000703@cisco.com> <007301d14fa8$05d15540$1173ffc0$@gmail.com> <994C5976EA09B556.00059E8E-F27D-40AE-A32D-879C0AFA1A19@mail.outlook.com> In-Reply-To: Date: Tue, 19 Jan 2016 12:22:22 -0500 Message-ID: <1d5b01d152dd$f5fb6b40$e1f241c0$@hallambaker.com> X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIBJAH98aSFpA/7hZmA2YNd3pJiLANA0KesAeaSxG0C9YhLSgJdD5XaAiSFxFMCLR+8IQIsG0lLAOE+VbsCDSwVjAHKLoEznfXwKZA= Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_1C2D_01D152B4.0A8A9420"; micalg=SHA1 Archived-At: Cc: 'General discussion of application-layer protocols' Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:22:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1C2D_01D152B4.0A8A9420 Content-Type: multipart/alternative; boundary="----=_NextPart_001_1C2E_01D152B4.0A8A9420" ------=_NextPart_001_1C2E_01D152B4.0A8A9420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Roy's response accuses me of lying, I regard that as defamatory. From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Roy T. Fielding Sent: Tuesday, January 19, 2016 11:43 AM To: Phillip Hallam-Baker Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come On Jan 16, 2016, at 10:48 AM, Phillip Hallam-Baker > wrote: [Matthew Kerwin wrote:] wasn't .well-known acknowledged to be an anti-pattern when it was set up? And isn't the DE role therefore to turn proposals away which would be better served by a (positive) pattern elsewhere, along with that explanation? The bar for .well-known should be very high because http != gopher, nor should it ever be. No, it was asserted but never conceded. More importantly, the IETF reviewed and agreed the RFC which makes no mention of such a position. http://tools.ietf.org/html/rfc5785#section-1.1 The position of DE is not meant to be an opportunity to impose a private view of Internet architecture on anyone. It certainly isn't an opportunity to tell people that they should 'do it my way' and especially not when that turns out to be implement someone's 20 year old thesis. The .well-known namespace has nothing whatsoever to do with REST. It is based on the general idea originally exposed by /robots.txt: a set of well known resources for which no link is necessary, such that a client can attempt to perform some defined (standard) prerequisite action before some other "normal" action on that same origin server. http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml I am well aware of the style of architecture that people are suggesting it is the role of the DE to impose. It is a style that I played as much of a part in creating as anyone else did. It is a style that I have used and have since abandoned because I think other approaches are better. You have not made a registration request of the DE, nor has anyone suggested that your poor use of DNS, SRV, and .well-known had anything to do with Web Services vs REST. Darrel Miller disagreed with your characterization of caching and use of HTTP as an application tunnel, which is what you should expect when making statements on a mailing list like apps-discuss that directly contradict all known experience with an IETF protocol. https://mailarchive.ietf.org/arch/search/?email_list=wellknown-uri-review Mark suggested here that you need to pick a name to register, in accordance with the RFC. https://mailarchive.ietf.org/arch/msg/apps-discuss/CACiBdiDnlW1X7JsnXdEXW22m 1U https://mailarchive.ietf.org/arch/msg/apps-discuss/X_MTE2a4xKeaPh2zOSlt4qmjN mg I suggested here that you can register a name even if the DE disagrees with your usage, as there is plenty of actual evidence of that in the mailing list, that a registration discussion is helpful for preventing misinformed folks from cluttering up the space when they actually want something else (usually a Link header field), and that such discussion is also useful for providing a historical record of why registrations are made regardless of suitability. https://mailarchive.ietf.org/arch/msg/apps-discuss/s0JohIW0qcr7ajHUDyJD4bJP8 6U The purpose of a DE is to ensure that the registrations meet the criteria of the namespace as defined by the relevant RFC. Equating all namespaces with port numbers is nonsense. Port numbers cannot contain trademarks, offensive slogans, or blatant categorical errors. The .well-known space would be misused under a first-come first-served basis. And, no, SRV would not have been used by "http" in 1992, nor would it be used in 2016, since having multiple independent Web servers per host has always been a desired feature (to escape the largely MIS-controlled gopher phenomenon) and it is still common today to identify configuration websites by local host names and IP addresses. The MX record as architecture is ideal for the social characteristics of email hosting, not for the comparatively anarchic nature of website deployment. Since then, you have repeatedly misquoted and misrepresented what we said in your own self-serving arguments. If anyone wants to discuss the larger role of DEs within the IETF, I hope that they do so based on actual events and not on your fabrications. ....Roy ------=_NextPart_001_1C2E_01D152B4.0A8A9420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roy’s response accuses me of lying, I regard that as = defamatory.

 

 

 

From:<= /b> = apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of = Roy T. Fielding
Sent: Tuesday, January 19, 2016 11:43 = AM
To: Phillip Hallam-Baker = <hallam@gmail.com>
Cc: General discussion of = application-layer protocols = <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] RFC = 5785: Registration of .well-known services under HTTP to First = Come

 

On Jan 16, 2016, at 10:48 AM, Phillip Hallam-Baker = <hallam@gmail.com> = wrote:

[Matthew Kerwin = wrote:]

wasn't .well-known = acknowledged to be an anti-pattern when it was set up? And isn't the DE = role therefore to turn proposals away which would be better served by a = (positive) pattern elsewhere, along with that = explanation?

The bar for .well-known = should be very high because http !=3D gopher, nor should it ever = be.

No, it was asserted but never conceded. More = importantly, the IETF reviewed and agreed the RFC which makes no mention = of such a position. 

 

http://tools.ietf= .org/html/rfc5785#section-1.1



The position of DE is not meant to be an opportunity = to impose a private view of Internet architecture on anyone. It = certainly isn't an opportunity to tell people that they should 'do it my = way' and especially not when that turns out to be implement someone's 20 = year old thesis.

 

The = .well-known namespace has nothing whatsoever to do with REST.  It = is based on the

general = idea originally exposed by /robots.txt: a set of well known resources = for which no link

is = necessary, such that a client can attempt to perform some defined = (standard) prerequisite

action before some other "normal" action on = that same origin server.

 



I am well aware of the style of architecture that = people are suggesting it is the role of the DE to impose. It is a style = that I played as much of a part in creating as anyone else did. It is a = style that I have used and have since abandoned because I think other = approaches are = better. 

 

You = have not made a registration request of the DE, nor has anyone suggested = that your

poor use of DNS, = SRV, and .well-known had anything to do with Web Services vs = REST.

Darrel Miller = disagreed with your characterization of caching and use of HTTP as = an

application tunnel, = which is what you should expect when making statements on a = mailing

list like = apps-discuss that directly contradict all known experience with an IETF = protocol.

 

 

Mark suggested here that you need to pick a name to = register, in accordance with the RFC.

 

 

I = suggested here that you can register a name even if the DE disagrees = with your usage,

as there = is plenty of actual evidence of that in the mailing list, that a = registration discussion

is = helpful for preventing misinformed folks from cluttering up the space = when they actually

want = something else (usually a Link header field), and that such discussion = is also useful

for = providing a historical record of why registrations are made regardless = of suitability.

 

 

The purpose of a DE is to ensure that the = registrations meet the criteria of the = namespace

as defined by = the relevant RFC. Equating all namespaces with port numbers is = nonsense.

Port numbers = cannot contain trademarks, offensive slogans, or blatant categorical = errors.

The .well-known = space would be misused under a first-come first-served = basis.

 

And, no, SRV would not have been used by = "http" in 1992, nor would it be used = in

2016, since having = multiple independent Web servers per host has always been a = desired

feature (to escape = the largely MIS-controlled gopher phenomenon) and it is still = common

today to identify = configuration websites by local host names and IP = addresses.

The MX record = as architecture is ideal for the social characteristics of email = hosting,

not for the = comparatively anarchic nature of website = deployment.

 

Since then, you have repeatedly misquoted and = misrepresented what we said in your own

self-serving arguments. If anyone wants to discuss the = larger role of DEs within the IETF,

I hope that they do so based on actual events and not = on your fabrications.

 

....Roy

 

------=_NextPart_001_1C2E_01D152B4.0A8A9420-- ------=_NextPart_000_1C2D_01D152B4.0A8A9420 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOMjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFQTCCBCmgAwIBAgIQdaERSLdY7bYwd5EFWa7+RDANBgkqhkiG9w0BAQsFADCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE1MTIxMDAwMDAwMFoXDTE2MTIw OTIzNTk1OVowJjEkMCIGCSqGSIb3DQEJARYVcGhpbGxAaGFsbGFtYmFrZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2YnK94wSqi7VB5wcp2LPCjFA+QAZiSra/0Tz5ARK4i9S aYK+WB4Nk4ckEmsuhZHcYgFA28TDEyu9sq2RJ9i0iy2KS0bIpUrV5jjHgvmS5TRM9wTw5/EeVEoD 8/0KPoOicsBcIQQ55A8fhu8TkAdpDrJmitFySel1rKbBoioN8fY/y0qQFm68VWPb8JojODlzmdbO ClG09TCAawnNWVgUU1yen+7VVJZEimuQNh0b/Uh03+uQCqy22OZyG1fKaG/d4MvCrvdoPS8kHf7r Z+19t5gLj7Wxu1SXozRJ3SJp7LEBkfEx+0wCp7dKkuNt5K/XhD0cBqubHiK1aOtL/FsbBQIDAQAB o4IB8zCCAe8wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFODuc5sM rDb49Kn7E7HWO98l++JVMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAgBgNVHREEGTAXgRVwaGlsbEBoYWxsYW1iYWtlci5jb20wDQYJKoZIhvcN AQELBQADggEBAFnZ5Nihol4Tnpha+lG8dUcOiTIOiW4RLmWsHduYoQ05Yn2RIT0dUqU7AQB4ryFR EGpqGqoSSByqL7rweQoO/vuXUuKCN60E3cONHabZcfEKt2tceqlpMFcpQ0/xOxjeG0Ci5greKpDu 6lxmnmTjC/v5WLwPAS1H1PTSbrdvc8s1PLaajFyC3X22z2Nrnj+QJ0f4zmY7Xagw1R6ZeyHVorQM vlcryhQvYkHkih5N9dtzoWqPrY1DpldMqSyUdSCiLq4pudm2n6C2z02RhLbysrP3k0yB9H8M4In6 2BeZ1XsGAMErU9/Ivki2LqzArV3hnKDKvkhHh4ptvPTqZJQj3RkxggRZMIIEVQIBATCBsDCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhB1oRFIt1jttjB3kQVZrv5E MAkGBSsOAwIaBQCgggJ9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE2MDExOTE3MjIxOVowIwYJKoZIhvcNAQkEMRYEFBkVrSopAdvlzMPjIsu2J+2SyMUKMIGTBgkq hkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFl AwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQdaERSLdY7bYwd5EFWa7+RDCB wwYLKoZIhvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1h bmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIQdaERSLdY7bYwd5EFWa7+RDANBgkqhkiG9w0BAQEFAASCAQBQ3Hh259vw6rTVNlFI A1cR5BU2DAMhi1ezmHkXn8XpLhSNmsB6L2gcrUDTSmeNrN+QatcrMEqQf0e2ATf5OprZnvjyv/oY KL0lm2XyvIq4pZkSKhC/exKgXLAy3g8EkX2NjCjS2HiDozNqZCm/qIlCLiiL6Yxxag8UEJ05NXJd wq7WOI14Q6N6n+/9CyanfR3xOeyZkpnpUi8mobvIfXYm+r+yaiWSt1kD7NzA4u2TzIIQV5QNeQ50 y3eQCA0lZo7PfO73X50cGSnTs06THQdMQknOAyJG7nsaNuAjwf3b6/yBbkoFGUe5/GfJCWYKjyfO xc3hW24vRXr7kIivqIBIAAAAAAAA ------=_NextPart_000_1C2D_01D152B4.0A8A9420-- From nobody Tue Jan 19 21:03:41 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7631A1BF4; Tue, 19 Jan 2016 21:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6AypYKryhYEo; Tue, 19 Jan 2016 21:03:38 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C48A1A1BF3; Tue, 19 Jan 2016 21:03:38 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5BBB322E273; Wed, 20 Jan 2016 00:03:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Wed, 20 Jan 2016 16:03:32 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6AB7D185-CF89-47D6-AEE7-B116D8B34274@mnot.net> References: <20151217143841.8732.14093.idtracker@ietfa.amsl.com> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.2104) Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, The IESG , General discussion of application-layer protocols Subject: Re: [apps-discuss] Spencer Dawkins' Discuss on draft-ietf-appsawg-http-problem-02: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:03:40 -0000 > On 8 Jan 2016, at 12:58 am, Spencer Dawkins at IETF = wrote: >=20 > I'll clear this Discuss, but would love it if you could say something = like what you've told me in the document. Thanks. See: https://github.com/mnot/I-D/commit/01ab26f579d933 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jan 19 21:13:29 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7971A212A; Tue, 19 Jan 2016 21:13:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120051326.20880.82321.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 21:13:26 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-problem-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:13:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : Problem Details for HTTP APIs Authors : Mark Nottingham Erik Wilde Filename : draft-ietf-appsawg-http-problem-03.txt Pages : 16 Date : 2016-01-19 Abstract: This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to define new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. This section is to be removed before publication. Note to RFC Editor Please replace all occurrences of "XXXX" with the final RFC number chosen for this draft. This section is to be removed before publication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-http-problem-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 20 12:44:25 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C431ACE58 for ; Wed, 20 Jan 2016 12:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 U1iNMp2psKgT for ; Wed, 20 Jan 2016 12:44:23 -0800 (PST) Received: from mx1.canada.ca (mx1.canada.ca [205.193.214.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946A41ACE57 for ; Wed, 20 Jan 2016 12:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=canada.ca; i=@canada.ca; q=dns/txt; s=mx1; t=1453322663; x=1484858663; h=from:to:subject:date:content-transfer-encoding: mime-version; bh=PD8BQEJmvJ/SwdwVqQlYxxVtRO8xvXZOTuYo/PHNpXk=; b=RFjO+RhUpaUrlF/JUq9ne4tk3kxszPoHHbfJCNNRv4eZJeoyVxbbvbuB unEvcDCMbV3tIUqXnc8yLbj6mojaR6E/dD1eq7mJ21N+C7UiESLUCSHmd u4sq6RkBIZ78hVWNgsSn9uonzi0fCsjDvI/li4WuSD6/K2nsNLDz5htci taytg3KqidUF4N2CsCyrbMpmoNCaWwx4MUWdPEnO5RLsom5wD93nfdQLq chRrPW7G7ZVANGkHveghnigB8HELoH26iS5t0Inws4r4XTvHodXxCM+gh q2YMB1uajSijy/zwvNKN8CZ5yKKujsz3a8AGlzhZ31BUz5m1dmaNGXO8w g==; X-Time-IN: 20 Jan 2016 20:44:22 -0000 From: "Rushforth, Peter (NRCan/RNCan)" To: IETF Apps Discuss Thread-Topic: RFC 6839 structured suffix support in actual software Thread-Index: AdFTwchQ+WE1ZoUgRHCFRtWZVlaoug== Date: Wed, 20 Jan 2016 20:44:21 +0000 Accept-Language: en-CA, en-US Content-Language: en-US x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20160120204423.946A41ACE57@ietfa.amsl.com> Archived-At: Subject: [apps-discuss] RFC 6839 structured suffix support in actual software X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:44:24 -0000 Hi, Can anyone please identify some available software which implements the beh= aviour described in section 2 of RFC 6839, specifically, generic processin= g of a media type based on its structured suffix? Any structured suffix will do. Thank you. Peter Rushforth From nobody Wed Jan 20 21:23:49 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C651B2F65 for ; Wed, 20 Jan 2016 21:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 oQiPYT3mLYs5 for ; Wed, 20 Jan 2016 21:23:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B273F1B2F64 for ; Wed, 20 Jan 2016 21:23:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2C2DC180092; Wed, 20 Jan 2016 21:22:33 -0800 (PST) To: pbryan@anode.ca, mnot@mnot.net, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160121052233.2C2DC180092@rfc-editor.org> Date: Wed, 20 Jan 2016 21:22:33 -0800 (PST) Archived-At: Cc: jeromem@ca.ibm.com, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC6902 (4596) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 05:23:48 -0000 The following errata report has been submitted for RFC6902, "JavaScript Object Notation (JSON) Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6902&eid=4596 -------------------------------------- Type: Technical Reported by: Missing 'Append' operation Section: GLOBAL Original Text ------------- Its value MUST be one of "add", "remove", "replace", "move", "copy", or "test"; other values are errors. Corrected Text -------------- Its value MUST be one of "add", "append", "remove", "replace", "move", "copy", or "test"; other values are errors. ... and more text to add the 'append' op description. Notes ----- There is a key missing piece to this RFC. You can do { "op": "add", "path": "/attr", "value": "val"}, which will add or modify the 'attr' attribute, if it exists or not. However, you cannot add an item to a potentially non-existing array. Updating an array that may or may not exists, forces the client to always call GET on the resource. See this API spec: https://orchestrate.io/docs/apiref#keyvalue-patch which implements the op 'append', which would solve this problem. 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6902 (draft-ietf-appsawg-json-patch-10) -------------------------------------- Title : JavaScript Object Notation (JSON) Patch Publication Date : April 2013 Author(s) : P. Bryan, Ed., M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Thu Jan 21 04:53:14 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061BB1B30A8; Thu, 21 Jan 2016 04:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 XLQDAYbJgodk; Thu, 21 Jan 2016 04:53:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 853ED1B30A6; Thu, 21 Jan 2016 04:53:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 09DAD180094; Thu, 21 Jan 2016 04:51:57 -0800 (PST) To: jeromem@ca.ibm.com, pbryan@anode.ca, mnot@mnot.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160121125157.09DAD180094@rfc-editor.org> Date: Thu, 21 Jan 2016 04:51:57 -0800 (PST) Archived-At: Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Rejected] RFC6902 (4596) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 12:53:13 -0000 The following errata report has been rejected for RFC6902, "JavaScript Object Notation (JSON) Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6902&eid=4596 -------------------------------------- Status: Rejected Type: Technical Reported by: Missing 'Append' operation Date Reported: 2016-01-21 Rejected by: Barry Leiba (IESG) Section: GLOBAL Original Text ------------- Its value MUST be one of "add", "remove", "replace", "move", "copy", or "test"; other values are errors. Corrected Text -------------- Its value MUST be one of "add", "append", "remove", "replace", "move", "copy", or "test"; other values are errors. ... and more text to add the 'append' op description. Notes ----- There is a key missing piece to this RFC. You can do { "op": "add", "path": "/attr", "value": "val"}, which will add or modify the 'attr' attribute, if it exists or not. However, you cannot add an item to a potentially non-existing array. Updating an array that may or may not exists, forces the client to always call GET on the resource. See this API spec: https://orchestrate.io/docs/apiref#keyvalue-patch which implements the op 'append', which would solve this problem. --VERIFIER NOTES-- This is an enhancement suggestion, not an errata report; the errata system is not for that. -------------------------------------- RFC6902 (draft-ietf-appsawg-json-patch-10) -------------------------------------- Title : JavaScript Object Notation (JSON) Patch Publication Date : April 2013 Author(s) : P. Bryan, Ed., M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Thu Jan 21 04:58:32 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63B61B30B6 for ; Thu, 21 Jan 2016 04:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bAL9Ky8Ve1E for ; Thu, 21 Jan 2016 04:58:30 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 94D781B30BC for ; Thu, 21 Jan 2016 04:58:30 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 1so52982384ion.1 for ; Thu, 21 Jan 2016 04:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QO2d3hJS164DgnKyYbCGMd3PuaHuYurGWvAd/kHCBTM=; b=SyoFP7+ZBpZsaSsvmqv40ArTlRxrvuqEXOfuZWZZfA5FXZWBbCUs0mtMU7D3a1Ci/x Apz4YG1fUGWVoJCIRGGJmIvh+e6SRMhRYdjoyc78Whtgg5RKu4Nl+PMFhtsgh1+HX+Rc OVvHfYWhQLprHfKyPvXee/ZEoIIGzAFNriOd4L7IulS9dqO79no4i1cJQ2DUY85jgDp0 HzgicqbH/ZCQPuHYroyN0sprA3eigjgP3ks9H4erzl3QtuteXVoZO8hxbzVT4PpX1Db8 EBShxJ0hs8YGShdFOqqANJXDnWY9FY6fRFSwrbcGjZoIkTJbKyhOYimHqFYYu4tbn3Ek vjmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QO2d3hJS164DgnKyYbCGMd3PuaHuYurGWvAd/kHCBTM=; b=JrHSKuDcWfXwmoh1Yqbp3dBDu4MPgPtDglPx+IfCDoP9sBrjEn9M1AzP5dPofV/Zkq OwAyEfj5FWB4kuObuIBEgBrcCnSgBWKNfHI+AXdgpbEPT3SAtsFIz9+JSKBX4/U1gGyo pBJCXw4ul+hsHW2UAsL+RaTBPbp4f0CQR+sVmOj7/ZPSArk3NzYNxFLWdRVVLp88rc7K 3/PCLxviwxktJKshrXAkL+8OMyJthV3ESe64M8mzdgPhp98ysH/A+HVuBoPgw6K2sju7 ujzc+gQU0EudDzs3+kytBB0bwq5OM9BHS2Z1YFpQce8hN7CMdnCloPnu36yq/IxKF8GY 1O+Q== X-Gm-Message-State: AG10YOQmV7kRO2venafmfoL+FtQvl8tZMpnkbO78N7a+xep6XKUbEA9HxC1tlBFeFb+cHoR6f+bR9R0Gpqs3VQ== MIME-Version: 1.0 X-Received: by 10.107.38.5 with SMTP id m5mr33042328iom.15.1453381109971; Thu, 21 Jan 2016 04:58:29 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.181.65 with HTTP; Thu, 21 Jan 2016 04:58:29 -0800 (PST) In-Reply-To: <568D20ED.6010702@att.com> References: <20160105014245.88C5A18000C@rfc-editor.org> <1707442344.20160105140217@w3.org> <568D20ED.6010702@att.com> Date: Thu, 21 Jan 2016 07:58:29 -0500 X-Google-Sender-Auth: YIs5vnteAU9n7Oh6W-4zSU3NEHc Message-ID: From: Barry Leiba To: Tony Hansen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7303 (4578) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 12:58:32 -0000 Seeing no further comments on this, I'm going to go ahead and mark this report Verified. Barry On Wed, Jan 6, 2016 at 9:13 AM, Tony Hansen wrote: > On 1/6/16 7:47 AM, Henry S. Thompson wrote: >> Chris Lilley writes: >> >>>> The following errata report has been submitted for RFC7303, >>>> "XML Media Types". >>> I believe that the original text is correct, because W3C is change >>> controller not only of the +xml suffic but also of application/xml and >>> related types. >>> >>> Henry, do you agree? >> No, I think Martin's change is OK -- this change is in section 4.2, >> which is specifically a takeover of the '+xml' suffix registration from >> RFC6839. >> >> That W3C is the change controller for application/xml etc. is not a >> change, it was true in 3023. > > As one of the authors of RFC6839, I agree with the above comments, and > support Martin's improved wording. W3C is not supposed to be the change > controller for application/example+xml, and reading this sentence to > mean that W3C does become such is definitely a mistake. Martin's > improved wording eliminates any such confusion. > > Tony Hansen > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Jan 21 05:02:31 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727AB1B30BF; Thu, 21 Jan 2016 05:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 AGE6dBjcKkqY; Thu, 21 Jan 2016 05:02:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 60BF91B30CB; Thu, 21 Jan 2016 05:02:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D0489180205; Thu, 21 Jan 2016 05:01:07 -0800 (PST) To: brettz9@yaho.com, pbryan@anode.ca, mnot@mnot.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160121130107.D0489180205@rfc-editor.org> Date: Thu, 21 Jan 2016 05:01:07 -0800 (PST) Archived-At: Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Rejected] RFC6902 (4419) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 13:02:26 -0000 The following errata report has been rejected for RFC6902, "JavaScript Object Notation (JSON) Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6902&eid=4419 -------------------------------------- Status: Rejected Type: Editorial Reported by: Brett Zamir Date Reported: 2015-07-17 Rejected by: Barry Leiba (IESG) Section: A.14 Original Text ------------- An example target JSON document: { "/": 9, "~1": 10 } A JSON Patch document: [ {"op": "test", "path": "/~01", "value": 10} ] The resulting JSON document: { "/": 9, "~1": 10 } Corrected Text -------------- Proper JSON Pointer escaping should occur when resolving paths for application to the target document. An example target JSON document: { "/": 9, "~1": 10 } A JSON Patch document: [ {"op": "add", "path": "/~01", "value": 11} ] The resulting JSON document: { "/": 9, "~1": 11 } Notes ----- At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few issues: 1. Even though JSON Pointer is referenced elsewhere, I think reference ought to be made here to JSON Pointer in order to clarify what meaning "escape ordering" has here. 2. The operation indicated in this section is "test" which is not documented in its respective sections as returning any kind of document at all. I believe "add" or "replace" must have been the intended operation instead. And to make clear that the value of key "~1" would have actually been affected by such a modifying operation, the value in the result ought to differ from that in the original document. --VERIFIER NOTES-- The example is correct, but could use clarification. The authors have noted this and put it in their JSON Patch issues list here: https://github.com/json-patch/json-patch-tests/issues/22 -------------------------------------- RFC6902 (draft-ietf-appsawg-json-patch-10) -------------------------------------- Title : JavaScript Object Notation (JSON) Patch Publication Date : April 2013 Author(s) : P. Bryan, Ed., M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From prvs=820790f80=peter.rushforth@canada.ca Wed Jan 20 12:20:41 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEBD1ACDCE for ; Wed, 20 Jan 2016 12:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xp5AOd_q1dNP for ; Wed, 20 Jan 2016 12:20:40 -0800 (PST) Received: from mx1.canada.ca (mx1.canada.ca [205.193.214.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D8C1ACDCB for ; Wed, 20 Jan 2016 12:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=canada.ca; i=@canada.ca; q=dns/txt; s=mx1; t=1453321240; x=1484857240; h=from:to:subject:date:content-transfer-encoding: mime-version; bh=/mk62Gw/gCSbjpHi6LttDLsT+D82RYeKT3fDhIuWIiM=; b=sMgCr4QX/d57skUE4CQw4sqjU/1AGg0EZ3z/j43uHBHVp2P90kWRuGz4 pyp4HWRWIOFgaSizgZyBY1tQsJRczbVI7ZVTADfs0qCytVp+E7+2Zewkv 083XtNI1uXJceORA1SEJDDNrD1KpYWSxRTFRl1WLAc37/vI8zqUdejx3s 6TSMte4Ha1Me2txJ/MU8KUDmYZTfAwhzVVsrd9k2WSF/C3raawe+HPNMu n9mEKfQAwAT2VsqWMYNwo75Hoz0+Cw0QDhVkiDIAYJNoLWSnRlBNvxYAG jAByRF+PO+R8qP2l059AeRSUyA5Ff0MOV4zTacJsZvSVWmB9Rv3qv5VmH g==; X-Time-IN: 20 Jan 2016 20:20:36 -0000 From: "Rushforth, Peter (NRCan/RNCan)" To: IETF Apps Discuss Thread-Topic: RFC 6839 structured suffix support in actual software Thread-Index: AdFTv1nOa/aRF41XRp6GoKCk9ui/KA== Date: Wed, 20 Jan 2016 20:20:28 +0000 Accept-Language: en-CA, en-US Content-Language: en-US x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20160120202040.42D8C1ACDCB@ietfa.amsl.com> Archived-At: X-Mailman-Approved-At: Thu, 21 Jan 2016 23:41:37 -0800 Subject: [apps-discuss] RFC 6839 structured suffix support in actual software X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:22:38 -0000 Hi, Can anyone please identify some available software which implements the beh= aviour described in section 2 of RFC 6839, specifically, generic processing of a media type ba= sed on its=20 structured suffix? Any structured suffix will do. Thank you. Peter Rushforth From nobody Thu Jan 21 23:47:27 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8A21AC42B for ; Thu, 21 Jan 2016 23:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 p-Ao5tPbil_h for ; Thu, 21 Jan 2016 23:47:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A77B1AC42A for ; Thu, 21 Jan 2016 23:47:24 -0800 (PST) Received: from [192.168.178.20] ([93.217.110.208]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LynHb-1a1hiJ1NNH-016A7s; Fri, 22 Jan 2016 08:47:20 +0100 To: "Rushforth, Peter (NRCan/RNCan)" , IETF Apps Discuss References: <20160120204423.946A41ACE57@ietfa.amsl.com> From: Julian Reschke Message-ID: <56A1DE89.9040501@gmx.de> Date: Fri, 22 Jan 2016 08:47:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160120204423.946A41ACE57@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ECVs7Wx3ZcKHua6csUdOsyBGrCeow5gSkliQmguIlWrcWVQHQl1 o/G/Z9HQ93WQM061poZ0PJA6DXrkURGxnlr6t+w9SkxRpNK7bCWSFnk/oMemWXt6yfSbLtd HJJPScDdRvrYYnkLD5aFsVegDgyiu4IlWfdNZD6yXP0wUnFAkcW6y5bO+c7S8O+HpUmTXIo Ud90C325yQO0Q4se3Qk2Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:Wc+hB79n3ww=:iNDRNoVcEn0ZiqQaEZr7KS U/cu6NZb65LcGEw1J/VgLsGg88lnyUbobprD6zqFlLzNmIBJbhErUSt5wJiyPqCVUXo3tlITv PLOl0MOF5pT0DfddkuSdUU2ukKyuT2Q4N4bq5vqdyCSGi5lNjY9xmFmqCoBDbHVmyCH0J04+o Vu5wGIgl5nds1WGuNiFLZcx+AVvdn1V5c0y2X+nWtTR336J9ew24pRRrTT0qCju4C1AIJj7E+ raZBYN6N65ZB1TmeoAZHA1vREXqUGwX2P7P3+AV63FPwxcKDciZcSocDhfbC+cSgGfglNXqAl JnqHViyg5FoU3e8c93sMFuGx9fgP8HXlnv80MdgrYi6uNmmh3VaOv5oUfWzRe38nxtdqC9BoV fcNReX10Jp376gL4d02wb7keSa628jlBNCHhMP5FJoumbEmk4Rwjd9W2OvyBkOfYFIImt/8c8 PspCu4IKTyEXLPcH1i2WzJD+r0cd8T1OBzicZzAb1XDRvY7g1Uq1isu/LEHgzOZ1M67P3HIZX AO/NRlrxWaXw4IQXwaSYh2fUKe5gzZrXdqqUAKj71Hv7hvGnIvBKRtBrougFXKV2vdgBI71mO BIUj6JCLaSrHSY8o8sOHAD9Y9z5ZILrTp6UTDaHZTxPApvDHMmsWYFJSW13ZtBr4wvYOXXQi+ OuzKk27iyAoq56SrP/68ginWq21rkbc9bpYktwexLNK0EwTRGRDbQGtnaPphpM2rl8EeK2ADL 6SD7LM5zPUjHYoAlf4ESnxiMGJ2frCv8z0weG1NQKiPBwIWif0ZYs6zIAmRn9XgvVHzcUbArm f0RdSYm Archived-At: Subject: Re: [apps-discuss] RFC 6839 structured suffix support in actual software X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 07:47:26 -0000 On 2016-01-20 21:44, Rushforth, Peter (NRCan/RNCan) wrote: > Hi, > > Can anyone please identify some available software which implements the behaviour described in section 2 of RFC 6839, specifically, generic processing of a media type based on its structured suffix? > > Any structured suffix will do. > > Thank you. > > Peter Rushforth AFAIK, XMLHttpRequest triggers special behavior based on the "+xml" suffix; see . Best regards, Julian From nobody Fri Jan 22 08:40:45 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB3B1B29C8 for ; Fri, 22 Jan 2016 08:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zdvL_oLwEVKF for ; Fri, 22 Jan 2016 08:40:40 -0800 (PST) Received: from mx1.canada.ca (mx1.canada.ca [205.193.214.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6419D1A6FDB for ; Fri, 22 Jan 2016 08:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=canada.ca; i=@canada.ca; q=dns/txt; s=mx1; t=1453480841; x=1485016841; h=from:to:subject:date:references:in-reply-to: content-transfer-encoding:mime-version; bh=THVz0ZfYmsPZ6zg3nKwpb+J+UhKjmhaf5v0T+9RWnvA=; b=Meo6J9/MczxyKo3JprU/uHKYBxQneBVfJDs9bDNP9tBkpm/P7CIOydBr rtffxeOg+ng06y3fMN7gmMPCjtzED4NWwvENArosjGhZppCYK279Yw2pC 6MMmi8BV6zcpbXdJoRMdnC3ob2XRE8adRZe7xeAoWYuOAE2E06PDG8As2 ZO0nR3XC2ShbIXFEMs59XoYrTnaH5zKgHti7EpJKlpiEta0lmvAucomOb CkfE6bF0dZS2VRHeLZrjklpuEDnXd8+m/r9D1QR5zLDx7sS8rOeAU5p/+ Hpvrm6eXvlrBQzspedLqn/pKtPrkQUyYqSRyfCLnjysd9egQqNeazE5XZ w==; X-Time-IN: 22 Jan 2016 16:40:39 -0000 From: "Rushforth, Peter (NRCan/RNCan)" To: Julian Reschke , IETF Apps Discuss Thread-Topic: [apps-discuss] RFC 6839 structured suffix support in actual software Thread-Index: AdFTwchQ+WE1ZoUgRHCFRtWZVlaougBUUByAAAgbviA= Date: Fri, 22 Jan 2016 16:40:36 +0000 References: <20160120204423.946A41ACE57@ietfa.amsl.com> <56A1DE89.9040501@gmx.de> In-Reply-To: <56A1DE89.9040501@gmx.de> Accept-Language: en-CA, en-US Content-Language: en-US x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20160122164040.6419D1A6FDB@ietfa.amsl.com> Archived-At: Subject: Re: [apps-discuss] RFC 6839 structured suffix support in actual software X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 16:40:43 -0000 Hi Julian, Thanks for your response. Indeed, I tested it in Chrome and it does appear= to work like that. Regards, Peter Rushforth > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: January 22, 2016 02:47 > To: Rushforth, Peter (NRCan/RNCan); IETF Apps Discuss > Subject: Re: [apps-discuss] RFC 6839 structured suffix support in actual > software >=20 > On 2016-01-20 21:44, Rushforth, Peter (NRCan/RNCan) wrote: > > Hi, > > > > Can anyone please identify some available software which implements the > behaviour described in section 2 of RFC 6839, specifically, generic proc= essing > of a media type based on its structured suffix? > > > > Any structured suffix will do. > > > > Thank you. > > > > Peter Rushforth >=20 > AFAIK, XMLHttpRequest triggers special behavior based on the "+xml" > suffix; see body-0>. >=20 > Best regards, Julian From nobody Sun Jan 24 09:29:48 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 768F01A8770; Sun, 24 Jan 2016 09:29:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160124172945.30408.26332.idtracker@ietfa.amsl.com> Date: Sun, 24 Jan 2016 09:29:45 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 17:29:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-06.txt Pages : 32 Date : 2016-01-24 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 25 02:38:52 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9B81A897D for ; Mon, 25 Jan 2016 02:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QOusjDTavOXr for ; Mon, 25 Jan 2016 02:38:48 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECB71A897C for ; Mon, 25 Jan 2016 02:38:46 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id u0PAcbSP030114; Mon, 25 Jan 2016 11:38:37 +0100 From: "Jose Saldana" To: References: <010f01d1381d$888d6570$99a83050$@unizar.es> In-Reply-To: <010f01d1381d$888d6570$99a83050$@unizar.es> Date: Mon, 25 Jan 2016 11:38:49 +0100 Message-ID: <027c01d1575c$9423ffd0$bc6bff70$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027D_01D15764.F5EA1580" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJjmlzDyI6g/vCZWHQFOG+mJ5MnnJ3nd7GA Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: Cc: =?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?= Subject: [apps-discuss] RV: A draft about delay limits for real-time services X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 10:38:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_027D_01D15764.F5EA1580 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear all, =20 Hi again. We would like to kindly ask you if you feel that this draft = could fall within the Applications and Real Time area. It contains a set of recommendations about the maximum delay tolerated by users of emerging real-time services as online games. =20 = = https://datatracker.ietf.org/doc/draft-suznjevic-dispatch-delay-limits/ =20 Thanks in advance! =20 Jose Saldana & Mirko Suznjevic =20 =20 De: apps-discuss [mailto:apps-discuss-bounces@ietf.org] En nombre de = Jose Saldana Enviado el: mi=E9rcoles, 16 de diciembre de 2015 17:19 Para: apps-discuss@ietf.org CC: 'Mirko Su=BEnjevi=E6' Asunto: [apps-discuss] A draft about delay limits for real-time services =20 Hi all, =20 We have submitted this draft: = https://datatracker.ietf.org/doc/draft-suznjevic-dispatch-delay-limits/=20 =20 It surveys a set of recommendations about the maximum latency tolerated = by the users of services with delay constraints. Some recommendations = already exist for e.g. VoIP, but emerging services as e.g. online gaming, have different requirements. =20 Different papers in the literature reporting these constraints are = surveyed, and a summary of the latency limits for each service is provided. =20 The draft has been adapted from a more specific one, which was submitted some time ago to the Transport Area WG ( http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/). The current version is more general, and not specific for the case of = traffic optimization with multiplexing. =20 We have first submitted it to the Dispatch WG, and the advice we have received is that we could ask in appsawg. The proposal does not aim to propose any new WG, and it is related to real-time applications as e.g. = VoIP or online games. As said in the charter, "The Applications Area = sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group." =20 =20 Thanks in advance, =20 Jose Saldana & Mirko Suznjevic =20 ------=_NextPart_000_027D_01D15764.F5EA1580 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Dear= all,

 <= /span>

Hi again. We would like to kindly ask you if you feel that this = draft could fall within the Applications and Real Time area. It contains = a set of recommendations about the maximum delay tolerated by users of = emerging real-time services as online games.

 

https://datatracker.ietf.org/doc/draft-= suznjevic-dispatch-delay-limits/

 

Thanks in advance!

 

Jose Saldana & Mirko Suznjevic

 

 

De: apps-discuss [mailto:apps-discuss-bounces@ietf.org] = En nombre de Jose Saldana
Enviado el: mi=E9rcoles, 16 = de diciembre de 2015 17:19
Para: = apps-discuss@ietf.org
CC: 'Mirko Su=BEnjevi=E6' = <Mirko.Suznjevic@fer.hr>
Asunto: [apps-discuss] A draft = about delay limits for real-time = services

 

Hi = all,

 

We have submitted this draft: = https://datatracker.ietf.org/doc/draft-= suznjevic-dispatch-delay-limits/

 

It surveys a set of recommendations = about the maximum latency tolerated by the users of services with delay = constraints. Some recommendations already exist for e.g. VoIP, but = emerging services as e.g. online gaming, have different = requirements.

 

Different papers in the literature = reporting these constraints are surveyed, and a summary of the latency = limits for each service is provided.

 

The draft has been adapted from a more = specific one, which was submitted some time ago to the Transport Area WG = (http://datatracker.ietf.org/doc/draft-s= uznjevic-tsvwg-mtd-tcmtf/). The current version is more = general, and not specific for the case of traffic optimization with = multiplexing.

 

We have first submitted it to the = Dispatch WG, and the advice we have received is that we could ask in = appsawg. The proposal does not aim to propose any new WG, and it is = related to real-time applications as e.g. VoIP or online games. As said = in the charter, “The Applications Area sometimes receives = proposals for the development of specifications dealing with = application-related topics that are not in scope for an existing working = group and do not justify the formation of a new working = group.”

 

 

Thanks in = advance,

 

Jose Saldana & Mirko = Suznjevic

 

------=_NextPart_000_027D_01D15764.F5EA1580-- From nobody Thu Jan 28 09:23:02 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11CC1A8ABA for ; Thu, 28 Jan 2016 09:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 kXeHQzDtlkYk for ; Thu, 28 Jan 2016 09:22:58 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 DD8461A8ACA for ; Thu, 28 Jan 2016 09:22:57 -0800 (PST) Received: by mail-qg0-x22b.google.com with SMTP id e32so44809873qgf.3 for ; Thu, 28 Jan 2016 09:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=zt6zFPC0/CnVdWrxmk7IuVM+5TCorvjFhyKKKay0GxI=; b=tw3syLb5q9tE/36zJaIAun1w0mYA9XXlwd8Df20dWvoAdyV4tyXbjs3uCntt7G/iMl 02oovdtlztHgsSxEIX9kkM3ElFXMQl4CrO9t2LCIxLZFnnI/wgTWQWsFbgcYk+TWi1Ph BC7xJrYlpwrdC7pvAAJXGwfx/P2A4XbXb0imCdvW35f2ehIhf64MvSBGU6s7lV2D1dBN pXIXdTX5wQMpw9ilyRn4yLnVDR8rHfZ33E+/G+JGOBDjIffwA3uc9nmpaR1Ot4zwukeQ H3p7qkJNzlGc1b0XjqOaAoUZw7huAVVj4ijag/zhVleGwt7Clh0ZiFZsIzKA1R61OFmu wbTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=zt6zFPC0/CnVdWrxmk7IuVM+5TCorvjFhyKKKay0GxI=; b=gPYMtjVpIozA/XJnOHB2C2N/To8w726+Z6cZF4YBhYpWt4PhjBQBNiwa+9TJU5nsXl +h24o67ExG4aX9zIcLocys+nlOHykWZDfWpq7cplGIsU/ot0AA9ZKxVn2ZBTswr+LAh+ iPF7BfzVDCaDQ30Gpj5jcqauPgEKW+vJQ+vtpY7UAYpxzMqjvJXrdX70XlDJbWZi0uT/ JC2ZWfgJnjcC+pVTmeMe0F0xcS0VXdwnWf9YynGjuG9A4Ch/n7erZ6XrftklB56trmWf 0KoB7CqtQAVKZ1QNk4dekTy4MoywZe9776+6eUy9lxq/LmwkwLfkmF5gW3k66CuyXrKZ VBKw== X-Gm-Message-State: AG10YOTja/kd0UXvLkdk6HINk342PysLY7KnpsV2ybgfe2zaTnjQOQlNIvXGUVZhhtjBlfRHgJ7sURcD0Z+gnQ== X-Received: by 10.140.100.229 with SMTP id s92mr4881691qge.19.1454001777124; Thu, 28 Jan 2016 09:22:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 28 Jan 2016 09:22:37 -0800 (PST) From: Ted Hardie Date: Thu, 28 Jan 2016 09:22:37 -0800 Message-ID: To: "apps-discuss@ietf.org" , Suzanne Woolf , Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c165226daaa5052a682b38 Archived-At: Subject: [apps-discuss] ARCING BoF and mailing list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 17:23:00 -0000 --001a11c165226daaa5052a682b38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, Andrew Sullivan, Suzanne Woolf and I have put a request in for a BoF at IETF 95 (arcing ) that is trying to take a slightly different squint at how to manage alternative resolution contexts like that of mDNS, .onion, or similar. We're trying to look beyond recent issues about RFC 6761 and special use name =E2=80=8B to see if there are different architectural approaches to the gen= eral problem. =E2=80=8B There's a stab at a problem statement draft available, building off of work that's already been done in DNSOP and other places. There is also a mailing list set up for early discussion ( arcing@ietf.org), and we'd appreciate anyone interested in the topic joining the discussion there. Apologies if you get multiple copies; it must mean we *really* want you to join. thanks, Ted, Andrew, Suzanne --001a11c165226daaa5052a682b38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Andrew Sullivan, Suzanne Woolf and I have= put a request in for a BoF at IETF 95 (arcing) that is trying to take a slightly different squint at how to manage=20 alternative resolution contexts like that of mDNS, .onion, or similar.=C2= =A0=20 We're trying to look beyond recent issues about RFC 6761 and special us= e name
=E2=80=8B to see if there are different architec= tural approaches to the general problem.

=E2=80=8B
There's = a stab at a problem statement draft available, building off of work that's already been done in DNSOP and= =20 other places.=C2=A0 There is also a mailing list set up for early discussio= n (arcing@ietf.org= ), and we'd appreciate anyone interested in the topic joining the discu= ssion there.

Apologies if you get multiple copies; it must mean we *really* wa= nt you to join.

thanks,

Ted, Andrew, Suzanne=C2=A0
--001a11c165226daaa5052a682b38--