From nobody Fri May 1 01:15:04 2015 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 1B4681B30C4 for ; Fri, 1 May 2015 01:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 08w1NZLCxQDr for ; Fri, 1 May 2015 01:14:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C12E1ACEA8 for ; Fri, 1 May 2015 01:14:48 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) with Microsoft SMTP Server (TLS) id 15.1.154.19; Fri, 1 May 2015 08:14:26 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0154.018; Fri, 1 May 2015 08:14:26 +0000 From: Larry Masinter To: Scott Kitterman Thread-Topic: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task Thread-Index: AQHQf7eCHYmdTOHmRkq/H8/Ai7KmKp1fbtL3gAAFDwCAABslgIAAJYaAgAMKPoeAArhaAIAAQHuAgAAawICAAAJCAIAA+YcA Date: Fri, 1 May 2015 08:14:24 +0000 Message-ID: <5959768E-B287-4514-A068-FD5F063C4A4C@adobe.com> References: <20150426155712.28596.qmail@ary.lan> <79C3716EE141838E0FCF95E6@JcK-HP8200.jck.com> <2e6e927d-2965-45a9-969c-dda3a93600a8@gulbrandsen.priv.no> <1661391.eimJUi6lYJ@kitterma-e6430> In-Reply-To: <1661391.eimJUi6lYJ@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kitterman.com; dkim=none (message not signed) header.d=none; x-originating-ip: [70.197.17.240] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1322; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DM2PR02MB1322; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1322; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(51704005)(87936001)(2656002)(106116001)(19580405001)(93886004)(19580395003)(50986999)(86362001)(54356999)(76176999)(82746002)(83716003)(33656002)(15975445007)(102836002)(5001960100002)(122556002)(2900100001)(110136002)(40100003)(92566002)(2950100001)(77156002)(99286002)(66066001)(36756003)(62966003)(16601075003)(587094005)(46102003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1322; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <8B0636D77405DE42A215821D5A67715C@adobe.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2015 08:14:24.9015 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1322 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task 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, 01 May 2015 08:14:51 -0000 Gopher should have been obsoleted by HTTP/0.9.... The gopher user community moved to HTTP a long time ago. The IETF standard = now for this application is HTTP/2 and I don't think any cycles should be s= pent on alternatives which don't begin to meet requirements. If there are any good ideas here then propose them for httpbis improvements= . -- http://larry.masinter.net > On Apr 30, 2015, at 7:21 PM, Scott Kitterman wrote: >=20 >> On Thursday, April 30, 2015 07:12:57 PM Arnt Gulbrandsen wrote: >> I have to agree that we occasionally have problems with noisy rhetoric. >> (RFC6851 isn't very different from a draft someone posted in 2001, and I >> don't think that draft was the first one, either. Most of the delay was = due >> to rhetoric.) >>=20 >> I'll review the gopher document. Don't care at all about its formal stat= us >> so long as the status includes the letters "r", "f" and "c" and four >> digits. >=20 > For a moment, I thought I saw another DoS vector, but then I remembered t= hat=20 > the number with five digits also has four. >=20 > Scott K >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri May 1 04:38:05 2015 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 0409E1B2EB4 for ; Fri, 1 May 2015 04:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 5pli9R_2NxMk for ; Fri, 1 May 2015 04:38:01 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631191B2D47 for ; Fri, 1 May 2015 04:38:01 -0700 (PDT) Authentication-Results: kerwin.net.au; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.148.16; Fri, 1 May 2015 11:37:39 +0000 Message-ID: <029301d08403$00aab460$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin , IETF Apps Discuss References: <20150414080648.20012.38227.idtracker@ietfa.amsl.com> Date: Fri, 1 May 2015 12:32:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: [81.151.162.168] X-ClientProxiedBy: HE1PR02CA0002.eurprd02.prod.outlook.com (25.162.33.12) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 0563F2E8B7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(51444003)(52044002)(13464003)(377424004)(55674003)(377454003)(24454002)(62966003)(77156002)(5001770100001)(5001960100002)(107886002)(33646002)(23676002)(50226001)(84392001)(81686999)(76176999)(81816999)(50986999)(47776003)(230783001)(40100003)(46102003)(122386002)(87976001)(66066001)(44716002)(62236002)(42186005)(19580395003)(15975445007)(19580405001)(14496001)(50466002)(61296003)(86362001)(77096005)(92566002)(1720100001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2015 11:37:39.0566 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-01.txt 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, 01 May 2015 11:38:04 -0000 Matthew eeeeeh what a lot of changes - could have done with a 'Changes from -00' but no matter, I think that the changes are in the right direction, moving a lot of the proprietary material to Appendices. The only bit I missed was having the sample file:, valid and invalid, more or less together but that is a minor consideration. So yes, I think that the revised structure addresses my concerns. I think, too, that the timing is nice w.r.t the recent discussions on the registration of URI schemes! I would reference that draft, not RFC4395, assuming that that draft will be ready in time for this one:-). It means, I think, that sections 7.3 and 7.4 apply and that you should use the short form template and include it within the file I-D. I tend to look at what others have done recently and RFC7252 is such an example, albeit under the old rules. Tom Petch ----- Original Message ----- From: "Matthew Kerwin" To: "IETF Apps Discuss" Sent: Tuesday, April 14, 2015 11:38 AM > Hi again folks, > > I managed to get a new version pushed out. It's not ready for publication, > but it should be ready for proper critique. Between -00 and -01 I focused > on addressing the broad thrust of the comments received so far, notably: > > * cutting out everything but a central core from the normative syntax, > moving the non-universal bits to optional appendices > > * less normative content and references, hopefully putting less burden on > implementers (especially those who are only mildly interested in supporting > the scheme) > > * putting a bit more effort into defining meaningful operations > > There are some obvious editorial issues, especially some incomplete text in > the appendices. What I'd really appreciate advice on is: > > 1) whether the new structure broadly satisfies a bunch of the concerns that > have been raised, and > > 2) how to deal with the IANA Considerations section (especially considering > the uri-scheme-reg draft.) Back at draft-kerwin-file-scheme-11 it had a > fully fleshed out registration template, but somebody (I forget who, sorry) > suggested that I could replace it with the current (much terser) text. > Which way should I go with it? > > I'm going to go back through the archives and see what remaining concerns > still apply, so I can create some issues in my github repository. Please > feel free to provide feedback and critique in the meantime. > > Cheers! > > > On 14 April 2015 at 18:06, wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Applications Area Working Group Working > > Group of the IETF. > > > > Title : The file URI Scheme > > Author : Matthew Kerwin > > Filename : draft-ietf-appsawg-file-scheme-01.txt > > Pages : 17 > > Date : 2015-04-14 > > > > Abstract: > > This document specifies the "file" Uniform Resource Identifier (URI) > > scheme, obsoleting the definition in RFC 1738. > > > > It attemps to define a common core which is intended to interoperate > > across the broad spectrum of existing implementations, while at the > > same time documenting other current practices. > > > > Note to Readers (To be removed by the RFC Editor) > > > > This draft should be discussed on the IETF Applications Area Working > > Group discussion list . > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-01 > > > > > > 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/ > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri May 1 10:42:17 2015 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 708A81A854D for ; Fri, 1 May 2015 10:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, 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 EN5uRc8z_p6U for ; Fri, 1 May 2015 10:42:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1EE1A6FCB for ; Fri, 1 May 2015 10:42:14 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YoEwx-000OqH-A0; Fri, 01 May 2015 13:42:07 -0400 Date: Fri, 01 May 2015 13:42:02 -0400 From: John C Klensin To: Larry Masinter , Scott Kitterman Message-ID: <70125587E355314F8081ACE4@JcK-HP8200.jck.com> In-Reply-To: <5959768E-B287-4514-A068-FD5F063C4A4C@adobe.com> References: <20150426155712.28596.qmail@ary.lan> <79C3716EE141838E0FCF95E6@JcK-HP8200.jck.com> <2e6e927d-2965-45a9-969c-dda3a93600a8@gulbrandsen.priv.no> <1661391.eimJUi6lYJ@kitterma-e6430> <5959768E-B287-4514-A068-FD5F063C4A4C@adobe.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task 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, 01 May 2015 17:42:15 -0000 --On Friday, May 01, 2015 08:14 +0000 Larry Masinter wrote: > Gopher should have been obsoleted by HTTP/0.9.... Your opinion on this subject has been clear from earlier notes. > The gopher user community moved to HTTP a long time ago. The > IETF standard now for this application is HTTP/2 and I don't > think any cycles should be spent on alternatives which don't > begin to meet requirements. Given that Nick and others have claimed that there is still an active user (and even developer) community and that material in some of the references in the I-D appear to support that claim, it would appear that at least some of the gopher user community didn't make that move. Is your statement above merely over-broad or is it intended to imply that you have concluded that any gopher user who did not make the move (presumably before HTTP/1.0 was published in 1996) are so hopelessly retarded that they should either be forced to convert or forced off the Internet? Statements like yours above bother me for at least two reasons: (1) Independent of whether one appreciates text-oriented presentation and navigation models, there are some features of the Gopher data model that may still be useful and should not lightly be discarded. Perhaps a better solution for that model would be a GopherText Markup Language that worked will with HTTP, but, to the best of my knowledge, no one has proposed one of those to the IETF or anyone else. (2) I don't see a stopping rule. For example, we've all heard people claim that IMAP and POP are obsolete because all right-thinking people have switched to Webmail and that email itself is obsolete because everyone communicates in short instant messages (the people making that claim don't seem to think mailing lists like this are counterexample, just as you apparently don't believe existing Gopher servers and their users are counterexamples). Would you argue that SMTP and Internet Message formats became obsolete when the fist XMPP spec was published and that work on email should be turned over to the XMPP WG? Certainly there are more email users today than there are Gopher users, but I'd be hard-pressed to demonstrate that the percentage decrease in email users over the last 20 or 25 years, adjusted for Internet growth, is smaller than the percentage decrease in gopher users, similarly adjusted. > If there are any good ideas here then propose them for httpbis > improvements. Mark has already commented on that. I think there are real questions about Gopher-2 in the IETF, questions that depend critically on whether there is critical mass for doing the work and carefully reviewing it. But I don't think "some group of people believe that its function has been subsumed by other things and therefore we should be trying to kill it off" is a good story, whether we are talking about Gopher, email, or, for that matter, things like SIP or even UDP. john From nobody Sun May 3 23:25:43 2015 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 A2CFC1ACD90 for ; Sun, 3 May 2015 23:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_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 bubtBIeCMdg6 for ; Sun, 3 May 2015 23:25:39 -0700 (PDT) Received: from ausxipps310.us.dell.com (AUSXIPPS310.us.dell.com [143.166.148.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F229C1ACD8F for ; Sun, 3 May 2015 23:25:05 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: acceptlanguage:Content-Type:Content-Transfer-Encoding: MIME-Version; b=kmRvrzsKrd+y2T/A6o+GlnZDEF3FHeqEMTtH735M2+2/KkXScBJeeGOy e/jilc+l6brA4qkLgt3QQccvIA6WThS1RfEY76xlD2XuAH3ca+2sngzKN WR453RpfjZ7ySoSXwJQs8zir8pmiPRW6XASCKup3FnaYqQCLSPqV1MSOg 0=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1430720706; x=1462256706; h=from:to:cc:date:subject:message-id: content-transfer-encoding:mime-version; bh=N6jeagrE+4ywDad0AKSRhYv2PrpT9pel0lYss5U5ulg=; b=RboLE79nfbnJ/9xupBPOBfZepOSwW9+zEvCyHvTb7KFADF+5d5V8wqn3 Rk/ZJ27WlKunRCMZdHFpU5awJIcYBVIUsylmRGNDrsbx7ydZV9uuWkuQP 168HfWnq/ukvQ+9nRUnD+kFwW2TdwTtWtFs15mS5ZnEevLHFNOjaFqd5T o=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.13,364,1427778000"; d="scan'208";a="175906532" From: To: Date: Mon, 4 May 2015 01:24:45 -0500 Thread-Topic: [apps-discuss] New Proposed VNC URI Scheme Thread-Index: AdCGK8cK9qAVT8+CR6WcMgiEXLsK6w== Message-ID: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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, 04 May 2015 06:25:41 -0000 Hi all, I'd like to than Dominic/RealVNC for reviewing the proposed URI scheme. Based on his comments I've posted a revised the document available at: http://www.ietf.org/id/draft-warden-appsawg-vnc-scheme-01.txt To summarize, as suggested, I've: * Provided that userinfo information may be specified/processed but is depr= ecated. * Removed the default values for the IdHashAlgorithm, SaveConnection, and S= ecurityType parameters. * Renamed ColorModel to ColorLevel and removed the detailed behavior specif= ication. The values still refer to common pixel formats, which I assume is = acceptable. * Clarified the purposes of the SecurityType parameter. * Removed the LaunchKey parameter. * Provided that a canonical case should be used, and clients should proves = parameter names in a case-insensitive manner. * Discouraged use of SSLv3. * Rephrased the certificate verification discussion, providing the clients = can automatically verify a certificate, and referred to RFC5280 (on the Int= ernet certificate profile). * Added a reference to the URL for the IANA schemes registry (although they= may eventually move the page). I've also revised the document a bit to conform to the proposed best practi= ce around scheme registration, including clarifying we conceptually support= a "VIEW" operation, although I know the IETF tries to avoid references to = pending documents. When adopted, it may be sufficient just to refer to the = new RFC number. Here are some specific responses: >>Section 2.1 URI Scheme Syntax >> A "vnc" URI has the general form: >> vnc://host:port?parm1=3Dvalue1¶m2=3Dvalue2... >We also feel that there should be a note specifying that password data SHO= ULD be percent encoded. I've clarified that password data is often so encoded, but I don't see a be= nefit to encoding password characters that don't need to be so encoded.=20 >Also on this section - might it be worth allowing an optional path compone= nt? This could be used to identify a particular view/monitor or other imple= mentation-specific >subdivision. I don't think this would be constructive. There is no current use for said = component, and if two apps use a path component in different ways, it would= be difficult to standardize on such use in the future. In contrast, parame= ters with application-specific prefixes could move toward standardization v= ia a parameters registry the same way browsers standardize on attributes: -webkit-xyz, -ms-xyz -> xyz com.xyz.screenwidth, com.abc.screenwidth -> screenwidth >> VNC Clients supporting application-specific parameters SHOULD include=20 >> a distinguishing prefix within the parameter name [...]=20 >> vnc://?com.dell.vncclient.ScreenMode=3D2& >This seems like a good idea - perhaps we could specify a facility to defin= e a namespace alias and encourage people to use it for multiple arguments, = e.g.:=20 >vnc://?ns.Dell=3Dcom.dell.vncclient&Dell.SecurityType=3D1&Dell.ViewOnly=3D= true& I don't think we should use namespace aliases because it would substantiall= y increase complexity. In schemes like XML where aliases are common, extens= ive work is required to deal with issues, such as multiple namespaces, scop= ing/nesting, prefix reuse, and so on. In any event, it would complicate par= ameter parsing substantially. If parameter namespaces become common in the = future and libraries are made available, perhaps this could be revisited.=20 >Section 2.3 Integrated Security Types > A broad comment on this section is that we'd prefer a scheme which attemp= ts to separate SSH and TLS tunnel security types from a more basic VNC URI = specification.=20 > Perhaps with a scheme looking something like this: > vnc+ssh://hostname:port/?parameter=3Dvalue& If possible, I'd like to get more feedback from the group on this. I see ar= guments both ways: + Some precedent with https/http, snews/nntp + Can allow for more combinations of VNC security types and tunneling schem= es + Clean separation of security types/tunnels - It could require clients to register multiple schemes, and if new securit= y types are used, could lead to an explosion in the number of scheme regist= rations required, as opposed to just adding a new security type in the IANA= registry. - Not all combinations make a lot of sense, like tunneling AnonTLS over TLS= . - It could make it harder for security software to screen/filter such URIs. - Clients might still have to connect using SSH from a "vnc:" URI if a conn= ection profile is used. - Requires changing our current implementation >2.3.1 The "Integrated SSH" Security Type & > 2.3.2 The "Secure Tunnel" Security Type >There should probably be some discussion here about how SSH and TLS parame= ters such as cipher suites and version are expected to be configured. I consider this to be outside the scope of this document, because clients u= sually automatically do a good job of dealing with such configuration, enfo= rcing reasonable key-size minimums and matching keys to compatible suites. = I've added a note clarifying this is out of scope.=20 Thanks, David Warden Dell Enterprise Solutions Group From nobody Mon May 4 01:19:55 2015 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 2A4001A923A for ; Mon, 4 May 2015 01:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 hEOkpKLFiViv for ; Mon, 4 May 2015 01:19:48 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7C11A9147 for ; Mon, 4 May 2015 01:19:47 -0700 (PDT) Authentication-Results: Dell.com; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.1.154.19; Mon, 4 May 2015 08:14:47 +0000 Message-ID: <006801d08642$268bbd00$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> Date: Mon, 4 May 2015 09:12:34 +0100 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: [81.151.162.168] X-ClientProxiedBy: HE1PR02CA0013.eurprd02.prod.outlook.com (25.162.33.23) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR07MB059; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB059; X-Forefront-PRVS: 05669A7924 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51444003)(164054003)(13464003)(53754006)(51704005)(44716002)(61296003)(81816999)(15975445007)(77096005)(5001920100001)(122386002)(40100003)(86362001)(76176999)(50986999)(46102003)(66066001)(81686999)(92566002)(44736004)(107886002)(19580395003)(5001770100001)(5001960100002)(47776003)(116806002)(62966003)(77156002)(42186005)(19580405001)(50466002)(33646002)(14496001)(50226001)(23756003)(87976001)(1556002)(62236002)(551544002)(7059030)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2015 08:14:47.9128 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB059 Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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, 04 May 2015 08:19:52 -0000 David I think that at some point the IANA Considerations should be revisited. There is a 5226bis which should be referenced (and read!). That I-D asks that the terminology be Group and Registry, thus avoiding sub-(sub-(sub-))registry. It also asks that the IANA Considerations be just explicit directions to IANA, leaving any technical stuff to the other parts of the document, making it clear whether this is additions to an existing Group or Registry or the creation of a new one such. E.g. 'IANA is asked to create a "VNC ID Hash Algorithms" Registry within the "Remote Framebuffer (RFB)" Group, so wording it such that 'is asked to create' can become 'has created' in the hands of the RFC Editor. I note too that in this case, the I-D goes on to say "The registry should include the enumeration value, description, and reference document/contact person." whereas the details are then " Value Description Reference" which is not quite the same. Picky? Yes, but the more accurate the directions are, the simpler it is for IANA to do what you want (and who do a magnificent job when presented with rubbish but deserve better than that:-). ' "Expert Review" or "IESG Approval" process ' are two quite different approaches, almost at opposite ends of the spectrum. For any one registry, or subset of entries in a registry, I find it hard to see how both could be applicable. I would include one or the other (or something else if appropriate) within the section that asks IANA to create a new registry. If you do want Expert Review, then you should give guidance for the Expert Reviewer to use to judge whether or not to approve an application. There has been quite a lot of discussion on this topic in the context of applications for URI Schemes on this list recently; worth a look at if you do decide to go with Expert Review. Expert Review also means that the IESG have to find and maintain Expert Reviewers with a suitable level of expertise ( more work for the IESG:-(. There is also a new version of RFC4395 making its way through the system; again, worth a read (and a reference). Tom Petch ----- Original Message ----- From: To: Sent: Monday, May 04, 2015 7:24 AM Subject: Re: [apps-discuss] New Proposed VNC URI Scheme > Hi all, > > I'd like to than Dominic/RealVNC for reviewing the proposed URI scheme. > > Based on his comments I've posted a revised the document available at: > http://www.ietf.org/id/draft-warden-appsawg-vnc-scheme-01.txt > > To summarize, as suggested, I've: > * Provided that userinfo information may be specified/processed but is deprecated. > * Removed the default values for the IdHashAlgorithm, SaveConnection, and SecurityType parameters. > * Renamed ColorModel to ColorLevel and removed the detailed behavior specification. The values still refer to common pixel formats, which I assume is acceptable. > * Clarified the purposes of the SecurityType parameter. > * Removed the LaunchKey parameter. > * Provided that a canonical case should be used, and clients should proves parameter names in a case-insensitive manner. > * Discouraged use of SSLv3. > * Rephrased the certificate verification discussion, providing the clients can automatically verify a certificate, and referred to RFC5280 (on the Internet certificate profile). > * Added a reference to the URL for the IANA schemes registry (although they may eventually move the page). > > I've also revised the document a bit to conform to the proposed best practice around scheme registration, including clarifying we conceptually support a "VIEW" operation, although I know the IETF tries to avoid references to pending documents. When adopted, it may be sufficient just to refer to the new RFC number. > > Here are some specific responses: > > >>Section 2.1 URI Scheme Syntax > >> A "vnc" URI has the general form: > >> vnc://host:port?parm1=value1¶m2=value2... > >We also feel that there should be a note specifying that password data SHOULD be percent encoded. > > I've clarified that password data is often so encoded, but I don't see a benefit to encoding password characters that don't need to be so encoded. > > >Also on this section - might it be worth allowing an optional path component? This could be used to identify a particular view/monitor or other implementation-specific >subdivision. > > I don't think this would be constructive. There is no current use for said component, and if two apps use a path component in different ways, it would be difficult to standardize on such use in the future. In contrast, parameters with application-specific prefixes could move toward standardization via a parameters registry the same way browsers standardize on attributes: > -webkit-xyz, -ms-xyz -> xyz > com.xyz.screenwidth, com.abc.screenwidth -> screenwidth > > >> VNC Clients supporting application-specific parameters SHOULD include > >> a distinguishing prefix within the parameter name [...] > >> vnc://?com.dell.vncclient.ScreenMode=2& > >This seems like a good idea - perhaps we could specify a facility to define a namespace alias and encourage people to use it for multiple arguments, e.g.: > >vnc://?ns.Dell=com.dell.vncclient&Dell.SecurityType=1&Dell.ViewOnly=tru e& > > I don't think we should use namespace aliases because it would substantially increase complexity. In schemes like XML where aliases are common, extensive work is required to deal with issues, such as multiple namespaces, scoping/nesting, prefix reuse, and so on. In any event, it would complicate parameter parsing substantially. If parameter namespaces become common in the future and libraries are made available, perhaps this could be revisited. > > >Section 2.3 Integrated Security Types > > A broad comment on this section is that we'd prefer a scheme which attempts to separate SSH and TLS tunnel security types from a more basic VNC URI specification. > > Perhaps with a scheme looking something like this: > > vnc+ssh://hostname:port/?parameter=value& > > If possible, I'd like to get more feedback from the group on this. I see arguments both ways: > + Some precedent with https/http, snews/nntp > + Can allow for more combinations of VNC security types and tunneling schemes > + Clean separation of security types/tunnels > > - It could require clients to register multiple schemes, and if new security types are used, could lead to an explosion in the number of scheme registrations required, as opposed to just adding a new security type in the IANA registry. > - Not all combinations make a lot of sense, like tunneling AnonTLS over TLS. > - It could make it harder for security software to screen/filter such URIs. > - Clients might still have to connect using SSH from a "vnc:" URI if a connection profile is used. > - Requires changing our current implementation > > >2.3.1 The "Integrated SSH" Security Type & > > 2.3.2 The "Secure Tunnel" Security Type > >There should probably be some discussion here about how SSH and TLS parameters such as cipher suites and version are expected to be configured. > > I consider this to be outside the scope of this document, because clients usually automatically do a good job of dealing with such configuration, enforcing reasonable key-size minimums and matching keys to compatible suites. I've added a note clarifying this is out of scope. > > Thanks, > > David Warden > Dell Enterprise Solutions Group > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon May 4 14:31:29 2015 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 9E6F11B2C82 for ; Mon, 4 May 2015 14:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZQ-8VPTgdBdn for ; Mon, 4 May 2015 14:31:24 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::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 37B1A1B2C81 for ; Mon, 4 May 2015 14:31:24 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so140633000iec.0 for ; Mon, 04 May 2015 14:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=rRdhayZoUYM7dvk5vJ1v4mGDAQ0w1il4tZ+rCnzbGWo=; b=iDbwDV/sxwoVKnkgLQFqjOz0Ma0VBB/1HdcPzMLBvaf5NzEgGWVh6atX8ubNu6JZ0A 7r0p40hpSLTIzXTyUkso1sbQm3OkqWW+71+splOILhE1OoUu96xbXtzRt0nBe+aYy4eb oncnVR2SXj/r7ZlfpbEWUVOygB25M58eQJH+9oxQWSO4fq+HAEnViQ7NDQPI2MbgQsaL i28yaHJd8W+QkLOUmFBHRwIaOl0NyAOpNRuRrGgj/mcG22O48kGxtQvF9LlUuws5cXDc yfweKMhtO81542MtpuRnQr5iZXMWdsLyCf8zTQAodhfbjlbXEupDQtIWgCoVW4x70cAn diLQ== X-Received: by 10.107.19.2 with SMTP id b2mr167316ioj.9.1430775083691; Mon, 04 May 2015 14:31:23 -0700 (PDT) Received: from [192.168.3.13] (75-119-248-54.dsl.teksavvy.com. [75.119.248.54]) by mx.google.com with ESMTPSA id av3sm5977307igc.16.2015.05.04.14.31.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 May 2015 14:31:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Nick Matavka In-Reply-To: Date: Mon, 4 May 2015 17:31:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 1 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, 04 May 2015 21:31:27 -0000 > On May 4, 2015, at 2:25 AM, apps-discuss-request@ietf.org wrote: > Date: Fri, 1 May 2015 08:14:24 +0000 > From: Larry Masinter > To: Scott Kitterman > Cc: "apps-discuss@ietf.org" > Subject: Re: [apps-discuss] Proposal for adoption of Gopher document > as an AppsAWG task > Message-ID: <5959768E-B287-4514-A068-FD5F063C4A4C@adobe.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Gopher should have been obsoleted by HTTP/0.9.... >=20 > The gopher user community moved to HTTP a long time ago. The IETF = standard now for this application is HTTP/2 and I don't think any cycles = should be spent on alternatives which don't begin to meet requirements. >=20 > If there are any good ideas here then propose them for httpbis = improvements. >=20 > -- > http://larry.masinter.net >=20 Oh yeah? That's bullshit Larry and you know that. "httpbis = improvements" is another word for "leave it on the trash heap to rot". "Don't begin to meet requirements"? Please go to another forum with = your sanctimonious attitude. You sound like a bulldog farting out a = nest of angry wasps. Drone on and on and on and on... Personally I think if there's a community of users that not only use it, = but also develop it, some sort of description or standard should be in = order. It's not a dead technology until it is fully superseded and, in = fact, subsumed by another. That's like saying that FTP is dead because = file transfers happen over HTTP these days, or that POP 3 is dead = because IMAP is more popular on mobile. IMAP has a competing philosophy = to POP3, just as much as Gopher has a competing philosophy to HTTP. Why = should a structured, regimented Internet language not co-exist with a = wild, crazy, unstructured one like HTTP? Both have their benefits, both = have their drawbacks, but to keep the benefits one must continue to = develop on both. Why the fuck are you saying that "the gopher user community moved to = HTTP a long time ago"? You're not the Lorax. You don't speak for a = whole fucking community of people. That's what I mean by pompous and = stuck-up. I know tons of people that use HTTP and, yes, Gopher for = their own separate advantages. But, according to you, those people are = fucking retards... Fraternally yours, Edward.= From nobody Mon May 4 16:28:43 2015 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 B613F1B2CD7 for ; Mon, 4 May 2015 16:28:35 -0700 (PDT) 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 SMI2qET-FtAE for ; Mon, 4 May 2015 16:28:28 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450: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 8D0F71B2CCF for ; Mon, 4 May 2015 16:28:27 -0700 (PDT) Received: by widdi4 with SMTP id di4so126691747wid.0 for ; Mon, 04 May 2015 16:28:26 -0700 (PDT) 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=hL3Bgb8FxEluXnj1vDsyOicxN2H8HTunAnUskHccLPw=; b=dZaoQlVLtO2k5vTNWMmo8ZxLRazQMwpHx6z8fK/bYjD4F2oYLhhkcMEfMDnsLP2fMo ZmIREtMit4dHiFSIjhCkTwYbgVNNmJ6lxbY5YoFRyEQLGlfwVC/Ye9iUsbjicVORuRP9 297ghnN2psQq7kB8w+ckmE+2ZRG3Y9OrAn07fqpRk/W06o5j+TEzokKQIZiXs1a9Y+I1 jR2/8rOQDQA2xeVtls0ZEmh4ha+47mxoKCol88XW4PkDSRGLtZZSHNOb9rXSdswLM+J3 +cthjHuFNI1uQyfTTK3243JsNl0ZtJw20tN7lYCVd0+Lft7p7A7QkHAfbq4/lP7FZOYc 1lng== MIME-Version: 1.0 X-Received: by 10.194.242.101 with SMTP id wp5mr2079328wjc.4.1430782106296; Mon, 04 May 2015 16:28:26 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Mon, 4 May 2015 16:28:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 May 2015 16:28:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Nick Matavka Content-Type: multipart/alternative; boundary=089e01419f52326868051549ebba Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 1 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, 04 May 2015 23:28:35 -0000 --089e01419f52326868051549ebba Content-Type: text/plain; charset=UTF-8 On Mon, May 4, 2015 at 2:31 PM, Nick Matavka < n.theodore.matavka.files@gmail.com> wrote: > > On May 4, 2015, at 2:25 AM, apps-discuss-request@ietf.org wrote: > > Date: Fri, 1 May 2015 08:14:24 +0000 > > From: Larry Masinter > > To: Scott Kitterman > > Cc: "apps-discuss@ietf.org" > > Subject: Re: [apps-discuss] Proposal for adoption of Gopher document > > as an AppsAWG task > > Message-ID: <5959768E-B287-4514-A068-FD5F063C4A4C@adobe.com> > > Content-Type: text/plain; charset="us-ascii" > > > > Gopher should have been obsoleted by HTTP/0.9.... > > > > The gopher user community moved to HTTP a long time ago. The IETF > standard now for this application is HTTP/2 and I don't think any cycles > should be spent on alternatives which don't begin to meet requirements. > > > > If there are any good ideas here then propose them for httpbis > improvements. > > > > -- > > http://larry.masinter.net > > > > Oh yeah? That's bullshit Larry and you know that. "httpbis improvements" > is another word for "leave it on the trash heap to rot". > > "Don't begin to meet requirements"? Please go to another forum with your > sanctimonious attitude. You sound like a bulldog farting out a nest of > angry wasps. Drone on and on and on and on... > > Personally I think if there's a community of users that not only use it, > but also develop it, some sort of description or standard should be in > order. It's not a dead technology until it is fully superseded and, in > fact, subsumed by another. That's like saying that FTP is dead because > file transfers happen over HTTP these days, or that POP 3 is dead because > IMAP is more popular on mobile. IMAP has a competing philosophy to POP3, > just as much as Gopher has a competing philosophy to HTTP. Why should a > structured, regimented Internet language not co-exist with a wild, crazy, > unstructured one like HTTP? Both have their benefits, both have their > drawbacks, but to keep the benefits one must continue to develop on both. > > Why the fuck are you saying that "the gopher user community moved to HTTP > a long time ago"? You're not the Lorax. You don't speak for a whole > fucking community of people. That's what I mean by pompous and stuck-up. > I know tons of people that use HTTP and, yes, Gopher for their own separate > advantages. But, according to you, those people are fucking retards... > > Fraternally yours, > > Edward. > Mr. Matavka, This response is entirely unacceptable for this list. There was nothing "fraternal" about it. Please ensure any further replies to this list on any thread (or indeed, any IETF list) are kept civil and professional. Failure to do so could lead to suspension of your posting privileges, under the provisions of BCP 94. -MSK, APPSAWG co-chair --089e01419f52326868051549ebba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 4, 2015 at 2:31 PM, Nick Matavka <n.theodore.matavka.files@gmail.com> wrote:
> On May 4, 2015, at 2:25 AM, apps-discuss-request@ietf.org wrote:
> Date: Fri, 1 May 2015 08:14:24 +0000
> From: Larry Masinter <masinte= r@adobe.com>
> To: Scott Kitterman <scott@k= itterman.com>
> Cc: "apps-discuss@ietf.o= rg" <apps-discuss@ietf= .org>
> Subject: Re: [apps-discuss] Proposal for adoption of Gopher document >=C2=A0 =C2=A0 =C2=A0 =C2=A0as an AppsAWG task
> Message-ID: <5959768E-B287-4514-A068-FD5F063C4A4C@adobe.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Gopher should have been obsoleted by HTTP/0.9....
>
> The gopher user community moved to HTTP a long time ago. The IETF stan= dard now for this application is HTTP/2 and I don't think any cycles sh= ould be spent on alternatives which don't begin to meet requirements. >
> If there are any good ideas here then propose them for httpbis improve= ments.
>
> --
> http://larry.m= asinter.net
>

Oh yeah?=C2=A0 That's bullshit Larry and you know that.=C2=A0 "htt= pbis improvements" is another word for "leave it on the trash hea= p to rot".

"Don't begin to meet requirements"?=C2=A0 Please go to anothe= r forum with your sanctimonious attitude.=C2=A0 You sound like a bulldog fa= rting out a nest of angry wasps.=C2=A0 Drone on and on and on and on...

Personally I think if there's a community of users that not only use it= , but also develop it, some sort of description or standard should be in or= der.=C2=A0 It's not a dead technology until it is fully superseded and,= in fact, subsumed by another.=C2=A0 That's like saying that FTP is dea= d because file transfers happen over HTTP these days, or that POP 3 is dead= because IMAP is more popular on mobile.=C2=A0 IMAP has a competing philoso= phy to POP3, just as much as Gopher has a competing philosophy to HTTP.=C2= =A0 Why should a structured, regimented Internet language not co-exist with= a wild, crazy, unstructured one like HTTP?=C2=A0 Both have their benefits,= both have their drawbacks, but to keep the benefits one must continue to d= evelop on both.

Why the fuck are you saying that "the gopher user community moved to H= TTP a long time ago"?=C2=A0 You're not the Lorax.=C2=A0 You don= 9;t speak for a whole fucking community of people.=C2=A0 That's what I = mean by pompous and stuck-up.=C2=A0 I know tons of people that use HTTP and= , yes, Gopher for their own separate advantages.=C2=A0 But, according to yo= u, those people are fucking retards...

Fraternally yours,

Edward.

Mr. Matavka,

T= his response is entirely=20 unacceptable for this list.=C2=A0 There was nothing "fraternal" a= bout it.

Please ensure any further replies to this list on any thread (or indeed, any=20 IETF list) are kept civil and professional.=C2=A0 Failure to do so could le= ad to suspension of your posting privileges, under the provisions of BCP 94.<= br>
-MSK, APPSAWG co-chair
--089e01419f52326868051549ebba-- From nobody Tue May 5 14:23:00 2015 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 B0D551B2A0B for ; Tue, 5 May 2015 14:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 6z4NfTdUQSgX for ; Tue, 5 May 2015 14:22:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 494CE1ACEBC for ; Tue, 5 May 2015 14:22:54 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D6502403CA for ; Tue, 5 May 2015 17:22:55 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_621EB18C-D2B8-4828-B4A0-847F87C59D56" Message-Id: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> Date: Tue, 5 May 2015 22:22:51 +0100 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [apps-discuss] new work being considered: lager: label generation rules 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 May 2015 21:22:56 -0000 --Apple-Mail=_621EB18C-D2B8-4828-B4A0-847F87C59D56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, this is some new work that is being considered and we would like to get = your input.=20 Regards, Marc. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D wg Acronym: lager (Label Generation Rules) Domain registries, particularly those implementing IDNA (RFC 5890 = et.al), usually maintain a set of criteria (or "ruleset") that governs = permissible labels allowed for registration, such as [IANAIDNTABLES].=20 These rulesets are commonly a mixture of eligible code points along=20 with contextual criteria that must be met concerning the positioning of certain code points. Some registries also specify rules regarding variant labels and how they are to be handled. Domain registries commonly need to share these rules, but there is no interoperable format that can be used that can support many common use = cases. This group seeks to produce such a format, which will enable re-use and simpler implementation of rulesets in registries. A comprehensive format specification has been developed, named Label Generation Rules, primarily to support the rules to be used for the=20 DNS Root Zone [Davies]. This group will use this specification as a=20 starting point to develop a common XML language that provides a superset=20= of functionality of current specifications [RFC 3743, RFC 4290, et.al], along with other known use cases. This = single format is expected to supersede existing formats, and form the basis for future rulesets used at different levels of the DNS hierarchy. Work items: - Standard Track Specification of the Label Generation Rules References: [Davies] https://datatracker.ietf.org/doc/draft-davies-idntables/ [IANAIDNTABLES] https://www.iana.org/domains/idn-tables = = --Apple-Mail=_621EB18C-D2B8-4828-B4A0-847F87C59D56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello,
 this is = some new work that is being considered and we would like to get your = input. 

Regards, Marc.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
wg = Acronym: lager  (Label Generation Rules)

Domain registries, particularly those implementing IDNA (RFC = 5890 et.al),
usually maintain a set of criteria (or = "ruleset") that governs permissible
labels allowed for = registration, such as [IANAIDNTABLES]. 
These = rulesets are commonly a mixture of eligible code points along 
with contextual criteria that must be met
concerning the positioning of certain code points. Some = registries also
specify rules regarding variant labels and = how they are to be handled.
Domain registries commonly = need to share these rules, but there is no
interoperable = format that can be used that can support many common use cases.
This group seeks to produce such a format, which will enable = re-use and
simpler implementation of rulesets in = registries.

A comprehensive format = specification has been developed, named Label
Generation = Rules, primarily to support the rules to be used for the 
DNS Root Zone [Davies]. This group will use this = specification as a 
starting point to develop a = common XML language that provides a superset 
of = functionality of current specifications
[RFC 3743, RFC = 4290, et.al], along with other known use cases. This single
format is expected to supersede existing formats, and form = the basis for
future rulesets used at different levels of = the DNS hierarchy.

Work items:
- Standard Track Specification of the Label Generation = Rules

References:
[Davies] https://datatracker.ietf.org/doc/draft-davies-idntables/[IANAIDNTABLES] https://www.iana.org/domains/idn-tables= --Apple-Mail=_621EB18C-D2B8-4828-B4A0-847F87C59D56-- From nobody Tue May 5 15:53:32 2015 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 4933A1B2A81; Tue, 5 May 2015 15:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2mGhygiHL54n; Tue, 5 May 2015 15:53:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E61B2A86; Tue, 5 May 2015 15:53:23 -0700 (PDT) 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.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150505225323.29836.99808.idtracker@ietfa.amsl.com> Date: Tue, 05 May 2015 15:53:23 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-08.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: Tue, 05 May 2015 22:53:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-08.txt Pages : 52 Date : 2015-05-05 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-08 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 Tue May 5 16:42:34 2015 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 77F791A89A7 for ; Tue, 5 May 2015 16:42:32 -0700 (PDT) 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_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3i92UknS-5XR for ; Tue, 5 May 2015 16:42:30 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0D01A897C for ; Tue, 5 May 2015 16:42:30 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BA647C40028 for ; Tue, 5 May 2015 18:42:29 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430869349; bh=Y40zmtCB5yc0tP/x0qHsV06AW6PZJUM1rkO2wrqwhIQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FzdElFq1u4804uDNgqDHnqMMNb9GhLnZktluc6z0dp84CRT4He/MjPeiLRmDbpicF +sW1t1hcCKDSCR77AVCfhRtG9EVhb93mdgRmzVE7Z9EtRM7iQYzEoJRZHbtwUPCJGi jYEzn0+JGIDy+Bp5AT9g3xpALCfyR0Az7CIiMeDs= From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 05 May 2015 19:42:29 -0400 Message-ID: <1476089.F7n01INvCY@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> References: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] new work being considered: lager: label generation rules 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 May 2015 23:42:32 -0000 On Tuesday, May 05, 2015 10:22:51 PM Marc Blanchet wrote: > Hello, > this is some new work that is being considered and we would like to get > your input. > > Regards, Marc. > > =================================== > wg Acronym: lager (Label Generation Rules) Please pick a name that doesn't already mean something else popular. Trying to search for information about lager probably won't get the result people want unless they are interested in beer. Scott K From nobody Tue May 5 20:21:12 2015 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 49EAD1B2A23 for ; Tue, 5 May 2015 20:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 EeAWfEEJ0pQ3 for ; Tue, 5 May 2015 20:21:10 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AFFC1ACDD8 for ; Tue, 5 May 2015 20:21:10 -0700 (PDT) Received: (qmail 28814 invoked from network); 6 May 2015 03:21:11 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 May 2015 03:21:11 -0000 Date: 6 May 2015 03:20:46 -0000 Message-ID: <20150506032046.43995.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] new work being considered: lager: label generation rules 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 May 2015 03:21:11 -0000 >A comprehensive format specification has been developed, named Label >Generation Rules, primarily to support the rules to be used for the >DNS Root Zone [Davies]. This group will use this specification as a >starting point to develop a common XML language that provides a superset >of functionality of current specifications >[RFC 3743, RFC 4290, et.al], along with other known use cases. This single >format is expected to supersede existing formats, and form the basis for >future rulesets used at different levels of the DNS hierarchy. Who are the expected users of this super XML schema? I know that ICANN has an RFP out for tools using the current LGR draft. Anyone else? R's, John From nobody Wed May 6 01:14:31 2015 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 169E41A8998 for ; Wed, 6 May 2015 01:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1oub_ci6J3v1 for ; Wed, 6 May 2015 01:14:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1411A899F for ; Wed, 6 May 2015 01:14:28 -0700 (PDT) Received: from h194.viagenie.ca (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E8629403CD; Wed, 6 May 2015 04:14:29 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Marc Blanchet In-Reply-To: <20150506032046.43995.qmail@ary.lan> Date: Wed, 6 May 2015 09:14:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8621B05F-08C5-4863-B173-9799FC7AAEB1@viagenie.ca> References: <20150506032046.43995.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Kim Davies , apps-discuss@ietf.org Subject: Re: [apps-discuss] new work being considered: lager: label generation rules 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 May 2015 08:14:30 -0000 > Le 2015-05-06 =C3=A0 04:20, John Levine a =C3=A9crit = : >=20 >> A comprehensive format specification has been developed, named Label >> Generation Rules, primarily to support the rules to be used for the=20= >> DNS Root Zone [Davies]. This group will use this specification as a=20= >> starting point to develop a common XML language that provides a = superset=20 >> of functionality of current specifications >> [RFC 3743, RFC 4290, et.al], along with other known use cases. This = single >> format is expected to supersede existing formats, and form the basis = for >> future rulesets used at different levels of the DNS hierarchy. >=20 > Who are the expected users of this super XML schema? I know that > ICANN has an RFP out for tools using the current LGR draft. Anyone > else? thanks for the very good question. So this work will enable people to = specify (and therefore verify) the rules for valid labels. The first = near term use is for the root zone. In this context, anyone who wants to = verify if a label is valid (i.e. whatever it is actually a delegated = label or not) would be a target user, therefore many people within the = registration ecosystem. This work is also a framework for specifying = variants, which are identified as blocked or allocatable. In this = context, verify if a label is allocatable is also useful for parties in = the registration system. Moreover, it is envisionned that this = technology could also be used for any level such as second levels. So = potentially many parties in the registration ecosystem. Regards, Marc. >=20 > R's, > John From nobody Thu May 7 00:07:28 2015 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 C24FC1B2A4D for ; Thu, 7 May 2015 00:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 4tV9MVYjRbvE for ; Thu, 7 May 2015 00:07:24 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (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 5DD521B2A45 for ; Thu, 7 May 2015 00:07:23 -0700 (PDT) Received: by qgdy78 with SMTP id y78so16654371qgd.0 for ; Thu, 07 May 2015 00:07:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/fM86gf7URVvsX6DvxPb+Ysmy2zmaXyhEzqqRUuGq+k=; b=hWuiIoW0xAmBsYKhZAJcOg+bIYzS+/LhpyjMX4tTXBrjzu6Xsar2gmnbdgCAHzKpAI aPnatGHeY+wIeAa8qTwXE5/cxuXiZxluazJV+lJkJwMXOUNCfEACMtkT9Ytxe/WTbcfg GMRw4NGwxzZwoIK6LUfrenUvWrVkMvLWncg/ioX+D+ZXJTxLo9pXmNitR0gtq3JsLVWP McnZ0uQ6eKnnp02uOIsa/57/8AvF58teuv5V5WuxFEox6qrOpMjf1it74gjrgFuZVHz7 N4xGQVFzO5+TDJghv9C6OnyVjvZXVTAXUmD8aCEAA66zLyWM9OXUnyX4i72I6tvwmrM0 WBrw== X-Gm-Message-State: ALoCoQmiWw01xQrrrC4IZAJY5o+3G5uwleeohJ/ZplCgU7ZcZ+FCnndjDJRczUgmIM4i7S+wqBuT MIME-Version: 1.0 X-Received: by 10.140.86.146 with SMTP id p18mr3198674qgd.49.1430982442626; Thu, 07 May 2015 00:07:22 -0700 (PDT) Received: by 10.96.42.100 with HTTP; Thu, 7 May 2015 00:07:22 -0700 (PDT) In-Reply-To: <1476089.F7n01INvCY@kitterma-e6430> References: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> <1476089.F7n01INvCY@kitterma-e6430> Date: Thu, 7 May 2015 08:07:22 +0100 Message-ID: From: Phil Lello To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c130382c4d9705157890d3 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] new work being considered: lager: label generation rules 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 May 2015 07:07:26 -0000 --001a11c130382c4d9705157890d3 Content-Type: text/plain; charset=UTF-8 > > Please pick a name that doesn't already mean something else popular. > Trying > to search for information about lager probably won't get the result people > want unless they are interested in beer. > Is that a huge issue? The IETF already has, for example, the Kitten WG ( https://datatracker.ietf.org/wg/kitten/charter/), which is a top result for "IETF kitten" (https://www.google.co.uk/search?q=ietf+kitten), but not "kitten" (https://www.google.co.uk/search?q=kitten) Phil --001a11c130382c4d9705157890d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please pick a name that doesn't already mean something else popu= lar.=C2=A0 Trying
to search for information about lager probably won't get the result peo= ple
want unless they are interested in beer.

Is that a huge issue? The IETF already has, for example, the Kitten WG (<= a href=3D"https://datatracker.ietf.org/wg/kitten/charter/">https://datatrac= ker.ietf.org/wg/kitten/charter/), which is a top result for "IETF = kitten" (h= ttps://www.google.co.uk/search?q=3Dietf+kitten), but not "kitten&q= uot; (https://www.go= ogle.co.uk/search?q=3Dkitten)

Phil
--001a11c130382c4d9705157890d3-- From nobody Thu May 7 16:56:56 2015 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 07E251B2CA9 for ; Thu, 7 May 2015 16:56:54 -0700 (PDT) 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, 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 cLlAy7IIJJlF for ; Thu, 7 May 2015 16:56:52 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE7F1B2CA2 for ; Thu, 7 May 2015 16:56:52 -0700 (PDT) Received: from kitterma-e6430.localnet (unknown [50.253.56.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C012AC401B4 for ; Thu, 7 May 2015 18:56:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431043011; bh=mVFJSSZ/URxVp8QTHRAZGqtiO6WCPIeRP0GPObFv9Ns=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BJCeq5rSLnUYRA007X6pkP9EfKS+QTyMxzTOb7IvJCzgZor3aeUPrCl/JtefZX+vb gSSOYWiWTXljywZW0jkYpgIIjZki8EoZSzbuaRVmUVk1Si/SsTaVQs7+k5mek15QPL TCuDgpF42b3jT0kSsdJs8Nlm4IGjasMVvF3NFo4M= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 07 May 2015 19:56:50 -0400 Message-ID: <3245023.cAZXTf3Sts@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> <1476089.F7n01INvCY@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] new work being considered: lager: label generation rules 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 May 2015 23:56:54 -0000 On Thursday, May 07, 2015 08:07:22 AM Phil Lello wrote: > > Please pick a name that doesn't already mean something else popular. > > Trying > > to search for information about lager probably won't get the result people > > want unless they are interested in beer. > > Is that a huge issue? The IETF already has, for example, the Kitten WG ( > https://datatracker.ietf.org/wg/kitten/charter/), which is a top result for > "IETF kitten" (https://www.google.co.uk/search?q=ietf+kitten), but not > "kitten" (https://www.google.co.uk/search?q=kitten) > > Phil Huge issue, no, but a number of people, myself included, aren't fond of the IETF doing this. There's all kinds of examples (lemonade is another one) and it makes things harder later when one is trying to understand what went before. Scott K From nobody Thu May 7 17:51:13 2015 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 448FA1AD2A9 for ; Thu, 7 May 2015 17:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 5It5fHDnUX9Q for ; Thu, 7 May 2015 17:51:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D5B1AD0AC for ; Thu, 7 May 2015 17:51:12 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t480p819024350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 May 2015 17:51:11 -0700 Message-ID: <554C0877.6080004@dcrocker.net> Date: Thu, 07 May 2015 17:51:03 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Scott Kitterman , apps-discuss@ietf.org References: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> <1476089.F7n01INvCY@kitterma-e6430> In-Reply-To: <1476089.F7n01INvCY@kitterma-e6430> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 07 May 2015 17:51:11 -0700 (PDT) Archived-At: Subject: Re: [apps-discuss] new work being considered: lager: label generation rules X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 00:51:13 -0000 On 5/5/2015 4:42 PM, Scott Kitterman wrote: >> wg Acronym: lager (Label Generation Rules) > > Please pick a name that doesn't already mean something else popular. Trying > to search for information about lager probably won't get the result people > want unless they are interested in beer. So, you wouldn't consider it to be an improvement if they instead chose: Allowed Label Entries ? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu May 7 18:09:42 2015 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 F1EF21B2D82 for ; Thu, 7 May 2015 18:09:41 -0700 (PDT) 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, 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 Cfl25S2dXJ7o for ; Thu, 7 May 2015 18:09:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A596A1B2D66 for ; Thu, 7 May 2015 18:09:40 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A90DAC4016C for ; Thu, 7 May 2015 20:09:39 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431047379; bh=6zjCgywJ6jNAXqAr2AcNM5MXK4B0xNk5NAXurYMhsNQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RwNfPQiwXkFEqK6ob1oVoM3pP8+FRdnd6Az1YnVPG05aEb3Pm56Q3sQ9qd1O+gg0U LMPSrE3ZvAB1i3ROwNGecQ9l/k7HXj8S23w3+NcYOXso/vAvXTrS++VJsOsM/bPLjM CYtE9Qul/sd0IF9qlJ/jXFMhop+6XR1++1VTl4zc= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 07 May 2015 21:09:38 -0400 Message-ID: <2023418.TrC9vtEYYZ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <554C0877.6080004@dcrocker.net> References: <8E61E9B8-D981-4FF4-A973-F99B6F2A51F2@viagenie.ca> <1476089.F7n01INvCY@kitterma-e6430> <554C0877.6080004@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] new work being considered: lager: label generation rules 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, 08 May 2015 01:09:42 -0000 On Thursday, May 07, 2015 05:51:03 PM Dave Crocker wrote: > On 5/5/2015 4:42 PM, Scott Kitterman wrote: > >> wg Acronym: lager (Label Generation Rules) > > > > Please pick a name that doesn't already mean something else popular. > > Trying to search for information about lager probably won't get the > > result people want unless they are interested in beer. > > So, you wouldn't consider it to be an improvement if they instead chose: > > Allowed Label Entries ? No. Basic Extensible Entity Rules wouldn't be better either. Scott K From nobody Thu May 7 23:39:01 2015 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 1FB901ACD57 for ; Thu, 7 May 2015 23:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 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_15=0.6, 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 wGMSf4g9Ryd6 for ; Thu, 7 May 2015 23:38:58 -0700 (PDT) Received: from ausxippc110.us.dell.com (AUSXIPPC110.us.dell.com [143.166.85.200]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EE41ACD41 for ; Thu, 7 May 2015 23:38:58 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version; b=zt92fmcalJocx3wKTe6BgA5MckXDdV+GNO0u3U+IiamsMTZDyz2WG1y4 UW3erwKAncXkvMIYmN+LrTHwkkWK1lcW+sZ6lI3C9ZxW3O+lVTytVY/jd FHpqXTe6kgCilKShg/b6ifRIEV0JNYtP808FWOyhbmLWBPynVgbH+X7Q4 E=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1431067139; x=1462603139; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZTZAlALE8X19/hIQcAjZTerviQlMM7s8BPO1KbeVbb8=; b=GhjVr6GHPK/LVFKbF2kF8VAZUsY76LOnKKXvRZzlhPutba2jr0X3F2Dn vqcJ4NN/EuYn2I42yNLbI2Pa7kNy7zLeuZBaEID8cWTTP5S0mAH/k7wTJ DOj59U1Z5iv+E+XCZBmxqYfRTy9SBdq+srAYqeYmMHhllMH/VfL0tVKYz A=; X-LoopCount0: from 10.170.28.41 X-IronPort-AV: E=Sophos;i="5.13,389,1427778000"; d="scan'208";a="165749593" From: To: Date: Fri, 8 May 2015 01:38:31 -0500 Thread-Topic: [apps-discuss] New Proposed VNC URI Scheme Thread-Index: AdCGQn0D+5z9MybbRU2JII8DcXFFpADEly0g Message-ID: <2D58682309E75147BB3B286C815CAC7E2AC107881B@AUSX7MCPS308.AMER.DELL.COM> References: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> <006801d08642$268bbd00$4001a8c0@gateway.2wire.net> In-Reply-To: <006801d08642$268bbd00$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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, 08 May 2015 06:39:00 -0000 Tom, thanks for the comments. See my notes below. >-----Original Message----- >From: t.petch [mailto:ietfc@btconnect.com]=20 > I think that at some point the IANA Considerations should be revisited. > There is a 5226bis which should be referenced (and read!). > That I-D asks that the terminology be Group and Registry, thus avoiding s= ub-(sub-(sub-))registry. > It also asks that the IANA Considerations be just explicit directions to = IANA, leaving any technical stuff to the other parts of the document, makin= g it clear whether this is > additions to an existing Group or Registry or = the creation of a new one such. E.g. 'IANA is asked to create a "VNC ID Has= h Algorithms" Registry within the "Remote ... I've updated the document in accordance with your recommendations. >' "Expert Review" or "IESG Approval" process ' are two quite different ap= proaches, almost at opposite ends of the spectrum. For any one registry, o= r subset of entries in >a registry, I find it hard to see how both could be= applicable. I would include one or the other (or something else if approp= riate) within the section that asks IANA to >create a new registry. This language was based on the RFB RFC (RFC6143) which applies to the exist= ing registries. While it is effectively "expert review", it makes it clear = the IESG can do whatever it wants without requiring an expert, which may no= t be obvious to someone reading the document in isolation. I see some value= in keeping these consistent.=20 The existing registries have values in fixed-length data structures and req= uire some controls that are less necessary in a URI. However, I think it is= reasonable to have someone review proposed parameters, and I don't see a l= ot of new hash algorithms coming along such that a lower standard will make= much difference one way or another.=20 The use of prefixes for custom parameters provides a safe method for implem= entation prior to registration, reducing the need for provisional registrat= ion like that used in URI schemes.=20 > If you do want Expert Review, then you should give guidance for the Exper= t Reviewer to use to judge whether or not to approve an application. There= has been quite a > lot of discussion on this topic in the context of appli= cations for URI Schemes on this list recently; worth a look at if you do de= cide to go with Expert Review. Expert Review > also means that the IESG ha= ve to find and maintain Expert Reviewers with a suitable level of expertise= ( more work for the IESG:-(. I've added some basic guidance. I assume I am going to be invited to review= any changes for the next thirty years or so after which time cyborg implan= ts will replace remote desktop connectivity. The RFB author Tristan Richard= son or his staff would also be excellent reviewers.=20 > There is also a new version of RFC4395 making its way through the system;= again, worth a read (and a reference). I've read the update to RFC 4395 and believe this draft meets its requireme= nts. However, I can't easily reference a document that does not have an RFC= number, and IETF materials strongly discourage such references to other dr= afts as it can delay publication. If and when the updates to 4395 and 5226 = are published, I will reference them.=20 > Tom Petch Thanks again, David From nobody Mon May 11 02:50:14 2015 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 EF2C11A88E8; Mon, 11 May 2015 02:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3] 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 L36VLV9zME_Q; Mon, 11 May 2015 02:50:09 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 62DE41A88C4; Mon, 11 May 2015 02:50:08 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=[172.18.0.54]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1YrkLf-0000xq-2k; Mon, 11 May 2015 10:50:07 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ben Niven-Jenkins In-Reply-To: <552D6F72.7060901@cisco.com> Date: Mon, 11 May 2015 10:50:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74AB9882-4C1F-4EE1-9718-49D2BA33B5F5@niven-jenkins.co.uk> References: <552D6F72.7060901@cisco.com> To: =?utf-8?Q?=E2=8C=98_Matt_Miller?= X-Mailer: Apple Mail (2.2070.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: draft-ietf-cdni-metadata.all@tools.ietf.org, cdni@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] [CDNi] Appsdir early review of draft-ietf-cdni-metadata-09 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 May 2015 09:50:12 -0000 Hi Matt, Thanks for the review and apologies for the delay in responding. I will discuss your review with my co-authors and we'll re-work the = document to incorporate your comments. Thanks again Ben > On 14 Apr 2015, at 20:50, =E2=8C=98 Matt Miller = wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > I have been selected as the Applications Area Directorate early > reviewer for this draft (for background on appsdir, please see > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat > e > ). >=20 > 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. >=20 > Document: draft-ietf-cdni-metadata > Title: CDN Interconnection Metadata > Reviewer: Matthew Miller > Review Date: 2015-04-14 > IETF Last Call Date: N/A > IESG Telechat Date: N/A >=20 > Summary: This draft is not ready for publication as a Proposed > Standard and should be revised. >=20 > Comments: >=20 > This draft is written expecting multiple encodings in the future, then > spends very little space discussing the one encoding that is defined > (JSON). The end result is a document that, in my opinion, is too > abstract. I think it would be more understandable if this draft > mentioned and used JSON throughout (e.g., a micro-example for each of > the defined types). I think it's appropriate to do this and yet still > reserve the right to support other encoding formats in the future. >=20 > Also, this draft is not very internally consistent (e.g., terminology > usage, editorial structuring, etc.), which I found made it hard to > follow at times. I would recommend that the authors do a round of > editing to be more internally consistent; I've noted in the nits a > number of specific examples. >=20 > Major Issues: >=20 > * I think Section 6.4.2. is underspecified. There are a number of > quirks and gotchas I noticed that are not discussed: >=20 > - dealing with large (requiring more than ~53 bits) integers (encode > as JSON String) > - dealing with duplicate keys within a JSON Object (MUST NOT have > duplicates) > - dealing with escaping (see Minor Issue #2) >=20 > I note that the examples in 6.4.2.1. illustrate some of the > concerns, but nowhere are they explicitly discussed. I would strongly > recommend outlining these concerns, better would be to refer to RFC > 7492 (I-JSON) and follow its recommendations explicitly. I don't > think this is much of a burden since this document appears to already > follow them implicitly. >=20 >=20 > Minor Issues: >=20 > * In Section 3.1., I find Table 2 hard to follow. I suggest each row > be broken out to its own item in an unordered list. It would also > help to point to each item's full definition. >=20 > * In Section 4.1.5., note that '\' must be escaped as '\\' in JSON, > which means the JSON string for a with a literal '\' would have > '\\\\' (this also applies for literal '?' and '*'). I can understand > why an alternative form of escaping, such as percent encoding, would > be undesirable, but it will be surprising to some to see this "extra > escaping". This effect on pattern escaping ought to be called out; if > not in Section 4.1.5. then I suggest in Section 6.4.2. >=20 > * Sections 8.2., 8.3., and 8.5., seem to cover the concerns, but I > would recommend reviewing and referencing draf-ietf-uta-tls-bcp, as I > think you would get a more complete picture here. >=20 > Nits: >=20 > * In Abstract, CDN is not expanded on first occurrence. >=20 > * In Abstract, CDNI is not expanded on first occurrence. >=20 > * In Section 1.2., dCDN is not expanded on first occurrence. >=20 > * In Section 1.2., uCDN is not expanded on first occurrence. >=20 > * Reference to HTTPv1.1 (commonly referred to as "HTTP/1.1") (RFC7230, > et al) comes very late (Section 7.2.), first noted in Section 1.2. >=20 > * No reference to HTTPv2.0 (often referred to as "http/2") > (draft-ietf-httpbis-http2-17), first noted in Section 1.2. >=20 > * Reference to HTTP over TLS (RFC 2818) comes very late (Section > 7.2.), first noted in Section 1.2. >=20 > * No reference to JSON (RFC 7159), first noted in Section 2. >=20 > * In Section 3.2., the two tables are not captioned. >=20 > * In Section 4.2.4.1., "protocol" is not capitalized (i.e., > "Protocol") like other type references in "Type: List of protocol = object > s" >=20 > * In Section 6. and many of its subsections, "Downstream CDN" is often > used instead of "dCDN", which is elsewhere in this document. I would > recommend more consistency and use "dCDN". >=20 > * In Section 6. and many of its subsections, "Upstream CDN" is often > used instead of "uCDN", which is elsewhere in this document. I would > recommend more consistency and use "uCDN". >=20 >=20 > - --=20 > - - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org >=20 > iQEcBAEBCgAGBQJVLW9yAAoJEDWi+S0W7cO1g9UIAJIV8yShj/0KiqhC82m/ixk6 > VkW5IZvB8iWp9mVStx+fQtwwm1B7LrvccFnSr5CwmyURjmaljSBKP97F6I/QnjpL > 6YJkfGyRLTP1r/fpH7N9ptpHZJQpNd5iQlBElWforfBaNHd5xm4mhLkCzlv8UKjk > TP8SDYeW5pKvUkHtK7fhW7h2eTcs/EuPZr/GlTb9yIWQAAwN0q7JTnwXVN1Lo9uQ > ap1mqUnG2YdZMuAKqrDUQRywazIuBGPu8DopbKX6Hl9fyuSEnPUry73P+7aK727x > T+/qHyARqy5PGSgesRYAQdFy3gS4/8SeeYWHpkE+7MPSjTNj4nTralxfcu7uxAU=3D > =3D+QNl > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon May 11 04:02:15 2015 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 42E271A89FC for ; Mon, 11 May 2015 04:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_15=0.6, SPF_HELO_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 HrJZ1RP2zn0t for ; Mon, 11 May 2015 04:02:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747A81A0074 for ; Mon, 11 May 2015 04:02:06 -0700 (PDT) Authentication-Results: Dell.com; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.160.19; Mon, 11 May 2015 10:57:09 +0000 Message-ID: <012001d08bd8$f8c37420$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> <006801d08642$268bbd00$4001a8c0@gateway.2wire.net> <2D58682309E75147BB3B286C815CAC7E2AC107881B@AUSX7MCPS308.AMER.DELL.COM> Date: Mon, 11 May 2015 11:53:18 +0100 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: [81.151.162.168] X-ClientProxiedBy: DB4PR02CA0051.eurprd02.prod.outlook.com (10.242.174.179) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; X-Forefront-PRVS: 05739BA1B5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(54094003)(51444003)(51914003)(43784003)(377454003)(46102003)(87976001)(116806002)(4001540100001)(66066001)(1556002)(42186005)(62966003)(77156002)(62236002)(44716002)(5001830100001)(50226001)(44736004)(61296003)(5001860100001)(92566002)(5001770100001)(77096005)(5001960100002)(15975445007)(122386002)(189998001)(47776003)(40100003)(107886002)(1456003)(86362001)(19580405001)(19580395003)(33646002)(50466002)(84392001)(14496001)(23756003)(81816999)(50986999)(81686999)(76176999)(7059030)(74416001)(7726001)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2015 10:57:09.4919 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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 May 2015 11:02:15 -0000 ---- Original Message ----- From: To: Cc: Sent: Friday, May 08, 2015 7:38 AM Tom, thanks for the comments. See my notes below. >-----Original Message----- >From: t.petch [mailto:ietfc@btconnect.com] > I think that at some point the IANA Considerations should be revisited. > There is a 5226bis which should be referenced (and read!). > That I-D asks that the terminology be Group and Registry, thus avoiding sub-(sub-(sub-))registry. > It also asks that the IANA Considerations be just explicit directions to IANA, leaving any technical stuff to the other parts of the document, making it clear whether this is > additions to an existing Group or Registry or the creation of a new one such. E.g. 'IANA is asked to create a "VNC ID Hash Algorithms" Registry within the "Remote ... I've updated the document in accordance with your recommendations. >' "Expert Review" or "IESG Approval" process ' are two quite different approaches, almost at opposite ends of the spectrum. For any one registry, or subset of entries in >a registry, I find it hard to see how both could be applicable. I would include one or the other (or something else if appropriate) within the section that asks IANA to >create a new registry. This language was based on the RFB RFC (RFC6143) which applies to the existing registries. While it is effectively "expert review", it makes it clear the IESG can do whatever it wants without requiring an expert, which may not be obvious to someone reading the document in isolation. I see some value in keeping these consistent. The existing registries have values in fixed-length data structures and require some controls that are less necessary in a URI. However, I think it is reasonable to have someone review proposed parameters, and I don't see a lot of new hash algorithms coming along such that a lower standard will make much difference one way or another. The use of prefixes for custom parameters provides a safe method for implementation prior to registration, reducing the need for provisional registration like that used in URI schemes. > If you do want Expert Review, then you should give guidance for the Expert Reviewer to use to judge whether or not to approve an application. There has been quite a > lot of discussion on this topic in the context of applications for URI Schemes on this list recently; worth a look at if you do decide to go with Expert Review. Expert Review > also means that the IESG have to find and maintain Expert Reviewers with a suitable level of expertise ( more work for the IESG:-(. I've added some basic guidance. I assume I am going to be invited to review any changes for the next thirty years or so after which time cyborg implants will replace remote desktop connectivity. The RFB author Tristan Richardson or his staff would also be excellent reviewers. > There is also a new version of RFC4395 making its way through the system; again, worth a read (and a reference). I've read the update to RFC 4395 and believe this draft meets its requirements. However, I can't easily reference a document that does not have an RFC number, and IETF materials strongly discourage such references to other drafts as it can delay publication. If and when the updates to 4395 and 5226 are published, I will reference them. Um yes, I should have read RFC6143 more carefully before commenting. I see what you mean about having both Expert Review and IESG Approval - I had not seen that before. Both place an extra burden on the IESG and I do see the IESG as a limiting factor in the work of the IETF and so am always keen to reduce that burden when possible. Hence my enthusiasm for other forms of update, such as RFC Required. You do have a Normative Reference to RFC6143 and RFC6143 is Informational which means that this is a Downref and one that has not occurred before AFAICT http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry# which is a procedural point for AD Review or IETF Last Call. I wonder if this I-D should now be Standards Track. Informational is always a bit lightweight. Setting up IANA Registries and URIs can and does happen with Informational but is perhaps less common. A number of protocols have started life as Informational and then become Standards Track or at least in part thereof. You can reference an I-D by its name as, for example, draft-ietf-appsawg-rfc7001bis does for I-D draft-kucherawy-dmarc-base. Yes, it causes publication to be held up but that is not unexpected. Separately, I wonder if the entries in the new VNC ID Hash Algorithms registry should be required to appear in another registry, such as the TLS one, to discourage people from inventing their own i.e. they have to convince Eric Rescorla of its value before VMC can use it:-) On the URI itself, I am unsure about unreserved-symbols = ":" / "/" / "#" / "[" / "]" / "@" / "!" / "$" / "'" / "(" / ")" / "*" / "," / ";" where you are unreserving some gen-delims. It is hard to say whether or not RFC3986 prohibits this (it is sometimes hard to say what RFC3986 says:-) but '#' is problematic as is ']'. The subject of '#' came up recently on this list with the point being made that generic parsers may scan backwards and treat the first '#' as being the only one so a second one will result in misinterpretation. The whole question of '#' is fraught as that discussion showed. While on ']', RFC3986 appears to be quite specific about its use to wit 'A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]"). This is the only place where square bracket characters are allowed in the URI syntax. ' Again, this surfaced recently on this list and it emerged that there is one URI definition that is in breach of this, but I do not see that as an argument for another. There are others on this list with greater expertise than I in this matter and I expect you will get more comments on the syntax as some stage. Tom Petch > Tom Petch Thanks again, David From nobody Mon May 11 10:02:21 2015 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 64ACA1A90B1 for ; Mon, 11 May 2015 10:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 Y33cjoms3M3k for ; Mon, 11 May 2015 10:02:16 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE5D1A8948 for ; Mon, 11 May 2015 10:02:16 -0700 (PDT) Received: (qmail 38670 invoked from network); 11 May 2015 17:02:18 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 May 2015 17:02:18 -0000 Date: 11 May 2015 17:01:52 -0000 Message-ID: <20150511170152.4765.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <012001d08bd8$f8c37420$4001a8c0@gateway.2wire.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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 May 2015 17:02:17 -0000 >This language was based on the RFB RFC (RFC6143) which applies to the >existing registries. While it is effectively "expert review", it makes >it clear the IESG can do whatever it wants without requiring an expert, >which may not be obvious to someone reading the document in isolation. I >see some value in keeping these consistent. I am trying and failing to remember why we picked that language in 6143. I think it was just cut and paste from somewhere else. Personally, I think it should just be expert review. In the unlikely even that there's no expert, the IESG should designate one and let her sort it out. R's, John From nobody Mon May 11 12:32:04 2015 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 725EB1AD357; Mon, 11 May 2015 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 G5bLlkpyQ28p; Mon, 11 May 2015 12:32:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C03C21AD35B; Mon, 11 May 2015 12:31:57 -0700 (PDT) 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.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511193157.9013.7779.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 12:31:57 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-09.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: Mon, 11 May 2015 19:32:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-09.txt Pages : 51 Date : 2015-05-11 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-09 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 Tue May 12 01:56:13 2015 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 4E01B1A00FE for ; Tue, 12 May 2015 01:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_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 JUfETtv6h45n for ; Tue, 12 May 2015 01:56:09 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557981A0102 for ; Tue, 12 May 2015 01:56:08 -0700 (PDT) Authentication-Results: btconnect.com; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.1.154.19; Tue, 12 May 2015 08:27:12 +0000 Message-ID: <00d201d08c8d$2f97cfa0$4001a8c0@gateway.2wire.net> From: t.petch To: t.petch , , References: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> <006801d08642$268bbd00$4001a8c0@gateway.2wire.net> <2D58682309E75147BB3B286C815CAC7E2AC107881B@AUSX7MCPS308.AMER.DELL.COM> <012001d08bd8$f8c37420$4001a8c0@gateway.2wire.net> Date: Tue, 12 May 2015 09:23:03 +0100 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: [81.151.162.168] X-ClientProxiedBy: DB3PR05CA0016.eurprd05.prod.outlook.com (25.160.41.144) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR07MB059; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB059; X-Forefront-PRVS: 0574D4712B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(51444003)(51704005)(377454003)(13464003)(86362001)(76176999)(81816999)(81686999)(66066001)(62236002)(44716002)(19580405001)(15975445007)(50466002)(2201001)(19580395003)(92566002)(50226001)(50986999)(87976001)(84392001)(61296003)(47776003)(5001770100001)(107886002)(5001960100002)(33646002)(46102003)(42186005)(14496001)(5001920100001)(122386002)(77096005)(77156002)(62966003)(93886004)(23756003)(40100003)(189998001)(7059030)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2015 08:27:12.2583 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB059 Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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, 12 May 2015 08:56:12 -0000 Responding to my own post to correct a factual error, . Tom Petch ----- Original Message ----- From: "t.petch" To: ; Sent: Monday, May 11, 2015 11:53 AM > ---- Original Message ----- > From: > To: > Cc: > Sent: Friday, May 08, 2015 7:38 AM > > Tom, thanks for the comments. See my notes below. > > >-----Original Message----- > >From: t.petch [mailto:ietfc@btconnect.com] > > I think that at some point the IANA Considerations should be > revisited. > > There is a 5226bis which should be referenced (and read!). > > That I-D asks that the terminology be Group and Registry, thus > avoiding sub-(sub-(sub-))registry. > > > It also asks that the IANA Considerations be just explicit directions > to IANA, leaving any technical stuff to the other parts of the document, > making it clear whether this is > additions to an existing Group or > Registry or the creation of a new one such. E.g. 'IANA is asked to > create a "VNC ID Hash Algorithms" Registry within the "Remote ... > > I've updated the document in accordance with your recommendations. > > >' "Expert Review" or "IESG Approval" process ' are two quite different > approaches, almost at opposite ends of the spectrum. For any one > registry, or subset of entries in >a registry, I find it hard to see how > both could be applicable. I would include one or the other (or > something else if appropriate) within the section that asks IANA to > >create a new registry. > > This language was based on the RFB RFC (RFC6143) which applies to the > existing registries. While it is effectively "expert review", it makes > it clear the IESG can do whatever it wants without requiring an expert, > which may not be obvious to someone reading the document in isolation. I > see some value in keeping these consistent. > > The existing registries have values in fixed-length data structures and > require some controls that are less necessary in a URI. However, I think > it is reasonable to have someone review proposed parameters, and I don't > see a lot of new hash algorithms coming along such that a lower standard > will make much difference one way or another. > > The use of prefixes for custom parameters provides a safe method for > implementation prior to registration, reducing the need for provisional > registration like that used in URI schemes. > > > If you do want Expert Review, then you should give guidance for the > Expert Reviewer to use to judge whether or not to approve an > application. There has been quite a > lot of discussion on this topic > in the context of applications for URI Schemes on this list recently; > worth a look at if you do decide to go with Expert Review. Expert > Review > also means that the IESG have to find and maintain Expert > Reviewers with a suitable level of expertise ( more work for the > IESG:-(. > > I've added some basic guidance. I assume I am going to be invited to > review any changes for the next thirty years or so after which time > cyborg implants will replace remote desktop connectivity. The RFB author > Tristan Richardson or his staff would also be excellent reviewers. > > > There is also a new version of RFC4395 making its way through the > system; again, worth a read (and a reference). > > I've read the update to RFC 4395 and believe this draft meets its > requirements. However, I can't easily reference a document that does not > have an RFC number, and IETF materials strongly discourage such > references to other drafts as it can delay publication. If and when the > updates to 4395 and 5226 are published, I will reference them. Um yes, I should have read RFC6143 more carefully before commenting. see what you mean about having both Expert Review and IESG Approval - I had not seen that before. Both place an extra burden on the IESG and I do see the IESG as a limiting factor in the work of the IETF and so am always keen to reduce that burden when possible. Hence my enthusiasm for other forms of update, such as RFC Required. You do have a Normative Reference to RFC6143 and RFC6143 is Informational which means that this is a Downref and one that has not occurred before AFAICT http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry# which is a procedural point for AD Review or IETF Last Call. well, it would be if this were a Standards Track I-D which it is not! So were it to become a Standards Track I-D, then this would be a consideration but currently it isn't so it isn't! Sorry about the error. I wonder if this I-D should now be Standards Track. Informational is always a bit lightweight. Setting up IANA Registries and URIs can and does happen with Informational but is perhaps less common. A number of protocols have started life as Informational and then become Standards Track or at least in part thereof. You can reference an I-D by its name as, for example, draft-ietf-appsawg-rfc7001bis does for I-D draft-kucherawy-dmarc-base. Yes, it causes publication to be held up but that is not unexpected. I am not sure what the rules are for Informational RFC - I have seen it said, but cannot track down a reference, that it may be ok to have a Normative Reference to an I-D in a Informational RFC - I will look some more for that. Separately, I wonder if the entries in the new VNC ID Hash Algorithms registry should be required to appear in another registry, such as the TLS one, to discourage people from inventing their own i.e. they have to convince Eric Rescorla of its value before VMC can use it:-) On the URI itself, I am unsure about unreserved-symbols = ":" / "/" / "#" / "[" / "]" / "@" / "!" / "$" / "'" / "(" / ")" / "*" / "," / ";" where you are unreserving some gen-delims. It is hard to say whether or not RFC3986 prohibits this (it is sometimes hard to say what RFC3986 says:-) but '#' is problematic as is ']'. The subject of '#' came up recently on this list with the point being made that generic parsers may scan backwards and treat the first '#' as being the only one so a second one will result in misinterpretation. The whole question of '#' is fraught as that discussion showed. While on ']', RFC3986 appears to be quite specific about its use to wit 'A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]"). This is the only place where square bracket characters are allowed in the URI syntax. ' Again, this surfaced recently on this list and it emerged that there is one URI definition that is in breach of this, but I do not see that as an argument for another. There are others on this list with greater expertise than I in this matter and I expect you will get more comments on the syntax as some stage. Tom Petch > > Tom Petch > > Thanks again, > > David > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed May 13 15:28:13 2015 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 5669C1ACEDE; Wed, 13 May 2015 15:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 oCeZviqCoRaT; Wed, 13 May 2015 15:28:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E21B1AD21C; Wed, 13 May 2015 15:28:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513222803.26998.11672.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 15:28:03 -0700 Archived-At: Cc: draft-ietf-appsawg-rfc7001bis.authors@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-rfc7001bis.shepherd@ietf.org, draft-ietf-appsawg-rfc7001bis.ad@ietf.org, draft-ietf-appsawg-rfc7001bis.chairs@ietf.org Subject: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-rfc7001bis-09: (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: Wed, 13 May 2015 22:28:08 -0000 Ben Campbell has entered the following ballot position for draft-ietf-appsawg-rfc7001bis-09: 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-rfc7001bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- 2.6, 2nd paragraph: Why might one choose _not_ to include version tokens? -- 2.7.7, first paragraph, last sentence: I’m not sure how such a β€œpreference” should be applied for IANA stuff -- 4, last sentence: Known not to authenticate, or not known to authenticate? -- 4.1, 2nd paragraph is it reasonable for users to be expected to know which services are used in their ADMDs? -- 5, last paragraph: How do you imply a version? From nobody Wed May 13 15:57:26 2015 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 8CF2C1B31BA; Wed, 13 May 2015 15:57:23 -0700 (PDT) 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 JukoJb7LhRN3; Wed, 13 May 2015 15:57:21 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 E1B431B31B0; Wed, 13 May 2015 15:56:57 -0700 (PDT) Received: by wgic8 with SMTP id c8so57807098wgi.1; Wed, 13 May 2015 15:56:56 -0700 (PDT) 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=hkTtV6wu7Xf4oXS14fEPOY5EHJCTjXgzgxKHQinu4so=; b=s45GG/rsA8BRwjBxJYM9aLSC9+eVm26vM8vh2MrdGBhzmz4rDsvs7yh7La1BEeSu0C gC+BorlPM6McMdJgeWAAFDpwXbb1yi8TdOOKcC4qghhY9f1AIPw2vHgWkZBfR0VnOb3z Rh4Rj24SY5CO/kVGlpD34ja+Audl3TVFWnI2YAou3ZGHzQ9CnjRP0B9BZKl8rsfxcE9/ K02iU50ZlCUEO3jPZF3xs372nn3AC+9VIRp8FpNNJWMvitH3lJhGHDQoPGvqD742Q+fP NMj/3JZAIbZwEalcX1EcXfI6X2QfeorfBR2CpgIRf7MAAl9cLOYNxf6L1/FDb4cqQLjQ z4fw== MIME-Version: 1.0 X-Received: by 10.194.193.66 with SMTP id hm2mr2026667wjc.111.1431557816705; Wed, 13 May 2015 15:56:56 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Wed, 13 May 2015 15:56:56 -0700 (PDT) In-Reply-To: <20150513222803.26998.11672.idtracker@ietfa.amsl.com> References: <20150513222803.26998.11672.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 15:56:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ben Campbell Content-Type: multipart/alternative; boundary=047d7b874e6223e79d0515fe8705 Archived-At: Cc: draft-ietf-appsawg-rfc7001bis.ad@ietf.org, IETF Apps Discuss , draft-ietf-appsawg-rfc7001bis.authors@ietf.org, draft-ietf-appsawg-rfc7001bis.chairs@ietf.org, draft-ietf-appsawg-rfc7001bis.shepherd@ietf.org, The IESG Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-rfc7001bis-09: (with 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, 13 May 2015 22:57:23 -0000 --047d7b874e6223e79d0515fe8705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ben, On Wed, May 13, 2015 at 3:28 PM, Ben Campbell wrote: > > -- 2.6, 2nd paragraph: > > Why might one choose _not_ to include version tokens? > They've been optional since RFC5451. None of the authentication methods currently supported have any version other than the basic ones. This was added in anticipation of needing them, but that need has not (so far) materialized. > -- 2.7.7, first paragraph, last sentence: > > I=E2=80=99m not sure how such a =E2=80=9Cpreference=E2=80=9D should be ap= plied for IANA stuff > The Designated Expert for the registry can insist on something be published if the description associated with a result code is non-trivial. In the spirit of keeping IANA requirements minimal, we chose not to require it. > -- 4, last sentence: > > Known not to authenticate, or not known to authenticate? > "Known not" is correct. For example, SPF does not authenticate the local-part of an email address, so MUAs shouldn't claim that it did. > -- 4.1, 2nd paragraph > > is it reasonable for users to be expected to know which services are used > in their ADMDs? > If MUAs are using A-R content for filtering, then yes, that's the assumption. > -- 5, last paragraph: > > How do you imply a version? > The ABNF in Section 2.2 says the version of this specification is "1", and that's the version of A-R assumed to be in use if no version is explicitly provided; it's implied by the generator and inferred by the consumer. -MSK --047d7b874e6223e79d0515fe8705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben,

On Wed, May 13, 2015 at 3:28 PM, Ben Campbe= ll <ben@nostrum.com> wrote:

-- 2.6, 2nd paragraph:

Why might one choose _not_ to include version tokens?
=
They've been optional since RFC5451.=C2=A0 None of the a= uthentication methods currently supported have any version other than the b= asic ones.=C2=A0 This was added in anticipation of needing them, but that n= eed has not (so far) materialized.
=C2=A0
-- 2.7.7, first paragraph, last sentence:

I=E2=80=99m not sure how such a =E2=80=9Cpreference=E2=80=9D should be appl= ied for IANA stuff

The Designated Exper= t for the registry can insist on something be published if the description = associated with a result code is non-trivial.=C2=A0 In the spirit of keepin= g IANA requirements minimal, we chose not to require it.
=C2=A0
-- 4, last sentence:

Known not to authenticate, or not known to authenticate?

"Known not" is correct.=C2=A0 For example, SPF = does not authenticate the local-part of an email address, so MUAs shouldn&#= 39;t claim that it did.
=C2=A0
-- 4.1, 2nd paragraph

is it reasonable for users to be expected to know which services are used in their ADMDs?

If MUAs are using A-R conten= t for filtering, then yes, that's the assumption.
=C2=A0
-- 5, last paragraph:

How do you imply a version?

The ABNF in= Section 2.2 says the version of this specification is "1", and t= hat's the version of A-R assumed to be in use if no version is explicit= ly provided; it's implied by the generator and inferred by the consumer= .

-MSK
--047d7b874e6223e79d0515fe8705-- From nobody Wed May 13 16:02:00 2015 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 375241B31CF; Wed, 13 May 2015 16:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 pRJcHWPqvj1x; Wed, 13 May 2015 16:01:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6B7191B31CE; Wed, 13 May 2015 16:01:57 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4DN1h2V094178 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 18:01:53 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Murray S. Kucherawy" Date: Wed, 13 May 2015 18:01:42 -0500 Message-ID: <9BB02B92-19CE-4112-B630-530EA647D5AB@nostrum.com> In-Reply-To: References: <20150513222803.26998.11672.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-appsawg-rfc7001bis.ad@ietf.org, IETF Apps Discuss , draft-ietf-appsawg-rfc7001bis.authors@ietf.org, draft-ietf-appsawg-rfc7001bis.chairs@ietf.org, draft-ietf-appsawg-rfc7001bis.shepherd@ietf.org, The IESG Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-rfc7001bis-09: (with 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, 13 May 2015 23:01:58 -0000 Thanks for the quick response--it addresses all of my questions/comments. None of them appear to need changes in the text. Ben. On 13 May 2015, at 17:56, Murray S. Kucherawy wrote: > Hi Ben, > > On Wed, May 13, 2015 at 3:28 PM, Ben Campbell wrote: > >> >> -- 2.6, 2nd paragraph: >> >> Why might one choose _not_ to include version tokens? >> > > They've been optional since RFC5451. None of the authentication > methods > currently supported have any version other than the basic ones. This > was > added in anticipation of needing them, but that need has not (so far) > materialized. > > >> -- 2.7.7, first paragraph, last sentence: >> >> I’m not sure how such a β€œpreference” should be applied for IANA >> stuff >> > > The Designated Expert for the registry can insist on something be > published > if the description associated with a result code is non-trivial. In > the > spirit of keeping IANA requirements minimal, we chose not to require > it. > > >> -- 4, last sentence: >> >> Known not to authenticate, or not known to authenticate? >> > > "Known not" is correct. For example, SPF does not authenticate the > local-part of an email address, so MUAs shouldn't claim that it did. > > >> -- 4.1, 2nd paragraph >> >> is it reasonable for users to be expected to know which services are >> used >> in their ADMDs? >> > > If MUAs are using A-R content for filtering, then yes, that's the > assumption. > > >> -- 5, last paragraph: >> >> How do you imply a version? >> > > The ABNF in Section 2.2 says the version of this specification is "1", > and > that's the version of A-R assumed to be in use if no version is > explicitly > provided; it's implied by the generator and inferred by the consumer. > > -MSK From nobody Thu May 14 02:21:46 2015 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 BCBB81AC420; Thu, 14 May 2015 02:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3] 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 2Le0aGHng4bt; Thu, 14 May 2015 02:21:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C141AC41C; Thu, 14 May 2015 02:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514092143.19776.51595.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 02:21:43 -0700 Archived-At: Cc: draft-ietf-appsawg-rfc7001bis.authors@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-rfc7001bis.shepherd@ietf.org, draft-ietf-appsawg-rfc7001bis.ad@ietf.org, draft-ietf-appsawg-rfc7001bis.chairs@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-rfc7001bis-09: (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, 14 May 2015 09:21:44 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-rfc7001bis-09: 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-rfc7001bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Based on the diff [1] from 7001, I've no objection. Thanks for ensuring that that diff was useful for this review. (Or else I'm glad we were lucky - it really speeds things up for me:-) [1] https://www.ietf.org/rfcdiff?url1=rfc7001&url2=draft-ietf-appsawg-rfc7001bis-09 From nobody Thu May 14 07:17:06 2015 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 89F101B2A84; Thu, 14 May 2015 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vdjEYQAab6gn; Thu, 14 May 2015 07:17:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A48A1A8897; Thu, 14 May 2015 07:16:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514141637.14724.49139.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 07:16:37 -0700 Archived-At: Cc: draft-ietf-appsawg-rfc7001bis.authors@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-rfc7001bis.shepherd@ietf.org, draft-ietf-appsawg-rfc7001bis.ad@ietf.org, draft-ietf-appsawg-rfc7001bis.chairs@ietf.org Subject: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-rfc7001bis-09: (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, 14 May 2015 14:17:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-appsawg-rfc7001bis-09: 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-rfc7001bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Edit: All of my comments have been addressed via email. The resolution is that I was in the rough on all points; no change needed. -- 2.6, 2nd paragraph: Why might one choose _not_ to include version tokens? -- 2.7.7, first paragraph, last sentence: I’m not sure how such a β€œpreference” should be applied for IANA stuff -- 4, last sentence: Known not to authenticate, or not known to authenticate? -- 4.1, 2nd paragraph is it reasonable for users to be expected to know which services are used in their ADMDs? -- 5, last paragraph: How do you imply a version? From nobody Fri May 15 06:12:48 2015 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 9B4031A6F20 for ; Fri, 15 May 2015 06:12:46 -0700 (PDT) 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 cUmiq1xbWhe5 for ; Fri, 15 May 2015 06:12:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 241F31A6F1D for ; Fri, 15 May 2015 06:12:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8E76D180092; Fri, 15 May 2015 06:10:52 -0700 (PDT) To: tony+sss@maillennium.att.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150515131052.8E76D180092@rfc-editor.org> Date: Fri, 15 May 2015 06:10:52 -0700 (PDT) Archived-At: Cc: yakov-ietf@shaftek.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 13:12:46 -0000 The following errata report has been submitted for RFC6839, "Additional Media Type Structured Syntax Suffixes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 -------------------------------------- Type: Technical Reported by: Yakov Shafranovich Section: 3.1 Original Text ------------- Encoding considerations: Per [RFC4627], JSON is allowed to be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045]). Corrected Text -------------- Encoding considerations: binary as per section 11 of RFC 7159 Notes ----- RFC 7159, section 11 specifies that encoding for JSON is binary. 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. -------------------------------------- RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) -------------------------------------- Title : Additional Media Type Structured Syntax Suffixes Publication Date : January 2013 Author(s) : T. Hansen, A. Melnikov Category : INFORMATIONAL Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri May 15 06:18:41 2015 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 C45EC1A889D for ; Fri, 15 May 2015 06:18:39 -0700 (PDT) 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, 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 6NJm0mmwgqf5 for ; Fri, 15 May 2015 06:18:38 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::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 3A6CB1A06FD for ; Fri, 15 May 2015 06:18:38 -0700 (PDT) Received: by iepk2 with SMTP id k2so110543617iep.3 for ; Fri, 15 May 2015 06:18:37 -0700 (PDT) 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=r3oLN/9selpiYseh9eY1kWeNfPNmry86t3ycyvUZlWU=; b=nxgAuz5bga80ZhWiRoxWQrJdJKZeDbkxWK+0LUaL3JDHgDbCJz3jRmvvCWXXH38YsT RyBzWE1X2Nej8f9XhJLGtWRZ97uzRCSZR12UsJ7nMeB62cl3EegnPUArbGOgAe2zPCNs UpFank+hdsjnAa1UqD1gRNJIFVS47yfc8nxF+KydOECDUDvdlyMe2WlKaSO2J2to1vKs lxNFuLkWJsRjt4IMS46RPBvnJtJjDypVTJCn8UFwICSzuWrUc+mXj03mVZt8+xu7wwvG b6m5yYklHm0cam1NiqfD+HvE/4z5nbhyJdxkr4HP7WX5yeiusqHGQVNAhOsRJmyVdYfc 66xg== MIME-Version: 1.0 X-Received: by 10.50.30.69 with SMTP id q5mr13951020igh.11.1431695917705; Fri, 15 May 2015 06:18:37 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.154 with HTTP; Fri, 15 May 2015 06:18:37 -0700 (PDT) In-Reply-To: <20150515131052.8E76D180092@rfc-editor.org> References: <20150515131052.8E76D180092@rfc-editor.org> Date: Fri, 15 May 2015 14:18:37 +0100 X-Google-Sender-Auth: wxhiKOqqdShw8M1Vj-C2ZWx2gAU Message-ID: From: Barry Leiba To: RFC Errata System Content-Type: multipart/alternative; boundary=047d7bdc1c0c99f1b005161eae0b Archived-At: Cc: "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , "yakov-ietf@shaftek.org" Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 13:18:39 -0000 --047d7bdc1c0c99f1b005161eae0b Content-Type: text/plain; charset=ISO-8859-1 And yet this RFC predates 7159, so how can 7159 be taken to support errata for this RFC? Barry On Friday, May 15, 2015, RFC Errata System wrote: > The following errata report has been submitted for RFC6839, > "Additional Media Type Structured Syntax Suffixes". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 > > -------------------------------------- > Type: Technical > Reported by: Yakov Shafranovich > > > Section: 3.1 > > Original Text > ------------- > Encoding considerations: > > Per [RFC4627], JSON is allowed to be represented using UTF-8, > UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit > compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, > JSON is binary ([RFC2045]). > > Corrected Text > -------------- > Encoding considerations: binary as per section 11 of RFC 7159 > > Notes > ----- > RFC 7159, section 11 specifies that encoding for JSON is binary. > > 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. > > -------------------------------------- > RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) > -------------------------------------- > Title : Additional Media Type Structured Syntax Suffixes > Publication Date : January 2013 > Author(s) : T. Hansen, A. Melnikov > Category : INFORMATIONAL > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG > > --047d7bdc1c0c99f1b005161eae0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And yet this RFC predates 7159, so how can 7159 be taken to support errata = for this RFC?

Barry

On Friday, May 1= 5, 2015, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitted for RFC6839,
"Additional Media Type Structured Syntax Suffixes".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6839&eid=3D4367

--------------------------------------
Type: Technical
Reported by: Yakov Shafranovich <yakov-ietf@shafte= k.org>

Section: 3.1

Original Text
-------------
Encoding considerations:

=A0 =A0 =A0 Per [RFC4627], JSON is allowed to be represented using UTF-8, =A0 =A0 =A0 UTF-16, or UTF-32.=A0 When JSON is written in UTF-8, JSON is 8b= it
=A0 =A0 =A0 compatible ([RFC2045]).=A0 When JSON is written in UTF-16 or UT= F-32,
=A0 =A0 =A0 JSON is binary ([RFC2045]).

Corrected Text
--------------
Encoding considerations:=A0 binary as per section 11 of RFC 7159

Notes
-----
RFC 7159, section 11 specifies that encoding for JSON is binary.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
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.

--------------------------------------
RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08)
--------------------------------------
Title=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Additional Media Type Structured Synt= ax Suffixes
Publication Date=A0 =A0 : January 2013
Author(s)=A0 =A0 =A0 =A0 =A0 =A0: T. Hansen, A. Melnikov
Category=A0 =A0 =A0 =A0 =A0 =A0 : INFORMATIONAL
Source=A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications Area Working Group
Area=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications
Stream=A0 =A0 =A0 =A0 =A0 =A0 =A0 : IETF
Verifying Party=A0 =A0 =A0: IESG

--047d7bdc1c0c99f1b005161eae0b-- From nobody Fri May 15 08:17:02 2015 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 6C5FE1A0078 for ; Fri, 15 May 2015 08:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 rIJbh8HQMK-y for ; Fri, 15 May 2015 08:16:59 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21C1D1A0045 for ; Fri, 15 May 2015 08:16:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PLZVS4E0HC00NT21@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 15 May 2015 08:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1431702695; bh=1UjvgLgPqSX2V2gp98Uzo1ulF1j2nSwWwkGaxntpfCY=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=ivmfG+j9Z1hWRx8Fxz8CRfoknM/TtMhg3NFXiFp6eMpKTHR+6JsAUhgc8qxAf20pv NhCBM6H4RKYTi9UtlBAptOU83bjPNfA/uN+nQXKlaP+tdhu/AIHYznvzbd2JRQ8epi C2p7rb/0d/VcHuAfo+FsfEwgVR1kajt6Kqn+ColE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PLUN66JM8W0000AQ@mauve.mrochek.com>; Fri, 15 May 2015 08:11:32 -0700 (PDT) Message-id: <01PLZVS2TH6K0000AQ@mauve.mrochek.com> Date: Fri, 15 May 2015 08:11:10 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 15 May 2015 06:10:52 -0700 (PDT)" <20150515131052.8E76D180092@rfc-editor.org> References: <20150515131052.8E76D180092@rfc-editor.org> To: RFC Errata System Archived-At: Cc: tony+sss@maillennium.att.com, apps-discuss@ietf.org, barryleiba@computer.org, rfc-editor@rfc-editor.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 15:17:00 -0000 This is bogus and should be rejected. Ned > The following errata report has been submitted for RFC6839, > "Additional Media Type Structured Syntax Suffixes". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 > -------------------------------------- > Type: Technical > Reported by: Yakov Shafranovich > Section: 3.1 > Original Text > ------------- > Encoding considerations: > Per [RFC4627], JSON is allowed to be represented using UTF-8, > UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit > compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, > JSON is binary ([RFC2045]). > Corrected Text > -------------- > Encoding considerations: binary as per section 11 of RFC 7159 > Notes > ----- > RFC 7159, section 11 specifies that encoding for JSON is binary. > 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. > -------------------------------------- > RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) > -------------------------------------- > Title : Additional Media Type Structured Syntax Suffixes > Publication Date : January 2013 > Author(s) : T. Hansen, A. Melnikov > Category : INFORMATIONAL > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri May 15 08:17:03 2015 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 BD8A91A0045 for ; Fri, 15 May 2015 08:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 RRSOhYGGSh0X for ; Fri, 15 May 2015 08:16:59 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 765D11A0064 for ; Fri, 15 May 2015 08:16:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PLZVVPAT5C00T4GT@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 15 May 2015 08:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1431702868; bh=3ZUkyEbqo2mg1F8sVE4nZ5vpTQsRmB8qN48aFADERZs=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=aYlpyCXmsMVu9ROfwD3BX0SFV+xyVB1YnjULJB4luuqqqhQ/uSglpmEzS/G9Wtjep QOekjtpAcY6n6FfCPnmvZkLpN9WUF95FMyr4U0u7CSWNAfUmA/3+R/EQAEkELijaOP T/zBqylM55CNbPQ7MEMrwrYm/KrzC9mQtrzuliYU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PLUN66JM8W0000AQ@mauve.mrochek.com>; Fri, 15 May 2015 08:14:26 -0700 (PDT) Message-id: <01PLZVVO768U0000AQ@mauve.mrochek.com> Date: Fri, 15 May 2015 08:12:59 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 15 May 2015 14:18:37 +0100" References: <20150515131052.8E76D180092@rfc-editor.org> To: Barry Leiba Archived-At: Cc: "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 15:17:00 -0000 > And yet this RFC predates 7159, so how can 7159 be taken to support errata > for this RFC? I suppose it could if it corrected something in the earlier RFC. But it doesn't. The earlier RFC is simply providing a more complete description of the encoding considerations that exist for JSON. Neither is incorrect though, so it doesn't make any sort of case for being an error. Ned > Barry > On Friday, May 15, 2015, RFC Errata System > wrote: > > The following errata report has been submitted for RFC6839, > > "Additional Media Type Structured Syntax Suffixes". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 > > > > -------------------------------------- > > Type: Technical > > Reported by: Yakov Shafranovich > > > > > Section: 3.1 > > > > Original Text > > ------------- > > Encoding considerations: > > > > Per [RFC4627], JSON is allowed to be represented using UTF-8, > > UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit > > compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, > > JSON is binary ([RFC2045]). > > > > Corrected Text > > -------------- > > Encoding considerations: binary as per section 11 of RFC 7159 > > > > Notes > > ----- > > RFC 7159, section 11 specifies that encoding for JSON is binary. > > > > 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. > > > > -------------------------------------- > > RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) > > -------------------------------------- > > Title : Additional Media Type Structured Syntax Suffixes > > Publication Date : January 2013 > > Author(s) : T. Hansen, A. Melnikov > > Category : INFORMATIONAL > > Source : Applications Area Working Group > > Area : Applications > > Stream : IETF > > Verifying Party : IESG > > > > From nobody Fri May 15 08:22:47 2015 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 CF83E1A00E4 for ; Fri, 15 May 2015 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 9-sz3P9h7dbe for ; Fri, 15 May 2015 08:22:45 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (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 1DCD21A1B82 for ; Fri, 15 May 2015 08:22:45 -0700 (PDT) Received: by qcyk17 with SMTP id k17so58431284qcy.1 for ; Fri, 15 May 2015 08:22:44 -0700 (PDT) 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:from :date:message-id:subject:to:cc:content-type; bh=2CrgsZ3htLktSYHqbz0MrVv+ch1bJxzL5lN9JAlEskA=; b=OjJDEK0e4EXeYXhXAJqdGlU4q2f4W2WhrmJ+xmGz4L+KuOw6SFqfdk2vAhyPlxLQmN 6aRoyqdJyP31G2HtsQ79hfRZFMTt7jj5NjavejFz6Mel19Oj1jZlSzJnVzqlaJqjHxUG /JqnqUhNSt1fNKEw6mLy0ZJVZIGMB3i6hPClZyHLku/XU70OwGTh3CXvRgK197n7BbgT K1T7L6PlAmwOjE8J/YhgGmZvDz90k78LRFqgjAbYT21D/IiI0dSCM9clw+WBxLGABcDv 6cUL0z1OZisjxPfKYfojd5mGeP7NpSoiNMdyn6rUvs0oETkHmR4x+5OVyiLJ6puqMZ6k iL/Q== X-Gm-Message-State: ALoCoQlolPKv7SbspApODFqrjacGfUv7lktiUUD97iPd9NKBjeqj79A3sy97lAFQVcM87WqhZBiG X-Received: by 10.55.49.12 with SMTP id x12mr704082qkx.21.1431703364439; Fri, 15 May 2015 08:22:44 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.140.98.194 with HTTP; Fri, 15 May 2015 08:22:14 -0700 (PDT) X-Originating-IP: [74.103.24.152] In-Reply-To: <01PLZVVO768U0000AQ@mauve.mrochek.com> References: <20150515131052.8E76D180092@rfc-editor.org> <01PLZVVO768U0000AQ@mauve.mrochek.com> From: Yakov Shafranovich Date: Fri, 15 May 2015 11:22:14 -0400 X-Google-Sender-Auth: g5x9iToADJiBlO80QsCtWqLEVDc Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Barry Leiba , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 15:22:47 -0000 Thank you. If both are correct, can either one be specified for a new +json media type registration. I am a member of the W3C CSVW group where this is originating from. This is in regards to the following registration: https://www.ietf.org/mail-archive/web/media-types/current/msg00686.html At the W3C, the following issue was raised: https://github.com/w3c/csvw/issues/546 " "When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]) so, 8bit not binary, since utf-8 is the default encoding your media type registration says binary rfc6839 (which you reference) says the above" Yakov On Fri, May 15, 2015 at 11:12 AM, Ned Freed wrote: >> And yet this RFC predates 7159, so how can 7159 be taken to support errata >> for this RFC? > > I suppose it could if it corrected something in the earlier RFC. But it > doesn't. The earlier RFC is simply providing a more complete description of the > encoding considerations that exist for JSON. Neither is incorrect though, so it > doesn't make any sort of case for being an error. > > Ned > >> Barry > >> On Friday, May 15, 2015, RFC Errata System >> wrote: > >> > The following errata report has been submitted for RFC6839, >> > "Additional Media Type Structured Syntax Suffixes". >> > >> > -------------------------------------- >> > You may review the report below and at: >> > http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Yakov Shafranovich > >> > >> > Section: 3.1 >> > >> > Original Text >> > ------------- >> > Encoding considerations: >> > >> > Per [RFC4627], JSON is allowed to be represented using UTF-8, >> > UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit >> > compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, >> > JSON is binary ([RFC2045]). >> > >> > Corrected Text >> > -------------- >> > Encoding considerations: binary as per section 11 of RFC 7159 >> > >> > Notes >> > ----- >> > RFC 7159, section 11 specifies that encoding for JSON is binary. >> > >> > 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. >> > >> > -------------------------------------- >> > RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) >> > -------------------------------------- >> > Title : Additional Media Type Structured Syntax Suffixes >> > Publication Date : January 2013 >> > Author(s) : T. Hansen, A. Melnikov >> > Category : INFORMATIONAL >> > Source : Applications Area Working Group >> > Area : Applications >> > Stream : IETF >> > Verifying Party : IESG >> > >> > From nobody Fri May 15 09:36:46 2015 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 D382E1A1BDD for ; Fri, 15 May 2015 09:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Opfh92k-u_aR for ; Fri, 15 May 2015 09:36:44 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7BA1A1BCC for ; Fri, 15 May 2015 09:36:43 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 99026555.0.6124393.00-2385.17237542.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 15 May 2015 16:36:44 +0000 (UTC) X-MXL-Hash: 5556209c4bcc187f-31e89fc35e09d1b61467e0495124d98928175696 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 t4FGaea9008865 for ; Fri, 15 May 2015 12:36:41 -0400 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 t4FGaYwV008793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 May 2015 12:36:35 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Fri, 15 May 2015 16:36:25 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 t4FGaPTS002963 for ; Fri, 15 May 2015 12:36:25 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4FGaK59002738 for ; Fri, 15 May 2015 12:36:20 -0400 Received: from tonys-macbook-pro.local (azcdtl01kp2625.itservices.sbc.com?[135.110.240.171](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150515163617gw1000ce98e>; Fri, 15 May 2015 16:36:20 +0000 X-Originating-IP: [135.110.240.171] Message-ID: <55562081.6070504@att.com> Date: Fri, 15 May 2015 12:36:17 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yakov Shafranovich , Barry Leiba References: <20150515131052.8E76D180092@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=FPCsMZUs c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5hWoPXNsKEoA:10 a=4wVnF6RUk10A:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=h1PgugrvaO0A:10 a=8qSefF8w] X-AnalysisOut: [AAAA:8 a=BqEg4_3jAAAA:8 a=QbxTNZaXAAAA:8 a=gMVBA8GuGAaxY0H] X-AnalysisOut: [9i-8A:9 a=pILNOxqGKmIA:10 a=mhd2NDuUijAA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 16:36:46 -0000 On 5/15/15 9:31 AM, Yakov Shafranovich wrote: > [For context, this is originating from the work at the W3C regarding CS= V files] > > There appears to be an issue about how to specify encoding > considerations for media types that can be encoded in UTF-8, UTF-16 > and UTF-32. For media types, the valid choices are 7-bit, 8-bit and > binary, which would mean that UTF-16 and UTF-32 are binary. For JSON > specifically, since both RFCs define JSON, there is a conflict. > > There are two ways to write this then: > > 1. As in RFC 6839: > > "When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). > When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045])." > > 2. As per RFC 7159: > > "binary" > > What I am arguing is that the second approach would make more sense. > Just like RFC 7159 choose to use "binary" in case of multiple UTF > encodings, we should follow the same approach in RFC 6839. If not, > then RFC 7159 should have errata pointing back to RFC 6839. Hmmm, it's too bad we didn't catch this before 7159 was published. 7159 is wrong, or at least incomplete. When JSON is written in UTF-8, you MAY use an encoding of 8-bit, or you MAY use an encoding of binary. When JSON is written in UTF-16 or -32, you MUST use an encoding of binary. This is because of the definition of the encoding system definitions of 7-bit, 8-bit and binary, which is totally orthogonal to ANY media type. The definition of UTF-8 is, in and of itself, compatible with the definition of 8-bit encoding. Tony > > Thanks, > Yakov > > On Fri, May 15, 2015 at 9:18 AM, Barry Leiba = wrote: >> And yet this RFC predates 7159, so how can 7159 be taken to support er= rata >> for this RFC? >> >> Barry >> >> >> On Friday, May 15, 2015, RFC Errata System = >> wrote: >>> The following errata report has been submitted for RFC6839, >>> "Additional Media Type Structured Syntax Suffixes". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6839&eid=3D4367 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Yakov Shafranovich >>> >>> Section: 3.1 >>> >>> Original Text >>> ------------- >>> Encoding considerations: >>> >>> Per [RFC4627], JSON is allowed to be represented using UTF-8, >>> UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit= >>> compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-= 32, >>> JSON is binary ([RFC2045]). >>> >>> Corrected Text >>> -------------- >>> Encoding considerations: binary as per section 11 of RFC 7159 >>> >>> Notes >>> ----- >>> RFC 7159, section 11 specifies that encoding for JSON is binary. >>> >>> 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. >>> >>> -------------------------------------- >>> RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) >>> -------------------------------------- >>> Title : Additional Media Type Structured Syntax Suffixe= s >>> Publication Date : January 2013 >>> Author(s) : T. Hansen, A. Melnikov >>> Category : INFORMATIONAL >>> Source : Applications Area Working Group >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >>> From nobody Fri May 15 09:44:18 2015 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 5A3841A6F05 for ; Fri, 15 May 2015 09:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 ZeGAwJFrn-lU for ; Fri, 15 May 2015 09:44:14 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (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 6525D1A6EE2 for ; Fri, 15 May 2015 09:44:14 -0700 (PDT) Received: by qcyk17 with SMTP id k17so59732847qcy.1 for ; Fri, 15 May 2015 09:44:13 -0700 (PDT) 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:from :date:message-id:subject:to:cc:content-type; bh=K6pGBWmtTO+vLLB/MteSWieJmq9BLmAHRPuDBxfgE3c=; b=hP13YDdPaRFd6E0hwblvE7f5LhJXg2/8su9PWSlRtxkAp58AjBbAaLHtGk1yChAGXs v2eQ9qv38chFP3Vvrs+wbAIk27vbkkatOtenwP4BH/9QgMvLH/5vjS0pdgn9yZ43FCAI nyVHrP02S7g00+MChGS2ibs9ZzlrIWObFvEzqQRX5+Q49Pnl7X4oUozA5BpZBXBiX2TH lclei0H+6NQx9cMXMnlh49t2Ammi1R7w4WpiRKh6Hgk7Ty42tHPwQp/vcjWDdRhlIEyb Ms0Ch6EoREnpMkMpL2uR146Wg7biMFsiVZRkKib18WFw6zlvNgh8ELNCVemvdwzFShAp kT6g== X-Gm-Message-State: ALoCoQm/MgOBDJqr92z98fV1eSurVlFFAIMToB5wgp8AKl1sUHKeC+y9Z+B9eGGZz+RR+B9LGGD5 X-Received: by 10.140.149.147 with SMTP id 141mr14420918qhv.17.1431708253669; Fri, 15 May 2015 09:44:13 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.140.98.194 with HTTP; Fri, 15 May 2015 09:43:43 -0700 (PDT) X-Originating-IP: [74.103.24.152] In-Reply-To: <55562081.6070504@att.com> References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> From: Yakov Shafranovich Date: Fri, 15 May 2015 12:43:43 -0400 X-Google-Sender-Auth: -FhMpqJxztCUltFPpLnxA-m_hJc Message-ID: To: Tony Hansen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , Barry Leiba , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 16:44:16 -0000 Thank you! I will relay this information to my WG at the W3C. I guess this means the errata should really be reported on RFC 7159 instead? On Fri, May 15, 2015 at 12:36 PM, Tony Hansen wrote: > On 5/15/15 9:31 AM, Yakov Shafranovich wrote: >> [For context, this is originating from the work at the W3C regarding CSV files] >> >> There appears to be an issue about how to specify encoding >> considerations for media types that can be encoded in UTF-8, UTF-16 >> and UTF-32. For media types, the valid choices are 7-bit, 8-bit and >> binary, which would mean that UTF-16 and UTF-32 are binary. For JSON >> specifically, since both RFCs define JSON, there is a conflict. >> >> There are two ways to write this then: >> >> 1. As in RFC 6839: >> >> "When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). >> When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045])." >> >> 2. As per RFC 7159: >> >> "binary" >> >> What I am arguing is that the second approach would make more sense. >> Just like RFC 7159 choose to use "binary" in case of multiple UTF >> encodings, we should follow the same approach in RFC 6839. If not, >> then RFC 7159 should have errata pointing back to RFC 6839. > > Hmmm, it's too bad we didn't catch this before 7159 was published. 7159 > is wrong, or at least incomplete. > > When JSON is written in UTF-8, you MAY use an encoding of 8-bit, or you > MAY use an encoding of binary. When JSON is written in UTF-16 or -32, > you MUST use an encoding of binary. > > This is because of the definition of the encoding system definitions of > 7-bit, 8-bit and binary, which is totally orthogonal to ANY media type. > The definition of UTF-8 is, in and of itself, compatible with the > definition of 8-bit encoding. > > Tony > >> >> Thanks, >> Yakov >> >> On Fri, May 15, 2015 at 9:18 AM, Barry Leiba wrote: >>> And yet this RFC predates 7159, so how can 7159 be taken to support errata >>> for this RFC? >>> >>> Barry >>> >>> >>> On Friday, May 15, 2015, RFC Errata System >>> wrote: >>>> The following errata report has been submitted for RFC6839, >>>> "Additional Media Type Structured Syntax Suffixes". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Yakov Shafranovich >>>> >>>> Section: 3.1 >>>> >>>> Original Text >>>> ------------- >>>> Encoding considerations: >>>> >>>> Per [RFC4627], JSON is allowed to be represented using UTF-8, >>>> UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit >>>> compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, >>>> JSON is binary ([RFC2045]). >>>> >>>> Corrected Text >>>> -------------- >>>> Encoding considerations: binary as per section 11 of RFC 7159 >>>> >>>> Notes >>>> ----- >>>> RFC 7159, section 11 specifies that encoding for JSON is binary. >>>> >>>> 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. >>>> >>>> -------------------------------------- >>>> RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) >>>> -------------------------------------- >>>> Title : Additional Media Type Structured Syntax Suffixes >>>> Publication Date : January 2013 >>>> Author(s) : T. Hansen, A. Melnikov >>>> Category : INFORMATIONAL >>>> Source : Applications Area Working Group >>>> Area : Applications >>>> Stream : IETF >>>> Verifying Party : IESG >>>> > > From nobody Fri May 15 09:54:49 2015 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 D26A81A710C for ; Fri, 15 May 2015 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WBvL-5Lnivtx for ; Fri, 15 May 2015 09:54:46 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A591A702A for ; Fri, 15 May 2015 09:54:45 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 4d426555.0.6138049.00-2263.17275317.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 15 May 2015 16:54:45 +0000 (UTC) X-MXL-Hash: 555624d54e94d4d7-ef6f5389d2dbd6918157ca64bc6d6c0bef0262ac 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 t4FGsiVI026143 for ; Fri, 15 May 2015 12:54:44 -0400 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 t4FGsdAG026090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 May 2015 12:54:41 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Fri, 15 May 2015 16:54:24 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 t4FGsOrv004346 for ; Fri, 15 May 2015 12:54:24 -0400 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 t4FGs0pe003036 for ; Fri, 15 May 2015 12:54:02 -0400 Received: from tonys-macbook-pro.local (azcdtl01kp2625.itservices.sbc.com?[135.110.240.171](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150515165359gw1000ce99e>; Fri, 15 May 2015 16:54:00 +0000 X-Originating-IP: [135.110.240.171] Message-ID: <555624A6.5050505@att.com> Date: Fri, 15 May 2015 12:53:58 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yakov Shafranovich References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ea6Kic4H c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5hWoPXNsKEoA:10 a=4wVnF6RUk10A:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=h1PgugrvaO0A:10 a=8qSefF8w] X-AnalysisOut: [AAAA:8 a=BqEg4_3jAAAA:8 a=QbxTNZaXAAAA:8 a=7fpexHYy274LJzc] X-AnalysisOut: [aK28A:9 a=pILNOxqGKmIA:10 a=mhd2NDuUijAA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , Barry Leiba , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 16:54:48 -0000 There is one more constraint for a file written with utf-8 to use the encoding of 8bit: the lines are limited to 998 bytes in length (not counting the CRLF line terminators). See RFC 2045 for details. It's up to you whether you want to write an errata against RFC 7159. Tony Hansen On 5/15/15 12:43 PM, Yakov Shafranovich wrote: > Thank you! I will relay this information to my WG at the W3C. > > I guess this means the errata should really be reported on RFC 7159 ins= tead? > > On Fri, May 15, 2015 at 12:36 PM, Tony Hansen wrote: >> On 5/15/15 9:31 AM, Yakov Shafranovich wrote: >>> [For context, this is originating from the work at the W3C regarding = CSV files] >>> >>> There appears to be an issue about how to specify encoding >>> considerations for media types that can be encoded in UTF-8, UTF-16 >>> and UTF-32. For media types, the valid choices are 7-bit, 8-bit and >>> binary, which would mean that UTF-16 and UTF-32 are binary. For JSON >>> specifically, since both RFCs define JSON, there is a conflict. >>> >>> There are two ways to write this then: >>> >>> 1. As in RFC 6839: >>> >>> "When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). >>> When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045]).= " >>> >>> 2. As per RFC 7159: >>> >>> "binary" >>> >>> What I am arguing is that the second approach would make more sense. >>> Just like RFC 7159 choose to use "binary" in case of multiple UTF >>> encodings, we should follow the same approach in RFC 6839. If not, >>> then RFC 7159 should have errata pointing back to RFC 6839. >> Hmmm, it's too bad we didn't catch this before 7159 was published. 715= 9 >> is wrong, or at least incomplete. >> >> When JSON is written in UTF-8, you MAY use an encoding of 8-bit, or yo= u >> MAY use an encoding of binary. When JSON is written in UTF-16 or -32, >> you MUST use an encoding of binary. >> >> This is because of the definition of the encoding system definitions o= f >> 7-bit, 8-bit and binary, which is totally orthogonal to ANY media type= =2E >> The definition of UTF-8 is, in and of itself, compatible with the >> definition of 8-bit encoding. >> >> Tony >> >>> Thanks, >>> Yakov >>> >>> On Fri, May 15, 2015 at 9:18 AM, Barry Leiba wrote: >>>> And yet this RFC predates 7159, so how can 7159 be taken to support = errata >>>> for this RFC? >>>> >>>> Barry >>>> >>>> >>>> On Friday, May 15, 2015, RFC Errata System >>>> wrote: >>>>> The following errata report has been submitted for RFC6839, >>>>> "Additional Media Type Structured Syntax Suffixes". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6839&eid=3D4367 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Yakov Shafranovich >>>>> >>>>> Section: 3.1 >>>>> >>>>> Original Text >>>>> ------------- >>>>> Encoding considerations: >>>>> >>>>> Per [RFC4627], JSON is allowed to be represented using UTF-8,= >>>>> UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8b= it >>>>> compatible ([RFC2045]). When JSON is written in UTF-16 or UT= F-32, >>>>> JSON is binary ([RFC2045]). >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> Encoding considerations: binary as per section 11 of RFC 7159 >>>>> >>>>> Notes >>>>> ----- >>>>> RFC 7159, section 11 specifies that encoding for JSON is binary. >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary, pleas= e >>>>> 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. >>>>> >>>>> -------------------------------------- >>>>> RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) >>>>> -------------------------------------- >>>>> Title : Additional Media Type Structured Syntax Suffi= xes >>>>> Publication Date : January 2013 >>>>> Author(s) : T. Hansen, A. Melnikov >>>>> Category : INFORMATIONAL >>>>> Source : Applications Area Working Group >>>>> Area : Applications >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>>> >> From nobody Fri May 15 12:07:42 2015 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 E84931A87CB for ; Fri, 15 May 2015 12:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.111 X-Spam-Level: X-Spam-Status: No, score=-5.111 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_HI=-5, 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 lIuZrdKHHeHN for ; Fri, 15 May 2015 12:07:37 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E825E1A87C7 for ; Fri, 15 May 2015 12:07:35 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wyQvSdonRqONt6ntPvBqj758BKNAI2R+KaNmyvHz3SJDE+T3ySClCXs7 25+tszLG195MXaM8oLpzNiu+crLqvfUp49MomibUiaFAJlCB5YPzyVVvh l5/Xz0wcbLvPuhplHMVXfhbZyFDGU3jKkDOk6WZjGgg3MuL+6mM29Zl4N w=; X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.13,435,1427778000"; d="scan'208";a="655528898" From: To: , Date: Fri, 15 May 2015 14:07:03 -0500 Thread-Topic: [apps-discuss] New Proposed VNC URI Scheme Thread-Index: AdCMjXe4KPoiFP1sRe6vRzg1IXeFbACsjQNQ Message-ID: <2D58682309E75147BB3B286C815CAC7E2AC31D0E7D@AUSX7MCPS308.AMER.DELL.COM> References: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> <006801d08642$268bbd00$4001a8c0@gateway.2wire.net> <2D58682309E75147BB3B286C815CAC7E2AC107881B@AUSX7MCPS308.AMER.DELL.COM> <012001d08bd8$f8c37420$4001a8c0@gateway.2wire.net> <00d201d08c8d$2f97cfa0$4001a8c0@gateway.2wire.net> In-Reply-To: <00d201d08c8d$2f97cfa0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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 May 2015 19:07:40 -0000 Here are my comments on Tom's suggestions. ----- Original Message ----- From: "t.petch" To: ; Sent: Monday, May 11, 2015 11:53 AM > >Um yes, I should have read RFC6143 more carefully before commenting. >see what you mean about having both Expert Review and IESG Approval - I ha= d not seen that before. Both place an extra burden on the IESG and I do se= e the IESG as a limiting factor in the >work of the IETF and so am always k= een to reduce that burden when possible. Hence my enthusiasm for other for= ms of update, such as RFC Required. I've revised the document to remove references to IESG Approval, so it is n= ow "Expert Review" only. >Separately, I wonder if the entries in the new VNC ID Hash Algorithms regi= stry should be required to appear in another registry, such as the TLS one,= to discourage people from inventing their >own i.e. they have to convince = Eric Rescorla of its value before VMC can use it:-) As you've inferred, I was originally thinking there would be value in a "un= iversal" hash algorithms registry since a number of protocols use the same = algorithms and have registries with similar content. Some protocols may req= uire slightly different representations (such as a byte value or string) an= d might use them differently (perhaps requiring all algorithms in the regis= try be supported). There may be some use for shared registries, however if = this is to be someone with at least slightly more ambition and perhaps grea= ter standing with the IETF will need to take this on.=20 >On the URI itself, I am unsure about > unreserved-symbols =3D ":" / "/" / "#" / "[" / "]" / "@" / "!" / > "$" / "'" / "(" / ")" / "*" / "," / ";" > where you are unreserving some gen-delims. It is hard to say whether or = not RFC3986 prohibits this (it is sometimes hard to say what RFC3986 > says:-) but '#' is problematic as is ']'. The subject of '#' came up rec= ently on this list with the point being made that generic parsers may scan = backwards and treat the first '#' as being the only=20 > one so a second one will result in misinterpretation. The whole question= of '#' is fraught as that discussion showed. Upon review, it was an error not to keep # and [] reserved and I've updated= the document to reflect this. The RFC3986 BNF does not require reservation= of "/" (in the query) and ":", "@" (as a pchar in the query) and they rem= ain unreserved although they are gen-delims. I was playing around with stri= ng escape libraries and went a bit too far in reducing the number of reserv= ed characters.=20 Regards, David Warden From nobody Sat May 16 08:34:48 2015 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 A485E1B2BAE for ; Wed, 6 May 2015 09:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bTpSgKV6NIXt for ; Wed, 6 May 2015 09:07:45 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84891A0171 for ; Wed, 6 May 2015 09:07:44 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 6 May 2015 09:07:42 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Wed, 6 May 2015 09:07:42 -0700 From: Kim Davies To: Marc Blanchet Thread-Topic: [apps-discuss] new work being considered: lager: label generation rules Thread-Index: AQHQh9S6inmFigvnSkK/xbqcokht9J1vkz8A Date: Wed, 6 May 2015 16:07:42 +0000 Message-ID: References: <20150506032046.43995.qmail@ary.lan> <8621B05F-08C5-4863-B173-9799FC7AAEB1@viagenie.ca> In-Reply-To: <8621B05F-08C5-4863-B173-9799FC7AAEB1@viagenie.ca> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: <028590E82CF9174FABEA8235920BFF10@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 16 May 2015 08:34:45 -0700 Cc: John Levine , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] new work being considered: lager: label generation rules 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 May 2015 16:07:47 -0000 DQo+IE9uIE1heSA2LCAyMDE1LCBhdCAxOjE0IEFNLCBNYXJjIEJsYW5jaGV0IDxtYXJjLmJsYW5j aGV0QHZpYWdlbmllLmNhPiB3cm90ZToNCj4+IA0KPj4gV2hvIGFyZSB0aGUgZXhwZWN0ZWQgdXNl cnMgb2YgdGhpcyBzdXBlciBYTUwgc2NoZW1hPyAgSSBrbm93IHRoYXQNCj4+IElDQU5OIGhhcyBh biBSRlAgb3V0IGZvciB0b29scyB1c2luZyB0aGUgY3VycmVudCBMR1IgZHJhZnQuICBBbnlvbmUN Cj4+IGVsc2U/DQo+IA0KPiB0aGFua3MgZm9yIHRoZSB2ZXJ5IGdvb2QgcXVlc3Rpb24uIFNvIHRo aXMgd29yayB3aWxsIGVuYWJsZSBwZW9wbGUgdG8gc3BlY2lmeSAoYW5kIHRoZXJlZm9yZSB2ZXJp ZnkpIHRoZSBydWxlcyBmb3IgdmFsaWQgbGFiZWxzLiBUaGUgZmlyc3QgbmVhciB0ZXJtIHVzZSBp cyBmb3IgdGhlIHJvb3Qgem9uZS4gSW4gdGhpcyBjb250ZXh0LCBhbnlvbmUgd2hvIHdhbnRzIHRv IHZlcmlmeSBpZiBhIGxhYmVsIGlzIHZhbGlkIChpLmUuIHdoYXRldmVyIGl0IGlzIGFjdHVhbGx5 IGEgZGVsZWdhdGVkIGxhYmVsIG9yIG5vdCkgd291bGQgYmUgYSB0YXJnZXQgdXNlciwgdGhlcmVm b3JlIG1hbnkgcGVvcGxlIHdpdGhpbiB0aGUgcmVnaXN0cmF0aW9uIGVjb3N5c3RlbS4gVGhpcyB3 b3JrIGlzIGFsc28gYSBmcmFtZXdvcmsgZm9yIHNwZWNpZnlpbmcgdmFyaWFudHMsIHdoaWNoIGFy ZSBpZGVudGlmaWVkIGFzIGJsb2NrZWQgb3IgYWxsb2NhdGFibGUuIEluIHRoaXMgY29udGV4dCwg dmVyaWZ5IGlmIGEgbGFiZWwgaXMgYWxsb2NhdGFibGUgaXMgYWxzbyB1c2VmdWwgZm9yIHBhcnRp ZXMgaW4gdGhlIHJlZ2lzdHJhdGlvbiBzeXN0ZW0uIE1vcmVvdmVyLCBpdCBpcyBlbnZpc2lvbm5l ZCB0aGF0IHRoaXMgdGVjaG5vbG9neSBjb3VsZCBhbHNvIGJlIHVzZWQgZm9yIGFueSBsZXZlbCBz dWNoIGFzIHNlY29uZCBsZXZlbHMuIFNvIHBvdGVudGlhbGx5IG1hbnkgcGFydGllcyBpbiB0aGUg cmVnaXN0cmF0aW9uIGVjb3N5c3RlbS4NCg0KU29tZSBmdXJ0aGVyIHRob3VnaHRzIG9uIHRoaXMs IGluIGFkZGl0aW9uIHRvIGl0cyB1c2Ugc3BlY2lmaWNhbGx5IGZvciB0aGUgRE5TIHJvb3Qgem9u ZToNCg0KMS4gVGhlIG1ham9yaXR5IG9mIFRMRCByZWdpc3RyaWVzIHRoYXQgc3VwcG9ydCBJRE5z IGRpc2Nsb3NlIOKAlCBlaXRoZXIgdm9sdW50YXJpbHkgb3IgYnkgY29udHJhY3Qg4oCUIHRoZSDi gJxJRE4gdGFibGVz4oCdIHRoZXkgdXNlIGZvciBkb21haW4gcmVnaXN0cmllcy4gRXhwZXJpZW5j ZSB0byBkYXRlIGlzIHRob3NlIHByb3ZpZGVkIGFyZSBhIG1peCBvZiBmb3JtYXRzLCBwbHVzIGEg bG90IG9mIHRoZSBhc3NvY2lhdGVkIGJ1c2luZXNzIHJ1bGVzIGFyZSBlaXRoZXIgb21pdHRlZCwg b3IgZGVzY3JpYmVkIGluIGEgbmFycmF0aXZlIGZvcm0gdGhhdCBpcyBub3QgY29uZHVjaXZlIHRv IGVhc3kgcmUtdXNlLiBUaGlzIGZvcm1hdCBpbiBpbnRlbmRlZCB0byBwcm92aWRlIGEgY29tbW9u IGZvcm0gZm9yIGRvaW5nIHNvLCBwcm92aWRpbmcgZm9yIGdyZWF0ZXIgYWJpbGl0eSB0byByZS11 c2UgYW5kIGNvbXBhcmUuDQoNCjIuIFdlIG1haW50YWluIGFuIOKAnElETiBwcmFjdGljZXMgcmVw b3NpdG9yeeKAnSwgZWZmZWN0aXZlbHkgYSBsaXN0IG9mIHByb3ZpZGVkIElETiB0YWJsZXMsIG9u IHRoZSBJQU5BIHdlYnNpdGUuIEkgZXhwZWN0IHRoYXQgaWYgdGhlIGZvcm1hdCBpcyBmaW5hbGlz ZWQgd2Ugd2lsbCBhaW0gdG8gbWlncmF0ZSB0aGUgZXhpc3RpbmcgY29ycHVzIG9mIHRhYmxlcyB0 byB0aGUgbmV3IGZvcm1hdC4NCg0KMy4gSUNBTk4gaXMgYWxzbyBsb29raW5nIGludG8gZW5nYWdl IHJlc2VhcmNoZXJzIHRvIGRldmVsb3BpbmcgbW9kZWwgcnVsZXNldHMgZm9yIGRpZmZlcmVudCBs YW5ndWFnZXMsIHVwb24gd2hpY2ggcmVnaXN0cmllcyBjb3VsZCBiYXNlIHRoZWlyIHBvbGljaWVz LiBUaGVzZSB3b3VsZCBiZSBwcm92aWRlZCBpbiAgdGhpcyBmb3JtYXQuDQoNCjQuIEhhdmluZyBh IHN0YW5kYXJkIHdheSBvZiBkb2N1bWVudGluZyB0aGVzZSBraW5kcyBvZiBydWxlcyB3aWxsIGFs bG93IHJlZ2lzdHJ5IG9wZXJhdG9ycyB0bywgcmF0aGVyIHRoYW4gaGFyZC1jb2RpbmcgYnVzaW5l c3MgbG9naWMgaW50byB0aGVpciByZWdpc3RyeSBwbGF0Zm9ybXMgYXMgbWFueSBkbyB0b2RheSwg aW1wbGVtZW50IGEgZ2VuZXJpYyBlbmdpbmUgdGhhdCBzaW1wbHkgdW5kZXJzdGFuZHMgdGhlIExH UiBmb3JtYXQuIFRoZW4gZm9yIGVhY2ggbmV3IHpvbmUsIGl0IGNhbiBiZSBwYWlyZWQgd2l0aCBh biBMR1IgZmlsZSwgd2hpY2ggd2lsbCBiZSB1c2VkIHRvIGFzc2VzcyBlbGlnaWJpbGl0eSBvZiBu ZXcgbGFiZWxzLiBJdCBjYW4gbW92ZSB0aGUgcnVsZXNldCBmcm9tIGJlaW5nIHNvbWV0aGluZyB0 b2RheSB0aGF0IHJlZ2lzdHJ5IG9wZXJhdG9ycyBleHBvcnQgYXMgYW4gYWZ0ZXJ0aG91Z2h0LCB0 byBiZWluZyBhIHByaW1hcnkgZWxlbWVudCBhIHJlZ2lzdHJ5IGFzc2Vzc2VzIHBvbGljeS4NCg0K NS4gSSB0aGluayBpdCBpcyB3b3J0aCBhbHNvIGNvbnNpZGVyaW5nIHRoYXQgdGhlIHNwZWNpZmlj YXRpb24gaXMgbm90IGludGVuZGVkIHRvIGJlIGxpbWl0ZWQgdG8gdGhlIEROUywgZXZlbiB0aG91 Z2ggdGhhdCBpcyB0aGUgcHJpbWFyeSBpbnRlbmRlZCB1c2UuIFdl4oCZdmUgdHJpZWQgdG8gd3Jp dGUgdGhlIHNwZWNpZmljYXRpb24gdG8gZGF0ZSBzdWNoIHRoYXQgeW91IGNvdWxkIHVzIGl0IGZv ciBhc3Nlc3NpbmcgYW55IGtpbmQgb2YgY2FuZGlkYXRlIGxhYmVscyBvciBpZGVudGlmaWVycyBh Z2FpbnN0IGEgc2V0IG9mIHJ1bGVzLiBBcyBvbmUgZXhhbXBsZSwgeW91IGNvdWxkIHVzZSBpdCB0 byBhc3Nlc3MgdXNlcm5hbWUgZWxpZ2liaWxpdHkgaW4gYSBzeXN0ZW0uDQoNCmtpbQ0KDQo= From nobody Sat May 16 08:34:49 2015 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 B21021A8A74 for ; Fri, 15 May 2015 06:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 9IPZ-s-7hW60 for ; Fri, 15 May 2015 06:31:50 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (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 0EEEB1A8A8F for ; Fri, 15 May 2015 06:31:35 -0700 (PDT) Received: by qgfh8 with SMTP id h8so957626qgf.3 for ; Fri, 15 May 2015 06:31:34 -0700 (PDT) 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:from :date:message-id:subject:to:cc:content-type; bh=Fd2+30BNMQnlJvRc9uJW2bns9bSCQW674iBh7r6/1lA=; b=MwhlcW3pC3djy/S8KrM9PlGWEB3sX/hadZVwnaudSsJ9dVNeojQF+DwdkvWL3BLgmW FQBeUF0kSVva303AmeOpg4DGgA8/KtPSi1xDFJwTLsZ89NLstI/GfK1i7gmyyVWBiRK0 j5j1wIA9j/MAuNMd082ftpFN0vsFXoQ7ZEJ6Nu2R4ThBN2cSmr9UrWPpCDDW+aHx00sS AYN517zHmTVxzlAmoOSN7SEQdGIZPu84EW2KxXg/Wv5WLOEQ7mkC8VjpDP8o9FmpVDGy Lgz7Fk60qyh6F9KKkRQD6M0sOT9WHYb/IQNyDcWYNVRlH24A5cHPPYhNfinsTB/mRpYY 8lWg== X-Gm-Message-State: ALoCoQmJpVxjw16orhduTQgDsmEgWHELHcGCpFEzHlA0bhix2bSde9BNXBwleboqy6On+1smcqx2 X-Received: by 10.140.30.100 with SMTP id c91mr12228143qgc.81.1431696694309; Fri, 15 May 2015 06:31:34 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.140.98.194 with HTTP; Fri, 15 May 2015 06:31:03 -0700 (PDT) X-Originating-IP: [74.103.24.152] In-Reply-To: References: <20150515131052.8E76D180092@rfc-editor.org> From: Yakov Shafranovich Date: Fri, 15 May 2015 09:31:03 -0400 X-Google-Sender-Auth: nVj7k_Vq9nOnmbCUyfn5y13G6ac Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Archived-At: X-Mailman-Approved-At: Sat, 16 May 2015 08:34:45 -0700 Cc: "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 13:31:52 -0000 [For context, this is originating from the work at the W3C regarding CSV files] There appears to be an issue about how to specify encoding considerations for media types that can be encoded in UTF-8, UTF-16 and UTF-32. For media types, the valid choices are 7-bit, 8-bit and binary, which would mean that UTF-16 and UTF-32 are binary. For JSON specifically, since both RFCs define JSON, there is a conflict. There are two ways to write this then: 1. As in RFC 6839: "When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045])." 2. As per RFC 7159: "binary" What I am arguing is that the second approach would make more sense. Just like RFC 7159 choose to use "binary" in case of multiple UTF encodings, we should follow the same approach in RFC 6839. If not, then RFC 7159 should have errata pointing back to RFC 6839. Thanks, Yakov On Fri, May 15, 2015 at 9:18 AM, Barry Leiba wrote: > And yet this RFC predates 7159, so how can 7159 be taken to support errata > for this RFC? > > Barry > > > On Friday, May 15, 2015, RFC Errata System > wrote: >> >> The following errata report has been submitted for RFC6839, >> "Additional Media Type Structured Syntax Suffixes". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 >> >> -------------------------------------- >> Type: Technical >> Reported by: Yakov Shafranovich >> >> Section: 3.1 >> >> Original Text >> ------------- >> Encoding considerations: >> >> Per [RFC4627], JSON is allowed to be represented using UTF-8, >> UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit >> compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, >> JSON is binary ([RFC2045]). >> >> Corrected Text >> -------------- >> Encoding considerations: binary as per section 11 of RFC 7159 >> >> Notes >> ----- >> RFC 7159, section 11 specifies that encoding for JSON is binary. >> >> 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. >> >> -------------------------------------- >> RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) >> -------------------------------------- >> Title : Additional Media Type Structured Syntax Suffixes >> Publication Date : January 2013 >> Author(s) : T. Hansen, A. Melnikov >> Category : INFORMATIONAL >> Source : Applications Area Working Group >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> > From nobody Sat May 16 10:19:59 2015 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 EAFBA1A90B8 for ; Sat, 16 May 2015 10:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 PXwT-2DxbuAl for ; Sat, 16 May 2015 10:19:57 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 585961A90B6 for ; Sat, 16 May 2015 10:19:57 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PM1EEC8D6O00QLOA@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 16 May 2015 10:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1431796494; bh=Polv8OJBHg5A/QZaZ8BjzDciBWmXTXwkpPdTQLhWnjw=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=shnsDYzGArkSgOwC6CRJIybvECRkKEassRRwk7nEV2OqiF5IJT2/Zk2k5YWhei+ky t53hsw7vxqrTbfwhED1+MSBTn9rKRiGaZx6Y7UU2rgiCHIiXDtdz79TplElVj27aB/ tgZO/Y+hJiDgvwVb64MN2OLWjTnDlslPWHEIUclM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PLUN66JM8W0000AQ@mauve.mrochek.com>; Sat, 16 May 2015 10:14:51 -0700 (PDT) Message-id: <01PM1EEAH0PM0000AQ@mauve.mrochek.com> Date: Sat, 16 May 2015 10:11:19 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 15 May 2015 09:31:03 -0400" References: <20150515131052.8E76D180092@rfc-editor.org> To: Yakov Shafranovich Archived-At: Cc: Barry Leiba , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 17:19:59 -0000 > [For context, this is originating from the work at the W3C regarding CSV files] > There appears to be an issue about how to specify encoding > considerations for media types that can be encoded in UTF-8, UTF-16 > and UTF-32. For media types, the valid choices are 7-bit, 8-bit and > binary, which would mean that UTF-16 and UTF-32 are binary. For JSON > specifically, since both RFCs define JSON, there is a conflict. > There are two ways to write this then: > 1. As in RFC 6839: > "When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). > When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045])." > 2. As per RFC 7159: > "binary" > What I am arguing is that the second approach would make more sense. And that's a fine opinion to have, but others disagree. The fact remains that both statements are correct; we have always allowed a simple statement of the most general encoding that applies to the type or a more detailed statement of what encodings apply under certain circumstances. The registrations rules allow either approach. I also note that you have yet to identify any sort of conflict here. > Just like RFC 7159 choose to use "binary" in case of multiple UTF > encodings, we should follow the same approach in RFC 6839. If not, > then RFC 7159 should have errata pointing back to RFC 6839. You are free to use whichever approach you wish. But in no case is an erratum appropriate. Ned From nobody Sat May 16 11:19:45 2015 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 C0DCA1A0046 for ; Sat, 16 May 2015 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 pyaDeBRtAQr2 for ; Sat, 16 May 2015 11:19:42 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAA81A003A for ; Sat, 16 May 2015 11:19:42 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YtggS-0001LB-rA; Sat, 16 May 2015 19:19:36 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=conina-wl.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YtggS-0007KK-Ke; Sat, 16 May 2015 19:19:36 +0100 Message-ID: <55578A38.2010609@ninebynine.org> Date: Sat, 16 May 2015 19:19:36 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Tony Hansen , Yakov Shafranovich References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> <555624A6.5050505@att.com> In-Reply-To: <555624A6.5050505@att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Barry Leiba , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 18:19:43 -0000 On 15/05/2015 17:53, Tony Hansen wrote: > There is one more constraint for a file written with utf-8 to use the > encoding of 8bit: the lines are limited to 998 bytes in length (not > counting the CRLF line terminators). See RFC 2045 for details. I think that would be a problem for JSON - there's no way (I know of) to break long text strings over multiple lines, so that restriction would rule out very long string values. So maybe "binary" is the right choice. #g -- From nobody Sat May 16 11:57:03 2015 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 A60401A07BC for ; Sat, 16 May 2015 11:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 NqSF7axX9Qph for ; Sat, 16 May 2015 11:56:59 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 561A71A004D for ; Sat, 16 May 2015 11:56:59 -0700 (PDT) Received: by oift201 with SMTP id t201so104387813oif.3 for ; Sat, 16 May 2015 11:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PTulL6DLQph9oOYBCitkAvkFOt4bUY5ODh/vUKX0pFQ=; b=HpuF9incDkJUZxZazai07PW1Q01YxZpY8RK+d73fwaJs2QBC/6AnfOI6oa9Zwl6Vwx txHzy9vALtgRt0lx0hQoKMUJveEjunoJ1+pIGGtuiryXkW3Yp9Dk0b1jQSw/4h0EjEBZ p6wdU2ZC9L55FbdG4L/PXAfkzPu+OjjZBMcQs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PTulL6DLQph9oOYBCitkAvkFOt4bUY5ODh/vUKX0pFQ=; b=bGNWg43ZcmIT1A3M74sBDZeAo8IMVR/tv/244+QUjs+6DPgcUMOb7h3IwEDdfCosc0 rLqgL2j/nsgt6C6UvEqZb/sHvVJC2ufczIcS42U/0p3A5VmvaQUypezLAR5zHM8UrH7t O1KjcqoaricHhPblZKNFXdjzVDfMbxTLV4Gj5YE4T5Q2Lw1ZyoAy0svjtCgq1WECk6bL oFHKhf5t6zoAYAGtXvyCIxLUxjR0eWzytdgABHxeF0dcw62+XlnTFAkw+DuD7NvD1fqN yep3dFciYrJPtQ0MI+KMs2HTJzCH48/KIA/TzkJy9N6H39i8rozFpt4X/PPAhPaShmbi 5AKA== X-Gm-Message-State: ALoCoQm2l5evPrP6wvlumqopswsjd96AOh1XrH8NB4FGmwKDJM4WrqCxiQDoMff3DuBxpYtM3HA1 MIME-Version: 1.0 X-Received: by 10.60.145.228 with SMTP id sx4mr13349788oeb.79.1431802618821; Sat, 16 May 2015 11:56:58 -0700 (PDT) Received: by 10.60.119.4 with HTTP; Sat, 16 May 2015 11:56:58 -0700 (PDT) Received: by 10.60.119.4 with HTTP; Sat, 16 May 2015 11:56:58 -0700 (PDT) In-Reply-To: <55578A38.2010609@ninebynine.org> References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> <555624A6.5050505@att.com> <55578A38.2010609@ninebynine.org> Date: Sat, 16 May 2015 19:56:58 +0100 Message-ID: From: Dave Cridland To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7b5d30da7bd445051637860e Archived-At: Cc: "tony+sss@maillennium.att.com" , apps-discuss@ietf.org, Barry Leiba , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 18:57:01 -0000 --047d7b5d30da7bd445051637860e Content-Type: text/plain; charset=UTF-8 On 16 May 2015 19:19, "Graham Klyne" wrote: > > On 15/05/2015 17:53, Tony Hansen wrote: >> >> There is one more constraint for a file written with utf-8 to use the >> encoding of 8bit: the lines are limited to 998 bytes in length (not >> counting the CRLF line terminators). See RFC 2045 for details. > > > I think that would be a problem for JSON - there's no way (I know of) to break long text strings over multiple lines, so that restriction would rule out very long string values. So maybe "binary" is the right choice. > Plenty of languages don't use line termination in the same way, and in principle therefore plenty of things might not work as 8-bit. All that means is that once serialized, the application needs to test for long lines and use something different if needs be, like binary or base 64. But that's no different to HTML, or plain text. > #g > -- > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --047d7b5d30da7bd445051637860e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 May 2015 19:19, "Graham Klyne" <gk@ninebynine.org> wrote:
>
> On 15/05/2015 17:53, Tony Hansen wrote:
>>
>> There is one more constraint for a file written with utf-8 to use = the
>> encoding of 8bit: the lines are limited to 998 bytes in length (no= t
>> counting the CRLF line terminators). See RFC 2045 for details.
>
>
> I think that would be a problem for JSON - there's no way (I know = of) to break long text strings over multiple lines, so that restriction wou= ld rule out very long string values.=C2=A0 So maybe "binary" is t= he right choice.
>

Plenty of languages don't use line termination in the sa= me way, and in principle therefore plenty of things might not work as 8-bit= .

All that means is that once serialized, the application need= s to test for long lines and use something different if needs be, like bina= ry or base 64.

But that's no different to HTML, or plain text.

> #g
> --
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/apps-discuss

--047d7b5d30da7bd445051637860e-- From nobody Sat May 16 18:37:41 2015 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 3CCEB1A88BF for ; Sat, 16 May 2015 18:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 OqT7jfP5tMFd for ; Sat, 16 May 2015 18:37:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id A2D161A88C8 for ; Sat, 16 May 2015 18:36:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PM1VQ0E3CW00BEPZ@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 16 May 2015 18:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1431826287; bh=1q3sRaqRPiJwxPXvdj1+wTHYoLeGbwNgEZ/bpLWILRk=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=ewv7dBPn2ryG2VDwZ+AxzZ/UAjdW6J56g/J7d1GQ/VSg27T1h9QZddH3OMU06A0X6 UzwwL95yLiO3S1OHn06jvU1lzQwMiYDD/woghUQVjNQHRxwRQbsVqiDpx1m5NBHWdA m6vAfxE2lsO3JX2jkpAGI0W8lTGBmtA07c2Y0uQM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PLUN66JM8W0000AQ@mauve.mrochek.com>; Sat, 16 May 2015 18:31:25 -0700 (PDT) Message-id: <01PM1VPYNTIY0000AQ@mauve.mrochek.com> Date: Sat, 16 May 2015 18:21:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 16 May 2015 19:19:36 +0100" <55578A38.2010609@ninebynine.org> References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> <555624A6.5050505@att.com> <55578A38.2010609@ninebynine.org> To: Graham Klyne Archived-At: Cc: "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , Barry Leiba , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 01:37:40 -0000 > On 15/05/2015 17:53, Tony Hansen wrote: > > There is one more constraint for a file written with utf-8 to use the > > encoding of 8bit: the lines are limited to 998 bytes in length (not > > counting the CRLF line terminators). See RFC 2045 for details. > I think that would be a problem for JSON - there's no way (I know of) to break > long text strings over multiple lines, so that restriction would rule out very > long string values. So maybe "binary" is the right choice. The same can be said for XML - multimegabyte XML objects containing no line breaks at all are pretty common. And while you can in theory encode text() nodes as CDATA, introducing line breaks into XML isn't something you can just do and leave the semantics unchanged. It's also the case that the line terminators in an XML or JSON object may not always be CRLF, and thus an object may not be compatible with 7bit or 8bit on that basis. But the fact remains that a lot of XML and JSON objects are 8bit or even 7bit compatible. In fact a lot of formats based on XML or JSON are by their nature _always_ 8bit or 7bit compatible. And I see some value in pointing that out where it's appropriate to do so. I suppose we could insist on a full rundown of the issues in every registration. But do you really think this is a useful thing to do, rather than leaving it a judgement call on the part of the person constructing the registration? Ned From nobody Sun May 17 07:25:20 2015 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 B0B831AC43B for ; Sun, 17 May 2015 07:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 UhNmuDkKTjCR for ; Sun, 17 May 2015 07:25:14 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0191AC43A for ; Sun, 17 May 2015 07:25:13 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YtzV5-0005X6-mJ; Sun, 17 May 2015 15:25:08 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=conina-wl.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YtzV5-000738-Fe; Sun, 17 May 2015 15:25:07 +0100 Message-ID: <5558A4C0.9050900@ninebynine.org> Date: Sun, 17 May 2015 15:25:04 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ned Freed References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> <555624A6.5050505@att.com> <55578A38.2010609@ninebynine.org> <01PM1VPYNTIY0000AQ@mauve.mrochek.com> In-Reply-To: <01PM1VPYNTIY0000AQ@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Barry Leiba , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 14:25:18 -0000 On 17/05/2015 02:21, Ned Freed wrote: >> On 15/05/2015 17:53, Tony Hansen wrote: >> > There is one more constraint for a file written with utf-8 to use the >> > encoding of 8bit: the lines are limited to 998 bytes in length (not >> > counting the CRLF line terminators). See RFC 2045 for details. > >> I think that would be a problem for JSON - there's no way (I know of) to break >> long text strings over multiple lines, so that restriction would rule out very >> long string values. So maybe "binary" is the right choice. > > The same can be said for XML - multimegabyte XML objects containing no line > breaks at all are pretty common. And while you can in theory encode text() > nodes as CDATA, introducing line breaks into XML isn't something you can just > do and leave the semantics unchanged. > > It's also the case that the line terminators in an XML or JSON object may not > always be CRLF, and thus an object may not be compatible with 7bit or 8bit on > that basis. > > But the fact remains that a lot of XML and JSON objects are 8bit or even 7bit > compatible. In fact a lot of formats based on XML or JSON are by their nature > _always_ 8bit or 7bit compatible. And I see some value in pointing that out > where it's appropriate to do so. > > I suppose we could insist on a full rundown of the issues in every > registration. But do you really think this is a useful thing to do, rather > than leaving it a judgement call on the part of the person constructing > the registration? No, I don't. I raised the point because I've found that I can construct XML in a way that avoids very long lines (YMMV). But I've noticed in my work with JSON that there is no way to encode long string values over multiple lines (even when the strings themselves are multiline values). Checking back... the encoding considerations for +xml in https://tools.ietf.org/html/rfc6839#section-4.1 call for 7bit or 8bit for UTF-8, and binary for UTF-16/32. Your comment suggests some UTF-8 encoded XML would not satisfy the 8bit constraint on line length, and binary should at least be an option there. And, as noted, https://tools.ietf.org/html/rfc7159#section-11 just says "binary" for JSON, which seems OK to me, but as you say 7bit or 8bit might be OK for some JSON data. (I suspect that in practice these concerns don't arise as 7bit and 8bit are primarily email concerns, and my experience is that JSON is mostly used in HTTP exchanges.) #g -- From nobody Mon May 18 02:26:54 2015 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 AFFCC1A884E for ; Mon, 18 May 2015 02:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_MISMATCH_COM=0.311, SPF_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 Fay0Dc1uiYzA for ; Mon, 18 May 2015 02:26:52 -0700 (PDT) Received: from SP39.realvnc.ltd (mx.realvnc.com [212.69.41.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A59D1A8849 for ; Mon, 18 May 2015 02:26:52 -0700 (PDT) Received: from SP39.realvnc.ltd (10.10.99.12) by SP39.realvnc.ltd (10.10.99.12) with Microsoft SMTP Server (TLS) id 15.0.775.38; Mon, 18 May 2015 10:26:43 +0100 Received: from SP39.realvnc.ltd ([fe80::8456:5aa7:9e32:c70b]) by SP39.realvnc.ltd ([fe80::8456:5aa7:9e32:c70b%13]) with mapi id 15.00.0775.031; Mon, 18 May 2015 10:26:43 +0100 From: Dominic Parkes To: "David_Warden@Dell.com" , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] New Proposed VNC URI Scheme Thread-Index: AdCGK8cK9qAVT8+CR6WcMgiEXLsK6wBF+vhw Date: Mon, 18 May 2015 09:26:42 +0000 Message-ID: <717bf3c1beb149deb7b322f934005e43@SP39.realvnc.ltd> References: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> In-Reply-To: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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 May 2015 09:26:53 -0000 David - thanks for updating your draft. It looks like you've covered most o= r all of the issues we had concerns over. Regarding the open question on the pros and cons of separating external sec= urity from the VNC scheme, and specifically this part: >- It could require clients to register multiple schemes, and if new securi= ty types are used, could lead to an explosion in the number of scheme regis= trations required, as opposed to just adding a new security type in the IAN= A registry. We certainly agree that we'd not like to see a large number of new scheme n= ames registered as a result of new security types being implemented. However - as you are aware (and at the risk of repeating what you've alread= y said) - security types can be negotiated within the RFB protocol's securi= ty type negotiation phase (as per RFC6143 - 7.1.2). I.e.: there's normally = no need to choose them prior to the RFB connection, or at least not at the = viewer side. The only security types that would require another scheme name= would be those needing to be set up prior to/outside RFB, like TLS or SSH = tunnelling - those that are logically separate. As they are separate mechanisms, and outside RFB, I do feel that they ought= to be outside the vanilla VNC URI scheme too. Thanks, Dominic From nobody Mon May 18 13:47:27 2015 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 595F01A037F for ; Mon, 18 May 2015 13:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 hrxsf7-X4Fv1 for ; Mon, 18 May 2015 13:47:23 -0700 (PDT) Received: from ausxipps310.us.dell.com (AUSXIPPS310.us.dell.com [143.166.148.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B82C1A00DB for ; Mon, 18 May 2015 13:47:23 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IQvwcAcJ/I7NBY6FcOxxj6UiUU2ind/PUenmiLRsYRtSXgOAcWAcsI3k fV64OhtqL/WjVChZfM/5pUbyGtL5teo6bEet9Hq3AxRiMW7pAh9rUiI+f QO16RbGClxSgf95FuSpMuxqURYZJQmcHuz0oZqUDdKLh2WWG7fXmh7Kiw c=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1431982043; x=1463518043; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QdMUzPlu/EmM3puL1c48aBphEUAiYc/7fL1b0eLv3F4=; b=jmnSL8COq1UDVycfJbExp6MVp2EB1cqBlqIKafTneZn2xUufC6Bgtd8M cXOH6cRMBpNJzVTaXrUn8Isz5VP3H2N3r3da2pXnDMb7PZkCeGzGnhg3l vZwumjB5nkFGFneJQAm8yWMtlf4eJuSMloSIQdQBvUjzJlQPRvm8r9k6v o=; X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.13,455,1427778000"; d="scan'208";a="181221623" From: To: Date: Mon, 18 May 2015 15:46:47 -0500 Thread-Topic: [apps-discuss] New Proposed VNC URI Scheme Thread-Index: AdCGK8cK9qAVT8+CR6WcMgiEXLsK6wBF+vhwApmPIqA= Message-ID: <2D58682309E75147BB3B286C815CAC7E2AC31D1256@AUSX7MCPS308.AMER.DELL.COM> References: <2D58682309E75147BB3B286C815CAC7E2AC088D4A8@AUSX7MCPS308.AMER.DELL.COM> <717bf3c1beb149deb7b322f934005e43@SP39.realvnc.ltd> In-Reply-To: <717bf3c1beb149deb7b322f934005e43@SP39.realvnc.ltd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New Proposed VNC URI Scheme 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 May 2015 20:47:25 -0000 Dominic, Would you be willing to go along with the addition of a new parameter/regis= try called something like ConnectionChannel? The connection channel could s= pecify one of the new types (TLS/SSH), traditional TCP, or perhaps IPSec. T= he SecurityType parameter would remain an option to constrain the negotiati= on of the traditional RFB security types.=20 Clients could optionally support the Secure Tunnel/SSH channel in the Secur= ityType parameter for backwards compatibility but it would be deprecated. Note I do see some value into allowing the URI to impose constraints on the= security negotiation. If we always negotiate without restriction, an admin= istrator expecting a session with stronger security might inadvertently end= up transmitting credentials/data over a session with weaker or no security= , and perhaps even to a system controlled by an attacker. At least some exi= sting clients will allow the security type to be (perhaps implicitly) speci= fied and return an error if they cannot negotiate that type. It makes sense= to me to extend this to the URI. Thanks, David -----Original Message----- From: Dominic Parkes [mailto:dominic.parkes@realvnc.com]=20 Sent: Monday, May 18, 2015 4:27 AM To: Warden, David; apps-discuss@ietf.org Subject: RE: [apps-discuss] New Proposed VNC URI Scheme David - thanks for updating your draft. It looks like you've covered most o= r all of the issues we had concerns over. Regarding the open question on the pros and cons of separating external sec= urity from the VNC scheme, and specifically this part: >- It could require clients to register multiple schemes, and if new securi= ty types are used, could lead to an explosion in the number of scheme regis= trations required, as opposed to just adding a new security type in the IAN= A registry. We certainly agree that we'd not like to see a large number of new scheme n= ames registered as a result of new security types being implemented. However - as you are aware (and at the risk of repeating what you've alread= y said) - security types can be negotiated within the RFB protocol's securi= ty type negotiation phase (as per RFC6143 - 7.1.2). I.e.: there's normally = no need to choose them prior to the RFB connection, or at least not at the = viewer side. The only security types that would require another scheme name= would be those needing to be set up prior to/outside RFB, like TLS or SSH = tunnelling - those that are logically separate. As they are separate mechanisms, and outside RFB, I do feel that they ought= to be outside the vanilla VNC URI scheme too. Thanks, Dominic From nobody Mon May 18 16:58:29 2015 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 842EA1B2B8C for ; Mon, 18 May 2015 16:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 giOlXUUEobaE for ; Mon, 18 May 2015 16:58:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0672.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:672]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027581B2B89 for ; Mon, 18 May 2015 16:58:24 -0700 (PDT) Received: from DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) by DM2PR02MB384.namprd02.prod.outlook.com (10.141.84.18) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 23:58:08 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 18 May 2015 23:58:07 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0166.017; Mon, 18 May 2015 23:58:07 +0000 From: Larry Masinter To: Graham Klyne , Ned Freed Thread-Topic: Encoding considerations (was Technical Errata for RFC 6839 Thread-Index: AQHQkcZ8c3J0XC0+JU2vaGI6rJpvtw== Date: Mon, 18 May 2015 23:58:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.9.0.150408 authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.184.24.49] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1324; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB384; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1324; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(54356999)(92566002)(68736005)(36756003)(2900100001)(50986999)(101416001)(19580395003)(86362001)(81156007)(97736004)(4001540100001)(4001350100001)(40100003)(15975445007)(102836002)(5001860100001)(5001830100001)(46102003)(122556002)(189998001)(5001770100001)(66066001)(5001960100002)(2656002)(99286002)(87936001)(33656002)(82746002)(64706001)(83506001)(105586002)(83716003)(229853001)(106356001)(77156002)(106116001)(62966003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <80A7395EBD886040999BB87F435A57AA@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 23:58:06.5698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324 X-OriginatorOrg: adobe.com Archived-At: Cc: Barry Leiba , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" Subject: [apps-discuss] Encoding considerations (was Technical Errata for RFC 6839 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 May 2015 23:58:27 -0000 QW0gSSBtaXNzaW5nIHNvbWUgbWFqb3IgaW5zdGFsbGVkIGJhc2Ugd2hpY2ggb25seSBzdXBwb3J0 cyA4Yml0IG9yIDdiaXQ/DQoNCklmIG5vdCwgSeKAmWQgZGVwcmVjYXRlIOKAnEVuY29kaW5nIGNv bnNpZGVyYXRpb25z4oCdIGFuZCBhbGxvdyBpdCB0byBiZSBvbWl0dGVkIGZyb20NCm1lZGlhIHR5 cGUgcmVnaXN0cmF0aW9ucywgdGhlIGFzc3VtcHRpb24gYmVpbmcgdGhhdCDigJxiaW5hcnnigJ0g aXMgdGhlIGRlZmF1bHQuDQoNClRoZSB3aG9sZSDigJhFbmNvZGluZyBjb25zaWRlcmF0aW9uc+KA mSBzZWN0aW9uIHNlZW1zIGxpa2UgYSByZWxpYy4NCg0KDQoNCj4+IEluIGZhY3QgYSBsb3Qgb2Yg Zm9ybWF0cyBiYXNlZCBvbiBYTUwgb3IgSlNPTiBhcmUgYnkgdGhlaXIgbmF0dXJlDQo+PiBfYWx3 YXlzXyA4Yml0IG9yIDdiaXQgY29tcGF0aWJsZS4gQW5kIEkgc2VlIHNvbWUgdmFsdWUgaW4gcG9p bnRpbmcgdGhhdCBvdXQNCj4+IHdoZXJlIGl0J3MgYXBwcm9wcmlhdGUgdG8gZG8gc28NCg0KQ291 bGQgc29tZW9uZSBnaXZlIGFuIGV4YW1wbGUgb2Ygd2hlcmUgaXQgaXMgdmFsdWFibGUgYW5kIG5v dCBqdXN0IGFub3RoZXINCnRoaW5nIHRvIGdldCB3cm9uZz8gQSBwcm90b2NvbCBpbiBjb21tb24g dXNlIHRoYXQgbmVlZHMgN2JpdCBvciA4Yml0IGFuZA0KY2Fu4oCZdCBkbyBiaW5hcnk/IA0KDQpM YXJyeQ0K4oCUDQpodHRwOi8vbGFycnkubWFzaW50ZXIubmV0DQoNCg== From nobody Mon May 18 17:24:10 2015 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 901311B2B61 for ; Mon, 18 May 2015 17:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZSVf-CDwwA_D for ; Mon, 18 May 2015 17:24:08 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9E1B2BC6 for ; Mon, 18 May 2015 17:24:07 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id AFF321DE005; Mon, 18 May 2015 17:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=/7dg1JJmI4SPtG XssdqaxWMjsyo=; b=Hfl+zqMZBTlejgkXz18fR6oMH3jGiQcAn0s6jBWHK2LCf6 3rtEV7R1v211ES7Z8VCJ49+W3nTeAFp7ImS/EK4bZDQHWizm5XDBEy205rU2pwQE hhZFO93IXAfxOB4qlPYZm2wBPQ9BvukCaXo/fycOwkD64BDtZ/klKxeI5FNXo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id E10DD1DE093; Mon, 18 May 2015 17:24:06 -0700 (PDT) Date: Mon, 18 May 2015 19:24:06 -0500 From: Nico Williams To: Larry Masinter Message-ID: <20150519002405.GB9922@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Encoding considerations (was Technical Errata for RFC 6839 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 May 2015 00:24:08 -0000 On Mon, May 18, 2015 at 11:58:06PM +0000, Larry Masinter wrote: > Am I missing some major installed base which only supports 8bit or 7bit? What does "only supports 8-bit" even mean? > >> In fact a lot of formats based on XML or JSON are by their nature > >> _always_ 8bit or 7bit compatible. And I see some value in pointing that out > >> where it's appropriate to do so Encoded JSON texts can contain non-ASCII without escaping, so JSON is not 7-bit compatible, but JSON texts can be re-encoded such that all non-ASCII Unicode codepoints are escaped, so in a sense JSON is 7-bit compatible. But so what? What's the context anyways? Nico -- From nobody Mon May 18 17:34:02 2015 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 0406D1B2C03 for ; Mon, 18 May 2015 17:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 NawyIquwrJ48 for ; Mon, 18 May 2015 17:34:00 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 40FBD1B2C02 for ; Mon, 18 May 2015 17:34:00 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 228502004F31E; Mon, 18 May 2015 17:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=qEZL0DQMqZ+NZo sJL6d1QlBfkZQ=; b=QUpoXV8N2gutxKbbs7Y7U3wxVA5TiMCYGbdKgUStqFIRWL iuXumviDLSsBnPIvDCw3KKUgC+zG5LTeCDimKQIbyv23szvFRjDJTvShQP3yNudO q6VdH7n2/9p4zMFXEc7qmgtK+iK4Q0W+gCwMZSKZ9VytEcQfESIf9LZlR6aOQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id B40582004F31D; Mon, 18 May 2015 17:33:59 -0700 (PDT) Date: Mon, 18 May 2015 19:33:59 -0500 From: Nico Williams To: Larry Masinter Message-ID: <20150519003358.GC9922@localhost> References: <20150519002405.GB9922@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150519002405.GB9922@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Encoding considerations (was Technical Errata for RFC 6839 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 May 2015 00:34:01 -0000 On Mon, May 18, 2015 at 07:24:06PM -0500, Nico Williams wrote: > On Mon, May 18, 2015 at 11:58:06PM +0000, Larry Masinter wrote: > > >> In fact a lot of formats based on XML or JSON are by their nature > > >> _always_ 8bit or 7bit compatible. And I see some value in pointing that out > > >> where it's appropriate to do so > > Encoded JSON texts can contain non-ASCII without escaping, so JSON is not > 7-bit compatible, but JSON texts can be re-encoded such that all > non-ASCII Unicode codepoints are escaped, so in a sense JSON is 7-bit > compatible. But so what? > > What's the context anyways? Never mind, I found the context. Nico -- From nobody Mon May 18 22:42:43 2015 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 2EA761A038B for ; Mon, 18 May 2015 22:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 ehVjwL9_pcTR for ; Mon, 18 May 2015 22:42:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id B17311A0387 for ; Mon, 18 May 2015 22:42:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PM4WWVNIBK00R0S6@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 18 May 2015 22:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1432013857; bh=qLwnVWPbwBlSv1DcdFPNi+xnqAxj54DCmhfv5xYfo6A=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=n9/BO/eUXh4qTvn10YYk4xfuLXoksvZudT2xr9EJD8WVa6+0qjGrjZLgaiXX+CVjf G0nVqfCUkzLe7mG5kB0enkAUethbg1H1ImTZQYFClI3D5F/cfUi8CL+2NdalUa9fIA ap0Hzncw6bie/F1N1a7kIyfvKlw+F5Oi/Yg1ibF4= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PLUN66JM8W0000AQ@mauve.mrochek.com>; Mon, 18 May 2015 22:37:34 -0700 (PDT) Message-id: <01PM4WWTKDD40000AQ@mauve.mrochek.com> Date: Mon, 18 May 2015 22:36:32 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 18 May 2015 23:58:06 +0000" References: To: Larry Masinter Archived-At: Cc: Ned Freed , Barry Leiba , Graham Klyne , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Encoding considerations (was Technical Errata for RFC 6839 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 May 2015 05:42:42 -0000 > Am I missing some major installed base which only supports 8bit or 7bit? It's called email. > If not, I’d deprecate β€œEncoding considerations” and allow it to be omitted from > media type registrations, the assumption being that β€œbinary” is the default. > The whole β€˜Encoding considerations’ section seems like a relic. It's the relic we're using to have this discussion, so... Ned From nobody Tue May 19 23:23:25 2015 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 1CCA61A020A for ; Tue, 19 May 2015 23:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Qo5Mzg5W7asp for ; Tue, 19 May 2015 23:23:21 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7109F1A0169 for ; Tue, 19 May 2015 23:23:21 -0700 (PDT) Received: from host1-145-static.44-85-b.business.telecomitalia.it ([85.44.145.1] helo=dretair11.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1YuxPS-0004P5-MH for apps-discuss@ietf.org; Tue, 19 May 2015 23:23:21 -0700 Message-ID: <555C284E.1030208@berkeley.edu> Date: Wed, 20 May 2015 08:23:10 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: IETF Apps Discuss Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 06:23:23 -0000 hello. we had some discussions at www2015 about a possible HTTP header for exposing a URI's "lifetime". please do not get hung up on any terminology, but the scenarios we discussed included: - a service entering the sunset period and wanting to expose the fact that it is going to stop operating at some point in time. - a service doing archiving and wanting to expose that resources will only be kept until a certain time, and then disposed. - a service that might want to encourage users to check back regularly so that they might implement some strategy to check back periodically and see if the resource is still available or not. we could not think of an exiting HTTP header field for exposing this kind of information. i have two questions: - is there such a header field? - if not, is that something that people find interesting and possibly useful, or do people think that's not needed or even a bad idea? thanks a lot and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue May 19 23:51:34 2015 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 507781B357E for ; Tue, 19 May 2015 23:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 cSnhzhBySGLi for ; Tue, 19 May 2015 23:51:30 -0700 (PDT) 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 9D4D11B35B2 for ; Tue, 19 May 2015 23:51:03 -0700 (PDT) Received: from [192.168.0.11] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9374522E200; Wed, 20 May 2015 02:50:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mark Nottingham In-Reply-To: <555C284E.1030208@berkeley.edu> Date: Wed, 20 May 2015 16:50:57 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net> References: <555C284E.1030208@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Herbert Van de Sompel , IETF Apps Discuss Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 06:51:33 -0000 On 20 May 2015, at 4:23 pm, Erik Wilde wrote: >=20 > hello. >=20 > we had some discussions at www2015 about a possible HTTP header for = exposing a URI's "lifetime". please do not get hung up on any = terminology, but the scenarios we discussed included: Hm. It's come up before, and there's a legitimate distinction between = this (which is about the resource) and Expires (which is about a = specific representation). However, I'm having trouble seeing how it would be useful to clients =E2=80= =94 can you illustrate the use cases a little more fully? E.g.,=20 > - a service entering the sunset period and wanting to expose the fact = that it is going to stop operating at some point in time. What will a client do with that information?=20 Given that this necessarily requires someone to predict the future and = make some level of commitment to that, it may be that the information it = conveys is of very limited use =E2=80=94 i.e., people won't trust it :) > - a service doing archiving and wanting to expose that resources will = only be kept until a certain time, and then disposed. This seems somewhat related to Memento; CC:ing Herbert for his comment / = information. Cheers, > - a service that might want to encourage users to check back regularly = so that they might implement some strategy to check back periodically = and see if the resource is still available or not. >=20 > we could not think of an exiting HTTP header field for exposing this = kind of information. i have two questions: >=20 > - is there such a header field? >=20 > - if not, is that something that people find interesting and possibly = useful, or do people think that's not needed or even a bad idea? >=20 > thanks a lot and cheers, >=20 > dret. >=20 > --=20 > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | >=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 May 20 01:08:42 2015 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 A9F0B1ACAD8 for ; Wed, 20 May 2015 01:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 SVXAByDGjOJj for ; Wed, 20 May 2015 01:08:39 -0700 (PDT) Received: from nerval.la-grange.net (nerval.la-grange.net [128.30.54.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870D01A90B3 for ; Wed, 20 May 2015 01:08:38 -0700 (PDT) Received: from [127.0.0.1] (nerval.la-grange.net [128.30.54.58]) by nerval.la-grange.net (8.14.9/8.14.9) with ESMTP id t4K7xdUL040508; Wed, 20 May 2015 03:59:40 -0400 (EDT) (envelope-from karl@la-grange.net) X-Authentication-Warning: nerval.la-grange.net: Host nerval.la-grange.net [128.30.54.58] claimed to be [127.0.0.1] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E46C02A1-7B96-4892-8E1F-73670F29274A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Karl Dubost In-Reply-To: <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net> Date: Wed, 20 May 2015 10:08:24 +0200 Message-Id: <6B4E5643-23E1-41FC-8F36-E30A5799A31E@la-grange.net> References: <555C284E.1030208@berkeley.edu> <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Herbert Van de Sompel , IETF Apps Discuss Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 08:08:40 -0000 --Apple-Mail=_E46C02A1-7B96-4892-8E1F-73670F29274A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Le 20 mai 2015 =C3=A0 08:50, Mark Nottingham a =C3=A9crit = : > Hm. It's come up before, and there's a legitimate distinction between = this (which is about the resource) and Expires (which is about a = specific representation). Maybe Mark is referring to the discussion (one among probably others): `Until:` HTTP header when the representation will disappear in the = future [1] It seems very similar. [1]: = https://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/thread.html#m= sg1030 -- Karl Dubost =F0=9F=90=84 http://www.la-grange.net/karl/ --Apple-Mail=_E46C02A1-7B96-4892-8E1F-73670F29274A 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 iQEcBAEBCgAGBQJVXED4AAoJEDa+6dB4kHpeOPIH/1B4Aj+CZta968Iz9F6DmLvc 5Hrfa5O/mDRuX/bRSdfc3xBJ/Tu5TbojAJU46oBkZ7NkEZKF6pFSS9G43zSVfLzV 8DxkRbFpEA71lE7UkWwNOrCboKV99HSIwKf2nvyrLWvRXPI4hyccFCbTcoOHAozh m8Rztfvc1UK/dxDL3NzNN8iIg3tFADehRecmdq5yVQPuZ/GFu63a7qudMsa763Ic jAmcbxlMzNKdSQ2q6FZNdVzgEH1YvOtZVF26Wabvfs4pcko+66wAu7JGfxrXx7bA dsYnqSd8R+sZNXrNN9ro2G70cDnd0gDqF+SIwBJCyo+ooK7dPM1buSFbjKCSkT0= =PlDn -----END PGP SIGNATURE----- --Apple-Mail=_E46C02A1-7B96-4892-8E1F-73670F29274A-- From nobody Wed May 20 01:33:11 2015 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 10A921A1A9F for ; Wed, 20 May 2015 01:33:10 -0700 (PDT) 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_40=-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 ymnIBGDKJ1fF for ; Wed, 20 May 2015 01:33:08 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BFD1A0338 for ; Wed, 20 May 2015 01:33:08 -0700 (PDT) Received: from host52-48-static.45-88-b.business.telecomitalia.it ([88.45.48.52] helo=dretair11.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1YuzR4-0007au-Kc; Wed, 20 May 2015 01:33:08 -0700 Message-ID: <555C46AD.2080006@berkeley.edu> Date: Wed, 20 May 2015 10:32:45 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Mark Nottingham References: <555C284E.1030208@berkeley.edu> <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net> In-Reply-To: <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Herbert Van de Sompel , IETF Apps Discuss Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 08:33:10 -0000 hello mark. On 2015-05-20 08:50, Mark Nottingham wrote: > On 20 May 2015, at 4:23 pm, Erik Wilde wrote: >> we had some discussions at www2015 about a possible HTTP header for exposing a URI's "lifetime". please do not get hung up on any terminology, but the scenarios we discussed included: > Hm. It's come up before, and there's a legitimate distinction between this (which is about the resource) and Expires (which is about a specific representation). we were specifically not interested in the caching mechanisms, because like you say, these are about the "lifetime of the resource state", and not about the resource as such. > However, I'm having trouble seeing how it would be useful to clients β€” can you illustrate the use cases a little more fully? so, one thing from my own experience is retention in content management: there are many scenarios where some data needs to be kept around for regulatory reasons for a certain period of time, and then it can and maybe will be removed. that's a fairly large category of scenarios. another one was decommissioning of services: at some point, a decision may be made to take down a service at some point in time. if this could be made visible in the uniform interface, then clients having awareness of this would have an easier time to maybe alert users. for some time, these services may still operate but redirect, and that at some time they may disappear completely. > What will a client do with that information? that depends on the client. services might simply raise alarms that some of the resources they are using are about to disappear. clients such as browsers may alert users that bookmarks are going to expire and encourage users to maybe check for redirects, or archive the page before it disappears. > Given that this necessarily requires someone to predict the future and make some level of commitment to that, it may be that the information it conveys is of very limited use β€” i.e., people won't trust it :) retention and decommissioning are relatively reliable ways to predict the future, but of course in many other cases there is no such mechanism. and of course this is more a hint than anything else, but it may be a hint worth having in the uniform interface. >> - a service doing archiving and wanting to expose that resources will only be kept until a certain time, and then disposed. > This seems somewhat related to Memento; CC:ing Herbert for his comment / information. yes, we did talk about memento. this just seemed to be way more than what we were discussing, and mostly revolve around the scenario of how to expose archived information ("looking into the past"), and not so much about just looking, as you said it, "into the future", thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Wed May 20 01:46:52 2015 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 06C381B35AE for ; Wed, 20 May 2015 01:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bUAo2CNEf7QM for ; Wed, 20 May 2015 01:46:47 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D3A1B35AF for ; Wed, 20 May 2015 01:46:46 -0700 (PDT) Received: from host52-48-static.45-88-b.business.telecomitalia.it ([88.45.48.52] helo=dretair11.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1YuzeF-0004EF-Fq; Wed, 20 May 2015 01:46:45 -0700 Message-ID: <555C494E.9070203@berkeley.edu> Date: Wed, 20 May 2015 10:43:58 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Karl Dubost , IETF Apps Discuss References: <555C284E.1030208@berkeley.edu> <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net> <6B4E5643-23E1-41FC-8F36-E30A5799A31E@la-grange.net> In-Reply-To: <6B4E5643-23E1-41FC-8F36-E30A5799A31E@la-grange.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Mark Nottingham Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 08:46:51 -0000 hello karl. On 2015-05-20 10:08, Karl Dubost wrote: > Le 20 mai 2015 Γ  08:50, Mark Nottingham a Γ©crit : >> Hm. It's come up before, and there's a legitimate distinction between this (which is about the resource) and Expires (which is about a specific representation). > Maybe Mark is referring to the discussion (one among probably others): > `Until:` HTTP header when the representation will disappear in the future [1] > It seems very similar. > [1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/thread.html#msg1030 yes, that's pretty much exactly what we were discussing. it seems like this wasn't going anywhere, but i am sure that the idea has popped up in a variety of forums at some point in time. and we were simply debating whether there was some mechanism, and i said i couldn't think of any. maybe it would be good if there was one for those services that can "predict the future", and for those clients willing to have some faith in that prediction. maybe a human readable text, and/or a link to an "explanation resource" might help with that. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Wed May 20 02:30:58 2015 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 8F4F81A1B3E for ; Wed, 20 May 2015 02:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 BFD9Zfj0ExyJ for ; Wed, 20 May 2015 02:30:54 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id C55541A03A5 for ; Wed, 20 May 2015 02:30:52 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Yv0Kx-0004Wi-k8; Wed, 20 May 2015 10:30:51 +0100 Received: from oerc-dynamic-205.oerc.ox.ac.uk ([129.67.194.205]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yv0Kx-0009H7-K9; Wed, 20 May 2015 10:30:51 +0100 Message-ID: <555C5451.5060804@ninebynine.org> Date: Wed, 20 May 2015 10:30:57 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Erik Wilde , IETF Apps Discuss References: <555C284E.1030208@berkeley.edu> In-Reply-To: <555C284E.1030208@berkeley.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 09:30:56 -0000 On 20/05/2015 07:23, Erik Wilde wrote: > hello. > > we had some discussions at www2015 about a possible HTTP header for exposing a > URI's "lifetime". please do not get hung up on any terminology, but the > scenarios we discussed included: > > - a service entering the sunset period and wanting to expose the fact that it is > going to stop operating at some point in time. > > - a service doing archiving and wanting to expose that resources will only be > kept until a certain time, and then disposed. > > - a service that might want to encourage users to check back regularly so that > they might implement some strategy to check back periodically and see if the > resource is still available or not. > > we could not think of an exiting HTTP header field for exposing this kind of > information. i have two questions: > > - is there such a header field? > > - if not, is that something that people find interesting and possibly useful, or > do people think that's not needed or even a bad idea? Following the subsequent couple of messages, this seems like the goals might be somewhat experimental. For such purposes, I think the desired effect *could* be achieved using a Link: header with a URI link relation; e.g., something like: Link: ; rel=http://linktype.example.org/retentionPolicy/ (If you don't want to store the retention information separately, maybe a data: URI?) I see an advantage of such an approach is that you could experiment with different kinds of retention information by changing the link relation URI, and the approach might play nicely with a wider linked data infrastructure. Just a thought. #g -- From nobody Wed May 20 02:50:33 2015 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 605AB1B35BE for ; Wed, 20 May 2015 02:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 3Drc0JmFKm04 for ; Wed, 20 May 2015 02:50:28 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E591B35BB for ; Wed, 20 May 2015 02:50:27 -0700 (PDT) Received: from host52-48-static.45-88-b.business.telecomitalia.it ([88.45.48.52] helo=dretair11.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Yv0ds-0006Y7-Ig; Wed, 20 May 2015 02:50:27 -0700 Message-ID: <555C58DC.7010309@berkeley.edu> Date: Wed, 20 May 2015 11:50:20 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Graham Klyne , IETF Apps Discuss References: <555C284E.1030208@berkeley.edu> <555C5451.5060804@ninebynine.org> In-Reply-To: <555C5451.5060804@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 09:50:30 -0000 hello graham. On 2015-05-20 11:30, Graham Klyne wrote: > Following the subsequent couple of messages, this seems like the goals > might be somewhat experimental. For such purposes, I think the desired > effect *could* be achieved using a Link: header with a URI link > relation; e.g., something like: > Link: ; > rel=http://linktype.example.org/retentionPolicy/ > (If you don't want to store the retention information separately, maybe > a data: URI?) > I see an advantage of such an approach is that you could experiment with > different kinds of retention information by changing the link relation > URI, and the approach might play nicely with a wider linked data > infrastructure. Just a thought. interesting idea. however, this shifts the problem from the header field to a well-known link relation *and* and well-known representation to even get the date. the reason why we were discussing a header field was also that it would be very clear to find in the uniform interface and very easy to process, and by default, no link would need to be dereferenced to get to the most important piece of information. so the potential header field might look something like this: Sunset: "Mon, 06 Jul 2015 09:00:00 GMT", reason = "We're shutting down for good", reasonURI = http://example.com/goodbye.html and both the human-readable label and the link to the sunset information resource would be optional. this seems to be a bit more explicit than what you're suggesting, but i do agree that in the end, both approaches are representing (almost) the same information. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Wed May 20 03:13:41 2015 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 DF93E1B35D5 for ; Wed, 20 May 2015 03:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] 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 zvoYT9dRp8YV for ; Wed, 20 May 2015 03:13:37 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0A1B35C2 for ; Wed, 20 May 2015 03:13:37 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Yv10J-0005O6-s6; Wed, 20 May 2015 11:13:35 +0100 Received: from oerc-dynamic-205.oerc.ox.ac.uk ([129.67.194.205]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yv10J-00083u-F9; Wed, 20 May 2015 11:13:35 +0100 Message-ID: <555C5E56.3010202@ninebynine.org> Date: Wed, 20 May 2015 11:13:42 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Erik Wilde , IETF Apps Discuss References: <555C284E.1030208@berkeley.edu> <555C5451.5060804@ninebynine.org> <555C58DC.7010309@berkeley.edu> In-Reply-To: <555C58DC.7010309@berkeley.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 10:13:39 -0000 On 20/05/2015 10:50, Erik Wilde wrote: > hello graham. > > On 2015-05-20 11:30, Graham Klyne wrote: >> Following the subsequent couple of messages, this seems like the goals >> might be somewhat experimental. For such purposes, I think the desired >> effect *could* be achieved using a Link: header with a URI link >> relation; e.g., something like: >> Link: ; >> rel=http://linktype.example.org/retentionPolicy/ >> (If you don't want to store the retention information separately, maybe >> a data: URI?) >> I see an advantage of such an approach is that you could experiment with >> different kinds of retention information by changing the link relation >> URI, and the approach might play nicely with a wider linked data >> infrastructure. Just a thought. > > interesting idea. however, this shifts the problem from the header field to a > well-known link relation *and* and well-known representation to even get the > date. the reason why we were discussing a header field was also that it would be > very clear to find in the uniform interface and very easy to process, and by > default, no link would need to be dereferenced to get to the most important > piece of information. so the potential header field might look something like this: > > Sunset: "Mon, 06 Jul 2015 09:00:00 GMT", reason = "We're shutting down for > good", reasonURI = http://example.com/goodbye.html > > and both the human-readable label and the link to the sunset information > resource would be optional. this seems to be a bit more explicit than what > you're suggesting, but i do agree that in the end, both approaches are > representing (almost) the same information. Fair enough. I thought it might be interesting to see how close to this one might get with a Link: header: Link: ,rel=http://linktype.example.com/sunset It's clearly not as pretty, but I can't tell how important that might be. #g -- From nobody Wed May 20 07:42:43 2015 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 265901A8789 for ; Wed, 20 May 2015 07:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 inClR-EKIPvZ for ; Wed, 20 May 2015 07:42:40 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 EFA031A8787 for ; Wed, 20 May 2015 07:42:39 -0700 (PDT) Received: by oica37 with SMTP id a37so37637547oic.0 for ; Wed, 20 May 2015 07:42:39 -0700 (PDT) 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:content-transfer-encoding; bh=26bvRDDhEcGW+5uSDSn4WWBH7AztjIFhht2eLiqbMYo=; b=zA4p8h7zTWF7zRkwY5FUKCwHy0IjU5D7rXkSrf82IGchvp1S4zG//ngHnrpF/rKzcc +M03zdRaGb/hpl2fSKEUctkmw6vNOVRQYpJfiWpLRdzRWbUk/zo5Yijyfz0EYGXySleJ kTVbqXkKXU+fHaWZTtmIIAKNz3FQ+IMrvFR8vFOrmlt/64JzEVTcbnD7/rfhH1R0Zbr3 itLqeIGZrg3IFch9SLUxZZPVUawskP5kcMo8FRsFK6xYawtvJ6ZmzdxV1YQ+fVMxDYOc 7BLCE6jTMMauTY1EFVWMNSkox/eJKiaul/haz4NEFgUZMZ09w40kZzqcZlKK9rp9+lL8 QJGg== MIME-Version: 1.0 X-Received: by 10.60.39.65 with SMTP id n1mr29204075oek.31.1432132959327; Wed, 20 May 2015 07:42:39 -0700 (PDT) Received: by 10.202.192.137 with HTTP; Wed, 20 May 2015 07:42:39 -0700 (PDT) In-Reply-To: <555C46AD.2080006@berkeley.edu> References: <555C284E.1030208@berkeley.edu> <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net> <555C46AD.2080006@berkeley.edu> Date: Wed, 20 May 2015 08:42:39 -0600 Message-ID: From: Herbert Van de Sompel To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mark Nottingham , Herbert Van de Sompel , IETF Apps Discuss Subject: Re: [apps-discuss] HTTP header field for "URI lifetime" 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 May 2015 14:42:42 -0000 hi, (Thanks for cc-ing me) Rather interesting. Indeed, it is not directly related to Memento; the Memento-Datetime header is for expressing that a resource has been "frozen" at the datetime that is conveyed as the header value, i.e. it entails a promise that the resource will not change beyond the expressed datetime. The way I understand what you are discussing, this is about a header that indicates that a URI will no longer be existent starting at a certain date, ie past that date one can expect a 404 or similar bad news. But there is a relation with a possible web archiving use case: if a web archiving client comes across a URI-R that indicates its extinction datetime, then the client could make it a priority to crawl that URI-R and archive its representation at URI-M in a web archive. Using Memento, URI-M would then have a HTTP link with relation type "original" pointing at URI-R. Even when URI-R is gone, using Memento, URI-R could still be used to access archived snapshots of URI-R such as URI-M. Magic :-) I am thinking that this could be particularly useful for shortened URIs, many of which - as we know - aren't long lasting and the minters of those URIs are very much aware of that. If these minters would convey their short term URI retention strategy using a header, then applications that consume/mine tweets and resources linked in tweets (there's a lot of research in this realm) could optimize their data collecting strategy by taking the URI expiration date into account. Cheers Herbert On Wed, May 20, 2015 at 2:32 AM, Erik Wilde wrote: > hello mark. > > On 2015-05-20 08:50, Mark Nottingham wrote: >> >> On 20 May 2015, at 4:23 pm, Erik Wilde wrote: >>> >>> we had some discussions at www2015 about a possible HTTP header for >>> exposing a URI's "lifetime". please do not get hung up on any terminolo= gy, >>> but the scenarios we discussed included: >> >> Hm. It's come up before, and there's a legitimate distinction between th= is >> (which is about the resource) and Expires (which is about a specific >> representation). > > > we were specifically not interested in the caching mechanisms, because li= ke > you say, these are about the "lifetime of the resource state", and not ab= out > the resource as such. > >> However, I'm having trouble seeing how it would be useful to clients =E2= =80=94 can >> you illustrate the use cases a little more fully? > > > so, one thing from my own experience is retention in content management: > there are many scenarios where some data needs to be kept around for > regulatory reasons for a certain period of time, and then it can and mayb= e > will be removed. that's a fairly large category of scenarios. > > another one was decommissioning of services: at some point, a decision ma= y > be made to take down a service at some point in time. if this could be ma= de > visible in the uniform interface, then clients having awareness of this > would have an easier time to maybe alert users. for some time, these > services may still operate but redirect, and that at some time they may > disappear completely. > >> What will a client do with that information? > > > that depends on the client. services might simply raise alarms that some = of > the resources they are using are about to disappear. clients such as > browsers may alert users that bookmarks are going to expire and encourage > users to maybe check for redirects, or archive the page before it > disappears. > >> Given that this necessarily requires someone to predict the future and >> make some level of commitment to that, it may be that the information it >> conveys is of very limited use =E2=80=94 i.e., people won't trust it :) > > > retention and decommissioning are relatively reliable ways to predict the > future, but of course in many other cases there is no such mechanism. and= of > course this is more a hint than anything else, but it may be a hint worth > having in the uniform interface. > >>> - a service doing archiving and wanting to expose that resources will >>> only be kept until a certain time, and then disposed. >> >> This seems somewhat related to Memento; CC:ing Herbert for his comment / >> information. > > > yes, we did talk about memento. this just seemed to be way more than what= we > were discussing, and mostly revolve around the scenario of how to expose > archived information ("looking into the past"), and not so much about jus= t > looking, as you said it, "into the future", > > thanks and cheers, > > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | --=20 Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ =3D=3D From nobody Wed May 20 08:43:57 2015 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 E1B5B1A88F7; Wed, 20 May 2015 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Icf0GZtg8Hwv; Wed, 20 May 2015 08:43:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A1EB81A88FA; Wed, 20 May 2015 08:43:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 43B40180478; Wed, 20 May 2015 08:42:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150520154202.43B40180478@rfc-editor.org> Date: Wed, 20 May 2015 08:42:02 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7565 on The 'acct' URI Scheme 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 May 2015 15:43:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7565 Title: The 'acct' URI Scheme Author: P. Saint-Andre Status: Standards Track Stream: IETF Date: May 2015 Mailbox: peter@andyet.com Pages: 8 Characters: 18244 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-acct-uri-07.txt URL: https://www.rfc-editor.org/info/rfc7565 DOI: http://dx.doi.org/10.17487/RFC7565 This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 20 13:46:47 2015 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 58F1B1A90DB for ; Wed, 20 May 2015 13:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 CDVom7HTeys8 for ; Wed, 20 May 2015 13:46:45 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0511A90DD for ; Wed, 20 May 2015 13:46:45 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 2D3752005E808; Wed, 20 May 2015 13:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=P4T9zNVVoyRY0n tIDJ0XgwEd+1I=; b=pZG/wVtfOyz0BDUCaLKiiMZUPsEqB9CizIhUmHceX936xj pmIObAl+yvhEzZDFXkO9h26FQItkDl1t1OEqTQW0ogqbTGo8xdlv2N54BayN5nAn 8N9of+3bORY4pmNCN1+410JDbaSocGZFBpX6RSoQgH4ylxVdBg9uJURAY+NAA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 898912005E806; Wed, 20 May 2015 13:46:43 -0700 (PDT) Date: Wed, 20 May 2015 15:46:42 -0500 From: Nico Williams To: Graham Klyne Message-ID: <20150520204641.GH19183@localhost> References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> <555624A6.5050505@att.com> <55578A38.2010609@ninebynine.org> <01PM1VPYNTIY0000AQ@mauve.mrochek.com> <5558A4C0.9050900@ninebynine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5558A4C0.9050900@ninebynine.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Barry Leiba , Ned Freed , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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 May 2015 20:46:46 -0000 On Sun, May 17, 2015 at 03:25:04PM +0100, Graham Klyne wrote: > I raised the point because I've found that I can construct XML in a > way that avoids very long lines (YMMV). But I've noticed in my work > with JSON that there is no way to encode long string values over > multiple lines (even when the strings themselves are multiline > values). +1. Binary is the correct thing to say for any JSON-using protocol unless the schema used allows one to ensure that UTF-8-encoded JSON texts have "lines" no longer than 1000 bytes -- but why bother? > And, as noted, https://tools.ietf.org/html/rfc7159#section-11 just > says "binary" for JSON, which seems OK to me, but as you say 7bit or > 8bit might be OK for some JSON data. Right, and that's true, but not often possible to ensure. > (I suspect that in practice these concerns don't arise as 7bit and > 8bit are primarily email concerns, and my experience is that JSON is > mostly used in HTTP exchanges.) Agreed. This is one of those how many angels can dance on a pin head kind of debates. The erratum could be accepted or rejected, and it wouldn't make a difference. Since the MIME registration exists outside the RFC, I think it's better to correct it than to not, and note that it's not necessary to correct the RFC to correct the registration. Add some text discussing the interop considerations if you like. Nico -- From nobody Sat May 23 15:54:21 2015 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 C4CD81A88E0 for ; Sat, 23 May 2015 15:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1BGZij3b945y for ; Sat, 23 May 2015 15:54:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0067.outbound.protection.outlook.com [65.55.169.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DD31A88F3 for ; Sat, 23 May 2015 15:54:15 -0700 (PDT) Received: from DM2PR02MB1323.namprd02.prod.outlook.com (25.161.142.22) by DM2PR02MB462.namprd02.prod.outlook.com (10.141.88.15) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sat, 23 May 2015 22:54:14 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1323.namprd02.prod.outlook.com (25.161.142.22) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sat, 23 May 2015 22:54:12 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0166.017; Sat, 23 May 2015 22:54:12 +0000 From: Larry Masinter To: Nico Williams , Graham Klyne Thread-Topic: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) Thread-Index: AQHQjxDY3b/TVMOMRkevrilc2B5EnJ19BSuAgAA3Y1aAAAHrgIAAAt4AgAGqQQCAAHpsxIAA1mIAgAUhnwCABGVCgA== Date: Sat, 23 May 2015 22:54:10 +0000 Message-ID: <5FE7CED7-8DF6-43C5-8736-67DA281CAD45@adobe.com> References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> <555624A6.5050505@att.com> <55578A38.2010609@ninebynine.org> <01PM1VPYNTIY0000AQ@mauve.mrochek.com> <5558A4C0.9050900@ninebynine.org> <20150520204641.GH19183@localhost> In-Reply-To: <20150520204641.GH19183@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150508 authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.184.24.49] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1323; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DM2PR02MB1323; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1323; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(106356001)(2950100001)(62966003)(122556002)(40100003)(77156002)(66066001)(15975445007)(36756003)(81156007)(102836002)(2900100001)(33656002)(68736005)(50986999)(82746002)(64706001)(97736004)(46102003)(4001540100001)(76176999)(83716003)(19580395003)(86362001)(92566002)(2656002)(93886004)(101416001)(5001960100002)(189998001)(54356999)(106116001)(105586002)(4001350100001)(83506001)(5001830100001)(99286002)(87936001)(5001860100001)(5001770100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1323; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <270E3920F4818E408D6EEAA80A572209@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2015 22:54:11.0146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1323 X-OriginatorOrg: adobe.com Archived-At: Cc: Barry Leiba , Ned Freed , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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, 23 May 2015 22:54:19 -0000 VGhlIGVycm9yIHJlcG9ydGVkIHNob3VsZCBiZSBhY2NlcHRlZCBhcyBhbiBlcnJhdHVtIG9uIFJG QzY5Mzkgd2hpY2gNCnNheXM6DQoNCiJXaGVuIEpTT04gaXMgd3JpdHRlbiBpbiBVVEYtOCwgSlNP TiBpcyA4Yml0IGNvbXBhdGlibGUgKFtSRkMyMDQ1XSkuDQpXaGVuIEpTT04gaXMgd3JpdHRlbiBp biBVVEYtMTYgb3IgVVRGLTMyLCBKU09OIGlzIGJpbmFyeSAoW1JGQzIwNDVdKS4iDQoNCg0Kd2hp Y2ggaXMgZmFsc2UuIFJGQyAyMDQ1IGRlZmluZXMgOGJpdCBkYXRhDQoNCiAgICI4Yml0IGRhdGEi IHJlZmVycyB0byBkYXRhIHRoYXQgaXMgYWxsIHJlcHJlc2VudGVkIGFzIHJlbGF0aXZlbHkNCiAg ICBzaG9ydCBsaW5lcyB3aXRoIDk5OCBvY3RldHMgb3IgbGVzcyBiZXR3ZWVuIENSTEYgbGluZSBz ZXBhcmF0aW9uDQogICAgc2VxdWVuY2VzIFtSRkMtODIxXSksIGJ1dCBvY3RldHMgd2l0aCBkZWNp bWFsIHZhbHVlcyBncmVhdGVyIHRoYW4gMTI3DQogICAgbWF5IGJlIHVzZWQuICBBcyB3aXRoICI3 Yml0IGRhdGEiIENSIGFuZCBMRiBvY3RldHMgb25seSBvY2N1ciBhcyBwYXJ0DQogICAgb2YgQ1JM RiBsaW5lIHNlcGFyYXRpb24gc2VxdWVuY2VzIGFuZCBubyBOVUxzIGFyZSBhbGxvd2VkLg0KDQoN Cg0KYnV0IFVURi04IEpTT04gbWF5IHdlbGwgY29udGFpbiBzZXF1ZW5jZXMgdGhhdCBpbmNsdWRl IENSIG9yIExGDQpvY3RldHMgbm90IHBhcnQgb2YgQ1JMRiBzZXF1ZW5jZXMsIGFuZCBtYXkgYWxz byBjb250YWluIG1vcmUgdGhhbg0KOTk4IG9jdGV0cyBiZXR3ZWVuIENSTEYgbGluZSBzZXBhcmF0 aW9uIHNlcXVlbmNlcy4NCg0KRm9sbG93aW5nIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZXJyYXRhLXByb2Nlc3NpbmcuaHRtbDoNCg0KSXTigJlzIGEgbWF0dGVyIG9mIGp1ZGdt ZW50IHdoZXRoZXIgdGhpcyBlcnJvciBDT1VMRCBjYXVzZSBpbXBsZW1lbnRhdGlvbg0Kb3IgZGVw bG95bWVudCBwcm9ibGVtcyAoc29tZW9uZSBhc3N1bWluZyB0aGV5IGNvdWxkIHVzZSA4Yml0IGZv ciBhcmJpdHJhcnkNCnV0ZjggSlNPTj8pIGJ1dCBpdCBzZWVtcyBwb3NzaWJsZS4gDQoNClRoZSBj aGFuZ2UgcHJvcG9zZWQgbWFrZXMgYSByZWZlcmVuY2UgdG8gUkZDIDcxNTkgd2hpY2ggaXMgdW5u ZWNlc3NhcnksDQppdCBjb3VsZCBqdXN0IHNheSDigJxFbmNvZGluZyBDb25zaWRlcmF0aW9uczog YmluYXJ54oCdLg0KDQpJdCBzZWVtcyBsaWtlIGEgdGF1dG9sb2d5IHRvIGhhdmUgYSBtZWRpYSB0 eXBlIHdoaWNoIGluIGdlbmVyYWwNCnJlcXVpcmVzIOKAnGJpbmFyeeKAnSBidXQgdG8gbm90ZSDi gJxJZiBhbiBpbnN0YW5jZSBvZiB0aGUgbWVkaWEgdHlwZQ0KbWVldHMgdGhlIHJlcXVpcmVtZW50 cyBmb3IgN2JpdCBvciA4Yml0IHRyYW5zcG9ydCB0aGVuIDdiaXQgb3INCjhiaXQgZW5jb2Rpbmcg aXMgY29tcGF0aWJsZeKAnSwgc2luY2UgeW91IGNvdWxkIHNheSB0aGF0IGZvciBhbnkNCmJpbmFy eSBtZWRpYSB0eXBlLg0KDQogUkZDIDY4Mzgg4oCcTWVkaWEgVHlwZSBSZWdpc3RyYXRpb27igJ0g c2VjdGlvbiA0Ljggc2F5cw0KIlBvc3NpYmxlIHZhbHVlcyBvZiB0aGlzIFtFbmNvZGluZyBDb25z aWRlcmF0aW9uc10gZmllbGQgYXJlOuKAnQ0KDQphbmQgbGlzdHMgN2JpdCwgOGJpdCwgYmluYXJ5 LCBmcmFtZWQgYXMgdGhlIHBvc3NpYmxlIHZhbHVlcy4NCg0KTGFycnkNCuKAlA0KaHR0cDovL2xh cnJ5Lm1hc2ludGVyLm5ldA0KDQoNCg0K From nobody Sun May 24 00:05:45 2015 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 DD6271A879A for ; Sun, 24 May 2015 00:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 N27GES7Yypev for ; Sun, 24 May 2015 00:05:32 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1bn0103.outbound.protection.outlook.com [134.170.140.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402A71A8794 for ; Sun, 24 May 2015 00:03:10 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [192.168.1.4] (58.89.24.97) by KAWPR01MB0130.jpnprd01.prod.outlook.com (25.161.27.11) with Microsoft SMTP Server (TLS) id 15.1.172.22; Sun, 24 May 2015 07:03:05 +0000 Message-ID: <556177A5.1030909@it.aoyama.ac.jp> Date: Sun, 24 May 2015 16:03:01 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Larry Masinter , Nico Williams , Graham Klyne References: <20150515131052.8E76D180092@rfc-editor.org> <55562081.6070504@att.com> <555624A6.5050505@att.com> <55578A38.2010609@ninebynine.org> <01PM1VPYNTIY0000AQ@mauve.mrochek.com> <5558A4C0.9050900@ninebynine.org> <20150520204641.GH19183@localhost> <5FE7CED7-8DF6-43C5-8736-67DA281CAD45@adobe.com> In-Reply-To: <5FE7CED7-8DF6-43C5-8736-67DA281CAD45@adobe.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [58.89.24.97] X-ClientProxiedBy: TY1PR01CA0026.jpnprd01.prod.outlook.com (25.164.162.136) To KAWPR01MB0130.jpnprd01.prod.outlook.com (25.161.27.11) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0130; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(520002)(3002001); SRVR:KAWPR01MB0130; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0130; X-Forefront-PRVS: 058637CA05 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(6049001)(479174004)(199003)(189002)(24454002)(5001830100001)(77096005)(68736005)(77156002)(93886004)(50466002)(5001860100001)(80316001)(74482002)(122386002)(4001350100001)(81156007)(97736004)(40100003)(4001540100001)(46102003)(5001960100002)(59896002)(2950100001)(189998001)(117156001)(62966003)(5001770100001)(99136001)(65816999)(47776003)(54356999)(87266999)(66066001)(65956001)(65806001)(64706001)(50986999)(76176999)(101416001)(64126003)(85202003)(106356001)(105586002)(86362001)(83506001)(92566002)(33656002)(23676002)(42186005)(87976001)(85182001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0130; H:[192.168.1.4]; 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-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2015 07:03:05.7307 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0130 Archived-At: Cc: Barry Leiba , Ned Freed , "tony+sss@maillennium.att.com" , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367) 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, 24 May 2015 07:05:37 -0000 On 2015/05/24 07:54, Larry Masinter wrote: > It seems like a tautology to have a media type which in general > requires β€œbinary” but to note β€œIf an instance of the media type > meets the requirements for 7bit or 8bit transport then 7bit or > 8bit encoding is compatible”, since you could say that for any > binary media type. Well, there are media types where although only binary is good enough to cover every case, many or even most cases are covered by 8bit or even 7bit. The JSON-related types are definitely in this category, and some of the types with a +json suffix may even be 7bit in all cases. On the other hand, there are types where the vast majority of instances won't work with 7bit, and most also won't work with 8bit. Image formats and video formats will be in this category. Using the text that you cite above makes sense for the former category, but not for the later. Regards, Martin. From nobody Tue May 26 10:43:30 2015 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 6416D1A00FD for ; Tue, 26 May 2015 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 IUIuyZIb9K7R for ; Tue, 26 May 2015 10:43:23 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 5DE181A0040 for ; Tue, 26 May 2015 10:43:23 -0700 (PDT) Received: by wghq2 with SMTP id q2so103909918wgh.1 for ; Tue, 26 May 2015 10:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+Tfu3rXjLCV5k1hp1oUZ5+gQVtlUmdbcCwmKRfiC57U=; b=vI5CFDfnyZRrT9w35UO3f9TQSfrRvxjGXKoeLbIvVVQmZ2xrDHY4n35VRvDr8ehlAD NYO9/I1B/T0g0UcKOPRK/1bcpbNacyI85aGfiF/V1nyfsuWa2ejlr5CaDJMo3jPXupu/ yYbveTMGdSrMrHuywHww4V3JNPmI71VcJiMwZyQrrI+xNO8225PbmNhHBso1DtZIagfa kvNLUQJUJEs8yVgsCvNh9SKrPIo1aRjHPFPFToUJ2K1/dpxZxfax5JOVT8GQOvDWp70z t+Ijr8yOQwEMQErFXtIWD0OIkqkeaFhJowoHIexXlNmLPomfuftB/LQ1c6V+Uq31R5Hq YLIw== MIME-Version: 1.0 X-Received: by 10.180.221.9 with SMTP id qa9mr4534937wic.52.1432662202167; Tue, 26 May 2015 10:43:22 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Tue, 26 May 2015 10:43:21 -0700 (PDT) Date: Tue, 26 May 2015 10:43:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1134ccc0a4b7350516ffa98e Archived-At: Subject: [apps-discuss] Gopher work and stream selection 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, 26 May 2015 17:43:27 -0000 --001a1134ccc0a4b7350516ffa98e Content-Type: text/plain; charset=UTF-8 Colleagues, We'd like to get a feel for rough consensus about what path the proposed Gopher document work should take through to RFC publication. The question we'd like you to consider is: Is there enough technical work to do here, and enough support for doing it (i.e., willing to contribute text, reviews, shepherding), to have it done via the IETF stream, or is the Independent Submission route preferable? Constructive replies only, please. Also, please leave the question of which working group is the right place for it until later; for now, we only want to consider the basic question of IETF vs. ISE. Thanks, -MSK, APPSAWG co-chair --001a1134ccc0a4b7350516ffa98e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

We'd= like to get a feel for rough consensus about what path the proposed Gopher= document work should take through to RFC publication.=C2=A0 The question w= e'd like you to consider is:

Is there enough technical wor= k to do here, and enough support for doing it (i.e., willing to contribute = text, reviews, shepherding), to have it done via the IETF stream, or is the= Independent Submission route preferable?

Constructive replies= only, please.=C2=A0 Also, please leave the question of which working group= is the right place for it until later; for now, we only want to consider t= he basic question of IETF vs. ISE.

Thanks,
-MSK, APPS= AWG co-chair

--001a1134ccc0a4b7350516ffa98e-- From nobody Tue May 26 11:16:14 2015 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 D732D1B2C7B for ; Tue, 26 May 2015 11:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 jAUbWjvyggwq for ; Tue, 26 May 2015 11:16:12 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D473E1B2C9F for ; Tue, 26 May 2015 11:16:05 -0700 (PDT) Received: (qmail 72094 invoked from network); 26 May 2015 18:16:12 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 26 May 2015 18:16:12 -0000 Date: 26 May 2015 18:15:42 -0000 Message-ID: <20150526181542.15129.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Gopher work and stream selection 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, 26 May 2015 18:16:13 -0000 >Is there enough technical work to do here, Maybe and enough support for doing it >(i.e., willing to contribute text, reviews, shepherding), to have it done >via the IETF stream, or is the Independent Submission route preferable? Independent, please. Gopher was swell, but it is only of interest now to historians and fans of retrocomputing. R's, John From nobody Tue May 26 11:34:03 2015 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 D31561B2FD6 for ; Tue, 26 May 2015 11:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 jaCSDO2nYr1p for ; Tue, 26 May 2015 11:34:00 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 2A5C01B2F63 for ; Tue, 26 May 2015 11:34:00 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so105111792wgb.3 for ; Tue, 26 May 2015 11:33:58 -0700 (PDT) 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=IhC8kGzCCuTXup4SAE5IhyyXV4aYfl9jB7CawWQ8WIk=; b=HgJt4go/HBw/rQSP3JVXW/QdYU9pgnJq0AdcdkeaO8ux67CzoqgeXw/j4t77kUSRCZ Y31z1o579sAfFdiFeveIfZ46sCALSUiatwlQuV4WXIUHUo5SYEz+kOaDPDF6lwz+JQlc TY/I2Kj48gVsDV/JqN1nVTYLs0Wtsg3avSRQ9LOGfSYwFLkYyoXQimGsN06k6rE6JQ+Y mxgkP59sGFkVshGh2PgykBnJkbJS4I7BBP567GcO4YTtv4vDs4gpMXqfYnxz/EtDrEL8 q+lOoD8jix9GL5tM8eUfZP+5j0EE+0qx6MKuaTiUtR2dPTjsQCI/bOeYrFNsURmZpKja j/6A== MIME-Version: 1.0 X-Received: by 10.194.189.4 with SMTP id ge4mr32131323wjc.111.1432665238748; Tue, 26 May 2015 11:33:58 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Tue, 26 May 2015 11:33:58 -0700 (PDT) In-Reply-To: <20150526181542.15129.qmail@ary.lan> References: <20150526181542.15129.qmail@ary.lan> Date: Tue, 26 May 2015 11:33:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7bf0c0a0a345920517005e73 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 26 May 2015 18:34:02 -0000 --047d7bf0c0a0a345920517005e73 Content-Type: text/plain; charset=UTF-8 On Tue, May 26, 2015 at 11:15 AM, John Levine wrote: > >Is there enough technical work to do here, > > Maybe > > and enough support for doing it > >(i.e., willing to contribute text, reviews, shepherding), to have it done > >via the IETF stream, or is the Independent Submission route preferable? > > Independent, please. Gopher was swell, but it is only of interest now > to historians and fans of retrocomputing. > Let's be careful (and, as I asked, constructive) here. There is a claim to the contrary before us, as John Klensin and Patrik have pointed out; specifically, that there is indeed a community of people interested in developing Gopher and not simply documenting it. As you pointed out earlier, we do want to be inclusive, so I don't think "fans of retrocomputing" is a complete basis to deflect to the Independent Stream. The more salient point to me is whether there's enough support for doing so in the IETF stream. Is that community committed to the idea of doing that work in our context, and/or are there enough people in the APPS area to contribute to and support the work through the IETF process? -MSK --047d7bf0c0a0a345920517005e73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 26, 2015 at 11:15 AM, John Levine <johnl@taugh.= com> wrote:
>Is there enough technical = work to do here,

Maybe

=C2=A0and enough support for doing it
>(i.e., willing to contribute text, reviews, shepherding), to have it do= ne
>via the IETF stream, or is the Independent Submission route preferable?=

Independent, please.=C2=A0 Gopher was swell, but it is only of inter= est now
to historians and fans of retrocomputing.

Let's be careful (and, as I asked, constructive) here.=C2=A0 There i= s a claim to the contrary before us, as John Klensin and Patrik have pointe= d out; specifically, that there is indeed a community of people interested = in developing Gopher and not simply documenting it.

As yo= u pointed out earlier, we do want to be inclusive, so I don't think &qu= ot;fans of retrocomputing" is a complete basis to deflect to the Indep= endent Stream.=C2=A0 The more salient point to me is whether there's en= ough support for doing so in the IETF stream.=C2=A0 Is that community commi= tted to the idea of doing that work in our context, and/or are there enough= people in the APPS area to contribute to and support the work through the = IETF process?

-MSK
--047d7bf0c0a0a345920517005e73-- From nobody Tue May 26 11:42:21 2015 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 51A8F1B2FF4 for ; Tue, 26 May 2015 11:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 1bzgywaNBq1v for ; Tue, 26 May 2015 11:42:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDCF1B2FEF for ; Tue, 26 May 2015 11:42:19 -0700 (PDT) Received: from [192.168.1.141] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4QIgFNM015019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 11:42:18 -0700 Message-ID: <5564BE84.5040108@dcrocker.net> Date: Tue, 26 May 2015 11:42:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Levine , apps-discuss@ietf.org References: <20150526181542.15129.qmail@ary.lan> In-Reply-To: <20150526181542.15129.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 26 May 2015 11:42:19 -0700 (PDT) Archived-At: Subject: Re: [apps-discuss] Gopher work and stream selection X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 18:42:20 -0000 On 5/26/2015 11:15 AM, John Levine wrote: >> (i.e., willing to contribute text, reviews, shepherding), to have it done >> >via the IETF stream, or is the Independent Submission route preferable? > Independent, please. Gopher was swell, but it is only of interest now > to historians and fans of retrocomputing. Having an IETF working group produce an Independent Stream doc is more than odd. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 26 11:43:22 2015 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 51ADC1A0120 for ; Tue, 26 May 2015 11:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 iOKYLsTc_yA8 for ; Tue, 26 May 2015 11:43:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD6D1A011D for ; Tue, 26 May 2015 11:43:20 -0700 (PDT) Received: from [192.168.1.141] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4QIhFKv015108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 11:43:18 -0700 Message-ID: <5564BEC0.2090802@dcrocker.net> Date: Tue, 26 May 2015 11:43:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , John Levine References: <20150526181542.15129.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 26 May 2015 11:43:18 -0700 (PDT) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 18:43:21 -0000 On 5/26/2015 11:33 AM, Murray S. Kucherawy wrote: > There is a claim to the contrary before us, as John Klensin and Patrik > have pointed out; specifically, that there is indeed a community of > people interested in developing Gopher and not simply documenting it. Other than assertions that they exist, I haven't noticed their direct advocacy for particular work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 26 12:38:35 2015 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 7C37C1A8769 for ; Tue, 26 May 2015 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.763 X-Spam-Level: X-Spam-Status: No, score=0.763 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, WEIRD_PORT=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 2woJfNSf9HEm for ; Tue, 26 May 2015 12:38:33 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD7E1A8729 for ; Tue, 26 May 2015 12:38:32 -0700 (PDT) Received: (qmail 85246 invoked from network); 26 May 2015 19:38:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14cfd.5564cbbe.k1505; bh=lFHGfMjz+/TT92uCQOyVgD8S1rt80MZB2D9eO/p/TPw=; b=QDBXVbfZbBN80FUINkrTtaAIvWpX2/83FjJf2tETjt3Dz2s01bNhMVzYjaga72FcxPgVf5sPqD+6Ykdup+WAxJclMGVuxPD709xY7p8qPsWauTHwDHjB0jM4+dPouLiLAYJWUOgoe6AS3/Vs8sOWl1A0DmvGbbmAnBKSB646PttNN7DnbWGbkrNfDqIC9XhFPDqZ4Yv9Q6cd4XAE6D8Isa9X7szgIhZYG95SZ+fDOlDQTNGFgomSCMj/5Ob79xsc DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14cfd.5564cbbe.k1505; bh=lFHGfMjz+/TT92uCQOyVgD8S1rt80MZB2D9eO/p/TPw=; b=gNLj9LdNEuw+KIjRhTp+OZx0bw6vbqd570NiZ7Jm04w4gL4i5ml11EGD85WFHMtHbmqLZt/vVQDLrQP0qx7KxD4vRAvu6lGpT+fmBUL9K5vPyZ8z0XJnyn5yJG1TxIMNLy5JffKdk4mo5WrIcF18Vsio9F2K7pvxY5NxmCaTNUDsI6HfgamWc6rH9sXpYdXLmBUywjdKOJ4pUeDsomz2TaFC/XuQyudXfrZc8wp/RlKCsQ3/EuKIC77NcnBf0A5e Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 May 2015 19:38:38 -0000 Date: 26 May 2015 15:38:30 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150526181542.15129.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 26 May 2015 19:38:34 -0000 > Let's be careful (and, as I asked, constructive) here. There is a claim to > the contrary before us, as John Klensin and Patrik have pointed out; > specifically, that there is indeed a community of people interested in > developing Gopher and not simply documenting it. I'm as big a fan of retrocomputing as you're likely to meet, and will be pleased to discuss the use of the Fortran FREQUENCY statement and the function of the PDP-8's link bit. But that doesn't mean I think the IETF should spend time on them. If there were really a viable Gopher community, we wouldn't need to have this discussion, because the gopher users would be working on the document already. I see no reason to believe that there are as many as ten working servers any more. Start at this page and you'll find that most of the links are dead: http://gopher.quux.org:70/Software/Gopher/servers So if some people want to spend their own time on a gopher spec and send it to the ISE, that's fine, and I might even review the drafts. Fun though it might be, it would not be a good use of a WG that is presumably intending to develop standards for the future. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue May 26 13:02:43 2015 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 F15E01A1A86 for ; Tue, 26 May 2015 13:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 IX8KB_tfkXCz for ; Tue, 26 May 2015 13:02:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDC51A1A30 for ; Tue, 26 May 2015 13:02:40 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YxL3b-000FQA-JM; Tue, 26 May 2015 16:02:35 -0400 Date: Tue, 26 May 2015 16:02:30 -0400 From: John C Klensin To: "Murray S. Kucherawy" , John Levine Message-ID: In-Reply-To: References: <20150526181542.15129.qmail@ary.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Nick Matavka , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 26 May 2015 20:02:42 -0000 (copying Nick -- I don't know if he is on this list and he needs to be part of the conversation) --On Tuesday, May 26, 2015 11:33 -0700 "Murray S. Kucherawy" wrote: >> Independent, please. Gopher was swell, but it is only of >> interest now to historians and fans of retrocomputing. > Let's be careful (and, as I asked, constructive) here. There > is a claim to the contrary before us, as John Klensin and > Patrik have pointed out; specifically, that there is indeed a > community of people interested in developing Gopher and not > simply documenting it. And that community, or at least one or two people speaking on its behalf, are, as I understand it, claiming that they are working on, and have deployed, a GopherNG, aka "Gopher II", protocol, that IETF standardization might be helpful, and that the process might add value. Of course, all three of those conditions depends on our being able to act like adults rather than saying "historians and fans of retrocomputing" because of having heard or experienced and earlier protocol of the same name long ago. I believe that we need to treat that protocol the same way we would if something new came in that was deployed, had a supporting community, and named after some other large rodent. > As you pointed out earlier, we do want to be inclusive, so I > don't think "fans of retrocomputing" is a complete basis to > deflect to the Independent Stream. The more salient point to > me is whether there's enough support for doing so in the IETF > stream. Is that community committed to the idea of doing that > work in our context, and/or are there enough people in the APPS > area to contribute to and support the work through the IETF > process? Let me try to answer that question in a different way. I believe that for this to move forward, Nick and his colleagues have to be committed to doing the heavy lifting. That means willingness to participate in discussions, to update the document(s) on a timely basis, and to seriously consider protocol changes if the IETF community identifies issues. If they are, then I'm willing to do some reviewing and advising. Moreover, I think everyone in the Applications Area who has ever brought an at least partially-baked protocol to the IETF and expected the community to work on it and standardize it has some obligation to do so was well. If Nick and his colleagues are not willing to do that work, then I think this discussion just ended because I don't believe anyone here is likely to be able (much less willing) to do it for them. FWIW, I am concerned that a -01 version of the draft has not appeared and wonder if it is symptomatic of anything. So, Nick. sorry to put you on the spot, but how committed are you? best, john From nobody Tue May 26 13:15:27 2015 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 46E671B3079 for ; Tue, 26 May 2015 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 eJhpk2gSm0E9 for ; Tue, 26 May 2015 13:15:23 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 9A1FF1B2FE1 for ; Tue, 26 May 2015 13:15:22 -0700 (PDT) Received: by wizo1 with SMTP id o1so3066386wiz.1 for ; Tue, 26 May 2015 13:15:21 -0700 (PDT) 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=DVFnfAMN5MR/busSlaZr1hQOXuo6zT6z2ipB9wuhYwU=; b=GEbpnS67OnB9bCJdgKdzBhaFJRWzdd2Hcyf4Hx8O9kimqkIORxC3NRQa+Opur62Rhq COaEH0U+3MHPNl8u/KW04kAT5pHyYnOu95jAfpH0pVFsDz8ufpr8xQp+2hbPlyj08yek I33AibL+O0JqrsoWCle+HA2X6JvooNyu8/mzGSEdtuC/U+swL/Qrsg9A0w818sdiRc/4 RyoUCezghjzQE8HEHhuJrZMMNo5c8bSvd/hH9uc0lcE9JCiDtrGDtYzAyL6Axm5NYP7I sKtl9E0016m1r1hTtESrp90pjbwhp+LeSDTmfBnRpdCaCY9P+Bz7QVOR1TJJekVyTT2G +RKQ== MIME-Version: 1.0 X-Received: by 10.180.207.67 with SMTP id lu3mr44985784wic.10.1432671321345; Tue, 26 May 2015 13:15:21 -0700 (PDT) Received: by 10.195.17.163 with HTTP; Tue, 26 May 2015 13:15:21 -0700 (PDT) In-Reply-To: References: <20150526181542.15129.qmail@ary.lan> Date: Tue, 26 May 2015 13:15:21 -0700 Message-ID: From: Ted Hardie To: John C Klensin Content-Type: multipart/alternative; boundary=001a1133d3ce30523a051701c947 Archived-At: Cc: John Levine , Nick Matavka , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 26 May 2015 20:15:25 -0000 --001a1133d3ce30523a051701c947 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 26, 2015 at 1:02 PM, John C Klensin wrote: > (copying Nick -- I don't know if he is on this list and he needs > I believe that we need to treat that protocol > the same way we would if something new came in that was > deployed, had a supporting community, and named after some other > large rodent. > > =E2=80=8BSo, a variant of this seems like the most sensible question to ask= here. I'd certainly ask all of the questions John implies (is this deployed? is there a supporting community?), but I'd also add "Is this deployment Internet scale, likely to become so, or important for the infrastructure of the net?"=E2=80=8B If the answer to the first two is yes, and the third no, I'd personally suggest taking the work to the ISE. If the answer=E2=80=8B to the third is= yes, then I think the IETF should definitely agree to review/help. That you might need a crystal ball to figure out "likely to become so" is a nasty side effect of this question, unfortunately. But I think if the current belief is either clearly yes or clearly no, then we can always change our minds (and the stream) if the answer changes. Just my personal take on where to spend the cycles, Ted --001a1133d3ce30523a051701c947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 26, 2015 at 1:02 PM= , John C Klensin <john-ietf@jck.com> wrote:
(copying Nick -- I don't k= now if he is on this list and he needs
=C2=A0 I believe that we need to treat that protocol
the same way we would if something new came in that was
deployed, had a supporting community, and named after some other
large rodent.

<= /div>
=C2=A0
=E2=80=8BSo, a variant of this= seems like the most sensible question to ask here.
I= 9;d certainly ask all of the questions John implies (is this deployed? is
there a supporting community?), but I'd also add &quo= t;Is this deployment
Internet scale, likely to become so= , or important for the infrastructure
of the net?"=E2=80=8B
If the answer to the first two is yes, and the third no, I= 'd personally
suggest taking the work to the ISE.=C2= =A0 If the answer=E2=80=8B to the third is yes,
then I t= hink the IETF should definitely agree to review/help.=C2=A0 That you
might need a crystal ball to figure out "likely to become= so" is a
nasty side effect of this question, unfor= tunately.=C2=A0 But I think if the current
belief is eit= her clearly yes or clearly no, then we can always change
our minds (and the stream) if the answer changes.

<= /div>
Just my personal take on where to spend the cycles,

<= /div>
Ted
--001a1133d3ce30523a051701c947-- From nobody Tue May 26 18:08:35 2015 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 2EE6B1A1A15 for ; Tue, 26 May 2015 18:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 MU7kwpA1O6RZ for ; Tue, 26 May 2015 18:08:33 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1on0137.outbound.protection.outlook.com [134.170.140.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD161A1A11 for ; Tue, 26 May 2015 18:08:32 -0700 (PDT) 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 OS1PR01MB0133.jpnprd01.prod.outlook.com (25.161.228.149) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 01:08:28 +0000 Message-ID: <55651906.5000706@it.aoyama.ac.jp> Date: Wed, 27 May 2015 10:08:22 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ted Hardie , John C Klensin References: <20150526181542.15129.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0050.jpnprd01.prod.outlook.com (25.164.162.160) To OS1PR01MB0133.jpnprd01.prod.outlook.com (25.161.228.149) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0133; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(520003)(3002001); SRVR:OS1PR01MB0133; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0133; X-Forefront-PRVS: 05891FB07F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(51704005)(189002)(377454003)(199003)(479174004)(24454002)(105586002)(5001860100001)(101416001)(62966003)(85202003)(5001960100002)(76176999)(50986999)(54356999)(87266999)(85182001)(65956001)(66066001)(77156002)(122386002)(5001830100001)(50466002)(23676002)(68736005)(189998001)(86362001)(106356001)(87976001)(99136001)(15975445007)(93886004)(19580405001)(40100003)(2950100001)(5001770100001)(74482002)(46102003)(97736004)(42186005)(4001350100001)(64706001)(59896002)(65806001)(65816999)(83506001)(19580395003)(81156007)(92566002)(117636001)(64126003)(47776003)(4001540100001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0133; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2015 01:08:28.2902 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0133 Archived-At: Cc: Nick Matavka , John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 01:08:35 -0000 Ted's questions below, the questions that John asks at the end of his mail (not copied below), the answers that have been given and the answers that haven't shown up yet for me all point to ISE. That might of course change if and when we get (different) answers. Also, John spoke about GopherNG. It would be good to know what's really new there; I don't think we have seen any significant information on that. If GopherNG is close to just cleaning up a few loose ends, that would still mean ISE for me. If it's about something intrinsically new that might give it a new chance to come out big, then that might change my opinion. Regards, Martin. On 2015/05/27 05:15, Ted Hardie wrote: > On Tue, May 26, 2015 at 1:02 PM, John C Klensin wrote: > >> (copying Nick -- I don't know if he is on this list and he needs >> I believe that we need to treat that protocol >> the same way we would if something new came in that was >> deployed, had a supporting community, and named after some other >> large rodent. >> >> > ​So, a variant of this seems like the most sensible question to ask here. > I'd certainly ask all of the questions John implies (is this deployed? is > there a supporting community?), but I'd also add "Is this deployment > Internet scale, likely to become so, or important for the infrastructure > of the net?"​ > > If the answer to the first two is yes, and the third no, I'd personally > suggest taking the work to the ISE. If the answer​ to the third is yes, > then I think the IETF should definitely agree to review/help. That you > might need a crystal ball to figure out "likely to become so" is a > nasty side effect of this question, unfortunately. But I think if the > current > belief is either clearly yes or clearly no, then we can always change > our minds (and the stream) if the answer changes. > > Just my personal take on where to spend the cycles, > > Ted > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue May 26 18:23:10 2015 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 F2D4C1A1A73 for ; Tue, 26 May 2015 18:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] 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 FHagXmSAavtN for ; Tue, 26 May 2015 18:23:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084941B3373 for ; Tue, 26 May 2015 18:23:07 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4R1MxFd025384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 18:23:04 -0700 Message-ID: <55651C6F.8020700@dcrocker.net> Date: Tue, 26 May 2015 18:22:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Ted Hardie , John C Klensin References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> In-Reply-To: <55651906.5000706@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 26 May 2015 18:23:05 -0700 (PDT) Archived-At: Cc: Nick Matavka , John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 01:23:09 -0000 On 5/26/2015 6:08 PM, "Martin J. DΓΌrst" wrote: > Also, John spoke about GopherNG. It would be good to know what's really > new there I saw an originally request that appeared to be for documenting the earlier gopher protocol. I saw that from one person interested in doing the task. I have not seen a groundswell of interest amongst those active on this list. Reference to an NG effort appears to be about something different than was originally requested. No matter, it requires a collection of people interested in specifying and/or deploying it. (In practical terms, that's really /two/ collections of people. And another type of groundswell.) I haven't seen anything that looked like that, either. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 26 18:36:37 2015 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 AD1011B33A1 for ; Tue, 26 May 2015 18:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 3id5Q6JASHeN for ; Tue, 26 May 2015 18:36:35 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513D01ACF03 for ; Tue, 26 May 2015 18:36:35 -0700 (PDT) Received: (qmail 35480 invoked from network); 27 May 2015 01:36:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8a97.55651fa9.k1505; bh=IyIrsIAxy887gyhMu+1HrEhFyNUqLvVZ0+3Laxt7KIU=; b=ZwzA3utzlj5Gu4+VkBTpuk5Uf1KrzDYazNWrVylV/zQ1h4Qy6w7OGsQ98xMCOCsooMIHMFzbviCEkxBshnaF7goEOVXad5fHgiWsJk6oCmTjvnBUU8zE0728iDbaEdpR49NvO8fUGrKSm+xbuHyD7TbEoKe5CuT9A9JxPXn95UD7tggkGA3MYJ01mtObdPSwyxrdC4mpZjiK2zh96t32OcUhet5JntOcnQq8gooJh2E/daOIgwLhY4Wwo8HwvP5T DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8a97.55651fa9.k1505; bh=IyIrsIAxy887gyhMu+1HrEhFyNUqLvVZ0+3Laxt7KIU=; b=diFWZOJleIEboW/TuvX4SPuWH/9Zkr2y6Zcb365rm5xN3SF17u/mKRjlwmk5AN6HfutvNT55bqgVT4bQcTk8FhraI91JSzlyCLsraw9OxaYiScLjt+ECGWqutASLqoegn8L0Ss8FemZaLI1p0Oyt8ubpbTBDUyzQ41euCJhbouPUOYGSb6tsvmfF6hRwbMsazXOxt+OSd6M92es4hp4JuJM3xwCxpX4JeGdR3ag3PQ585mMludHzOr+U4lJSC6RG Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 27 May 2015 01:36:41 -0000 Date: 26 May 2015 21:36:33 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <55651C6F.8020700@dcrocker.net> References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 01:36:36 -0000 > I saw an originally request that appeared to be for documenting the > earlier gopher protocol. I saw that from one person interested in doing > the task. I have not seen a groundswell of interest amongst those > active on this list. Gopher is documented in RFC 1436. There was a not very popular multimedia extension called Gopher+ which is mentioned in RFC 1738. It cites a definition of Gopher+ on a file on a long dead FTP server at U. of Minn. This appears to be a copy of it: http://iubio.bio.indiana.edu/soft/util/gopher/Gopher+-spec.text Once again, I think Gopher is swell, but we've already wasted too much time on it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue May 26 19:41:46 2015 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 2DDA11AD0C2 for ; Tue, 26 May 2015 19:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 c9wCo5oZxBCV for ; Tue, 26 May 2015 19:41:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8A91AD0BE for ; Tue, 26 May 2015 19:41:44 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4R2fe5B027654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 19:41:43 -0700 Message-ID: <55652EE0.3080908@dcrocker.net> Date: Tue, 26 May 2015 19:41:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John R Levine References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 26 May 2015 19:41:43 -0700 (PDT) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 02:41:45 -0000 On 5/26/2015 6:36 PM, John R Levine wrote: > Gopher is documented in RFC 1436. The new draft explicitly cites that and then offers its reasons for wanting a revised document. I'm not commenting on the efficacy of those reasons, but want to note that just citing back to the existing RFC is counter-productive. More generally I don't know why some folk are finding it necessary to make disparaging comments about this or the people who might want it, but it's fucking distracting. As with most proposals for work in the IETF, the core process issues are quite simple: Is the targeted work coherent (or somesuch?) Is there a group wanting to develop it and a group wanting to use it. The default answer is always no. It take active effort by advocates to change from the default. I haven't see that here, yet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 26 22:06:28 2015 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 DED5F1A8785 for ; Tue, 26 May 2015 22:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 lbimTDBMaT-J for ; Tue, 26 May 2015 22:06:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0081.outbound.protection.outlook.com [65.55.169.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3CB1A8782 for ; Tue, 26 May 2015 22:06:25 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) with Microsoft SMTP Server (TLS) id 15.1.166.22; Wed, 27 May 2015 05:06:23 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0166.017; Wed, 27 May 2015 05:06:23 +0000 From: Larry Masinter To: IETF Apps Discuss Thread-Topic: [apps-discuss] Gopher work and stream selection Thread-Index: AQHQl9t9bNw9E8Vk3EWORaLNtvsl3p2OkDwAgAAFGwCAABi8AIAAA5eAgABR3wCAAAQQgIAAA8+AgAASLQD//7MaAA== Date: Wed, 27 May 2015 05:06:23 +0000 Message-ID: <034273B0-EA28-4EA0-933E-2D489D897105@adobe.com> References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> In-Reply-To: <55652EE0.3080908@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150508 authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.184.24.49] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1322; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DM2PR02MB1322; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1322; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(82746002)(2656002)(66066001)(450100001)(76176999)(86362001)(50986999)(68736005)(83716003)(110136002)(106116001)(122556002)(87936001)(189998001)(54356999)(558084003)(5001960100002)(77156002)(106356001)(5002640100001)(102836002)(2950100001)(62966003)(83506001)(4001540100001)(105586002)(2900100001)(33656002)(99286002)(64706001)(101416001)(4001350100001)(97736004)(107886002)(93886004)(46102003)(36756003)(40100003)(5001860100001)(81156007)(5001830100001)(92566002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1322; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <9D30FD7B33F09343A8A8BB0027CC8416@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 05:06:23.6347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1322 Archived-At: Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 05:06:27 -0000 U2VhcmNoIGZvciDigJxoaXN0b3JpY2FsIG5vdGXigJ0gaW4gUkZDIDQyNjYgU2VjdGlvbiAyIA0K KHN0YW5kYXJkcyB0cmFjaykuDQo= From nobody Tue May 26 22:51:52 2015 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 E8B931A00EF for ; Tue, 26 May 2015 22:51:51 -0700 (PDT) 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 yECKXO04a1Zd for ; Tue, 26 May 2015 22:51:50 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::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 473F81A00E9 for ; Tue, 26 May 2015 22:51:50 -0700 (PDT) Received: by wgez8 with SMTP id z8so114623723wge.0 for ; Tue, 26 May 2015 22:51:49 -0700 (PDT) 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=zvwsY7w8fJZZZdw5l8Kif6+xEO83GzB8M5WHFkJhuxU=; b=GeozZprmfCeX9eAqz9pubU3rQEWV0EkZPqTLJUUUxx4wtyBJf644gJ2GtIKLQ5ypHt m7IrY6D3/XGgz5DBglSz+SpFkZ6yxhvxVvqn5jNk98MAdlTZA12CNKFNXgnr/Uzqj4u/ rgGmXOeFWKWmFSNCNqPVJfusPX8XEg75J+eKNoQDO/KJUXNHy55PN9Snr+56dbL0OkbE X0ZIAOkp9nTYOd/hX8ulBa1RiLQG4zoH9L3tfxvG+3CKGg14tRlcnY1zV0uIxdvw45qc OP+J9SEvXi7DT3VbMYjHywOfyGUrRZ91t86vphRXsCwjoIFc+ldbnficgR5+UsGpjsL9 Qtbg== MIME-Version: 1.0 X-Received: by 10.180.210.162 with SMTP id mv2mr2425682wic.59.1432705908995; Tue, 26 May 2015 22:51:48 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Tue, 26 May 2015 22:51:48 -0700 (PDT) In-Reply-To: <55652EE0.3080908@dcrocker.net> References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> Date: Tue, 26 May 2015 22:51:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c37daec5fdf7051709d69f Archived-At: Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 05:51:52 -0000 --001a11c37daec5fdf7051709d69f Content-Type: text/plain; charset=UTF-8 On Tue, May 26, 2015 at 7:41 PM, Dave Crocker wrote: > On 5/26/2015 6:36 PM, John R Levine wrote: > > Gopher is documented in RFC 1436. > > The new draft explicitly cites that and then offers its reasons for > wanting a revised document. I'm not commenting on the efficacy of those > reasons, but want to note that just citing back to the existing RFC is > counter-productive. > > More generally I don't know why some folk are finding it necessary to > make disparaging comments about this or the people who might want it, [...] > I agree; the editorializing about the current utility of old versions of Gopher strikes me as pretty much irrelevant. I'm much more interested in whether there's a community of people interested in committing to processing the proposed document in the IETF stream. -MSK --001a11c37daec5fdf7051709d69f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 26, 2015 at 7:41 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:
On 5/26/2015 6:36= PM, John R Levine wrote:
> Gopher is documented in RFC 1436.

The new draft explicitly cites that and then offers its reasons for<= br> wanting a revised document.=C2=A0 I'm not commenting on the efficacy of= those
reasons, but want to note that just citing back to the existing RFC is
counter-productive.

More generally I don't know why some folk are finding it necessary to make disparaging comments about this or the people who might want it, [...]=
=C2=A0
I agree; the editorializing about th= e current utility of old versions of Gopher strikes me as pretty much irrel= evant.=C2=A0 I'm much more interested in whether there's a communit= y of people interested in committing to processing the proposed document in= the IETF stream.

-MSK
--001a11c37daec5fdf7051709d69f-- From nobody Tue May 26 23:32:53 2015 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 456CE1A1B2C for ; Tue, 26 May 2015 23:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 qpxygDaROzK2 for ; Tue, 26 May 2015 23:32:50 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099DE1A1BAE for ; Tue, 26 May 2015 23:32:47 -0700 (PDT) Received: internal info suppressed Date: Wed, 27 May 2015 08:32:14 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio5.garrtest.units.it To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1432708353; bh=/S7G46PtK7DdRhOyztdMtuD6CvT7Uro7a8lFZXT7NTk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fl6HGCNp90m7LJ/WE/vGNDOsrDz+iL8PF+CncN0JX9SUgVuHduF3pQJiGWFrB2xX9 /5VttaQK4nFX/vczg8VnfTkd7TNbI2xFhftmqmwjRZYCvjeDcr/zKprVTPnU8MfUgs 3clsVy+cfNkTrUQ8aa192XmnISSjSvHDjxb+u+bg= Archived-At: Cc: John R Levine , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 06:32:52 -0000 "we believe in rough consensus"... and still after a long discussion I do not see it appearing here, and we have what seems a moving target in front: "documenti what's out" --> docuenting extensions --> standardizing an NG version... so, for the moment I also do not SEE a reaction from those propising to do some work (and it seems instead consensus that those writing here will NOT do any work). Still too much on the "-1" side... ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Wed May 27 03:18:50 2015 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 047B81A9167 for ; Wed, 27 May 2015 03:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.421 X-Spam-Level: X-Spam-Status: No, score=0.421 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021] 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 sGcu9plaF0Ki for ; Wed, 27 May 2015 03:18:48 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B941ACC91 for ; Wed, 27 May 2015 03:18:48 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id A33D2FA0078; Wed, 27 May 2015 10:18:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1432721919; bh=TZTfbj9E05zHaD1CpDYUClVEbsfM9I2Vnd7v0lI3v0U=; h=From:Cc:Subject:Date:In-Reply-To:References:From; b=m6C7o6A7/IZdM8MeJen+4qwBSBH2VmJRypXh0dla6jnqbgqvI0wVBEGfrWwzOJxwB 2yvBGcDfYWRVhEYAIUe6QByE57bjb3gBGeRWSSeUxY8bVdZymHSwIOgnH2gHAdHSTF 4LMQjW/vm+u7HxcLKEPcQN/TdtIV+A/fLH+LDtFk= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1432721841-28872-28871/12/23; Wed, 27 May 2015 10:17:21 +0000 From: Arnt Gulbrandsen Cc: IETF Apps Discuss Date: Wed, 27 May 2015 11:18:15 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.0 (jessie) Mime-Version: 1.0 Message-Id: <10529216-84fc-4601-adda-550a95927877@gulbrandsen.priv.no> In-Reply-To: <55652EE0.3080908@dcrocker.net> References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 10:18:50 -0000 Dave Crocker writes: > The new draft explicitly cites that and then offers its reasons for > wanting a revised document. I'm not commenting on the efficacy of those > reasons, but want to note that just citing back to the existing RFC is > counter-productive. > > More generally I don't know why some folk are finding it necessary to > make disparaging comments about this or the people who might want it, > but it's fucking distracting. +1 to all of that. > As with most proposals for work in the IETF, the core process issues are > quite simple: Is the targeted work coherent (or somesuch?) Is there a > group wanting to develop it and a group wanting to use it. > > The default answer is always no. It take active effort by advocates to > change from the default. > > I haven't see that here, yet. I'm not aware of explicit policy, but the threshold seems vaguely higher for new work than for updates of or extensions to existing RFCs. In this case there aren't many remaining users, but there is an existing RFC and there are (AFAICT) existing interoperable implementations that have left the RFC behind. MSK: I'll review. If I haven't said so already. Arnt From nobody Wed May 27 12:12:04 2015 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 A82C61A904F for ; Wed, 27 May 2015 12:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qjQRV0R8b6fO for ; Wed, 27 May 2015 12:12:01 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263C21A904E for ; Wed, 27 May 2015 12:12:01 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Wed, 27 May 2015 15:12:00 -0400 From: "MH Michael Hammer (5304)" To: Claudio Allocchio , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] Gopher work and stream selection Thread-Index: AQHQl9t8wB+BJAd7KUqS/RGnrbZabJ2O00oAgAAFGwCAABi8AIAAA5iAgABR3gCAAAQQgIAAA9CAgAAEWLSAAE5EAIAAkK8Q Date: Wed, 27 May 2015 19:11:59 +0000 Message-ID: References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.227] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: John R Levine , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 19:12:02 -0000 > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of > Claudio Allocchio > Sent: Wednesday, May 27, 2015 2:32 AM > To: Murray S. Kucherawy > Cc: John R Levine; Dave Crocker; IETF Apps Discuss > Subject: Re: [apps-discuss] Gopher work and stream selection >=20 >=20 > "we believe in rough consensus"... and still after a long discussion I do= not > see it appearing here, and we have what seems a moving target in > front: "documenti what's out" --> docuenting extensions --> standardizing= an > NG version... >=20 > so, for the moment I also do not SEE a reaction from those propising to d= o > some work (and it seems instead consensus that those writing here will NO= T > do any work). >=20 A question I have to ask, is whether the people who are interested are awar= e of this discussion on apps-discuss? The lack of proponents may be due to = this rather than a lack of interest. Mike From nobody Wed May 27 12:25:19 2015 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 7D0BC1A90BC for ; Wed, 27 May 2015 12:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 osbRumooLeX0 for ; Wed, 27 May 2015 12:25:16 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2751A0181 for ; Wed, 27 May 2015 12:25:16 -0700 (PDT) Received: internal info suppressed Date: Wed, 27 May 2015 21:24:26 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio5.garrtest.units.it To: "MH Michael Hammer (5304)" In-Reply-To: Message-ID: References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1432754689; bh=NqTZuwWmSSZ93YaHpIo2NY0wbHEWEY/9sJVB+1iCh/I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nu1eem+z6fFB648B4aldZAl9h1xdnGuiZlzyIdSVgxs3D5QlTYMmHuuI72ahFXX8H SQX1LpWtBxJBURrbFYu09wBeK6GfHSue/gXcKJNtezlEiBECVLzYyIwBCXE6h3oB5t VGp5+dzM2RkpWkbOkGhGQyBOpubRvlWiXBgfQqXk= Archived-At: Cc: John R Levine , IETF Apps Discuss , Dave Crocker Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 19:25:18 -0000 > A question I have to ask, is whether the people who are interested are > aware of this discussion on apps-discuss? The lack of proponents may be > due to this rather than a lack of interest. this is an abvious (but quite odd) possibility... Anybody proposing any work in the APPS are should at least be aware that apps-discuss is the place to go for discussion, before a specific WG is identified (if any)... but you are right... let's ask them... ;-) > > Mike > > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Wed May 27 12:36:55 2015 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 25F5E1A90D0 for ; Wed, 27 May 2015 12:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 7vOJQddijM2k for ; Wed, 27 May 2015 12:36:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA3A1A011D for ; Wed, 27 May 2015 12:36:51 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4RJaXdC007459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2015 12:36:37 -0700 Message-ID: <55661CBE.2010409@dcrocker.net> Date: Wed, 27 May 2015 12:36:30 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Claudio Allocchio , "MH Michael Hammer (5304)" References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 27 May 2015 12:36:37 -0700 (PDT) Archived-At: Cc: John R Levine , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 19:36:53 -0000 On 5/27/2015 12:24 PM, Claudio Allocchio wrote: > this is an abvious (but quite odd) possibility... Anybody proposing any > work in the APPS are should at least be aware that apps-discuss is the > place to go for discussion, before a specific WG is identified (if any)... > > but you are right... let's ask them... ;-) I suggest we /not/. A very long-standing premise to doing work in the IETF is that proponents for work self-organize. The proponents have to "show up"; it is not the IETF's job to recruit them. (It's fine if those folk happen to already be in the IETF, so that an announcement or a BOF is enough to get them to participate in the self-organization, but that's more accident than reliable. I've always considered this an essential aspect of the IETF, because success /after/ IETF work is done depends upon exactly that support. That is, IETF work is merely a way-station along a path of industry motivating, creating, adopting and using a standardized technology. The only exception to this is when the IETF chooses to be concerned about possibly related work in other standards bodies. And that's not a factor in this case. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 27 13:04:18 2015 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 253011A9175 for ; Wed, 27 May 2015 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Wrhbkx5MTHWT for ; Wed, 27 May 2015 13:04:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC171A9177 for ; Wed, 27 May 2015 13:04:14 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YxhYe-000Ox8-Gf; Wed, 27 May 2015 16:04:08 -0400 Date: Wed, 27 May 2015 16:04:03 -0400 From: John C Klensin To: Claudio Allocchio , "MH Michael Hammer (5304)" Message-ID: In-Reply-To: References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Nick Matavka , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 20:04:17 -0000 Claudio and Mike, (top post) That is why I copied Nick in my note on this subject to Murray yesterday and am copying him on this one. This is where the "newcomer" issue interacts with the "new work proposal" one and we need to decide whether we are going to be welcoming or, instead, present as many barriers as possible to anything getting on the standards track unless it comes from an IETF process expert and/or "member of the in-crowd". I continue to hope that a proposal will get the same consideration, using the same criteria, and have at least equal chance of succeeding whether it comes from a newcomer and outsider to the community or if it comes from one of the two of you or, for that matter, from Murray, Dave, or John Levine. I hope those same principles apply whether the proposal is called "Gopher-II" or was a new proposal for "PackRat-I" or some subspecies of Badger or Beaver that happened to show some genus or species relationship to Gophers. Neither Nick nor his colleagues "proposed work in the APPS area". He/they posed the question of how this should be handled in the IETF. They were told that, if the goal was to simply produce improved documentation of the historic Gopher protocol, that should probably be an informational document submitted to the ISE but that, if there was new protocol work involved and under active development, the standards-track question should be explored. I believe that exploration of AppsAWG, other Apps Area options, and other standards track options are part of that exploration, with the questions being asked to keep things orderly and as much by some combination of Barry (in his AD role), myself (as part of "helping out the newcomer" and not wanting to see this dismissed because of prejudices about "retrocomputing" if there really is an active user and developer community), and Murray (in an Apps Area capacity) as by Nick. Given that, while I think he'd best get on this mailing list, at least temporarily, if he wants us to continue exploring the topic, I don't think anyone has said "if you want this to be discussed in the IETF, you are required to be on the following mailing lists", nor is that necessarily a requirement for such exploration even though, if Appa Area WG decided to take the work on, it would clearly be necessary for those interested to subscribe. best, john --On Wednesday, May 27, 2015 21:24 +0200 Claudio Allocchio wrote: > >> A question I have to ask, is whether the people who are >> interested are aware of this discussion on apps-discuss? The >> lack of proponents may be due to this rather than a lack of >> interest. > > this is an abvious (but quite odd) possibility... Anybody > proposing any work in the APPS are should at least be aware > that apps-discuss is the place to go for discussion, before a > specific WG is identified (if any)... > > but you are right... let's ask them... ;-) > >> > Mike >... From nobody Wed May 27 13:16:56 2015 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 830811A92DD for ; Wed, 27 May 2015 13:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 eJchhuOYszjA for ; Wed, 27 May 2015 13:16:54 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18B91A92DC for ; Wed, 27 May 2015 13:16:53 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Wed, 27 May 2015 16:16:52 -0400 From: "MH Michael Hammer (5304)" To: "dcrocker@bbiw.net" , Claudio Allocchio Thread-Topic: [apps-discuss] Gopher work and stream selection Thread-Index: AQHQl9t8wB+BJAd7KUqS/RGnrbZabJ2O00oAgAAFGwCAABi8AIAAA5iAgABR3gCAAAQQgIAAA9CAgAAEWLSAAE5EAIAAkK8QgABHEgCAAANfAP//xlcw Date: Wed, 27 May 2015 20:16:51 +0000 Message-ID: References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> <55661CBE.2010409@dcrocker.net> In-Reply-To: <55661CBE.2010409@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.227] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 20:16:55 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGF2ZSBDcm9ja2VyIFtt YWlsdG86ZGhjQGRjcm9ja2VyLm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMjcsIDIwMTUg MzozNyBQTQ0KPiBUbzogQ2xhdWRpbyBBbGxvY2NoaW87IE1IIE1pY2hhZWwgSGFtbWVyICg1MzA0 KQ0KPiBDYzogSm9obiBSIExldmluZTsgSUVURiBBcHBzIERpc2N1c3M7IERhdmUgQ3JvY2tlcg0K PiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gR29waGVyIHdvcmsgYW5kIHN0cmVhbSBzZWxl Y3Rpb24NCj4gDQo+IE9uIDUvMjcvMjAxNSAxMjoyNCBQTSwgQ2xhdWRpbyBBbGxvY2NoaW8gd3Jv dGU6DQo+ID4gdGhpcyBpcyBhbiBhYnZpb3VzIChidXQgcXVpdGUgb2RkKSBwb3NzaWJpbGl0eS4u LiBBbnlib2R5IHByb3Bvc2luZw0KPiA+IGFueSB3b3JrIGluIHRoZSBBUFBTIGFyZSBzaG91bGQg YXQgbGVhc3QgYmUgYXdhcmUgdGhhdCBhcHBzLWRpc2N1c3MgaXMNCj4gPiB0aGUgcGxhY2UgdG8g Z28gZm9yIGRpc2N1c3Npb24sIGJlZm9yZSBhIHNwZWNpZmljIFdHIGlzIGlkZW50aWZpZWQgKGlm IGFueSkuLi4NCj4gPg0KPiA+IGJ1dCB5b3UgYXJlIHJpZ2h0Li4uIGxldCdzIGFzayB0aGVtLi4u IDstKQ0KPiANCj4gDQo+IEkgc3VnZ2VzdCB3ZSAvbm90Ly4NCj4gDQo+IEEgdmVyeSBsb25nLXN0 YW5kaW5nIHByZW1pc2UgdG8gZG9pbmcgd29yayBpbiB0aGUgSUVURiBpcyB0aGF0IHByb3BvbmVu dHMgZm9yDQo+IHdvcmsgc2VsZi1vcmdhbml6ZS4gIFRoZSBwcm9wb25lbnRzIGhhdmUgdG8gInNo b3cgdXAiOyBpdCBpcyBub3QgdGhlIElFVEYncw0KPiBqb2IgdG8gcmVjcnVpdCB0aGVtLiAgKEl0 J3MgZmluZSBpZiB0aG9zZSBmb2xrIGhhcHBlbiB0byBhbHJlYWR5IGJlIGluIHRoZSBJRVRGLCBz bw0KPiB0aGF0IGFuIGFubm91bmNlbWVudCBvciBhIEJPRiBpcyBlbm91Z2ggdG8gZ2V0IHRoZW0g dG8gcGFydGljaXBhdGUgaW4gdGhlDQo+IHNlbGYtb3JnYW5pemF0aW9uLCBidXQgdGhhdCdzIG1v cmUgYWNjaWRlbnQgdGhhbiByZWxpYWJsZS4NCj4gDQo+IEkndmUgYWx3YXlzIGNvbnNpZGVyZWQg dGhpcyBhbiBlc3NlbnRpYWwgYXNwZWN0IG9mIHRoZSBJRVRGLCBiZWNhdXNlIHN1Y2Nlc3MNCj4g L2FmdGVyLyBJRVRGIHdvcmsgaXMgZG9uZSBkZXBlbmRzIHVwb24gZXhhY3RseSB0aGF0IHN1cHBv cnQuDQo+IFRoYXQgaXMsIElFVEYgd29yayBpcyBtZXJlbHkgYSB3YXktc3RhdGlvbiBhbG9uZyBh IHBhdGggb2YgaW5kdXN0cnkgbW90aXZhdGluZywNCj4gY3JlYXRpbmcsIGFkb3B0aW5nIGFuZCB1 c2luZyBhIHN0YW5kYXJkaXplZCB0ZWNobm9sb2d5Lg0KPiANCj4gVGhlIG9ubHkgZXhjZXB0aW9u IHRvIHRoaXMgaXMgd2hlbiB0aGUgSUVURiBjaG9vc2VzIHRvIGJlIGNvbmNlcm5lZCBhYm91dA0K PiBwb3NzaWJseSByZWxhdGVkIHdvcmsgaW4gb3RoZXIgc3RhbmRhcmRzIGJvZGllcy4gIEFuZCB0 aGF0J3Mgbm90IGEgZmFjdG9yIGluDQo+IHRoaXMgY2FzZS4NCj4NCg0KRGF2ZSwgDQoNCkkndmUg YmVlbiBhY3RpdmUgaW4gd29ya2luZyBncm91cHMgaW4gdGhlIGVtYWlsIGF1dGggc3BhY2UgZ29p bmcgYmFjayB0byBNQVJJRCAoc2h1ZGRlcikuIEkgZGlkbid0IGhhdmUgYSBjbHVlIGFib3V0IHRo ZSBhcHBzLWRpc2N1c3MgbGlzdCB1bnRpbCBETUFSQyBlbmRlZCB1cCBiZWluZyBkaXNjdXNzZWQg aGVyZSBhbmQgc29tZW9uZSBzYWlkIHRoaXMgaXMgYSBsaXN0IHlvdSBuZWVkIHRvIGJlIG9uIGlm IHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB0aGF0LiBBcyBKb2huIEtsZW5zaW4gcG9pbnRzIG91dCwg dGhpcyB0b3VjaGVzIG9uIHRoZSBpc3N1ZSBvZiB3aGV0aGVyIHRoZSBnb2FsIGlzIGZvciBJRVRG IHRvIGJlIGF0dHJhY3RpdmUgdG8gIm5ldyIgZm9sa3MgaW50ZXJlc3RlZCBpbiBhIHBhcnRpY3Vs YXIgYXJlYSBvciB3aGV0aGVyIHRvIHRocm93IHVwIGJhcnJpZXJzICh0byBlbnRyeSkgc28gdG8g c3BlYWsuIEkgaGF2ZW4ndCBzZWVuIHdoYXQgdGhlIHByb3Bvc2VkIHdvcmsgcHJvZHVjdCBpcyBv ciBldmVuIGhvdyB3aWRlbHkgZ29waGVyIGlzIHVzZWQgdGhlc2UgZGF5cyAoaWYgYXQgYWxsKSBz byBJJ20gbm90IGluIGEgcG9zaXRpb24gdG8gc3BlYWsgdG8gdGhlIG1lcml0cyBvZiBhbnkgcHJv cG9zZWQgd29yay4NCg0KTWlrZQ0K From nobody Wed May 27 14:40:52 2015 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 858FC1AC3EC for ; Wed, 27 May 2015 14:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 7ElsgnI5CPrh for ; Wed, 27 May 2015 14:40:49 -0700 (PDT) Received: from groups.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AC3CA1A0105 for ; Wed, 27 May 2015 14:40:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3432; t=1432762838; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=CJg7Ew+lfs7cTCiopvzXFXxYkD4=; b=LavF7ggksui4VsXSZI6/vNQEuSXYyNsjgUzdAnIK1OY1BTqfd9zTwkxxt/2oQt HTyRTGGMcEbCEzrcJKmTVMLvwth/GGZCQMfd6L0fKtHA8Umcl2lnm44WOIkXQhhs s+bgA0546HLt4a/UKMpC/oWd256YHDb7CXULETrGju03w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 27 May 2015 17:40:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2177842858.17473.4544; Wed, 27 May 2015 17:40:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3432; t=1432762530; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=E1VT+Qe Ja3Jt/4OCvCl6phEoSCVG7P/ZSNFdNcQQdKc=; b=S8hdAXzqNVD1SxTv8EE7sU2 uX3SofF/Vx4+luNYf/33gFGu5d4N8PNG0023JLiLOEomFNS1JE2HmzFWxTIcRFzo FwOp162PA+tba36tpU9OE8PRLhirBe+4l3WCIq8UAkzrgTB8Y/tndfWoM6j2V5AI JxKoSZED1Y3YQN3XQ49g= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 27 May 2015 17:35:30 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 770098067.9.28304; Wed, 27 May 2015 17:35:28 -0400 Message-ID: <556639D4.8010005@isdg.net> Date: Wed, 27 May 2015 17:40:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: John C Klensin , Claudio Allocchio , "MH Michael Hammer (5304)" References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Nick Matavka , IETF Apps Discuss Subject: Re: [apps-discuss] Gopher work and stream selection 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, 27 May 2015 21:40:51 -0000 Hear hear. John, you remain among the last bastions of IETF hope. :) On 5/27/2015 4:04 PM, John C Klensin wrote: > Claudio and Mike, > > (top post) > > That is why I copied Nick in my note on this subject to Murray > yesterday and am copying him on this one. > > This is where the "newcomer" issue interacts with the "new work > proposal" one and we need to decide whether we are going to be > welcoming or, instead, present as many barriers as possible to > anything getting on the standards track unless it comes from an > IETF process expert and/or "member of the in-crowd". I > continue to hope that a proposal will get the same > consideration, using the same criteria, and have at least equal > chance of succeeding whether it comes from a newcomer and > outsider to the community or if it comes from one of the two of > you or, for that matter, from Murray, Dave, or John Levine. I > hope those same principles apply whether the proposal is called > "Gopher-II" or was a new proposal for "PackRat-I" or some > subspecies of Badger or Beaver that happened to show some genus > or species relationship to Gophers. > > Neither Nick nor his colleagues "proposed work in the APPS > area". He/they posed the question of how this should be handled > in the IETF. They were told that, if the goal was to simply > produce improved documentation of the historic Gopher protocol, > that should probably be an informational document submitted to > the ISE but that, if there was new protocol work involved and > under active development, the standards-track question should be > explored. I believe that exploration of AppsAWG, other Apps > Area options, and other standards track options are part of that > exploration, with the questions being asked to keep things > orderly and as much by some combination of Barry (in his AD > role), myself (as part of "helping out the newcomer" and not > wanting to see this dismissed because of prejudices about > "retrocomputing" if there really is an active user and developer > community), and Murray (in an Apps Area capacity) as by Nick. > Given that, while I think he'd best get on this mailing list, at > least temporarily, if he wants us to continue exploring the > topic, I don't think anyone has said "if you want this to be > discussed in the IETF, you are required to be on the following > mailing lists", nor is that necessarily a requirement for such > exploration even though, if Appa Area WG decided to take the > work on, it would clearly be necessary for those interested to > subscribe. > > best, > john > > > > > --On Wednesday, May 27, 2015 21:24 +0200 Claudio Allocchio > wrote: > >> >>> A question I have to ask, is whether the people who are >>> interested are aware of this discussion on apps-discuss? The >>> lack of proponents may be due to this rather than a lack of >>> interest. >> >> this is an abvious (but quite odd) possibility... Anybody >> proposing any work in the APPS are should at least be aware >> that apps-discuss is the place to go for discussion, before a >> specific WG is identified (if any)... >> >> but you are right... let's ask them... ;-) >> >>>> Mike >> ... > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- HLS From nobody Wed May 27 18:34:57 2015 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 EE8951ACD09 for ; Wed, 27 May 2015 18:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, J_CHICKENPOX_28=0.6, 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 0KQ2nCUwu-7c for ; Wed, 27 May 2015 18:34:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0657.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:657]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A621A8A3B for ; Wed, 27 May 2015 18:34:52 -0700 (PDT) Received: from SN1PR02MB1328.namprd02.prod.outlook.com (25.162.0.146) by SN1PR02MB1328.namprd02.prod.outlook.com (25.162.0.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 01:34:31 +0000 Received: from SN1PR02MB1328.namprd02.prod.outlook.com ([25.162.0.146]) by SN1PR02MB1328.namprd02.prod.outlook.com ([25.162.0.146]) with mapi id 15.01.0172.012; Thu, 28 May 2015 01:34:31 +0000 From: Larry Masinter To: Hector Santos , John C Klensin , Claudio Allocchio , "MH Michael Hammer (5304)" Thread-Topic: APP => ART: what are the criteria for IETF application work? Thread-Index: AQHQmOZxnaAkBrQKi06mhvXrqXCBDw== Date: Thu, 28 May 2015 01:34:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150508 authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.184.24.49] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR02MB1328; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:SN1PR02MB1328; BCL:0; PCL:0; RULEID:; SRVR:SN1PR02MB1328; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(106116001)(15975445007)(5001860100001)(86362001)(62966003)(5001960100002)(54356999)(5001830100001)(50986999)(99286002)(105586002)(77156002)(102836002)(40100003)(106356001)(101416001)(68736005)(5002640100001)(87936001)(2656002)(36756003)(122556002)(229853001)(66066001)(5001770100001)(189998001)(97736004)(46102003)(4001350100001)(4001540100001)(64706001)(92566002)(2900100001)(82746002)(83716003)(81156007)(83506001)(19580395003)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR02MB1328; H:SN1PR02MB1328.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <7EA86B03B70BB141AE3F6CE32467CE74@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 01:34:30.9725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR02MB1328 Archived-At: Cc: Nick Matavka , IETF Apps Discuss Subject: [apps-discuss] APP => ART: what are the criteria for IETF application work? 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 May 2015 01:34:56 -0000 VGhlIHJlY2VudCBkaXNjdXNzaW9uIGFib3V0IHVwZGF0aW5nIHRoZSBHb3BoZXIgcHJvdG9jb2wg aGFzDQpyYWlzZWQgc29tZSBoZWF0LCBidXQgdGhlIGRpc2FncmVlbWVudHMgc2VlbSB0byByZXN0 IG9uIHRoZQ0KcXVlc3Rpb25zIG9mIGhvdyBhcHBsaWNhdGlvbiBwcm90b2NvbCB3b3JrIGlzIGFj Y2VwdGVkIG9yDQpyZWplY3RlZCBpbiB0aGUgdmFyaW91cyBzdHJlYW1zLCBhbmQgYnkgd2hhdCBj cml0ZXJpYS4NCg0KRmlyc3QsIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0IHRoZXJlIGlzIG5vIG5l ZWQgZm9yIGFueQ0KYXBwbGljYXRpb24gd29yayB0byB3YWl0IGZvciB0aGUgSUVURiB0byBkbyBz b21ldGhpbmcNCmluIG9yZGVyIHRvIGRlc2lnbiwgYnVpbGQsIHNwZWNpZnksIHRlc3QsIGRlcGxv eSBhcHBsaWNhdGlvbg0KcHJvdG9jb2xzLiBQcm9wcmlldGFyeSBwcm90b2NvbHMgYXJlIGFidW5k YW50LCB0aGVyZSBhcmUNCm1hbnkgY29uc29ydGlhLCBvdGhlciBTRE9zIHRoYXQgZG8gYXBwbGlj YXRpb24gcHJvdG9jb2wNCndvcmssIHdpdGhvdXQgYW55IGludGVyYWN0aW9uIHdpdGggdGhlIElF VEYuDQoNCkEgZ3JvdXAgd29ya2luZyBvbiBhcHBsaWNhdGlvbnMgc2hvdWxkIGJyaW5nIHRoYXQg d29yaw0KdG8gdGhlIElFVEYgd2hlbiB0aGUgYWR2YW50YWdlcyBleGNlZWQgdGhlIGNvc3RzLCBm b3INCmJvdGggdGhlIGdyb3VwIGFuZCB0aGUgd2hvbGUgSW50ZXJuZXQgY29tbXVuaXR5Lg0KDQpJ IHRoaW5rIHRoZSBtYWluIGJlbmVmaXRzIHJlc3QgYXJvdW5kIGdldHRpbmcgcmV2aWV3DQpmcm9t IHRoZSBicm9hZGVyIGdyb3VwLCBidXQgZ2V0dGluZyByZXZpZXcgaW52b2x2ZXMNCnRoZSBjb3N0 IG9mIGFycmFuZ2luZyBpdCwgZGVhbGluZyB3aXRoIHJldmlldyBjb21tZW50cw0KeW91IHRoaW5r IGFyZSBpcnJlbGV2YW50LCBpbnN1bHRpbmcsIHVuaW5mb3JtZWQsIGV0Yy4NCg0KR2l2ZW4gbGlt aXRlZCByZXNvdXJjZXMgb2YgSUVURiwgSUVURiBhcHBsaWNhdGlvbiB3b3JrDQpzaG91bGQgZm9j dXMgb24gaGlnaC12YWx1ZSBwcm9qZWN0cyB0aGF0IHdvdWxkIGJlbmVmaXQNCmZyb20gdGhlIGNv bnRleHQgb2YgYmVpbmcgZG9uZSB3aXRoaW4gdGhlIElFVEYuDQoNClRoZSB2YXJpb3VzIGNoYW5u ZWxzIGZvciBicmluZ2luZyB3b3JrIHRvIHRoZQ0KSUVURiAoaW5kZXBlbmRlbnQsbmV3IFdHLGV4 aXN0aW5nIFdHLGFyZWEgV0csQUQpDQptYXkgaGF2ZSBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIGZv ciB0aGUgcXVlc3Rpb24NCuKAnElzIHRoZSB3b3JrIG9mIGludGVyZXN0IHRvIHRoZSBJbnRlcm5l dCBjb21tdW5pdHk/4oCdDQpidXQgY2FuIHdlIHBsZWFzZSB1c2UgdGhlIHNhbWUgbWV0cmljIGZv ciB0aGF0DQpxdWVzdGlvbj8NCg0KQmVpbmcgY2xlYXJlciB0byBvdXJzZWx2ZXMgYW5kIG5ld2Nv bWVycyBhYm91dA0KYXBwbGljYXRpb24gd29yayBzZWVtcyBsaWtlIGEgZ29vZCB0aGluZyB0byBt YW5hZ2UNCmluIHRoZSBBUFAgPT4gQVJUIHRyYW5zaXRpb24vbWVyZ2VyLg0KDQpMYXJyeQ0K4oCU DQoNCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0K From nobody Wed May 27 20:16:36 2015 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 CB8AC1A1A73 for ; Wed, 27 May 2015 20:16:34 -0700 (PDT) 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 jWtdKmjUmJo4 for ; Wed, 27 May 2015 20:16:33 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 3A8221A1A11 for ; Wed, 27 May 2015 20:16:33 -0700 (PDT) Received: by wgez8 with SMTP id z8so24864797wge.0 for ; Wed, 27 May 2015 20:16:32 -0700 (PDT) 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=fqZ6Fpcv1ezyZwfgNaE1O28lIktcfA7qXcmDu2UFrAg=; b=HJ7VAJwdjF3zoO/uRvnMpqnPN+lOolWuPSF0drEuqrVaRtANaczKBoqLQFyJ/Q5P48 1X5S1a6j8nmtR3PWyfMLx5vwNzhfNVHb/r67xLl5bJXtuwaxaLA5QbYYl81mqZTPhe1E dIvwjxqMvxn2dsmAW8mpoLs5k8RChHw/USbRq0nydZs1fbjek6St4icfKKQQZ2A42at8 n5R1goE105+Q4yykG07KxEp4jSLie7FrVVLeOochRmZE7HOguT7yOYPBXkOZat6vGHr9 b6fjL71v0CgYijF589/VkBpKq58xixbx7pns59lKtUk1Lhh+j9Iev38trduk10wEwbcc /4Bg== MIME-Version: 1.0 X-Received: by 10.180.206.45 with SMTP id ll13mr47530151wic.94.1432782991998; Wed, 27 May 2015 20:16:31 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Wed, 27 May 2015 20:16:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2015 20:16:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Larry Masinter Content-Type: multipart/alternative; boundary=001a11c2382c47447205171bc96a Archived-At: Cc: IETF Apps Discuss , Nick Matavka Subject: Re: [apps-discuss] APP => ART: what are the criteria for IETF application work? 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 May 2015 03:16:35 -0000 --001a11c2382c47447205171bc96a Content-Type: text/plain; charset=UTF-8 On Wed, May 27, 2015 at 6:34 PM, Larry Masinter wrote: > I think the main benefits rest around getting review > from the broader group, but getting review involves > the cost of arranging it, dealing with review comments > you think are irrelevant, insulting, uninformed, etc. > I don't think anyone is arguing any of those points, except for one: While it's true that sometimes one has to deal with insulting feedback, I also think that plain fact is unfortunate and doesn't excuse the people who make the choice to employ it. Multiple replies on this topic, which could have been delivered politely and/or constructively, were instead scattered between plainly dismissive and pointedly rude, and I have been unable to figure out how it's justified. I certainly know what I would think of the IETF if, as a newcomer, I had been on the receiving end of it. -MSK --001a11c2382c47447205171bc96a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 27, 2015 at 6:34 PM, Larry Masinter <masint= er@adobe.com> wrote:
I think the main benefits r= est around getting review
from the broader group, but getting review involves
the cost of arranging it, dealing with review comments
you think are irrelevant, insulting, uninformed, etc.
=
I don't think anyone is arguing any of those points, except f= or one: While it's true that sometimes one has to deal with insulting f= eedback, I also think that plain fact is unfortunate and doesn't excuse= the people who make the choice to employ it.=C2=A0 Multiple replies on thi= s topic, which could have been delivered politely and/or constructively, we= re instead scattered between plainly dismissive and pointedly rude, and I h= ave been unable to figure out how it's justified.

I certainly know what I would think of the IETF if, as a= newcomer, I had been on the receiving end of it.

-MSK
--001a11c2382c47447205171bc96a-- From nobody Wed May 27 22:56:49 2015 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 797371A00E6 for ; Wed, 27 May 2015 22:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, 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 wfLn75MMy46f for ; Wed, 27 May 2015 22:56:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0653.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::653]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF7D1A00A7 for ; Wed, 27 May 2015 22:56:45 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 05:56:24 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0172.012; Thu, 28 May 2015 05:56:24 +0000 From: Larry Masinter To: "Murray S. Kucherawy" Thread-Topic: [apps-discuss] APP => ART: what are the criteria for IETF application work? Thread-Index: AQHQmOZxnaAkBrQKi06mhvXrqXCBD52Qt5WAgAAsrBA= Date: Thu, 28 May 2015 05:56:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-originating-ip: [2601:9:8380:992:9417:cff2:983e:c35e] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1322; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DM2PR02MB1322; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1322; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(189002)(24454002)(189998001)(110136002)(5001960100002)(4001540100001)(5001830100001)(97736004)(81156007)(86362001)(2656002)(92566002)(68736005)(19580405001)(2900100001)(2950100001)(83716003)(64706001)(19580395003)(5001860100001)(87936001)(15975445007)(102836002)(82746002)(33656002)(16601075003)(105586002)(19617315012)(106116001)(5002640100001)(1411001)(99286002)(36756003)(106356001)(62966003)(77156002)(46102003)(101416001)(54356999)(76176999)(16236675004)(50986999)(40100003)(587094005)(122556002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1322; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D82BE6BFAEFF44F997C9163D16EA0168adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 05:56:23.6252 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1322 Archived-At: Cc: IETF Apps Discuss , Nick Matavka Subject: Re: [apps-discuss] APP => ART: what are the criteria for IETF application work? 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 May 2015 05:56:48 -0000 --_000_D82BE6BFAEFF44F997C9163D16EA0168adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the question is whether the work is important enough to do here, to say = no is not being inappropriately dismissive. Dismissive (of the work) is wha= t is called for if no is the right answer. -- http://larry.masinter.net On May 27, 2015, at 8:16 PM, Murray S. Kucherawy > wrote: On Wed, May 27, 2015 at 6:34 PM, Larry Masinter > wrote: I think the main benefits rest around getting review from the broader group, but getting review involves the cost of arranging it, dealing with review comments you think are irrelevant, insulting, uninformed, etc. I don't think anyone is arguing any of those points, except for one: While = it's true that sometimes one has to deal with insulting feedback, I also th= ink that plain fact is unfortunate and doesn't excuse the people who make t= he choice to employ it. Multiple replies on this topic, which could have b= een delivered politely and/or constructively, were instead scattered betwee= n plainly dismissive and pointedly rude, and I have been unable to figure o= ut how it's justified. I certainly know what I would think of the IETF if, as a newcomer, I had be= en on the receiving end of it. -MSK --_000_D82BE6BFAEFF44F997C9163D16EA0168adobecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If the question is whether the work is important enough to do here, to= say no is not being inappropriately dismissive. Dismissive (of the work) i= s what is called for if no is the right answer.

--

On May 27, 2015, at 8:16 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Wed, May 27, 2015 at 6:34 PM, Larry Masinter <masint= er@adobe.com> wrote:
I think the main benefits rest around getting review
from the broader group, but getting review involves
the cost of arranging it, dealing with review comments
you think are irrelevant, insulting, uninformed, etc.

I don't think anyone is arguing any of those points, except for one: While = it's true that sometimes one has to deal with insulting feedback, I also th= ink that plain fact is unfortunate and doesn't excuse the people who make t= he choice to employ it.  Multiple replies on this topic, which could have been delivered politely and/or con= structively, were instead scattered between plainly dismissive and pointedl= y rude, and I have been unable to figure out how it's justified.

I certainly know what I would think of the IETF = if, as a newcomer, I had been on the receiving end of it.

-MSK
--_000_D82BE6BFAEFF44F997C9163D16EA0168adobecom_-- From nobody Wed May 27 23:27:17 2015 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 7F82C1A1B00 for ; Wed, 27 May 2015 23:27:15 -0700 (PDT) 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 nopNFdUdkA9S for ; Wed, 27 May 2015 23:27:14 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 08E751A1AFF for ; Wed, 27 May 2015 23:27:14 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so134553157wic.0 for ; Wed, 27 May 2015 23:27:12 -0700 (PDT) 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=F8w5z83tRfqtd+IjqAh8CmqOcXB5dn12etdmjtqd2RA=; b=rTcuBiJFcsOFAOz6fNjFcCJ69oZ2GNFlhAMxZuckkoH+mQId40nE0A53+bjjw97BrY 12v6rBrkcs7zDOp3KUqp7a7jiNvQm1uomZ/PLNfSN1aE4FY60CcaF9TtESxphZ4E5pY4 QGpZdou977JLxLxS0e55AAc/PBAZljDhxdAfc/TVkjfed+RmNLR8ws87iAwyJ3Fk3cT5 87q5yzsxuwcC+5FW0DsT1OAyiXEJ4cTUUyChbnfg/d/7S58caujgdHjYQY+a00JdKRsj hqmXixU2O8qIw35NawuxjF7E2lbDKCC8oG9D94zTw8G5QcWRaEVUlm4cXiVMLCtPk567 hwtw== MIME-Version: 1.0 X-Received: by 10.194.61.50 with SMTP id m18mr2177331wjr.135.1432794432827; Wed, 27 May 2015 23:27:12 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Wed, 27 May 2015 23:27:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2015 23:27:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Larry Masinter Content-Type: multipart/alternative; boundary=047d7b66f8e734779a05171e73bd Archived-At: Cc: IETF Apps Discuss , Nick Matavka Subject: Re: [apps-discuss] APP => ART: what are the criteria for IETF application work? 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 May 2015 06:27:15 -0000 --047d7b66f8e734779a05171e73bd Content-Type: text/plain; charset=UTF-8 On Wed, May 27, 2015 at 10:56 PM, Larry Masinter wrote: > If the question is whether the work is important enough to do here, to > say no is not being inappropriately dismissive. Dismissive (of the work) is > what is called for if no is the right answer. > I agree, Larry. But that's not what happened. -MSK --047d7b66f8e734779a05171e73bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 27, 2015 at 10:56 PM, Larry Masinter <masint= er@adobe.com> wrote:
If the question is whether the work is important enough to do here, to= say no is not being inappropriately dismissive. Dismissive (of the work) i= s what is called for if no is the right answer.

I agree, Larry.=C2=A0 But that's not what happened= .

-MSK
--047d7b66f8e734779a05171e73bd-- From nobody Thu May 28 00:18:29 2015 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 53CDF1A1F02; Thu, 28 May 2015 00:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 DWFJ12lV0Yg6; Thu, 28 May 2015 00:18:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 625651A3B9D; Thu, 28 May 2015 00:18:26 -0700 (PDT) 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.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528071826.3803.44025.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 00:18:26 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-02.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: Thu, 28 May 2015 07:18:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-02.txt Pages : 19 Date : 2015-05-28 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It attemps to define a common core which is intended to interoperate across the broad spectrum of existing implementations, while at the same time documenting other current practices. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-02 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 Thu May 28 00:58:47 2015 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 70C561A877B for ; Thu, 28 May 2015 00:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 NMCILFghG1pI for ; Thu, 28 May 2015 00:58:41 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BE81A8747 for ; Thu, 28 May 2015 00:58:41 -0700 (PDT) Received: internal info suppressed Date: Thu, 28 May 2015 09:58:25 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Hector Santos In-Reply-To: <556639D4.8010005@isdg.net> Message-ID: References: <20150526181542.15129.qmail@ary.lan> <55651906.5000706@it.aoyama.ac.jp> <55651C6F.8020700@dcrocker.net> <55652EE0.3080908@dcrocker.net> <556639D4.8010005@isdg.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1432799909; bh=fBiNECn9fE45quUCTeJDHuCcS3JJj9lxPavO4iCzz7w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Np4wRBs75Z144QhdMe19RMgD0uY4R5Y5ji0fJfYhRQ3rbA7PwIiwidaAv/OrqLN2e mdAhFsng/YsZkXVypNBXmjRp1aENJnFD2CmErkWAIaCfmSyiXELBCuDTmwZh2AgLDw i20mPEBESJDo46Mc9JLaGjCtzzI3hAz3egxHEzJU= Archived-At: Cc: IETF Apps Discuss , Nick Matavka Subject: Re: [apps-discuss] Gopher work and stream selection 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 May 2015 07:58:44 -0000 On Wed, 27 May 2015, Hector Santos wrote: > Hear hear. John, you remain among the last bastions of IETF hope. :) Sure John... indeed if I try to just look from outside (to our web site for example), I may not easily find out about many discussion lists (and blogs)... I still find this is a lack of information also in WG chairs for some topics - while running the apps-dir it was - and still is - a struggle to let them know about it - ... so it may happen that people do not know how it works. That's why I saied "let's ask them"... I remember other cases in the past where the start was really odd and slow, but ended well in some useful specs in the end. We have all been newcomers... in the (long) past... with little clue on where to move about. So in conclusions, there is work to be done, we need to understand about committments about it, and who commits. all the best > > > On 5/27/2015 4:04 PM, John C Klensin wrote: >> Claudio and Mike, >> >> (top post) >> >> That is why I copied Nick in my note on this subject to Murray >> yesterday and am copying him on this one. >> >> This is where the "newcomer" issue interacts with the "new work >> proposal" one and we need to decide whether we are going to be >> welcoming or, instead, present as many barriers as possible to >> anything getting on the standards track unless it comes from an >> IETF process expert and/or "member of the in-crowd". I >> continue to hope that a proposal will get the same >> consideration, using the same criteria, and have at least equal >> chance of succeeding whether it comes from a newcomer and >> outsider to the community or if it comes from one of the two of >> you or, for that matter, from Murray, Dave, or John Levine. I >> hope those same principles apply whether the proposal is called >> "Gopher-II" or was a new proposal for "PackRat-I" or some >> subspecies of Badger or Beaver that happened to show some genus >> or species relationship to Gophers. >> >> Neither Nick nor his colleagues "proposed work in the APPS >> area". He/they posed the question of how this should be handled >> in the IETF. They were told that, if the goal was to simply >> produce improved documentation of the historic Gopher protocol, >> that should probably be an informational document submitted to >> the ISE but that, if there was new protocol work involved and >> under active development, the standards-track question should be >> explored. I believe that exploration of AppsAWG, other Apps >> Area options, and other standards track options are part of that >> exploration, with the questions being asked to keep things >> orderly and as much by some combination of Barry (in his AD >> role), myself (as part of "helping out the newcomer" and not >> wanting to see this dismissed because of prejudices about >> "retrocomputing" if there really is an active user and developer >> community), and Murray (in an Apps Area capacity) as by Nick. >> Given that, while I think he'd best get on this mailing list, at >> least temporarily, if he wants us to continue exploring the >> topic, I don't think anyone has said "if you want this to be >> discussed in the IETF, you are required to be on the following >> mailing lists", nor is that necessarily a requirement for such >> exploration even though, if Appa Area WG decided to take the >> work on, it would clearly be necessary for those interested to >> subscribe. >> >> best, >> john >> >> >> >> >> --On Wednesday, May 27, 2015 21:24 +0200 Claudio Allocchio >> wrote: >> >>> >>>> A question I have to ask, is whether the people who are >>>> interested are aware of this discussion on apps-discuss? The >>>> lack of proponents may be due to this rather than a lack of >>>> interest. >>> >>> this is an abvious (but quite odd) possibility... Anybody >>> proposing any work in the APPS are should at least be aware >>> that apps-discuss is the place to go for discussion, before a >>> specific WG is identified (if any)... >>> >>> but you are right... let's ask them... ;-) >>> >>>>> Mike >>> ... >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > -- > HLS > > > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Thu May 28 01:00:42 2015 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 DA0AB1A877B for ; Thu, 28 May 2015 01:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_24=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_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 5D26QIF6_i89 for ; Thu, 28 May 2015 01:00:40 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC261A8747 for ; Thu, 28 May 2015 01:00:39 -0700 (PDT) Received: internal info suppressed Date: Thu, 28 May 2015 10:00:27 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Larry Masinter In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-273300451-1432800028=:46794" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1432800028; bh=oByqHamLu1vnNYxReanjWqJ/u2AOxoVArVtIS42NWIo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qaQ6pV/x+j3yArBGeP+Azy4akkEW+1do3dzG5FnC/BjgCx7yPyF6yfVEmq0++bIfE RQK0bQOFoc4IBPkYaWC6HkJV7Mujc8slhNU9XsZOAdAZkPQzjqwibxgfBY0dnF4oH4 q0i0C96i/QdX3pjGpJbcb0PVZyz3x7DcKMQnJLo4= Archived-At: Cc: IETF Apps Discuss , Nick Matavka Subject: Re: [apps-discuss] APP => ART: what are the criteria for IETF application work? 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 May 2015 08:00:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-273300451-1432800028=:46794 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT very true Larry... On Thu, 28 May 2015, Larry Masinter wrote: > The recent discussion about updating the Gopher protocol has > raised some heat, but the disagreements seem to rest on the > questions of how application protocol work is accepted or > rejected in the various streams, and by what criteria. > > First, it should be clear that there is no need for any > application work to wait for the IETF to do something > in order to design, build, specify, test, deploy application > protocols. Proprietary protocols are abundant, there are > many consortia, other SDOs that do application protocol > work, without any interaction with the IETF. > > A group working on applications should bring that work > to the IETF when the advantages exceed the costs, for > both the group and the whole Internet community. > > I think the main benefits rest around getting review > from the broader group, but getting review involves > the cost of arranging it, dealing with review comments > you think are irrelevant, insulting, uninformed, etc. > > Given limited resources of IETF, IETF application work > should focus on high-value projects that would benefit > from the context of being done within the IETF. > > The various channels for bringing work to the > IETF (independent,new WG,existing WG,area WG,AD) > may have different requirements for the question > β€œIs the work of interest to the Internet community?” > but can we please use the same metric for that > question? > > Being clearer to ourselves and newcomers about > application work seems like a good thing to manage > in the APP => ART transition/merger. > > Larry > β€” > > http://larry.masinter.net > > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --0-273300451-1432800028=:46794-- From nobody Thu May 28 01:59:58 2015 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 F276E1A005D for ; Thu, 28 May 2015 01:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 o8GTGFqWxU-2 for ; Thu, 28 May 2015 01:59:55 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 8663E1A005A for ; Thu, 28 May 2015 01:59:55 -0700 (PDT) Received: by obbea2 with SMTP id ea2so27685945obb.3 for ; Thu, 28 May 2015 01:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xpVcCvH4NSBptIH/0CU+bW7nMGj7FapAzMeH9w4xJnw=; b=AS7a9D9AoFFoz8jgpPrJy30Y8Lv5YFI6GDkx//bR0wxaz3QW9THochJWUjR9h5eKGW BQxMxegbECAu1RQNA20fNtfi9lm9YKGAwvgoDicYHJ++3TdEupwU8aWLSaKtsWa6w2Xz GM1qrLKHzgV/a5Nc8g34KcQptQQwRSwOAWiE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xpVcCvH4NSBptIH/0CU+bW7nMGj7FapAzMeH9w4xJnw=; b=jQ3ncLL/pK2KrCfSNFxSuX6nzWqdQ8MF8E57vGpkuiYRtGVaN+aYletB6QDG2Lwjj8 Vsl+yQXedU59fcYWO7xEdje9vtxYgDFyWlAT6U4gbPppSFBhoW/lsA3Xsy8ROF9EAA/N d+962FJzCkGzLtgigINS8pd5fXPnz2hYnW/p0hUkrIvV88jUyZj2jzxl0i2N3+vBg0W4 myGn7FVpn4IWdQ76SG6c/snIquxnYLHTr35F6MesfmrbSCqZ3iP8/bGFucbASGcRXLOP ltH3UEAutAp1+uVr6emh07DJvOtip0HZqZwMx/k2qmCyY4fD9PYodZ/85ykFUG/nKudK CRPw== X-Gm-Message-State: ALoCoQma7DeQDqgF+Kj+1CwFP5RjnhmoNvghWBYTPdJ3hYHZOAcoPxjwXYc55kRzQvcVp8GPzGIA MIME-Version: 1.0 X-Received: by 10.60.123.51 with SMTP id lx19mr1536797oeb.46.1432803594926; Thu, 28 May 2015 01:59:54 -0700 (PDT) Received: by 10.60.119.4 with HTTP; Thu, 28 May 2015 01:59:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 May 2015 09:59:54 +0100 Message-ID: From: Dave Cridland To: Larry Masinter Content-Type: multipart/alternative; boundary=047d7b5d45ee4f0e0d051720951f Archived-At: Cc: IETF Apps Discuss , Nick Matavka Subject: Re: [apps-discuss] APP => ART: what are the criteria for IETF application work? 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 May 2015 08:59:57 -0000 --047d7b5d45ee4f0e0d051720951f Content-Type: text/plain; charset=UTF-8 On 28 May 2015 at 02:34, Larry Masinter wrote: > > Given limited resources of IETF, IETF application work > should focus on high-value projects that would benefit > from the context of being done within the IETF. > > It's not wholly clear to me how one might objectively measure that, short of employing a crystal ball. In addition, it seems to me that you're not concerned with the benefit to the project in question, but only the benefit to the IETF. Now if the IETF is actually a self-serving collective of old boys, that's an ideal criterion, but I'm hoping that's not what you meant. The fact is that we have dozens of strands of work that are remarkably esoteric. There's currently discussions about forming a working group to discuss an atomic replace operation for IMAP. Hardly a groundbreaking effort for the IETF, it just happens that the folks interested in it prefer to work within the IETF structure, and output an RFC. I don't see anything wrong with this at all - if people are willing to work here, then the worst that happens is insufficient review, and if you care about that, there's a quite obvious solution. If the argument is that unless the IETF wholeheartedly gathers its resources and hurls them at a problem it's not worth solving, then we should pretty much immediately drop the IMAP REPLACE work. Only a vanishingly tiny group of people will care. No headlines will be written, either way. On the other hand, I see significant value in attracting new communities to the IETF, if only to improve the resources we have in both breadth and depth. Who knows, maybe we'll attract some of those exciting young people in their fifties. What worries me is that really the only difference between the IMAP REPLACE work and this Gopher work is that the people involved in the IMAP REPLACE work are better known in the community. That's not a criterion I'm remotely comfortable with. Being clearer to ourselves and newcomers about > application work seems like a good thing to manage > in the APP => ART transition/merger. > So we're merging areas in response to less work, and you're suggesting that the correct reaction to this merge is to reduce the amount of work. There's a logical conclusion to this. Dave. --047d7b5d45ee4f0e0d051720951f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 28 May 2015 at 02:34, Larry Masinter <masinter@adobe.com>= wrote:
Given limited resources of IETF, IETF application work
should focus on high-value projects that would benefit
from the context of being done within the IETF.


It's not wholly clear to me h= ow one might objectively measure that, short of employing a crystal ball. I= n addition, it seems to me that you're not concerned with the benefit t= o the project in question, but only the benefit to the IETF. Now if the IET= F is actually a self-serving collective of old boys, that's an ideal cr= iterion, but I'm hoping that's not what you meant.
=
The fact is that we have dozens of strands of work that are = remarkably esoteric. There's currently discussions about forming a work= ing group to discuss an atomic replace operation for IMAP. Hardly a groundb= reaking effort for the IETF, it just happens that the folks interested in i= t prefer to work within the IETF structure, and output an RFC. I don't = see anything wrong with this at all - if people are willing to work here, t= hen the worst that happens is insufficient review, and if you care about th= at, there's a quite obvious solution.

If the a= rgument is that unless the IETF wholeheartedly gathers its resources and hu= rls them at a problem it's not worth solving, then we should pretty muc= h immediately drop the IMAP REPLACE work. Only a vanishingly tiny group of = people will care. No headlines will be written, either way.

<= /div>
On the other hand, I see significant value in attracting new comm= unities to the IETF, if only to improve the resources we have in both bread= th and depth. Who knows, maybe we'll attract some of those exciting you= ng people in their fifties.

What worries me is tha= t really the only difference between the IMAP REPLACE work and this Gopher = work is that the people involved in the IMAP REPLACE work are better known = in the community. That's not a criterion I'm remotely comfortable w= ith.

Being clearer to ourselves and ne= wcomers about
application work seems like a good thing to manage
in the APP =3D> ART transition/merger.

So we're merging areas in response to less work, and you're sugg= esting that the correct reaction to this merge is to reduce the amount of w= ork.

There's a logical conclusion to this.

Dave.
--047d7b5d45ee4f0e0d051720951f-- From nobody Thu May 28 07:13:24 2015 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 C5F9C1ACD85 for ; Thu, 28 May 2015 07:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_24=0.6, J_CHICKENPOX_28=0.6, 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 1KdDRSBn4sUZ for ; Thu, 28 May 2015 07:13:21 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 BD37A1ACD80 for ; Thu, 28 May 2015 07:13:18 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so115335558igb.1 for ; Thu, 28 May 2015 07:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=AHI9nHvaXDuEv0EfTTvuzi2xjFfUQuz1/PlBHc8SThY=; b=iUpdkK2N2RsMQyQKf1oLvgKGpAf3s34tjt0skVw2GlNSJBx6a4UxIzpS0m18m0Wesy cRhU/WVhtrB0aiEiUoDa2wZWz+DmbOwqwMut1Z58E1a6VvKtTUr1er7fKi4Y1th8gFbz kZ30eSCeN0ZBs89roXXBiQKAhQJoyMNQ2t9FqS/7afrvHrldM6ZnGxa90NNAjb5gfNo1 Lyr4ROF2n6WOGsJEC1dZiJPdXwhJKFlWCxxMGcqY/HeQfPHejwAsuc8+A99hThf2Nx5p UbanBq4N0ypplMbSTMWXPQnd0OwfvYjIFdYBgam1z27WKiZZkpruJaJ+8Vpe3v3uSgTp 1ZAQ== X-Received: by 10.107.167.73 with SMTP id q70mr3683318ioe.82.1432822398222; Thu, 28 May 2015 07:13:18 -0700 (PDT) Received: from [192.168.3.13] (69-196-138-82.dsl.teksavvy.com. [69.196.138.82]) by mx.google.com with ESMTPSA id j20sm4368346igt.5.2015.05.28.07.13.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 May 2015 07:13:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Nick Matavka In-Reply-To: Date: Thu, 28 May 2015 10:13:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 20 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 May 2015 14:13:22 -0000 >=20 > Message: 1 > Date: Thu, 28 May 2015 01:34:30 +0000 > From: Larry Masinter > To: Hector Santos , John C Klensin > , Claudio Allocchio = , > "MH Michael Hammer (5304)" > Cc: Nick Matavka , IETF Apps > Discuss > Subject: [apps-discuss] APP =3D> ART: what are the criteria for IETF > application work? > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" >=20 > I think the main benefits rest around getting review > from the broader group, but getting review involves > the cost of arranging it, dealing with review comments > you think are irrelevant, insulting, uninformed, etc. >=20 > Given limited resources of IETF, IETF application work > should focus on high-value projects that would benefit > from the context of being done within the IETF. In other words, you want the IETF to be a self-serving, old-boy network, = just like the popular conception of the Freemasons. As long as it = benefits the "in-crowd", you'd move mountains to get it done, but since = the proposer isn't a member of your "club", you'll stall and evade just = so you have less work dealing with comments that *you*, as Supreme = Arbiter, Great Architect of the Universe, and Judge, Jury, and = Executioner, think are irrelevant/uninformed. Only at least the = Freemasons are an official group, with presiding officers and a = constitution, to which one might appeal if things are being done the = "wrong" way. How the hell do you quantify value, anyway? Does your = conception of "value" imply that it is an ego-stroker for you, Larry = Masinter? Or that it advances the "in-crowd"'s unwritten goals, no = matter how nebulous? >=20 > The various channels for bringing work to the > IETF (independent,new WG,existing WG,area WG,AD) > may have different requirements for the question > ?Is the work of interest to the Internet community?? > but can we please use the same metric for that > question? >=20 > Being clearer to ourselves and newcomers about > application work seems like a good thing to manage > in the APP =3D> ART transition/merger. >=20 > Larry > ? >=20 > http://larry.masinter.net >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Wed, 27 May 2015 20:16:31 -0700 > From: "Murray S. Kucherawy" > To: Larry Masinter > Cc: IETF Apps Discuss , Nick Matavka > > Subject: Re: [apps-discuss] APP =3D> ART: what are the criteria for = IETF > application work? > Message-ID: > = > Content-Type: text/plain; charset=3D"utf-8" >=20 > On Wed, May 27, 2015 at 6:34 PM, Larry Masinter = wrote: >=20 >> I think the main benefits rest around getting review >> from the broader group, but getting review involves >> the cost of arranging it, dealing with review comments >> you think are irrelevant, insulting, uninformed, etc. >>=20 >=20 > I don't think anyone is arguing any of those points, except for one: = While > it's true that sometimes one has to deal with insulting feedback, I = also > think that plain fact is unfortunate and doesn't excuse the people who = make > the choice to employ it. Multiple replies on this topic, which could = have > been delivered politely and/or constructively, were instead scattered > between plainly dismissive and pointedly rude, and I have been unable = to > figure out how it's justified. Add "self-serving" to the list---Masinter and co. have essentially said = multiple times that if it doesn't benefit them personally, it isn't = worthy of the consideration. >=20 > I certainly know what I would think of the IETF if, as a newcomer, I = had > been on the receiving end of it. This exactly. >=20 > -MSK > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: = >=20 > ------------------------------ >=20 > Message: 3 > Date: Thu, 28 May 2015 05:56:23 +0000 > From: Larry Masinter > To: "Murray S. Kucherawy" > Cc: IETF Apps Discuss , Nick Matavka > > Subject: Re: [apps-discuss] APP =3D> ART: what are the criteria for = IETF > application work? > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > If the question is whether the work is important enough to do here, to = say no is not being inappropriately dismissive. Dismissive (of the work) = is what is called for if no is the right answer. >=20 > -- > http://larry.masinter.net >=20 Who decides if "no" is the right answer? The in-group? From nobody Thu May 28 08:53:27 2015 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 4A9B51B2BD4; Thu, 28 May 2015 08:53:26 -0700 (PDT) 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 wAEOtUNDTN0O; Thu, 28 May 2015 08:53:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 677A51B2BF1; Thu, 28 May 2015 08:48:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 746DE180205; Thu, 28 May 2015 08:46:27 -0700 (PDT) To: yakov-ietf@shaftek.org, tony+sss@maillennium.att.com, Alexey.Melnikov@isode.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150528154627.746DE180205@rfc-editor.org> Date: Thu, 28 May 2015 08:46:27 -0700 (PDT) Archived-At: Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Rejected] RFC6839 (4367) 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 May 2015 15:53:26 -0000 The following errata report has been rejected for RFC6839, "Additional Media Type Structured Syntax Suffixes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6839&eid=4367 -------------------------------------- Status: Rejected Type: Technical Reported by: Yakov Shafranovich Date Reported: 2015-05-15 Rejected by: Barry Leiba (IESG) Section: 3.1 Original Text ------------- Encoding considerations: Per [RFC4627], JSON is allowed to be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045]). Corrected Text -------------- Encoding considerations: binary as per section 11 of RFC 7159 Notes ----- RFC 7159, section 11 specifies that encoding for JSON is binary. --VERIFIER NOTES-- This does not qualify as an erratum, but do see the mailing list discussion that starts here: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg14321.html -------------------------------------- RFC6839 (draft-ietf-appsawg-media-type-suffix-regs-08) -------------------------------------- Title : Additional Media Type Structured Syntax Suffixes Publication Date : January 2013 Author(s) : T. Hansen, A. Melnikov Category : INFORMATIONAL Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri May 29 10:42:30 2015 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 6D2C11AC3E5 for ; Thu, 28 May 2015 15:28:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, 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 fjdShWq8Bz0B for ; Thu, 28 May 2015 15:28:35 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3868D1A9167 for ; Thu, 28 May 2015 15:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1432852116; x=1464388116; h=message-id:date:to:from:subject; bh=mvxIZcMXQin+0o6YA0cfdYcZDUd7Fu9NsGeW5qjewVs=; b=rvypMfMpfqKm4qflDAqvcKais4+Yux1WAxQgnRWY6qxmEGQii11xgJUJ HAPxZ72USZtADUyg+G0xdRxA3/JOxpmNF5MZx+zhs6FWZqU9aUBunl/lS zxEM11i2XLyTvEO5NDpwQjdMvhRcgjDoC0HqKOJMti+BK3+NsegaoxV3O s=; X-IronPort-AV: E=McAfee;i="5700,7163,7815"; a="90946959" Received: from unknown (HELO ironmsg02-R.qualcomm.com) ([172.30.46.16]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 May 2015 15:28:36 -0700 X-IronPort-AV: E=Sophos;i="5.13,514,1427785200"; d="scan'208";a="481016787" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 May 2015 15:28:33 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t4SMSX1N007373; Thu, 28 May 2015 15:28:33 -0700 X-IronPort-AV: E=Sophos;i="5.13,514,1427785200"; d="scan'208";a="981806926" X-ojodefuego: yes Received: from myvpn-l-00214.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.133.249]) by Ironmsg04-R.qualcomm.com with ESMTP; 28 May 2015 15:28:32 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Thu, 28 May 2015 15:28:31 -0700 To: (apps-discuss@ietf.org) From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 10:42:26 -0700 Subject: [apps-discuss] Virtual Bar-BoF for SLIM 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 May 2015 22:28:37 -0000 I'm sending this message to the Apps-Discuss list, but all discussion should take place on the SLIM list. I've created a Doodle poll to set a time and date for a virtual Bar-BoF for SLIM. To follow up on the SLIM face-to-face discussion in Dallas, this virtual bar-BoF provides an opportunity for further discussion with a goal of gaining consensus on moving forward with a charter. In particular: (1) Are there objections to the current proposed charter wording, or is it acceptable? (2) Are there objections to moving forward on this basis? Please participate in the Doodle poll to select the time/date, and then in the virtual Bar-BoF. http://doodle.com/ryuai9ieqxi7hue2 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Most people and their lazy, conventional ways of thinking wear down our childlike thinking powers over time. And we help them. --Marco Marsan, from 'Think Naked' From nobody Fri May 29 15:01:51 2015 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 065021A89AB; Fri, 29 May 2015 15:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qbOE8Y55mkhC; Fri, 29 May 2015 15:01:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A821A89A6; Fri, 29 May 2015 15:01:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529220149.25007.60400.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 15:01:49 -0700 Archived-At: Subject: [apps-discuss] Applications and Real-Time Area (ART) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iesg@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 22:01:50 -0000 On 28 May, the IESG approved the creation of the Applications and Real-Time (ART) Area, which will replace the existing Applications (APP) and Real-time Applications and Infrastructure (RAI) Areas. All existing working groups from those two areas will move into the new ART Area, and the three existing area directors -- Alissa Cooper, Barry Leiba, and Ben Campbell -- will be the ART ADs (or "ART Directors"). In addition, the CDNI working group will move from TSV to ART. Barry will be the responsible AD for CDNI, and no other AD assignments will change. The Secretariat will immediately begin working on the administrative changes required, and the change from APP+RAI to ART will be effective as soon as the administrative work can be completed. From nobody Sat May 30 02:58:11 2015 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 3B8491A1B14 for ; Sat, 30 May 2015 02:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, SPF_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 MAc71FC8IQ9B for ; Sat, 30 May 2015 02:58:08 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766251A1B11 for ; Sat, 30 May 2015 02:58:08 -0700 (PDT) Received: from [192.168.2.177] (unknown [93.217.114.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 78C6315A0598; Sat, 30 May 2015 11:58:06 +0200 (CEST) Message-ID: <556989AF.1070907@greenbytes.de> Date: Sat, 30 May 2015 11:58:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nick Matavka , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [apps-discuss] gopher work, was: apps-discuss Digest, Vol 88, Issue 20 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, 30 May 2015 09:58:10 -0000 On 2015-05-28 16:13, Nick Matavka wrote: >> Message: 1 >> Date: Thu, 28 May 2015 01:34:30 +0000 >> From: Larry Masinter >> To: Hector Santos , John C Klensin >> , Claudio Allocchio , >> "MH Michael Hammer (5304)" >> Cc: Nick Matavka , IETF Apps >> Discuss >> Subject: [apps-discuss] APP => ART: what are the criteria for IETF >> application work? >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >> >> I think the main benefits rest around getting review >> from the broader group, but getting review involves >> the cost of arranging it, dealing with review comments >> you think are irrelevant, insulting, uninformed, etc. >> >> Given limited resources of IETF, IETF application work >> should focus on high-value projects that would benefit >> from the context of being done within the IETF. > > In other words, you want the IETF to be a self-serving, old-boy network, just like the popular conception of the Freemasons. As long as it benefits the "in-crowd", you'd move mountains to get it done, but since the proposer isn't a member of your "club", you'll stall and evade just so you have less work dealing with comments that *you*, as Supreme Arbiter, Great Architect of the Universe, and Judge, Jury, and Executioner, think are irrelevant/uninformed. Only at least the Freemasons are an official group, with presiding officers and a constitution, to which one might appeal if things are being done the "wrong" way. How the hell do you quantify value, anyway? Does your conception of "value" imply that it is an ego-stroker for you, Larry Masinter? Or that it advances the "in-crowd"'s unwritten goals, no matter how nebulous? Nick, this WG discusses whether work on Gopher fits here. Rants like these are not helpful at all, and likely will affect the outcome. FWIW, I fully agree with Larry. > ... Best regards, Julian From nobody Sun May 31 17:16:45 2015 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 11E861ACEFD for ; Sun, 31 May 2015 17:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 JNLxLiOsNciP for ; Sun, 31 May 2015 17:16:42 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 4EF761A88E4 for ; Sun, 31 May 2015 17:16:42 -0700 (PDT) Received: by igbjd9 with SMTP id jd9so49798046igb.1 for ; Sun, 31 May 2015 17:16:41 -0700 (PDT) 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 :content-type; bh=d7WYw6lCrAZ7KEwz3RMpuYP1xNrqzfLwVrajKF/lEYo=; b=HabcYnhXFKAoCbHdXqTjYoJQVfkm0Qh2Yey74OXuIjyJDChZou//NGV+B8NS1FxV0F nWWsy6IHgtD1N5Yv3cH7s3CzeVsIWDvqjHOH5TjbjX0xN4PKjDlOTjUyVcW0sJigDRWd zSa6GsMxL3qgJKR4ySC6EWDy5fcw2uLx++KGOzOjUBBfRvCgvN3cD5blt/1pqNnjRLSj 1jBz1JgONERzxvFbTOZK3Hf2zXCs1nkXDy+u/xcHegqEz0RScs5SXOzU61S7f/wz3pMg t5P1HtJVvN+X6BumsS+gpDJfNNWgHtOKKGBjFtxlbwIrUrA7sH1dxMzIJyuxTwrHqPno 1XgQ== MIME-Version: 1.0 X-Received: by 10.42.93.17 with SMTP id v17mr2375084icm.42.1433117801445; Sun, 31 May 2015 17:16:41 -0700 (PDT) Received: by 10.107.14.77 with HTTP; Sun, 31 May 2015 17:16:41 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 May 2015 20:16:41 -0400 Message-ID: From: Nick Matavka To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=90e6ba614ce67a008a051769bd43 Archived-At: Subject: Re: [apps-discuss] apps-discuss Digest, Vol 88, Issue 23 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, 01 Jun 2015 00:16:44 -0000 --90e6ba614ce67a008a051769bd43 Content-Type: text/plain; charset=UTF-8 Julian Reschke wrote: > Nick, this WG discusses whether work on Gopher fits here. Rants like > these are not helpful at all, and likely will affect the outcome. > FWIW, I fully agree with Larry. > Best regards, Julian I didn't mean to be ranty, Julian. I meant to raise a point, that's all, and I still haven't received an answer. *Who* decides what a "high-value project" is? I think it's an important question. If it's group "consensus", how is "consensus" defined? Does consensus mean EVERYONE agrees (unanimous), or simply the prevailing wind of opinion? Larry makes good points, I agree, but his tone of voice is infuriating sometimes. What is the definition of a high-value project, anyway? To whom should the project be highly valuable? If the answer to this is, "the Internet-using public," who judges what is valuable to the public? Larry's right in being concerned about what I would call the signal-to-noise ratio of this mailing list. The fact is that there is the possibility and, in fact, the reality of irrelevant, insulting, and/or uninformed feedback. Some people just can't be professional about it; I'm not talking about Larry or myself, because I know we're decent people who just can't seem to disagree civilly, but the fact is that there are people with a consistent history of making unconstructive feedback either out of ignorance or because it amuses them. And if I were him, I would raise another reservation; not a pure objection, because I wouldn't object to my own project, but I would ask if the author is able and willing to work within the IETF framework. I would ask if the author or authors are willing to listen to, and heed, technically reasonable input and to have drafts updated within a reasonable turnaround time. I would also think about whether the author responds in an adult way to feedback, either positive or negative. I have no objection to Masinter's opinions, but rather his wording. In fact, I agree with the questions he raises, but he should define his words more carefully because what he writes might be mistaken for belligerence---this is why I replied to his comments in an equally belligerent tone, but with reasoned argument. Fraternal regards, Ed Matavka --90e6ba614ce67a008a051769bd43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Julian Reschke wrote:
> Nick, this WG discusses whet= her work on Gopher fits here. Rants like
> these are not helpful at a= ll, and likely will affect the outcome.

> FWIW, I fully agree wit= h Larry.

> Best regards, Julian

I didn'= ;t mean to be ranty, Julian.=C2=A0 I meant to raise a point, that's all= , and I still haven't received an answer.

*Who* deci= des what a "high-value project" is?=C2=A0 I think it's an imp= ortant question.=C2=A0 If it's group "consensus", how is &quo= t;consensus" defined?=C2=A0 Does consensus mean EVERYONE agrees (unani= mous), or simply the prevailing wind of opinion?=C2=A0 Larry makes good poi= nts, I agree, but his tone of voice is infuriating sometimes.=C2=A0 What is= the definition of a high-value project, anyway?=C2=A0 To whom should the p= roject be highly valuable?=C2=A0 If the answer to this is, "the Intern= et-using public," who judges what is valuable to the public?

Larry's right in being concerned about what I would cal= l the signal-to-noise ratio of this mailing list.=C2=A0 The fact is that th= ere is the possibility and, in fact, the reality of=C2=A0irrelevant, insulting, and/or uninformed feedback.=C2=A0 Som= e people just can't be professional about it; I'm not talking about= Larry or myself, because I know we're decent people who just can't= seem to disagree civilly, but the fact is that there are people with a con= sistent history of making unconstructive feedback either out of ignorance o= r because it amuses them.

And if I were him, = I would raise another reservation; not a pure objection, because I wouldn&#= 39;t object to my own project, but I would ask if the author is able and wi= lling to work within the IETF framework.=C2=A0 I would ask if the author or= authors are willing to listen to, and heed, technically reasonable input a= nd to have drafts updated within a reasonable turnaround time.=C2=A0 I woul= d also think about whether the author responds in an adult way to feedback,= either positive or negative.

I have no= objection to Masinter's opinions, but rather his wording.=C2=A0 In fac= t, I agree with the questions he raises, but he should define his words mor= e carefully because what he writes might be mistaken for belligerence---thi= s is why I replied to his comments in an equally belligerent tone, but with= reasoned argument.

<= /span>
Fraternal regards,=

Ed Matavka
--90e6ba614ce67a008a051769bd43--