From nobody Mon Nov 3 03:35:07 2014 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 7B3F61A00CA; Mon, 3 Nov 2014 03:35:04 -0800 (PST) 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 X61DbqnGXGFF; Mon, 3 Nov 2014 03:35:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E231A00B9; Mon, 3 Nov 2014 03:34:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: barryleiba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141103113451.14455.61839.idtracker@ietfa.amsl.com> Date: Mon, 03 Nov 2014 03:34:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SzeDs3dXRUoFbQqxbicd8Lxjs9A Cc: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, appsawg-chairs@tools.ietf.org, iesg-secretary@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Publication has been requested for draft-ietf-appsawg-uri-scheme-reg-04 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, 03 Nov 2014 11:35:04 -0000 Alexey Melnikov has requested publication of draft-ietf-appsawg-uri-scheme-reg-04 as Best Current Practice on behalf of the APPSAWG working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Mon Nov 3 05:08:52 2014 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 5ED181A0146 for ; Mon, 3 Nov 2014 05:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 vJMnf0c1xhH6; Mon, 3 Nov 2014 05:08:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9861A0191; Mon, 3 Nov 2014 05:08:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, alexey.melnikov@isode.com, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> Date: Mon, 03 Nov 2014 05:08:45 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ychsVcDvBkMETr_D9mpH8EB6XyI Subject: [apps-discuss] ID Tracker State Update Notice: 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, 03 Nov 2014 13:08:49 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Mon Nov 3 08:21:45 2014 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 F1DF51A0469; Mon, 3 Nov 2014 08:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 gHCBCcZhzJH7; Mon, 3 Nov 2014 08:21:41 -0800 (PST) Received: from bsa2.jck.com (ns.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 5BB281A19FC; Mon, 3 Nov 2014 08:21:38 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XlKNp-000Az7-Cr; Mon, 03 Nov 2014 11:21:33 -0500 Date: Mon, 03 Nov 2014 11:21:28 -0500 From: John C Klensin To: alexey.melnikov@isode.com Message-ID: <86601DE9FC5C6E8AB9E981FE@JcK-HP8200.jck.com> In-Reply-To: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> References: <20141103130845.9428.55882.idtracker@ietfa.amsl.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: http://mailarchive.ietf.org/arch/msg/apps-discuss/-YqZ2V1YcgpGna09zk14H68Ufb4 Cc: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, urn@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] ID Tracker State Update Notice: 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, 03 Nov 2014 16:21:45 -0000 --On Monday, November 03, 2014 05:08 -0800 IETF Secretariat wrote: > IESG state changed to AD Evaluation from Publication Requested > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme- > reg/ Alexey and relevant ADs, Independent of its particular merits, I believe this proposal should be put on hold. A controversy has been going on in the URNbis WG for some time that is, at root, how much RFC 3986 constrains the use, assumptions, and semantics of various URIs, including, but not limited to URNs (i.e., URI-format identifiers that use the "urn:" scheme) and more general name, or even "urn", systems that use other schemes. At times in that discussion, several people have proposed that some things people want to do with URNs would be ok in a different scheme, but not the "urn:" one. Keeping in mind that there is no requirement for URNs to resolve and that some of our URI assumptions include resolution, if such additional schemes were created, the community would presumably need to review their relationship to various understandings of RFC 3986 as well. Neither the AppsAWG nor, as far as I know, anyone else has done a careful review of draft-ietf-appsawg-uri-scheme-reg against developments and discussions in URNBIS. It cannot be evaluated against the conclusions of URNBIS because, at least based on consensus statements by the Chair or co-Chairs, such conclusions have not been reached. The above creates a situation in which we could either end up issuing contradictory standards or or in which the advancement of this specification could be used to turn the task of URNBIS from "difficult" to "impossible without making URNs much less useful". Consequently, this specification should either be put on hold until after URNBIS successfully concludes its work or should be assigned to URNBIS for a pre-IETF-LC review and progressed into IETF LC only after URNBIS has affirmatively reached consensus that it does not pose a problem. regards, john From nobody Mon Nov 3 08:24:33 2014 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 EB92C1A19F3; Mon, 3 Nov 2014 08:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMjlG69vqfpI; Mon, 3 Nov 2014 08:24:29 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25C91A19E4; Mon, 3 Nov 2014 08:24:25 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gq15so9882983lab.15 for ; Mon, 03 Nov 2014 08:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/y7x7FhClBWm4poTwLQWuh5h9pc8JPnCaLUOXQRz2Xo=; b=T/soyARZ316px8Iz7r6vjErQfTiO3IGs1bqIDdv+qlZIPLRnmalacUR5Jk5JKpcIwH xT7Rbu/F4vdC5jGdIY1DEVssg001gWSZ/TciLhCGYwhUtZp1SOnCEv86H/BvZcf4cIiD t6VZFPrX4OmxoVLc6NkJdDeQjLspSBaM6mxLbygR3Oh4PlNCu1zYOtgwO4x0Bm21ur14 qLmv49LAnrNd80KrDc1+jNbxIGfq2m+e2IJVXEGO0vfI37zObSVQHiV18jsNXm3lSGKW ecoT8Kz2qDxdrzkXAbGrqwa/XKRF9rT0/0DIc8oyYKaenopgWOOBWA3u2HCeukDf6Usu JZyQ== MIME-Version: 1.0 X-Received: by 10.112.132.104 with SMTP id ot8mr51942865lbb.3.1415031863918; Mon, 03 Nov 2014 08:24:23 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Mon, 3 Nov 2014 08:24:23 -0800 (PST) In-Reply-To: <86601DE9FC5C6E8AB9E981FE@JcK-HP8200.jck.com> References: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> <86601DE9FC5C6E8AB9E981FE@JcK-HP8200.jck.com> Date: Mon, 3 Nov 2014 11:24:23 -0500 X-Google-Sender-Auth: 1EE_foDAFu0melFYPMlkWI71g3k Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/scUlQpD1Fl-ZAnJnq-spbVXZzPU Cc: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, "urn@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] ID Tracker State Update Notice: 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, 03 Nov 2014 16:24:31 -0000 So noted. There is also a discussion going on with W3C about URIs, IRIs, and URLs, which has to be resolved before this document moves ahead. I'll be holding it in AD Evaluation state, and making sure the appropriate groups and people get involved before we continue, Barry, the relevant AD On Mon, Nov 3, 2014 at 11:21 AM, John C Klensin wrote: > > > --On Monday, November 03, 2014 05:08 -0800 IETF Secretariat > wrote: > >> IESG state changed to AD Evaluation from Publication Requested >> ID Tracker URL: >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme- >> reg/ > > Alexey and relevant ADs, > > Independent of its particular merits, I believe this proposal > should be put on hold. A controversy has been going on in the > URNbis WG for some time that is, at root, how much RFC 3986 > constrains the use, assumptions, and semantics of various URIs, > including, but not limited to URNs (i.e., URI-format identifiers > that use the "urn:" scheme) and more general name, or even > "urn", systems that use other schemes. At times in that > discussion, several people have proposed that some things people > want to do with URNs would be ok in a different scheme, but not > the "urn:" one. Keeping in mind that there is no requirement > for URNs to resolve and that some of our URI assumptions include > resolution, if such additional schemes were created, the > community would presumably need to review their relationship to > various understandings of RFC 3986 as well. > > Neither the AppsAWG nor, as far as I know, anyone else has done > a careful review of draft-ietf-appsawg-uri-scheme-reg against > developments and discussions in URNBIS. It cannot be evaluated > against the conclusions of URNBIS because, at least based on > consensus statements by the Chair or co-Chairs, such conclusions > have not been reached. > > The above creates a situation in which we could either end up > issuing contradictory standards or or in which the advancement > of this specification could be used to turn the task of URNBIS > from "difficult" to "impossible without making URNs much less > useful". Consequently, this specification should either be put > on hold until after URNBIS successfully concludes its work or > should be assigned to URNBIS for a pre-IETF-LC review and > progressed into IETF LC only after URNBIS has affirmatively > reached consensus that it does not pose a problem. > > regards, > john > > From nobody Mon Nov 3 08:51:21 2014 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 46A1C1A1A33; Mon, 3 Nov 2014 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 INjYHBEOe6ep; Mon, 3 Nov 2014 08:51:15 -0800 (PST) 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 B02F01A1A1B; Mon, 3 Nov 2014 08:51:15 -0800 (PST) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XlKqT-000B3D-Uw; Mon, 03 Nov 2014 11:51:09 -0500 Date: Mon, 03 Nov 2014 11:51:04 -0500 From: John C Klensin To: Barry Leiba Message-ID: <517D07E9E55809F8F97AA169@JcK-HP8200.jck.com> In-Reply-To: References: <20141103130845.9428.55882.idtracker@ietfa.amsl.com> <86601DE9FC5C6E8AB9E981FE@JcK-HP8200.jck.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: http://mailarchive.ietf.org/arch/msg/apps-discuss/7N1svSi-81tn-Qba-oEC1L1Sdg4 Cc: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org, urn@ietf.org, Apps Discuss Subject: Re: [apps-discuss] ID Tracker State Update Notice: 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, 03 Nov 2014 16:51:17 -0000 --On Monday, November 03, 2014 11:24 -0500 Barry Leiba wrote: > So noted. There is also a discussion going on with W3C about > URIs, IRIs, and URLs, which has to be resolved before this > document moves ahead. I'll be holding it in AD Evaluation > state, and making sure the appropriate groups and people get > involved before we continue, Thanks Barry. Exactly what I had hoped for and consider appropriate. Let me also use this as an advertisement: people in AppsAWG who are interested in or concerned about this topic and who have not been following the URNBIS work, probably want to do so. Having issues and positions emerge within WG discussions rather than during IETF Last Call is always A Good Thing. john From nobody Mon Nov 3 15:06:53 2014 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 DDD981A879C for ; Sun, 2 Nov 2014 05:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctFRZhUmSc1L for ; Sun, 2 Nov 2014 05:40:06 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E83D1A879A for ; Sun, 2 Nov 2014 05:40:06 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so2446530lbv.0 for ; Sun, 02 Nov 2014 05:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=fDKCbYb3Qe9Z3zR0nwMxMM3KNYL/B7gkJNIAhn9DE8c=; b=SrCCUcqyVqQzbqvXRHlFjKXUCfMXjcQs9onZp7GIVpTk06vTpdDqMMRVTg2Mx9bPuP i5oB8mkJVJsZb8qAF8PYWJt6NQc40A4BE2138gGYRXahQ6B0617qhznSsydmT1++MGQN 7Z1Hg2Q+LlCSuJfORCPnpyBZg5Y/j4QoMx5snpuzomToMYAR4xejzLxqUo6FXh3ltiE0 Muu9LQ2494BaKSyzlWQMdKH+wfgntyxpiT7ereFUubDH7qRB+9blvo2Qf00n+p0idZvc GHC2vG/neOgd0CVqrSLVWWyppm2aRtYqp1quyhimQ4+GHkOjz+7I8vLUJadczCRs8a/d snSQ== MIME-Version: 1.0 X-Received: by 10.152.234.136 with SMTP id ue8mr42656631lac.21.1414935604480; Sun, 02 Nov 2014 05:40:04 -0800 (PST) Received: by 10.114.2.14 with HTTP; Sun, 2 Nov 2014 05:40:04 -0800 (PST) Date: Sun, 2 Nov 2014 14:40:04 +0100 Message-ID: From: Daniel Migault To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a11349c4c15cf460506e05eca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0Q7idjB360b5wVpPgqLWOugNlGc X-Mailman-Approved-At: Mon, 03 Nov 2014 15:06:52 -0800 Cc: tzdist-chairs@tools.ietf.org Subject: [apps-discuss] Update of the Time Zone Data Distribution Service WG (tzdist) 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, 02 Nov 2014 13:40:09 -0000 --001a11349c4c15cf460506e05eca Content-Type: text/plain; charset=UTF-8 Hi, Please find herein an update of the tzdist WG. The tzdist WG has been created in end of June 2014 [1] and milestones have been approved in August. The WG is pretty active with between 200/300 per month in September/October. Milestones are mentioned below. tzdist is currently in line with its milestones. """ Done Adopt time zone data distribution protocol as WG document Done Adopt a CalDAV extension draft as WG document Jan 2015 WGLC for time zone data distribution protocol draft Jan 2015 WGLC for CalDAV extension draft Mar 2015 Request publication of time zone data distribution protocol draft as Standards Track RFC Mar 2015 Request publication of CalDAV extension draft as Standards Track RFC """ There are currently two WG documents: a) draft-ietf-tzdist-service-02[ 2] Time Zone Data Distribution Service b) draft-ietf-tzdist-caldav-timezone-ref-00[3] CalDAV: Time Zones by Reference draft-ietf-tzdist-service-02 is the more active draft with 11 open issues out of 21. Open issues are addressed though the mailing list as weel as during a phone conference on October 24. Discussions lead to major changes in the design of the protocol, and are likely to reach consensus by the end of the year. draft-ietf-tzdist-caldav-timezone-ref-00 has still 3 open issues out of 10. The WG will address these issues once draft-ietf-tzdist-service has reached consensus. [1] http://datatracker.ietf.org/wg/tzdist/charter/ [2] http://tools.ietf.org/html/draft-ietf-tzdist-service-02 [3] http://tools.ietf.org/html/draft-ietf-tzdist-caldav-timezone-ref-00 -- Daniel Migault Orange Labs / Security Lab +33 (0) 1 45 29 60 52 +33 (0) 6 70 72 69 58 --001a11349c4c15cf460506e05eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find herein an update of the tzdis= t WG.

The tzdist WG has been created in end of June 2014 [1] and=20 milestones have been approved in August. The WG is pretty active with=20 between 200/300 per month in September/October.

Milestones are ment= ioned below. tzdist is currently in line with its milestones.
=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0 """
=C2=A0=C2=A0=C2=A0 D= one =C2=A0=C2=A0=C2=A0 Adopt time zone data distribution protocol as WG doc= ument
=C2=A0=C2=A0=C2=A0 Done =C2=A0=C2=A0=C2=A0 Adopt a CalDAV extensio= n draft as WG document
=C2=A0=C2=A0=C2=A0 Jan 2015 WGLC for time zone da= ta distribution protocol draft
=C2=A0=C2=A0=C2=A0 Jan 2015 WGLC for CalD= AV extension draft
=C2=A0=C2=A0=C2=A0 Mar 2015 Request publication of ti= me zone data distribution protocol draft as Standards Track RFC
=C2=A0= =C2=A0=C2=A0 Mar 2015 Request publication of CalDAV extension draft as Stan= dards Track RFC
=C2=A0=C2=A0=C2=A0 """
=C2=A0
There= are currently two WG documents:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 a)=C2=A0 draft-ietf-tzdist-service-02[
2] Time Zone Data Distributi= on Service
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b) draft-ietf-tzdi= st-caldav-timezone-ref-00[3] CalDAV: Time Zones by Reference

draft-i= etf-tzdist-service-02 is the more active draft with 11 open issues out of 21. Open issues are addressed though the mailing list as weel as during a phone conference=20 on October 24. Discussions lead to major changes in the design of the=20 protocol, and are likely to reach consensus by the end of the year.

= draft-ietf-tzdist-caldav-timezone-ref-00 has still 3 open issues out of 10. The WG will address these issues=20 once draft-ietf-tzdist-service has reached consensus.

[1] http://d= atatracker.ietf.org/wg/tzdist/charter/
[2] http://tools.i= etf.org/html/draft-ietf-tzdist-service-02
[3] http://tools.ietf.org/html/draft-ietf-tzdist-caldav-timezone-ref-00



--
Daniel Migaul= t
Orange Labs / Security Lab
+33 (0) 1 45 29 60 52
+33 (0) 6 70 72= 69 58
--001a11349c4c15cf460506e05eca-- From nobody Tue Nov 4 03:26:00 2014 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 8C7AA1A008B for ; Tue, 4 Nov 2014 03:25:59 -0800 (PST) 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 5yB94qHECaOl for ; Tue, 4 Nov 2014 03:25:57 -0800 (PST) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5BE1A008A for ; Tue, 4 Nov 2014 03:25:56 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XlcFC-0002Db-fc; Tue, 04 Nov 2014 11:25:50 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XlcFC-0002SW-8F; Tue, 04 Nov 2014 11:25:50 +0000 Message-ID: <5458B7BE.4090000@ninebynine.org> Date: Tue, 04 Nov 2014 11:25:50 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stian Soiland-Reyes , Ira McDonald References: <54235269.2060002@seantek.com> <01PCZ1WHF6Q80000SM@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8ylMtWhtMVEgFSmsnJb91_s1SPQ Cc: Ned Freed , media-types@iana.org, IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] A proposal for a new top-level media type: archive 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, 04 Nov 2014 11:25:59 -0000 On 04/11/2014 10:40, Stian Soiland-Reyes wrote: > Hi, > > Was any decission made on the new archive/ tree? Not that I've seen. But that doesn't stop you from drafting and submitting a proposal for one - http://tools.ietf.org/html/rfc2077 might provide a model (sic) to follow. > Can we just start sending in submission? I would like to submit my > archive/robundle+zip as we want to stabilize our spec. AFAIK, there's no way to register that until the top-level type is approved, which I think requires standards action. But you might submit an Internet-draft in parallel with a top-level type proposal. #g -- > > On 13 October 2014 10:35, Stian Soiland-Reyes > wrote: >> +1 as well, specially on the general handling. For instance any archive/* >> could go through antivirus check. >> >> We have an archive type we have been meaning to get out of draft status and >> register with IANA as well, we currently call it >> application/vnd.wf4ever.robundle+zip but archive/robundle+zip would be a >> much better fit. >> >> https://w3id.org/bundle >> >> On 25 Sep 2014 06:06, "Ira McDonald" wrote: >>> Hi, >>> >>> +1 >>> >>> Cheers, >>> - Ira >>> >>> >>> Ira McDonald (Musician / Software Architect) >>> Co-Chair - TCG Trusted Mobility Solutions WG >>> Chair - Linux Foundation Open Printing WG >>> Secretary - IEEE-ISTO Printer Working Group >>> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG >>> IETF Designated Expert - IPP & Printer MIB >>> Blue Roof Music / High North Inc >>> http://sites.google.com/site/blueroofmusic >>> http://sites.google.com/site/highnorthinc >>> mailto: blueroofmusic@gmail.com >>> Winter 579 Park Place Saline, MI 48176 734-944-0094 >>> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >>> >>> >>> On Wed, Sep 24, 2014 at 10:38 PM, Ned Freed wrote: >>>>> On 25 September 2014 09:23, Sean Leonard wrote: >>>>>> Colleagues on media-types and apps-discuss: >>>>>> >>>>>> I would like to propose that the IETF create a new top-level media >>>>>> type: >>>>>> archive. >>>>>> >>>>>> >>>>> Colour me interested. >>>> Yeah, me too. I'm surpised nobody has suggested this before. >>>> >>>> Ned >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >>> _______________________________________________ >>> media-types mailing list >>> media-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/media-types >>> > > From nobody Tue Nov 4 07:53:30 2014 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 D49A71A8AAA for ; Tue, 4 Nov 2014 07:53:26 -0800 (PST) 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 AWEgwPH-sIOx for ; Tue, 4 Nov 2014 07:53:25 -0800 (PST) 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 E80351A8AA5 for ; Tue, 4 Nov 2014 07:53:21 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sA4FrAFZ025165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Nov 2014 07:53:13 -0800 Message-ID: <5458F65F.8040906@dcrocker.net> Date: Tue, 04 Nov 2014 07:53:03 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Graham Klyne , Stian Soiland-Reyes , Ira McDonald References: <54235269.2060002@seantek.com> <01PCZ1WHF6Q80000SM@mauve.mrochek.com> <5458B7BE.4090000@ninebynine.org> In-Reply-To: <5458B7BE.4090000@ninebynine.org> Content-Type: text/plain; charset=ISO-8859-1 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, 04 Nov 2014 07:53:14 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/t4-Gh5CnacFGGw3dBoPTOs3qqMs Cc: Ned Freed , media-types@iana.org, IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] A proposal for a new top-level media type: archive 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, 04 Nov 2014 15:53:27 -0000 On 11/4/2014 3:25 AM, Graham Klyne wrote: > AFAIK, there's no way to register that until the top-level type is > approved, which I think requires standards action. But you might submit > an Internet-draft in parallel with a top-level type proposal. +1 I remain conflicted about doing this new top-level type -- per the notes I posted earlier -- but it's clear that it has meaningful, strong and broad support. (Including from one or another curmudgeon who is typically ready to attack marginal ideas...) As such, you really should just charge ahead. Formal "decision-making" comes after doing the write-up(s). d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 4 15:23:38 2014 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 D78EF1A0191 for ; Tue, 4 Nov 2014 02:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 YjkOgMVH1pTc for ; Tue, 4 Nov 2014 02:40:34 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4702C1A004E for ; Tue, 4 Nov 2014 02:40:33 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id va2so10514862obc.35 for ; Tue, 04 Nov 2014 02:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mygrid.org.uk; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=8YaFSWYEaK8LNdS8Jp6aMDWcyoPyv7pOPU+eORtaY84=; b=V/Wlyuknmeu7eRMYKb15s+9VQtMuV8ieJ2lsQxcNqnW8JPn6OfYzjUSyAMIx1TMa+x yBHZGgtXhFzq7aDQiHI6XPZzsDfdAKnqWdhKbMkUXASNidBYr+UDroDJExxtUsLa6R/D SY+rw1xcoisbJ2sgmPTC6PMm9vEcl5ZdoWXSo= 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=8YaFSWYEaK8LNdS8Jp6aMDWcyoPyv7pOPU+eORtaY84=; b=h1VY5NMBHCqWxy2FUohMijSM7HuQcq3SxD3HL4VeuTLcBrqEG0c4KjVal88QRI8QZW LEUAn092/szq86afxFdeKlD6CyL/vFKAivelzkg/FgSYsK/89DFzi/8TscCjQ2svGOfB g2pYl093FualVzeAl7KDvRZ7eP+1jPSV7o4ZiAiBApIA1awwZqg+h87NUdBfUQhyhW+U UfPlxiXCgTsCFZrFnWeufjrPIPGLyjJbQMB7NE6/yDMRqKnMrknPnLoH3NGrnoniG7Nc TLOB64UgHpNZU5ebwjfm3xTe1P0Km8NxE0HoRy4uOZAvpfPFSO57NFvrA8PHrut3eK7d SHpw== X-Gm-Message-State: ALoCoQlktvQ5Lh3dqb4oH7Sym2bg+zjjInYCBBZ7V3zJhjIriX+YQUob4ncV9YzY6AzwkwIFHNt8 X-Received: by 10.60.82.163 with SMTP id j3mr41954332oey.13.1415097633222; Tue, 04 Nov 2014 02:40:33 -0800 (PST) MIME-Version: 1.0 Sender: stian@mygrid.org.uk Received: by 10.76.130.116 with HTTP; Tue, 4 Nov 2014 02:40:11 -0800 (PST) In-Reply-To: References: <54235269.2060002@seantek.com> <01PCZ1WHF6Q80000SM@mauve.mrochek.com> From: Stian Soiland-Reyes Date: Tue, 4 Nov 2014 10:40:11 +0000 X-Google-Sender-Auth: LrI_MKmMbA2oZrpHjFpuKzsnTHo Message-ID: To: Ira McDonald Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gD3iRZwtxNfvUomqeGTdboo7BTA X-Mailman-Approved-At: Tue, 04 Nov 2014 15:23:36 -0800 Cc: IETF Apps Discuss , Ned Freed , media-types@iana.org Subject: Re: [apps-discuss] [media-types] A proposal for a new top-level media type: archive 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, 04 Nov 2014 10:40:37 -0000 Hi, Was any decission made on the new archive/ tree? Can we just start sending in submission? I would like to submit my archive/robundle+zip as we want to stabilize our spec. On 13 October 2014 10:35, Stian Soiland-Reyes wrote: > +1 as well, specially on the general handling. For instance any archive/* > could go through antivirus check. > > We have an archive type we have been meaning to get out of draft status and > register with IANA as well, we currently call it > application/vnd.wf4ever.robundle+zip but archive/robundle+zip would be a > much better fit. > > https://w3id.org/bundle > > On 25 Sep 2014 06:06, "Ira McDonald" wrote: >> >> Hi, >> >> +1 >> >> Cheers, >> - Ira >> >> >> Ira McDonald (Musician / Software Architect) >> Co-Chair - TCG Trusted Mobility Solutions WG >> Chair - Linux Foundation Open Printing WG >> Secretary - IEEE-ISTO Printer Working Group >> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG >> IETF Designated Expert - IPP & Printer MIB >> Blue Roof Music / High North Inc >> http://sites.google.com/site/blueroofmusic >> http://sites.google.com/site/highnorthinc >> mailto: blueroofmusic@gmail.com >> Winter 579 Park Place Saline, MI 48176 734-944-0094 >> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >> >> >> On Wed, Sep 24, 2014 at 10:38 PM, Ned Freed wrote: >>> >>> > On 25 September 2014 09:23, Sean Leonard wrote: >>> >>> > > Colleagues on media-types and apps-discuss: >>> > > >>> > > I would like to propose that the IETF create a new top-level media >>> > > type: >>> > > archive. >>> > > >>> > > >>> > Colour me interested. >>> >>> Yeah, me too. I'm surpised nobody has suggested this before. >>> >>> Ned >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types >> > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718 From nobody Tue Nov 4 15:26:31 2014 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 9A02D1A19F7 for ; Tue, 4 Nov 2014 15:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u21WTDn7mIwr for ; Tue, 4 Nov 2014 15:26:20 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEF81A0636 for ; Tue, 4 Nov 2014 15:26:19 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so10890598wiv.13 for ; Tue, 04 Nov 2014 15:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R37/rWe9Y0zXdGHiV+pQqdYEW4R+XAP60usDyPC7of8=; b=vxSyrgPwVYqlouUx6IpwsJiASTHeLj8R09FJH9VLPAraqMtdcl6i/36B4k/Bv4+WtW 4oq3VVhGscJ2MRgn3dtnHLqP5x9uNOeQHQEl7qOdEG2K2NvjI3K7QHV8DIN+FYGnRH0a 9xnj5F6TnHb4nQ3bxOyOsiRdJf5j44mnmzgTjImYvWaJypKNI2lFsT76iYlhS4zal09R qC8YujMeNVVKU42OEcduISMVzvTf0rJn0Vprtz2UbZNWJSV3Vu4WGCZDTc9ugSL6Q8wA QtUfG0/Jrf7ZxSJuqt8aEvqtiFzbT7AnpvvSMm0D8lp3CuieFiP+0QThmmU3wmy08+w1 l32w== MIME-Version: 1.0 X-Received: by 10.180.91.49 with SMTP id cb17mr27277569wib.30.1415143578577; Tue, 04 Nov 2014 15:26:18 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 4 Nov 2014 15:26:18 -0800 (PST) In-Reply-To: References: <54235269.2060002@seantek.com> <01PCZ1WHF6Q80000SM@mauve.mrochek.com> Date: Tue, 4 Nov 2014 15:26:18 -0800 Message-ID: From: "Murray S. Kucherawy" To: Stian Soiland-Reyes Content-Type: multipart/alternative; boundary=f46d043c7b2a4eb0ce050710ca89 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qnjOxx8JQlQiPRsAQQOgLU-fJDg Cc: Ned Freed , "media-types@iana.org" , IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] A proposal for a new top-level media type: archive 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, 04 Nov 2014 23:26:24 -0000 --f46d043c7b2a4eb0ce050710ca89 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 4, 2014 at 2:40 AM, Stian Soiland-Reyes < soiland-reyes@cs.manchester.ac.uk> wrote: > Was any decission made on the new archive/ tree? > A BoF is being held next week at IETF 91 to discuss precisely this. If you are interested in participating, look for the "arcmedia" entry in the agenda and from there you should be able to find links to remote participation facilities (jabber, audio streaming). > Can we just start sending in submission? I would like to submit my > archive/robundle+zip as we want to stabilize our spec. > As others have said, it can't hurt to post a draft (once the embargo lifts). What's the worst that could happen? -MSK --f46d043c7b2a4eb0ce050710ca89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 4, 2014 at 2:40 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:
Was any decission made on the new archive/ tree?

A BoF is being held next week at IETF 91 to discuss precise= ly this.=C2=A0 If you are interested in participating, look for the "a= rcmedia" entry in the agenda and from there you should be able to find= links to remote participation facilities (jabber, audio streaming).
=C2= =A0
Can we just start sending in submission? I would like to submit my
archive/robundle+zip as we want to stabilize our spec.

As others have said, it can't hurt to post a draft (onc= e the embargo lifts).=C2=A0 What's the worst that could happen?

=
-MSK
--f46d043c7b2a4eb0ce050710ca89-- From nobody Tue Nov 4 16:28:59 2014 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 A8DE51A1AAA for ; Tue, 4 Nov 2014 16:28:57 -0800 (PST) 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_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 FaYp0hrN6D2n for ; Tue, 4 Nov 2014 16:28:56 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1A01A1A09 for ; Tue, 4 Nov 2014 16:28:56 -0800 (PST) Received: from [10.0.44.217] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B3EFB509B8; Tue, 4 Nov 2014 19:28:54 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_BC9AA9B1-0E16-4225-A8E0-6CB0E65BCE76"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Tue, 4 Nov 2014 16:28:17 -0800 To: IETF Apps Discuss , media-types@iana.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Sst0ogR2x7YwO-1PvnecMFGonaM Subject: [apps-discuss] (arcmedia top-level media type) draft-seantek-kerwin-arcmedia-type-00.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: Wed, 05 Nov 2014 00:28:57 -0000 --Apple-Mail=_BC9AA9B1-0E16-4225-A8E0-6CB0E65BCE76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Colleagues: In preparation for the arcmedia BoF, an Internet-Draft, = draft-seantek-kerwin-arcmedia-type-00.txt, has been successfully posted to the IETF repository. This Internet-Draft was written in a hurry before the deadline, and used = RFC 2077 (January 1997) as its basis. Thus, some parts of the draft may = look a bit outdated. The main purposes of this draft are to sketch out = the purpose of the archive top level media type, and to lay out several = areas for further discussion and work. (This Internet-Draft actually posted last week, but there was a naming = snag.) Name: draft-seantek-kerwin-arcmedia-type Revision: 00 Title: Concise Binary Object Representation (CBOR) Tags for = ASN.1 Object Identifiers Document date: 2014-10-27 Group: Individual Submission Pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-seantek-kerwin-arcmedia-type-00.= txt Status: = https://datatracker.ietf.org/doc/draft-seantek-kerwin-arcmedia-type-00/ Htmlized: = http://tools.ietf.org/html/draft-seantek-kerwin-arcmedia-type-00 Abstract: This document defines a new primary content-type to be known as "archive", which defines a fundamental type of content with unique presentational, hardware, and processing aspects. The IETF Secretariat -Sean= --Apple-Mail=_BC9AA9B1-0E16-4225-A8E0-6CB0E65BCE76 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTEwNTAwMjg1MlowIwYJKoZIhvcNAQkEMRYEFLCWtZos8tC4MslkzMy8JuHo gbJBMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAANWMW9FulStoq4LWGx+MTtuCYCAj7EApF7WSeVag/hXGgyUkE1ML2iDsFd000SMaLi9lQYaY Q8wGXQ85GJacDEd0xITD6coVU3iuEH7jGm6EbEC+AByQw0k2dvzQA60k5fif3WMik9SNRdbKOwdd QGq+8a8Jpa4HVVhKAjFgHxQzQzmW0ySQ3MyZ2H53TQlN2naoxLdVntd3CtcQ2cRGX9HjyOvkWiRR dg97s82cMVgWy5YvIegmNBdy/+9MV4UoX8Nat2W6xyeNhOty3JEB0IkfewUNIG7Z0BQTcm3EYKM7 rhufg/ik1HYRoOd9xAhT73Rg0JP+YiFNWeWJe4cHOwAAAAAAAA== --Apple-Mail=_BC9AA9B1-0E16-4225-A8E0-6CB0E65BCE76-- From nobody Tue Nov 4 16:55:27 2014 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 05F191A1AA6 for ; Tue, 4 Nov 2014 16:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_4pHaWYKOON for ; Tue, 4 Nov 2014 16:55:24 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2440A1A1AA1 for ; Tue, 4 Nov 2014 16:55:23 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so14589315wgh.26 for ; Tue, 04 Nov 2014 16:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b6iKDuBoIIaJCYp8CQ3m9Zv+QNwD6MMC5m4IGLZzW64=; b=dpGJfZKDOI20EY/qhYUT8hgQnpGsLewueSquoprTIxkW2eMuuzu9L6HjQRZxLyNyx/ rfRnY3+fDcgSjTXMmFzlH8Y0XmxVTofvdTAyruT7NkxWIHT6qKxBMLdScK+CANxlBqXM KK7lUSDqMucNIVCCrmtD91GJm8GfOr/l6gFgQe6+URkpnU3yBEd+f9QnlvIlCaywD8Yp ug9ct1pcrp2vm/D/+lQ9lY3N3gfeSOulY9qeaGIoeGNSEzcozyfejRcnUJKocWtxMFn9 FlLELzuD41yAio8vv1wgreDQU7Xo3JZOT/gLf5P7fb1BvxO4jyWQZ+VU63Qp48gU4SYY 0vjQ== MIME-Version: 1.0 X-Received: by 10.194.57.169 with SMTP id j9mr58508675wjq.33.1415148922773; Tue, 04 Nov 2014 16:55:22 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 4 Nov 2014 16:55:22 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 16:55:22 -0800 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=047d7bacb9dcd8a90b0507120814 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1BuC1EHBZHHqkanEKJ9A7opKnf8 Cc: "media-types@iana.org" , IETF Apps Discuss Subject: Re: [apps-discuss] (arcmedia top-level media type) draft-seantek-kerwin-arcmedia-type-00.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: Wed, 05 Nov 2014 00:55:26 -0000 --047d7bacb9dcd8a90b0507120814 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 4, 2014 at 4:28 PM, Sean Leonard wrote: > > Name: draft-seantek-kerwin-arcmedia-type > Revision: 00 > Title: Concise Binary Object Representation (CBOR) Tags for ASN.1 > Object Identifiers > Curious title. Did you actually receive it this way? Might be some issue with the tracker if so. -MSK --047d7bacb9dcd8a90b0507120814 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 4, 2014 at 4:28 PM, Sean Leonard <dev+ietf= @seantek.com> wrote:

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-seantek-kerwin-arcmedia= -type
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Concise Binary Object Representati= on (CBOR) Tags for ASN.1 Object Identifiers

=
Curious title.=C2=A0 Did you actually receive it this way?=C2=A0 Might= be some issue with the tracker if so.
=C2=A0
-MSK
--047d7bacb9dcd8a90b0507120814-- From nobody Tue Nov 4 16:58:23 2014 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 2C2F61A1A9A for ; Tue, 4 Nov 2014 16:58:21 -0800 (PST) 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_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 Z7ngXZOEF-kj for ; Tue, 4 Nov 2014 16:58:19 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7521A1AA2 for ; Tue, 4 Nov 2014 16:58:19 -0800 (PST) Received: from [10.0.44.217] (unknown [74.113.134.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 42CE350A87; Tue, 4 Nov 2014 19:58:18 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_BD6E87CD-05F1-4437-A890-1606B994349E"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <3AC44BDB-8931-4E8E-8131-38D9E2117283@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 4 Nov 2014 16:57:21 -0800 References: To: IETF Apps Discuss , "media-types@iana.org" In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0bH8UZYkyg4L0r58ddDQ4pkqB3o Subject: Re: [apps-discuss] (arcmedia top-level media type) draft-seantek-kerwin-arcmedia-type-00.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: Wed, 05 Nov 2014 00:58:21 -0000 --Apple-Mail=_BD6E87CD-05F1-4437-A890-1606B994349E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 D=92oh. I copied and pasted that part incorrectly (I did not receive an = automated notification; it was posted manually). Sorry! Name: draft-seantek-kerwin-arcmedia-type Revision: 00 Title: The Archive Primary Media Type for File Archives Document date: 2014-10-27 Group: Individual Submission Pages: 10 URL: = http://www.ietf.org/internet-drafts/draft-seantek-kerwin-arcmedia-type-00.= txt Status: = https://datatracker.ietf.org/doc/draft-seantek-kerwin-arcmedia-type-00/ Htmlized: = http://tools.ietf.org/html/draft-seantek-kerwin-arcmedia-type-00 Sean On Nov 4, 2014, at 4:55 PM, Murray S. Kucherawy = wrote: > On Tue, Nov 4, 2014 at 4:28 PM, Sean Leonard = wrote: >=20 > Name: draft-seantek-kerwin-arcmedia-type > Revision: 00 > Title: Concise Binary Object Representation (CBOR) Tags for = ASN.1 Object Identifiers >=20 > Curious title. Did you actually receive it this way? Might be some = issue with the tracker if so. > =20 > -MSK --Apple-Mail=_BD6E87CD-05F1-4437-A890-1606B994349E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTEwNTAwNTgxNlowIwYJKoZIhvcNAQkEMRYEFHHgTBAWTBPUv9p97paq7maF o9OUMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAo3BFT2D2Rq8Y5bbXHp11ywE73BIZ7WAMCKA/9LdkSmyoZmr+F8M6QM32MlFjelUeEFeg5FI0 3rqiofOEgyf/B0FefZAFAzQywXC6ijjrVC60DRMoS+0IlZm/apTEoixDV3ZYofTznPClG/4ToazJ n4XS113LyJQsmR/4tZ3j23VGacMZjJk2OY/B8HfvLUXh2oGL7NDHQPhjat0B8DAKRptjVTsm86U6 YmlToCptDQiOmvSZvQmdI6NzY/zJYm32HDwXTPdgS5f0GoT+xmwhVDTCgk2siNtRmsod2rM3Vv1O Pl+HJ0cuhN7JGML/fTRc+pOFR+boNrcfUxNldoLU9AAAAAAAAA== --Apple-Mail=_BD6E87CD-05F1-4437-A890-1606B994349E-- From nobody Wed Nov 5 14:02:38 2014 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 BB15D1ACE47 for ; Wed, 5 Nov 2014 14:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, 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 eWJLpKD5th6G for ; Wed, 5 Nov 2014 14:02:28 -0800 (PST) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6C1ACE42 for ; Wed, 5 Nov 2014 14:02:28 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Xm8eo-00044g-mB; Wed, 05 Nov 2014 22:02:26 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.atuin.ninebynine.org) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Xm8eo-0002hl-8Q; Wed, 05 Nov 2014 22:02:26 +0000 Message-ID: <545A9E70.2000004@ninebynine.org> Date: Wed, 05 Nov 2014 22:02:24 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Leonard , IETF Apps Discuss , media-types@iana.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8er8cpPCjBSHGkruW1QdqKcKZtg Subject: Re: [apps-discuss] (arcmedia top-level media type) draft-seantek-kerwin-arcmedia-type-00.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: Wed, 05 Nov 2014 22:02:32 -0000 It's good to see a proposal on the table, but I shall not be present at the BoF. If the issue of a common/default fragment identifier syntax is brought up, and without prejudice as to whether or not that's a good thing to specifiy, I would suggest looking at http://w3ctag.github.io/packaging-on-the-web/ as a candidate design (specifically http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers). The 'url=' option described there would, I think, encompass the case of a relative URI reference that is resolved relative to the base of the archive, as well as MIME-multipart-style mid:/cid: style references. E.g. http:/example.org/my/archive#url=/root/sub/file or http:/example.org/my/archive#url=cid:foo.bar@example.net I don't claim that the cid: example serves a useful purpose; I'm just noting that the 'url=' option can accommodate different forms of reference. It's not clear to me if the other options described at http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers would be useful with an archive media type, but if the keyword=value format is used, the door can be left open to supporting such options. (I don't claim that specification is itself a candidate for an archive/ subtype, because it serves a different purpose, but it would seem to me to me to make sense if there were some commonality of fragment identifier syntax and mechanism for accessing components within a composite object.) #g -- On 05/11/2014 00:28, Sean Leonard wrote: > Hello Colleagues: > > In preparation for the arcmedia BoF, an Internet-Draft, draft-seantek-kerwin-arcmedia-type-00.txt, > has been successfully posted to the IETF repository. > > This Internet-Draft was written in a hurry before the deadline, and used RFC 2077 (January 1997) as its basis. Thus, some parts of the draft may look a bit outdated. The main purposes of this draft are to sketch out the purpose of the archive top level media type, and to lay out several areas for further discussion and work. > > (This Internet-Draft actually posted last week, but there was a naming snag.) > > Name: draft-seantek-kerwin-arcmedia-type > Revision: 00 > Title: Concise Binary Object Representation (CBOR) Tags for ASN.1 Object Identifiers > Document date: 2014-10-27 > Group: Individual Submission > Pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-seantek-kerwin-arcmedia-type-00.txt > Status: https://datatracker.ietf.org/doc/draft-seantek-kerwin-arcmedia-type-00/ > Htmlized: http://tools.ietf.org/html/draft-seantek-kerwin-arcmedia-type-00 > > > Abstract: > This document defines a new primary content-type to be known as > "archive", which defines a fundamental type of content with unique > presentational, hardware, and processing aspects. > > > The IETF Secretariat > > > -Sean > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Nov 6 06:28:28 2014 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 648001A87BB for ; Thu, 6 Nov 2014 06:28:26 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 WjjAixVWK23z for ; Thu, 6 Nov 2014 06:28:24 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255011A8872 for ; Thu, 6 Nov 2014 06:28:23 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-e3-545b858617df Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.D6.04081.6858B545; Thu, 6 Nov 2014 15:28:22 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.73]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Thu, 6 Nov 2014 15:28:21 +0100 From: Salvatore Loreto To: IETF Apps Discuss Thread-Topic: Working Group Last Call on draft-ietf-appsawg-multipart-form-data Thread-Index: AQHP7XDBAHCBh5NXjk+uU6MxRGbAh5w7cVMAgBOBeQCABL1fAA== Date: Thu, 6 Nov 2014 14:28:21 +0000 Message-ID: <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_3D8DFE7580154CA2BF2B8B62C9E450B5ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM+JvjW5ba3SIwbMnghYzVhdZrH65gs1i 4vcGNgdmj52z7rJ7LFnyk8njVLNhAHMUl01Kak5mWWqRvl0CV8aFzn/MBRd0K/ZvWMPWwHha rYuRk0NCwERizacl7BC2mMSFe+vZuhi5OIQEjjBKHF5xjhnCWcQo8fb5VzaQKjYBM4nnD7cw g9giAroSn/9eZQKxmQXiJL7NOAVmCwsESKyc9p0VoiZQYs+0pYwQtpPEnq9XwOIsAioSv6af AbN5Bewlbj89CbX5NpPEvh/vwZZxAjVvmT8BbCgj0HnfT62BWiYucevJfCaIswUkluw5zwxh i0q8fPyPFcJWklix/RIjRH2yxLe5s5ghlglKnJz5hGUCo+gsJKNmISmbhaQMIm4g8f7cfGYI W1ti2cLXULa+xMYvZxkhbGuJK/0trMhqFjByrGIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQI jM2DW34b7GB8+dzxEKMAB6MSD6/hk6gQIdbEsuLK3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAuKIqrMPGzd6nME6Rydkj/Qfb1zAhF56P8qKRFdJvG0Ls9gp1dlwv XPr/ivK7Pcfa759udtG85SsexsC2ZKJD9sE731idEgo3+igtyT676ElEMf+B1S5bZj2q3qTe 1BUVtMnqovf8ymAZ1/VC7dMsxTqYmYPbvwo/Lz/xefYcq9d1i6rKbQ8qsRRnJBpqMRcVJwIA HfUr9a4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Zos7wGgOGluXS1Mh3WXjOBu8T7I Subject: Re: [apps-discuss] Working Group Last Call on draft-ietf-appsawg-multipart-form-data 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, 06 Nov 2014 14:28:26 -0000 --_000_3D8DFE7580154CA2BF2B8B62C9E450B5ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi there, I am acting as shepherd for the appsawg-mutlipart-form-data The wg lc for this draft has been issued on September 16, but since then no= body has sent any comment/feedback to the list. We really need people reviewing this document and providing their feedback in order to determine if there is or not working group consensus to be publ= ish this draft. best regards Salvatore ---------- Forwarded message ---------- From: Murray S. Kucherawy > Date: Tue, Sep 16, 2014 at 1:09 PM Subject: Working Group Last Call on draft-ietf-appsawg-multipart-form-data To: IETF Apps Discuss > Working Group Last Call: draft-ietf-appsawg-multipart-form-data Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-multipart= -form-data. The document seems to have stabilized and I believe Larry got = the help he needed in setting up test cases he needed. Please provide review comments or expressions of support for the current ve= rsion either on this list or privately to draft-ietf-appsawg-multipart-form= -data.all@tools.ietf.org on or before October 3, 2014. Be as detailed as possible. = The co-chairs need to determine if the document has working group consensu= s, which means we need to know people have read the latest version and agre= e with its content and with the idea that it is ready to proceed. A simple= =93+1=94 doesn=92t tell us anything. Also, if any participant has knowledge of IPR that needs to be declared on = this work, please do so, as required by BCPs 78 and 79. is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair --_000_3D8DFE7580154CA2BF2B8B62C9E450B5ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <61DEFE1AC22DD04FBFC47A4F2488AE3E@ericsson.com> Content-Transfer-Encoding: quoted-printable Hi there,

I am acting as shepherd for the appsawg-mutlipart-form-data

The wg lc for this draft has been issued on September 16, but since th= en nobody has sent
any comment/feedback to the list.

We really need people reviewing this document and providing their feed= back
in order to determine if there is or not working group consensus to be= publish this draft.

best regards
Salvatore




---------- Forwarded message ----------
From: Murray S. Kucherawy <superuser@g= mail.com>
Date: Tue, Sep 16, 2014 at 1:09 PM
Subject: Working Group Last Call on draft-ietf-appsawg-multipart-form-data<= br> To: IETF Apps Discuss <apps-discuss@ietf.org>


Working Group Last Call: draft-ietf-appsawg-multipart-form= -data

Colleagues,

This note starts a Working Group Last Call for draft-ietf-appsawg-multipart= -form-data.  The document seems to have stabilized and I believe Larry= got the help he needed in setting up test cases he needed.

Please provide review comments or expressions of support for the current ve= rsion either on this list or privately to draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org on or before = October 3, 2014.  Be as detailed as possible.  The co-chairs need= to determine if the document has working group consensus, which means we n= eed to know people have read the latest version and agree with its content and with the idea that it is ready to proceed.&= nbsp; A simple =93+1=94 doesn=92t tell us anything.

Also, if any participant has knowledge of IPR that needs to be declared on = this work, please do so, as required by BCPs 78 and 79.

<name> is fulfilling the duties of document shepherd.

-MSK, APPSAWG co-chair





--_000_3D8DFE7580154CA2BF2B8B62C9E450B5ericssoncom_-- From nobody Thu Nov 6 08:32:35 2014 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 7FBDB1A8850 for ; Thu, 6 Nov 2014 08:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 FXnH44WC1gJs for ; Thu, 6 Nov 2014 08:32:32 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 08D221A884C for ; Thu, 6 Nov 2014 08:32:32 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PEMGZ7QII80052L8@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 6 Nov 2014 08:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1415291250; bh=+VcjkDUL41FV4rQxNX5rkpwurOeRC9Sbyw6bt8PTs2c=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=NAay0uY6tk9SOId7BKtS5q2c2jKG4BOQ/VRQLwq1YZs58jMlCGP9LC9VCYMCgHQWP 6TjMWi1vMxAfmk4YPnLtgSlfC7rfyZHIBs3ftBPsOjNdn52HQ3G0iyVzb6Z8QTfkk7 Dv7O5bHxPOa2pgKg2yUTMRDGBLSS/plH1479RXEk= 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 <01PEKZE5Z31C003WE3@mauve.mrochek.com>; Thu, 06 Nov 2014 08:27:27 -0800 (PST) Message-id: <01PEMGZ6AW9C003WE3@mauve.mrochek.com> Date: Thu, 06 Nov 2014 08:02:05 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 06 Nov 2014 14:28:21 +0000" <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> References: <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> To: Salvatore Loreto Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jpzPOptdNuGbiMMzLQRltEIs4e0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call on draft-ietf-appsawg-multipart-form-data 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, 06 Nov 2014 16:32:33 -0000 > I am acting as shepherd for the appsawg-mutlipart-form-data > The wg lc for this draft has been issued on September 16, but since then nobody has sent > any comment/feedback to the list. > We really need people reviewing this document and providing their feedback > in order to determine if there is or not working group consensus to be publish this draft. A few comments. The wording in section 5.1 is a little odd. Quotes are only required around parameter values when a tspecial character is present. But the way this section is worded makes it sound like parameters always have to be quoted and systems that emit an unquoted parameter are doing something that's at a minimum wierd if not downright incorrect. I don't have alternate wording to suggest, but some clarification would be good. I question the need to reference RFC 1806 in section 5.2. RFC 2183 is the standards-track specification of content-disposition which replaced the experimental RFC 1806. (OTOH, the documents say that RFC 2183 updates RFC 1806; I don't understand why it didn't obsolete it. So maybe there's some need to reference it...) Section 5.2 makes use of the content-disposition "name" parameter. When I checked the IANA registry for this parameter (http://www.iana.org/assignments/cont-disp/cont-disp.xhtml#cont-disp-2) I noticed something odd: The parameter is supposedly defined in RFC 2388, which is the earlier version of this document. Moreover, RFC 2388 just talks about the parameter, it doesn't actually say it registers it. I suggest adding appropriate registration text to the IANA Considerations section and updating the registry to point to this document. Section 5.9 talks about what MIME fields are supported in form data parts, but doesn't go so far as to say they MUST NOT be present. It might be a good thing to clarify whether they are simply ignored if present or whether they might actually screw things up if you include them. Section 8 and/or the security considerations in section 9 probably should say something about privacy and integirty protection for form data. All media types are supposed to state whether or not they involve executable content, so this needs to be mentioned in section 9. That's it. Ned From nobody Thu Nov 6 14:37:38 2014 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 1C65F1ACE76 for ; Wed, 5 Nov 2014 14:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 KBLqQCd4fWhg for ; Wed, 5 Nov 2014 14:05:55 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBB61ACE6B for ; Wed, 5 Nov 2014 14:05:55 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id a141so53570oig.26 for ; Wed, 05 Nov 2014 14:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mygrid.org.uk; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=5dKpi25PUwyvxMNWc5XnIWrR+Wx4EfgZhWTkBS8Zuac=; b=e8GWJQonnieTDN3llLPRsSegG3VzzGwmbNTBgRio+PwFUvhC6kBFcZcLIgtnIQEDzv /vw/r/Css/LM8JV2B5PXgeShVZB2G1M9FUMPRyG2Niwr5A8m6Zp7XtlCMQYp9Irbslux Rcy0JlUzVzptG3rQys1dN+mumro57rDRMglMQ= 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 :content-transfer-encoding; bh=5dKpi25PUwyvxMNWc5XnIWrR+Wx4EfgZhWTkBS8Zuac=; b=f+GlQJSG+ASL90aEadbeTHsTxW2FxVvDwfVruHs2EAIYxw6u/DCiC6/iOtsAN2THAC uIUB2Ca61yPRWo9luUWaM7L+3SO20fbPQeC1hbMm4TBL1uFawlFXp3RuIpqDazcoqJHR WAeQ/MJQP1TcDkHo/WWGXbO6fg+Ykyd4SiYsmVNmzCz50TL1nE7KmoMpzoXAR68C/qvT V0i8lUQma7KJ5DxrN9zSX/aGD6RH5A9aMurWStNzUoLadizpweFnXccc5ODprK49fAdd aYRBIFbknHXa/llloEDXEQDC9fuJNsLwX1OlPlLACRRiSMOXFUYHTPTDy3Jb+WqOfjr2 fh6Q== X-Gm-Message-State: ALoCoQm4Grivk+UQx8vDs72YjFLz1rFEatW9gFOlqyMclHEDyVQlBTVkf7KJkBxZlCacwL6kJxjP X-Received: by 10.60.38.1 with SMTP id c1mr76048oek.51.1415225153623; Wed, 05 Nov 2014 14:05:53 -0800 (PST) MIME-Version: 1.0 Sender: stian@mygrid.org.uk Received: by 10.76.130.116 with HTTP; Wed, 5 Nov 2014 14:05:33 -0800 (PST) In-Reply-To: <3AC44BDB-8931-4E8E-8131-38D9E2117283@seantek.com> References: <3AC44BDB-8931-4E8E-8131-38D9E2117283@seantek.com> From: Stian Soiland-Reyes Date: Wed, 5 Nov 2014 22:05:33 +0000 X-Google-Sender-Auth: wA3YbxJJQPjBfvSEv3nsYIIfNBs Message-ID: To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wbfGiDY360GXW7ib7l7RtCzWcf0 X-Mailman-Approved-At: Thu, 06 Nov 2014 14:37:34 -0800 Cc: "media-types@iana.org" , IETF Apps Discuss Subject: Re: [apps-discuss] [media-types] (arcmedia top-level media type) draft-seantek-kerwin-arcmedia-type-00.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: Wed, 05 Nov 2014 22:06:00 -0000 Good work! Here are some executable archive formats, btw, as I saw you listed that as controversial. https://github.com/taverna/taverna-scufl2 (Taverna Workflow Bundle - based on .zip) https://rapidminer.com/ (RapidMiner workflow - based on .zip) http://www.knime.org/ (KNIME workflow - based on .zip) https://docs.docker.com/articles/baseimages/#creating-a-simple-base-image-u= sing-scratch (Docker virtualized applications - based on .tar) https://en.wikipedia.org/wiki/JAR_%28file_format%29 (Java library and application - based on .zip) https://en.wikipedia.org/wiki/Open_Virtualization_Format (OVA Virtual Machine - based on .tar) However for almost all of these one can argue that their main purpose is not to be an archive, as their constituent files don't make much sense outside the execution environment, and therefore they would not want to be under archive/ for the benefit of the user. It is still interesting for anti-virus engines to investigate such archives, but then again they would also want to check the actually executable code as well.. On 5 November 2014 00:57, Sean Leonard wrote: > D=E2=80=99oh. I copied and pasted that part incorrectly (I did not receiv= e an automated notification; it was posted manually). Sorry! > > > Name: draft-seantek-kerwin-arcmedia-type > Revision: 00 > Title: The Archive Primary Media Type for File Archives > Document date: 2014-10-27 > Group: Individual Submission > Pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-seantek-kerwin-= arcmedia-type-00.txt > Status: https://datatracker.ietf.org/doc/draft-seantek-kerwin-arc= media-type-00/ > Htmlized: http://tools.ietf.org/html/draft-seantek-kerwin-arcmedia-= type-00 > > Sean > > On Nov 4, 2014, at 4:55 PM, Murray S. Kucherawy wro= te: > >> On Tue, Nov 4, 2014 at 4:28 PM, Sean Leonard wrot= e: >> >> Name: draft-seantek-kerwin-arcmedia-type >> Revision: 00 >> Title: Concise Binary Object Representation (CBOR) Tags for ASN= .1 Object Identifiers >> >> Curious title. Did you actually receive it this way? Might be some iss= ue with the tracker if so. >> >> -MSK > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > --=20 Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718 From nobody Thu Nov 6 22:29:03 2014 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 BC5701ACEF5 for ; Thu, 6 Nov 2014 22:29:01 -0800 (PST) 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_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 DFXad3LdQzUc for ; Thu, 6 Nov 2014 22:29:00 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E4F1A1A52 for ; Thu, 6 Nov 2014 22:28:59 -0800 (PST) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D335E509B5 for ; Fri, 7 Nov 2014 01:28:58 -0500 (EST) Message-ID: <545C6644.8070707@seantek.com> Date: Thu, 06 Nov 2014 22:27:16 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030009050609050105030405" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kaSgQOOolkXUdmYKeh78npLAlXQ Subject: [apps-discuss] text/markdown: Simplifying the syntax parameter and the draft 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, 07 Nov 2014 06:29:01 -0000 This is a cryptographically signed message in MIME format. --------------ms030009050609050105030405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I have worked with several parties privately to try to see how we can=20 keep the text/markdown draft moving. Looking at all the feedback, the public comments are clearly going in=20 the direction of making the text/markdown registration simpler. (Yes, I=20 got the memo=E2=80=A6) Most of the complexity stems from unifying all=20 Markdown-derivative syntaxes into one media type (text/markdown) with=20 specific parameters. PROPOSAL Change the registration template in draft-03 as follows: *** Optional Parameters: variant: An optional identifier that serves as a =E2=80=9Chint=E2=80=9D t= o the recipient=20 of the specific Markdown variant that the author intended. When omitted, = there is no hint; the interpretation is entirely up to the receiver and=20 context. This identifier is plain US-ASCII and case-insensitive. People=20 who want interop can optionally register them using a simple webform=20 (IANA registry), which just asks for the Identifier, a Description, and=20 Contact Information. If a receiver does not recognize the variant=20 identifier, the receiver MAY present the identifier to a user to inform=20 him or her of it. Other parameters MAY be included with the media type. The semantics of=20 such parameters MAY be defined by the variant; they are not defined=20 here. As an alternative, the variant MAY be registered under another=20 media type; this text/markdown registration does not preclude other=20 registrations. *** With the text above in the registration template, pretty much all of=20 Section 3 (draft-03) would be eliminated. Additionally, Section 6 (IANA=20 Considerations) would be cut down to about 1/3 of its current size. Definition: "Variant" means a lightweight markup language that differs in some=20 respect from other Markdown-derived languages. The purpose of a variant=20 is to distinguish a given variation from other Markdown variations, as=20 well as from Gruber's original syntax specification and implementation,=20 where two parties wish to interoperate by implementing the common variati= on. The IANA Registry shall be called "Markdown Variants". The intent of=20 this name is to broaden the uses of variant identifiers, so protocols=20 that do not rely on Internet media types can still tag Markdown content=20 with a variant name. For example, a file can be named=20 "file.pandoc.markdown", which could have the equivalent meaning as=20 "Content-Type: text/markdown; variant=3Dpandoc". (Credit goes to Michel=20 Fortin for suggesting that the classification of variants have broader=20 value than just the media type registration; for example, in content=20 management systems that do not use media types to classify formats.) -Sean --------------ms030009050609050105030405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MTEwNzA2MjcxNlowIwYJKoZIhvcNAQkEMRYEFEtjtEVReY9Dou4D FgQWg9Odb1oqMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQC068YZU8lpVHwdfk8dErsHCkE6EhUq 24FNbZzKusFD19/FRUKu6TJjeEETE4Uegn/RfVKyMLoQ4MOsud8xNHUQ85EspKqT+NNuOX6+ ZDkdKZ7XbQsitVJA4wIHy1Lurmknl80Vj75QaIQjd1NoPioGTXhogITa3rmlPlRymsWu3O4C 4sBNPNu7O1+0RU0oP+5Wc7DwjUqSOzL/7XCfUzzr0X9Lp4UfLmtpYKzdJkITBcu9FF3DxqYr jLT57KVvq7XVJSz4Vo2U0c+mNdE+80cIzBe3L0Pc/DqefyvaWp53ABWzgTJvgLyhIEaTCkWB gARC6r51wfiESnHTN/Yzv1LPAAAAAAAA --------------ms030009050609050105030405-- From nobody Fri Nov 7 10:23:24 2014 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 820CE1AD3F3 for ; Fri, 7 Nov 2014 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnmjVa8f2Afn for ; Fri, 7 Nov 2014 10:23:14 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::721]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D471AD3B0 for ; Fri, 7 Nov 2014 10:23:13 -0800 (PST) Received: from AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) by AMXPR07MB037.eurprd07.prod.outlook.com (10.242.67.139) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 7 Nov 2014 18:17:44 +0000 Received: from pc6 (86.184.62.161) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.11.14; Fri, 7 Nov 2014 18:17:43 +0000 Message-ID: <02cc01cffab6$bf1bdd60$4001a8c0@gateway.2wire.net> From: t.petch To: Salvatore Loreto , IETF Apps Discuss References: <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> Date: Fri, 7 Nov 2014 18:14:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: DB4PR02CA0023.eurprd02.prod.outlook.com (10.242.174.151) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-MS-Exchange-Transport-FromEntityHeader: Hosted X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 03883BD916 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(22974006)(199003)(13464003)(51444003)(189002)(230783001)(116806002)(33646002)(84392001)(102836001)(93886004)(61296003)(42186005)(76176999)(81686999)(50986999)(81816999)(40100003)(104166001)(19580405001)(15975445006)(101416001)(122386002)(120916001)(21056001)(99396003)(95666004)(92726001)(92566001)(87286001)(87976001)(97736003)(88136002)(89996001)(4396001)(20776003)(46102003)(93916002)(19580395003)(44716002)(66066001)(50466002)(107886001)(107046002)(47776003)(77096003)(50226001)(62236002)(14496001)(23746002)(31966008)(44736004)(86362001)(105586002)(64706001)(106356001)(62966003)(77156002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB037; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZPR_fgQOhsdbr3fOA9GmafJv6HE Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data 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, 07 Nov 2014 18:23:22 -0000 Saving the RFC Editor a little work mostly s.4 /there are a generally series of fields,/there are generally aseries of fields,/ ' restricting field names to ASCII will help avoid some interoperability issues.' worth making a SHOULD? s.5.1 /Each field's form data of the form is /Each field's form data is/ /prepared to acommodate./prepared to accommodate./ s.5.3 Should there be a reference for '"file:" URI' or has that been omitted because there is no good one:-( s.5.6 /In the case where the form data text,/ In the case where the form data is text,/ s.8 I think that the Security Considerations should be stronger about protecting the privacy of confidential information s.9 The registration has two references to this document - these should probably be called out as RFCxxxx with the usual note to replace xxxx with the RFC number Tom Petch ----- Original Message ----- From: "Salvatore Loreto" To: "IETF Apps Discuss" Sent: Thursday, November 06, 2014 2:28 PM Hi there, I am acting as shepherd for the appsawg-mutlipart-form-data The wg lc for this draft has been issued on September 16, but since then nobody has sent any comment/feedback to the list. We really need people reviewing this document and providing their feedback in order to determine if there is or not working group consensus to be publish this draft. best regards Salvatore ---------- Forwarded message ---------- From: Murray S. Kucherawy > Date: Tue, Sep 16, 2014 at 1:09 PM Subject: Working Group Last Call on draft-ietf-appsawg-multipart-form-data To: IETF Apps Discuss > Working Group Last Call: draft-ietf-appsawg-multipart-form-data Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-multipart-form-data. The document seems to have stabilized and I believe Larry got the help he needed in setting up test cases he needed. Please provide review comments or expressions of support for the current version either on this list or privately to draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org on or before October 3, 2014. Be as detailed as possible. The co-chairs need to determine if the document has working group consensus, which means we need to know people have read the latest version and agree with its content and with the idea that it is ready to proceed. A simple “+1” doesn’t tell us anything. Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79. is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Nov 7 23:07:26 2014 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 76A7B1A19EE for ; Fri, 7 Nov 2014 23:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9BvcWQvZ6U3 for ; Fri, 7 Nov 2014 23:07:22 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3C31A19FC for ; Fri, 7 Nov 2014 23:07:21 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so6415770wiv.13 for ; Fri, 07 Nov 2014 23:07:20 -0800 (PST) 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=6Uq6KxdTQo+ONTfP7h1/Yls7fJb94anwuHI50LybPIk=; b=k6Nv+rI6F9R+xpkq+REviyNSHUFKR5nitPEiJQ6NsuMVznRLjwq/wWWIqBdD600Hj6 t9km3ti+YCCBc7RO8DnNhUmC5h7cWeesfH6iQvGBbHKhsEPbA+uj20ib0jsKyvuDxpPU WGoIn8MUZJO1VlB8Q7PVHJ0drqewKPaVzDJ5SnXHYdblnSjfM9+EM6eBSn8oNjPg/sMq Y7D7gZu2VyWCoBGAPn0ZDKWz2DIBdQzvrpsxJGQL6fmbgWaGjEJ4XdZrG/t1T1Q41n/j jB0vzCh2v+zwGkN30NOMVlVaz3IN2r3cUgWwZpw9s3mhDOGvVxl4BVhgrrhhJ+wW0eUM yyRg== MIME-Version: 1.0 X-Received: by 10.180.14.226 with SMTP id s2mr11532846wic.61.1415430440610; Fri, 07 Nov 2014 23:07:20 -0800 (PST) Received: by 10.27.76.134 with HTTP; Fri, 7 Nov 2014 23:07:20 -0800 (PST) Date: Fri, 7 Nov 2014 23:07:20 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04138c9f9df3d50507539470 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/724_AVPp3ziuDAEewCcCRX-kbHY Subject: [apps-discuss] APPSAWG/APPAREA agenda 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, 08 Nov 2014 07:07:24 -0000 --f46d04138c9f9df3d50507539470 Content-Type: text/plain; charset=UTF-8 Colleagues, Some discussion among the working group chairs has highlighted the fact that we, like other area working groups, typically get a run of document submissions close to the meeting and corresponding requests for meeting time. This meeting is no exception, and it results in us packing the agenda and sometimes shrinking other items' time slots in order to be accommodating, and it's not fair to the presenters of work already in progress that are actually in need of face time to complete active document work. Accordingly, we have rearranged this agenda so that all presentations that have not already had some kind of discussion on apps-discuss will appear toward the end of the dual meeting, during our "Any Other Business/Open Mic" slot, rather than as part of the APPSAWG time. That is, the layout in general will now be: - administrivia - APPSAWG (work already under discussion only) - APPAREA general meeting - AOB (including introduction of proposed new work) At the moment it looks like we should be just able to accommodate everything on the agenda, but AOB items that get pushed past the end of our assigned meeting time will not be able to present. For future meetings, the chairs may not accept requests for meeting time regarding documents that have not at least been introduced to the mailing list or don't clearly need face time, depending on other qualifying requests already in hand. Please get in the habit of introducing your work to apps-discuss well in advance of meetings if you would like to be assigned meeting time going forward. -MSK, APPSAWG co-chair --f46d04138c9f9df3d50507539470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Some discussi= on among the working group chairs has highlighted the fact that we, like ot= her area working groups, typically get a run of document submissions close = to the meeting and corresponding requests for meeting time.=C2=A0 This meet= ing is no exception, and it results in us packing the agenda and sometimes = shrinking other items' time slots in order to be accommodating, and it&= #39;s not fair to the presenters of work already in progress that are actua= lly in need of face time to complete active document work.

Acc= ordingly, we have rearranged this agenda so that all presentations that hav= e not already had some kind of discussion on apps-discuss will appear towar= d the end of the dual meeting, during our "Any Other Business/Open Mic= " slot, rather than as part of the APPSAWG time.=C2=A0 That is, the la= yout in general will now be:

- administrivia
- APPSAWG (work alre= ady under discussion only)
- APPAREA general meeting
- AOB (including= introduction of proposed new work)

At the moment it looks like we s= hould be just able to accommodate everything on the agenda, but AOB items t= hat get pushed past the end of our assigned meeting time will not be able t= o present.

For future meetings, the chairs may not accept requ= ests for meeting time regarding documents that have not at least been intro= duced to the mailing list or don't clearly need face time, depending on= other qualifying requests already in hand.=C2=A0 Please get in the habit o= f introducing your work to apps-discuss well in advance of meetings if you = would like to be assigned meeting time going forward.

-MSK, AP= PSAWG co-chair

--f46d04138c9f9df3d50507539470-- From nobody Sat Nov 8 05:41:47 2014 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 AF7241A802F for ; Sat, 8 Nov 2014 05:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd7kBAn5tqZh for ; Sat, 8 Nov 2014 05:41:44 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6FA1A802E for ; Sat, 8 Nov 2014 05:41:44 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so5678981wgh.20 for ; Sat, 08 Nov 2014 05:41:42 -0800 (PST) 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=te1Mqcsm3xYJZwC2pK7NvzBPwIxiK8mVfpIghaHTqvI=; b=1GBYNQ18w2CVNVwuVmubtE0FXUwTRxD73jnGunxBu6p+KC77wCkWYOb0Kra8l8QJpi SHm/TVYt/ORtKIbYNuzMYOr91i82RzZZIF1gSUQ6YdIdz0FLYDiPLGLVRLVZMLJNd1WP 25s9AeoUMaeTy9D21Id3L4xwHixpqAmWxnYfWcKv8QCaMVUEUX6PRAEm0bUS14iqS2kh IDtzrah//R4W5bQL5Z68tg+w2EfSPp8k7QWoLslmTZI/S8V90HacTZkPaJT6JfV4qL5F NZjrHr8DYWTV7OZ1WAgGn4IDOTdMXi86gvJ0StXbHay8tOj1ZSmNlANDvI7xeQn3F+0F XqTg== MIME-Version: 1.0 X-Received: by 10.180.14.226 with SMTP id s2mr13987057wic.61.1415454102872; Sat, 08 Nov 2014 05:41:42 -0800 (PST) Received: by 10.27.76.134 with HTTP; Sat, 8 Nov 2014 05:41:42 -0800 (PST) Received: by 10.27.76.134 with HTTP; Sat, 8 Nov 2014 05:41:42 -0800 (PST) Date: Sat, 8 Nov 2014 05:41:42 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04138c9fff69b00507591636 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/E93hY2BxHKulSrqajoZtQeD1o1A Subject: [apps-discuss] IETF 91 slides 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, 08 Nov 2014 13:41:45 -0000 --f46d04138c9fff69b00507591636 Content-Type: text/plain; charset=UTF-8 If you are presenting at APPSAWG/APPAREA on Monday and will be using slides, please submit them to appsawg-chairs@tools.ietf.org no later than Sunday evening. We will be unable to accommodate any submissions received Monday, including memory cards or sticks. -MSK --f46d04138c9fff69b00507591636 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If you are presenting at APPSAWG/APPAREA on Monday and will = be using slides, please submit them to appsawg-chairs@tools.ietf.org no later than Sunday evening= . We will be unable to accommodate any submissions received Monday, includi= ng memory cards or sticks.

-MSK

--f46d04138c9fff69b00507591636-- From nobody Sun Nov 9 22:56:53 2014 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 6ADB21A87BD for ; Sun, 9 Nov 2014 22:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPKJxoxMXTQ9 for ; Sun, 9 Nov 2014 22:56:50 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08E71A19E6 for ; Sun, 9 Nov 2014 22:56:49 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id k14so8017257wgh.0 for ; Sun, 09 Nov 2014 22:56:48 -0800 (PST) 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=dKAsJHy7fHy4Ce4WZdG+zo53RhPuhUQUftB38g7OhcE=; b=tOKN9BBQg5ejSgNEfd27GCJtYgM28tKq32QUZR42R263L5s9eulFS28o8qfWlF7L/h K0vuMPiLMVAStNKG7V9QK4Cge6eBcbuR7xEl8SjWeqxG08QzMc9jGVLy6SbgQXoyUBwl OoFtra4ZcVmApb1TnIIsfh/pKMVaT1hXhPT+lHby0NBO8kLZL4st8WrXj7vIxk6llGWF EUnD0vShOplIwq/IlP7fYKbWBQc4dw7PKAXqUpmHFl70dPnjH/uNFKgTFEnwdnzOwRcb yoPuRVy9WiJ4G48cz5DMsueDtQu4axglAeiThjMjqGzFw5ZWIq4WE1XItVx5ZEcrz3pQ lQVA== MIME-Version: 1.0 X-Received: by 10.194.157.137 with SMTP id wm9mr40442181wjb.5.1415602608508; Sun, 09 Nov 2014 22:56:48 -0800 (PST) Received: by 10.27.76.134 with HTTP; Sun, 9 Nov 2014 22:56:48 -0800 (PST) Date: Sun, 9 Nov 2014 20:56:48 -1000 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e013c6b689f985205077baa7c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9Y4CNkoPg1KK2PkvINI1Nb42b3I Subject: [apps-discuss] IETF 91 materials uploaded 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, 10 Nov 2014 06:56:51 -0000 --089e013c6b689f985205077baa7c Content-Type: text/plain; charset=UTF-8 Colleagues, I've uploaded the most recent slide decks we've received from tomorrow's presenters. They can be found here: https://datatracker.ietf.org/meeting/91/materials.html#appsawg If you are presenting and have slides, please verify ASAP that the correct set is there, and let us know if not. See you all in the morning, -MSK, APPSAWG co-chair --089e013c6b689f985205077baa7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

I've uploaded the m= ost recent slide decks we've received from tomorrow's presenters.= =C2=A0 They can be found here:

https://datatracker.ietf.org/meeting/= 91/materials.html#appsawg

If you are presenting and have slides,= please verify ASAP that the correct set is there, and let us know if not.<= br>
See you all in the morning,

-MSK,= APPSAWG co-chair
--089e013c6b689f985205077baa7c-- From nobody Mon Nov 10 09:40:35 2014 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 EE6121A1A4C for ; Mon, 10 Nov 2014 09:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 7ewOoenJOA2J for ; Mon, 10 Nov 2014 09:40:30 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 79D6F1A0386 for ; Mon, 10 Nov 2014 09:31:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,353,1413237600"; d="scan'208";a="5512278" Received: from exc-cashub03.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 10 Nov 2014 18:31:30 +0100 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 18:31:30 +0100 From: "Brandenburg, R. (Ray) van" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] URLs and HTTP Response Forms for Multicast Thread-Index: AQHP6S2H00UVMA6zAUyIR+TGGQ3SNpxaRfeA Date: Mon, 10 Nov 2014 17:31:30 +0000 Message-ID: References: <8B1EFDE4-697E-46EB-94A4-70C82B30670B@cisco.com> In-Reply-To: <8B1EFDE4-697E-46EB-94A4-70C82B30670B@cisco.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.141024 x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="utf-8" Content-ID: <95E37DD98C3C5C43B518DBF118C156FA@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Vahh3AEHad_-paOV3bPwRYMadvQ Subject: Re: [apps-discuss] URLs and HTTP Response Forms for Multicast 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, 10 Nov 2014 17:40:33 -0000 SGkgQWxpLA0KDQpJIG9ubHkgcmVjZW50bHkgbm90aWNlZCB0aGlzIGRyYWZ0LiBXaXRoIEhUVFAt YmFzZWQgc3RyZWFtaW5nIG1lY2hhbmlzbSANCihub3RhYmx5IEhMUyBhbmQgdG8gYSBsZXNzZXIg ZXh0ZW50IERBU0gpIGJlY29taW5nIHRoZSBkZS1mYWN0byBzdGFuZGFyZCwgDQpJIHRoaW5rIGl0 IG9ubHkgbWFrZXMgc2Vuc2UgdG8gbG9vayBhdCBtZWNoYW5pc21zIGZvciBwcm92aWRpbmcgaGFu ZG92ZXJzIA0KYmV0d2VlbiBzdWNoIHVuaWNhc3Qgc3RyZWFtaW5nIG1ldGhvZHMgYW5kIG11bHRp Y2FzdC4gVGhpcyBkcmFmdCBwcm92aWRlcyANCmEgZ29vZCBzdGFydGluZyBwb2ludCBmb3IgdGhp cy4gDQoNCkluIG90aGVyIHdvcmRzLCBJIGRlZmluaXRlbHkgc3VwcG9ydCB0aGlzIHdvcmsgYW5k IGFtIHdpbGxpbmcgdG8gDQpjb250cmlidXRlLiANCg0KQmVzdCByZWdhcmRzLA0KDQpSYXkNCg0K DQo+PkZyb206ICJBbGkgQy4gQmVnZW4gKGFiZWdlbikiIDxhYmVnZW5AY2lzY28uY29tPg0KPj4g VG86ICJhcHBzLWRpc2N1c3NAaWV0Zi5vcmciIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQo+PiBE YXRlOiBPY3RvYmVyIDE2LCAyMDE0IGF0IDEyOjM5OjQ0IEFNIEhTVA0KPj4gU3ViamVjdDogW2Fw cHMtZGlzY3Vzc10gVVJMcyBhbmQgSFRUUCBSZXNwb25zZSBGb3JtcyBmb3IgTXVsdGljYXN0DQo+ PiANCj4+IEhpIGV2ZXJ5b25lLA0KPj4gDQo+PiBEYXZlIGFuZCBJIHN1Ym1pdHRlZCBhIG5ldyBk cmFmdC4gVGhlIGlkZWEgaXMgbWFrZSBmaWxlIGRlbGl2ZXJ5IG92ZXIgDQo+Pm11bHRpY2FzdCBz aW1wbGUgd2hlcmUgdGhlIGRlbGl2ZXJ5IHByb3RvY29sIGhhcyBhIFVSTCBmb3JtLiBXZSBoYXZl IA0KPj5uaWNlIHVzZSBjYXNlcyBmb3IgdGhpcyB3aGVyZSBvdXIgbGlmZSBjb3VsZCBnZXQgYSBs b3QgZWFzaWVyIHdpdGggYSANCj4+bXVsdGljYXN0IFVSTC4NCj4+IA0KPj4gVGhlIGRyYWZ0IGlz IHNob3J0LiBXaGlsZSBpdCBpcyBzdGlsbCBtaXNzaW5nIHNvbWUgaW5mb3JtYXRpb24sIHRoZSAN Cj4+Y29yZSBpZGVhIGlzIGluIHRoZSBkcmFmdC4NCj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtc2luZ2VyLWFwcHNhd2ctbWNhc3QtdXJsLw0KPj4gDQo+PiBXZSB3b3Vs ZCBjZXJ0YWlubHkgd2VsY29tZSB5b3VyIGZlZWRiYWNrLiBUaW1lIHBlcm1pdHRpbmcsIHdlIGFs c28gDQo+PndvdWxkIGxpa2UgdG8gcHJlc2VudCB0aGlzIGluIEhhd2FpaS4NCj4+IA0KPj4gVGhh bmtzLg0KPj4gLWFjYmVnZW4NCj4+IA0KPj4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+PiAN Cj4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+Pj5kcmFmdC1zaW5nZXItYXBwc2F3Zy1tY2FzdC11 cmwtMDAudHh0DQo+Pj4gRGF0ZTogT2N0b2JlciAxNiwgMjAxNCBhdCAxMjoyOToyMSBQTSBHTVQr Mg0KPj4+IFRvOiBEYXZlIFNpbmdlciA8c2luZ2VyQGFwcGxlLmNvbT4sIERhdmlkIFNpbmdlciA8 c2luZ2VyQGFwcGxlLmNvbT4sIA0KPj4+QWxpIEJlZ2VuIDxhYmVnZW5AY2lzY28uY29tPiwgIkFs aSBDLiBCZWdlbiIgPGFiZWdlbkBjaXNjby5jb20+DQo+Pj4gDQo+Pj4gDQo+Pj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXNpbmdlci1hcHBzYXdnLW1jYXN0LXVybC0wMC50eHQNCj4+PiBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRv IHRoZQ0KPj4+IElFVEYgcmVwb3NpdG9yeS4NCj4+PiANCj4+PiBOYW1lOgkJZHJhZnQtc2luZ2Vy LWFwcHNhd2ctbWNhc3QtdXJsDQo+Pj4gUmV2aXNpb246CTAwDQo+Pj4gVGl0bGU6CQlVUkxzIGFu ZCBIVFRQIFJlc3BvbnNlIEZvcm1zIGZvciBNdWx0aWNhc3QNCj4+PiBEb2N1bWVudCBkYXRlOgky MDE0LTEwLTE2DQo+Pj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+PiBQYWdlczoJ CTEyDQo+Pj4gVVJMOiAgICAgICAgICAgIA0KPj4+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtc2luZ2VyLWFwcHNhd2ctbWNhc3QtdXJsLTAwLnR4DQo+Pj50DQo+Pj4g U3RhdHVzOiAgICAgICAgIA0KPj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtc2luZ2VyLWFwcHNhd2ctbWNhc3QtdXJsLw0KPj4+IEh0bWxpemVkOiAgICAgICANCj4+Pmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpbmdlci1hcHBzYXdnLW1jYXN0LXVybC0w MA0KPj4+IA0KPj4+IA0KPj4+IEFic3RyYWN0Og0KPj4+ICBUaGlzIGRvY3VtZW50IG1vdGl2YXRl cyB0aGUgbmVlZCBmb3IgZGVmaW5pbmcgYSBVUkwgZm9yIG11bHRpY2FzdA0KPj4+ICBkZWxpdmVy eSBhbmQgcHJvdmlkZXMgYSBwcm9wb3NhbCBmb3IgdGhpcyBwdXJwb3NlLg0KPj4+IA0KPj4+IA0K Pj4+IA0KPj4+IA0KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4+c3VibWlzc2lvbg0KPj4+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+Pj4gDQo+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+PiANCj4+IA0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGFwcHMtZGlzY3VzcyBt YWlsaW5nIGxpc3QNCj4+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNClRoaXMgbWVzc2FnZSBtYXkgY29u dGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBpbnRlbmRlZCBmb3IgeW91LiBJZiB5b3UgYXJl IG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlmIHRoaXMgbWVzc2FnZSB3YXMgc2VudCB0byB5b3UgYnkg bWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0ZWQgdG8gaW5mb3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGUgbWVzc2FnZS4gVE5PIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciB0aGUgY29udGVudCBv ZiB0aGlzIGUtbWFpbCwgZm9yIHRoZSBtYW5uZXIgaW4gd2hpY2ggeW91IHVzZSBpdCBhbmQgZm9y IGRhbWFnZSBvZiBhbnkga2luZCByZXN1bHRpbmcgZnJvbSB0aGUgcmlza3MgaW5oZXJlbnQgdG8g dGhlIGVsZWN0cm9uaWMgdHJhbnNtaXNzaW9uIG9mIG1lc3NhZ2VzLgo= From nobody Mon Nov 10 12:09:24 2014 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 670811ACD8E for ; Mon, 10 Nov 2014 12:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 I6aeS-wtGXkn for ; Mon, 10 Nov 2014 12:09:09 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D8E1AC446 for ; Mon, 10 Nov 2014 12:09:06 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAAK95RI024291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 10 Nov 2014 20:09:06 GMT Received: from hermes-fe-2.easd.brm.oracle.com (hermes-fe-2.easd.brm.oracle.com [10.79.248.11]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAAK94gY029562 for ; Mon, 10 Nov 2014 20:09:04 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from [10.145.239.205] (dhcp-ukc1-twvpn-2-vpnpool-10-175-217-207.vpn.oracle.com [10.175.217.207]) by hermes-fe-2.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0NEU0023QAN0ZS00@hermes-fe-2.easd.brm.oracle.com> for apps-discuss@ietf.org; Mon, 10 Nov 2014 12:09:04 -0800 (PST) Date: Mon, 10 Nov 2014 10:09:01 -0700 From: Chris Newman To: Franck Martin , IETF Apps Discuss Message-id: <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> In-reply-to: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZL5lIR9m74TdJqE76ZawBOM3568 Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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, 10 Nov 2014 20:09:16 -0000 --On October 21, 2014 15:07:43 -0500 Franck Martin wrote: > I incorporated the previous feedback I received on this list into > http://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/ > > I have not seen comments since. Several people were supportive of the work. > > I'd like to submit this document to become a WG document for eventual > publication. > > If you have any comments on the current version, I'll update it as much as I > can before the deadline for drafts submission 27 October. > > I have some code running, tho I need to do some fixes in the code (and it is > not public yet), but it helped me to better understand what needs to be > exposed on how to do it. My view of this draft is it adds a lot of clutter to the wrong header and that information has little or no value. The one useful piece of information is the negotiated cipher suite, but that is most useful if the information is provided on a hop-by-hop basis so it belongs in the Received header, IMHO. In my experience, client certificate authentication in SSL/TLS is very uncommon in all protocols. The general model for client certificate authentication is that the server has a CA that is used to sign all client certificates that are used with that server. That model doesn't work for SMTP relay (although it's a model I have implemented and works fine for SMTP Submission). For client certificate authentication to work, the server has to request a client certificate, the client has to have one configured and to use it to authenticate the session. I'd like to see data on how many deployed SMTP servers that support TLS request a client certificate. I know the servers I work on do not request that by default. I also doubt most SSL/TLS appliances request client certificates by default. There's also no standard for how to use client certificates with SMTP relay. Server certificate authentication is widely used in SSL/TLS, but it's not useful in SMTP relay today because there is no standard for how to do it, and in particular for how it relates to MX records and non-primary MX hosts. Until such a standard is published, I'm opposed to recording misleading information about server authentication. I'll also point out that server authentication is performed by the client and only the client knows if it verified the server's identity. So server identity and authentication is completely contrary to the model of authentication used by other Authentication-Results uses because the server-authentication information for the "long hop" can only be generated from outside the recipient's administrative domain. I also do not view the server's opinion of the key strength of a TLS cipher suite to have any value. The server's opinion can be wrong if the client has a bad SSL stack. The cipher suite that was used is a specific piece of factual data. If 10 weeks ago we used a cipher suite that was suddenly recognized as broken today, the cipher suite used information is quite valuable, but the server's opinion of its effective key size or strength will be worthless. Finally, the draft does not state how this TLS information would be used. I'm opposed to adding all this clutter to headers unless there is some plausible utility. - Chris From nobody Mon Nov 10 14:16:26 2014 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 994651A871D for ; Mon, 10 Nov 2014 14:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMmdu_Fy4iKn for ; Mon, 10 Nov 2014 14:16:19 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A1B1A8720 for ; Mon, 10 Nov 2014 14:16:19 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id r20so110875wiv.1 for ; Mon, 10 Nov 2014 14:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7m7UjQTRjGM4UbkZsEJpGmIB3x0klP9ZoYBofOqkOss=; b=y7jWTl7ZlDmK9ETZ0VoQ17LDRL03LHfEjHBiur4t1JcL1fkl7j4eN7wnySgwyk2vmr HpEoXZjMS80z5R8JN6PCcO/sv4Fa+G75d0CqI/qCXZpe5Elau5ERbfaVhv83YD1hlScx dkK5+fIfASIw9KwjUP/C1ZUC955vsA+c59YCythUinM/+0T8Uqgb2QfHTx8UORbdoXsU VkKM9S+N0ZJ+7K3WdEPTPynh+L5wXJLvbdPIKWx6ppXx9aoE8idxnQKMn2KMT6SlAxor zLwQnnw0uL3vtxvFJTzsBJoUzekqMkjgWZuzDiGv9Z4bK6ZgjO1zAS1v2NeHHqQ+Awjx JFNg== MIME-Version: 1.0 X-Received: by 10.180.14.226 with SMTP id s2mr34130008wic.61.1415657776559; Mon, 10 Nov 2014 14:16:16 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 10 Nov 2014 14:16:16 -0800 (PST) In-Reply-To: <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> Date: Mon, 10 Nov 2014 12:16:16 -1000 Message-ID: From: "Murray S. Kucherawy" To: Chris Newman Content-Type: multipart/alternative; boundary=f46d04138c9fe53e60050788821f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vfccTqILOONdC6XjM4B6Cvx2UjM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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, 10 Nov 2014 22:16:23 -0000 --f46d04138c9fe53e60050788821f Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 7:09 AM, Chris Newman wrote: > My view of this draft is it adds a lot of clutter to the wrong header and > that > information has little or no value. > I disagree at least with the wrong header argument. We created Authentication-Results because we need a place to collect information about email authentication methods' results when the message enters an ADMD, because Received fields can be reordered, scrubbed, malformed, etc. It seems to be to be exactly the right place to do it. However, it can only record what the MTA at ADMD ingress saw, so if the STARTTLS information for the entire handling chain is what's needed, this can't do it (but I also imagine that can't be done reliably at all). The one useful piece of information is the negotiated cipher suite, but > that is > most useful if the information is provided on a hop-by-hop basis so it > belongs > in the Received header, IMHO. > Would you not want to know the identity of the client, if that's available? At least in the case where the client is actually associated with a particular sending ADMD (maybe with DANE), that might be useful information. You kind of answer this here: In my experience, client certificate authentication in SSL/TLS is very > uncommon > in all protocols. The general model for client certificate authentication > is > that the server has a CA that is used to sign all client certificates that > are > used with that server. That model doesn't work for SMTP relay (although > it's a > model I have implemented and works fine for SMTP Submission). For client > certificate authentication to work, the server has to request a client > certificate, the client has to have one configured and to use it to > authenticate the session. I'd like to see data on how many deployed SMTP > servers that support TLS request a client certificate. I know the servers I > work on do not request that by default. I also doubt most SSL/TLS > appliances > request client certificates by default. > As we move (slowly) toward authenticating and securing everything, is there no hope of this changing toward what Franck is envisioning? > I also do not view the server's opinion of the key strength of a TLS cipher > suite to have any value. The server's opinion can be wrong if the client > has a > bad SSL stack. The cipher suite that was used is a specific piece of > factual > data. If 10 weeks ago we used a cipher suite that was suddenly recognized > as > broken today, the cipher suite used information is quite valuable, but the > server's opinion of its effective key size or strength will be worthless. > The various details about what gets reported are certainly open for discussion. I'm mostly arguing that there's something here worth looking at, and that A-R is the right place to put it. > Finally, the draft does not state how this TLS information would be used. > I'm > opposed to adding all this clutter to headers unless there is some > plausible > utility. > Yes, a use case example would be good to include in any case. -MSK, just participatin' --f46d04138c9fe53e60050788821f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 7:09 AM, Chris Newman <chri= s.newman@oracle.com> wrote:
My view of this draf= t is it adds a lot of clutter to the wrong header and that
information has little or no value.

I d= isagree at least with the wrong header argument.=C2=A0 We created Authentic= ation-Results because we need a place to collect information about email au= thentication methods' results when the message enters an ADMD, because = Received fields can be reordered, scrubbed, malformed, etc.=C2=A0 It seems = to be to be exactly the right place to do it.=C2=A0 However, it can only re= cord what the MTA at ADMD ingress saw, so if the STARTTLS information for t= he entire handling chain is what's needed, this can't do it (but I = also imagine that can't be done reliably at all).

The one useful piece of information is the negotiated cipher suite, but tha= t is
most useful if the information is provided on a hop-by-hop basis so it belo= ngs
in the Received header, IMHO.

Would you= not want to know the identity of the client, if that's available?=C2= =A0 At least in the case where the client is actually associated with a par= ticular sending ADMD (maybe with DANE), that might be useful information.
You kind of answer this here:

In my experience, client certificate authentication in SSL/TLS is very unco= mmon
in all protocols. The general model for client certificate authentication i= s
that the server has a CA that is used to sign all client certificates that = are
used with that server. That model doesn't work for SMTP relay (although= it's a
model I have implemented and works fine for SMTP Submission). For client certificate authentication to work, the server has to request a client
certificate, the client has to have one configured and to use it to
authenticate the session. I'd like to see data on how many deployed SMT= P
servers that support TLS request a client certificate. I know the servers I=
work on do not request that by default. I also doubt most SSL/TLS appliance= s
request client certificates by default.

As we move (slowly) toward authenticating and securing everything, is ther= e no hope of this changing toward what Franck is envisioning?
=C2=A0
=
I also do not view the server's opinion of the key strength of a TLS ci= pher
suite to have any value. The server's opinion can be wrong if the clien= t has a
bad SSL stack. The cipher suite that was used is a specific piece of factua= l
data. If 10 weeks ago we used a cipher suite that was suddenly recognized a= s
broken today, the cipher suite used information is quite valuable, but the<= br> server's opinion of its effective key size or strength will be worthles= s.

The various details about what gets = reported are certainly open for discussion.=C2=A0 I'm mostly arguing th= at there's something here worth looking at, and that A-R is the right p= lace to put it.
=C2=A0
Finally, the draft does not state how this TLS information would be used. I= 'm
opposed to adding all this clutter to headers unless there is some plausibl= e
utility.

Yes, a use case example would = be good to include in any case.

-MSK, just participatin&= #39;
--f46d04138c9fe53e60050788821f-- From nobody Mon Nov 10 14:23:35 2014 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 123C21A8935 for ; Mon, 10 Nov 2014 14:23:33 -0800 (PST) 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 n_lOPUVZrDDc for ; Mon, 10 Nov 2014 14:23:32 -0800 (PST) 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 E419B1A8918 for ; Mon, 10 Nov 2014 14:23:31 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sAAMNSTZ013895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Nov 2014 14:23:31 -0800 Message-ID: <54613ADC.2030401@dcrocker.net> Date: Mon, 10 Nov 2014 14:23:24 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chris Newman , Franck Martin References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> In-Reply-To: <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 10 Nov 2014 14:23:31 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bl0xcRmmVIRxemKMsU6944-tpoI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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: Mon, 10 Nov 2014 22:23:33 -0000 On 11/10/2014 9:09 AM, Chris Newman wrote: > My view of this draft is +1 to each of the points in Chris' well-considered note. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 10 16:04:11 2014 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 DC6921AC445 for ; Mon, 10 Nov 2014 16:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ToUEFO9hrFNC for ; Mon, 10 Nov 2014 16:03:43 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 448421A6EE9 for ; Mon, 10 Nov 2014 16:03:41 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 2618D564D24; Mon, 10 Nov 2014 18:03:34 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 156BFA05CE; Mon, 10 Nov 2014 18:03:34 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3rLTlpEeBIe; Mon, 10 Nov 2014 18:03:33 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A39A2A05D6; Mon, 10 Nov 2014 18:03:33 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com A39A2A05D6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415664213; bh=t9BN48VwAkhppF7qsSiKh6VG1+ItBOvrIZ4t2tzQUuY=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=fT29JLCdowoT0N86NhR0LcXmtrDxWqq67CrIU1iwEMery1rGi3YnOGPqwGls2Jj6C bx0Fd6dD8yjaEUmQQXxQS1XtUIrD0ZO2SlupmSmjaZCZLUDmv6wQrT05jWU3PWJNSD iG82++OFhsPHuOMz8XfQJnWS5idSYEwXTE30w2gY= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 83657A05D1; Mon, 10 Nov 2014 18:03:33 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HUu4INSXSnwU; Mon, 10 Nov 2014 18:03:33 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 4CA6BA05CE; Mon, 10 Nov 2014 18:03:33 -0600 (CST) Date: Mon, 10 Nov 2014 18:03:33 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <216663621.27915.1415664213150.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27914_1889869319.1415664213150" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: WG adoption for draft-martin-authentication-results-tls ? Thread-Index: cENyDh8CYMQxkD07qm6NcwmucxAJPg== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Kel_OgFfpTdir3op3agPRyNTFbs Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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, 11 Nov 2014 00:03:49 -0000 ------=_Part_27914_1889869319.1415664213150 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Chris Newman" > Cc: "Franck Martin" , "IETF Apps Discuss" > > Sent: Monday, November 10, 2014 2:16:16 PM > Subject: Re: [apps-discuss] WG adoption for > draft-martin-authentication-results-tls ? > On Mon, Nov 10, 2014 at 7:09 AM, Chris Newman < chris.newman@oracle.com > > wrote: > > My view of this draft is it adds a lot of clutter to the wrong header and > > that > > > information has little or no value. > > I disagree at least with the wrong header argument. We created > Authentication-Results because we need a place to collect information about > email authentication methods' results when the message enters an ADMD, > because Received fields can be reordered, scrubbed, malformed, etc. It seems > to be to be exactly the right place to do it. However, it can only record > what the MTA at ADMD ingress saw, so if the STARTTLS information for the > entire handling chain is what's needed, this can't do it (but I also imagine > that can't be done reliably at all). > > The one useful piece of information is the negotiated cipher suite, but > > that > > is > > > most useful if the information is provided on a hop-by-hop basis so it > > belongs > > > in the Received header, IMHO. > > Would you not want to know the identity of the client, if that's available? > At least in the case where the client is actually associated with a > particular sending ADMD (maybe with DANE), that might be useful information. > You kind of answer this here: > > In my experience, client certificate authentication in SSL/TLS is very > > uncommon > > > in all protocols. The general model for client certificate authentication > > is > > > that the server has a CA that is used to sign all client certificates that > > are > > > used with that server. That model doesn't work for SMTP relay (although > > it's > > a > > > model I have implemented and works fine for SMTP Submission). For client > > > certificate authentication to work, the server has to request a client > > > certificate, the client has to have one configured and to use it to > > > authenticate the session. I'd like to see data on how many deployed SMTP > > > servers that support TLS request a client certificate. I know the servers I > > > work on do not request that by default. I also doubt most SSL/TLS > > appliances > > > request client certificates by default. > > As we move (slowly) toward authenticating and securing everything, is there > no hope of this changing toward what Franck is envisioning? > > I also do not view the server's opinion of the key strength of a TLS cipher > > > suite to have any value. The server's opinion can be wrong if the client > > has > > a > > > bad SSL stack. The cipher suite that was used is a specific piece of > > factual > > > data. If 10 weeks ago we used a cipher suite that was suddenly recognized > > as > > > broken today, the cipher suite used information is quite valuable, but the > > > server's opinion of its effective key size or strength will be worthless. > > The various details about what gets reported are certainly open for > discussion. I'm mostly arguing that there's something here worth looking at, > and that A-R is the right place to put it. > > Finally, the draft does not state how this TLS information would be used. > > I'm > > > opposed to adding all this clutter to headers unless there is some > > plausible > > > utility. > > Yes, a use case example would be good to include in any case. I think many questions about the usefulness of AR are answered in http://tools.ietf.org/html/rfc7001 remembers this is just an update of this RFC. Some example could be useful indeed. While this information should also be in Received Headers, I never succeeded to teach appropriately a tech support to read correctly received headers and not be tricked. It is way much easier to say read the AR header. Finally, SMTP servers work in dual mode (client+server) while HTTP servers works in sever mode only. The server certificate in SMTP is often used as the client certificate too. This is why you may see more client certificates with SMTP than with HTTP. Is the information useful, may be. I'm not sure all the fields described in the protocol are useful. As it is the early days, I just want them there, so implementation can pick what they think is useful, and if adopted by the workgroup some fields will be culled as we get better understanding and data. However one may envision that one day, TLS authentication may be used in policy protocols like DMARC. ------=_Part_27914_1889869319.1415664213150 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


From: "Murra= y S. Kucherawy" <superuser@gmail.com>
To: "Chris Newman" &l= t;chris.newman@oracle.com>
Cc: "Franck Martin" <franck@peac= hymango.org>, "IETF Apps Discuss" <apps-discuss@ietf.org>
Se= nt: Monday, November 10, 2014 2:16:16 PM
Subject: Re: [apps-d= iscuss] WG adoption for draft-martin-authentication-results-tls ?
<= br>
On Mon, Nov 10, 2014 at 7:09 AM, Chris Newman <chris.newman@oracle.com> wrote:
My view of = this draft is it adds a lot of clutter to the wrong header and that
information has little or no value.

I d= isagree at least with the wrong header argument.  We created Authentic= ation-Results because we need a place to collect information about email au= thentication methods' results when the message enters an ADMD, because Rece= ived fields can be reordered, scrubbed, malformed, etc.  It seems to b= e to be exactly the right place to do it.  However, it can only record= what the MTA at ADMD ingress saw, so if the STARTTLS information for the e= ntire handling chain is what's needed, this can't do it (but I also imagine= that can't be done reliably at all).

The one useful piece of information is the negotiated cipher suite, but tha= t is
most useful if the information is provided on a hop-by-hop basis so it belo= ngs
in the Received header, IMHO.

Would you= not want to know the identity of the client, if that's available?  At= least in the case where the client is actually associated with a particula= r sending ADMD (maybe with DANE), that might be useful information.

You kind of answer this here:

In my experience, client certificate authentication in SSL/TLS is very unco= mmon
in all protocols. The general model for client certificate authentication i= s
that the server has a CA that is used to sign all client certificates that = are
used with that server. That model doesn't work for SMTP relay (although it'= s a
model I have implemented and works fine for SMTP Submission). For client certificate authentication to work, the server has to request a client
certificate, the client has to have one configured and to use it to
authenticate the session. I'd like to see data on how many deployed SMTP servers that support TLS request a client certificate. I know the servers I=
work on do not request that by default. I also doubt most SSL/TLS appliance= s
request client certificates by default.

As we move (slowly) toward authenticating and securing everything, is ther= e no hope of this changing toward what Franck is envisioning?

=
I also do not view the server's opinion of the key strength of a TLS cipher=
suite to have any value. The server's opinion can be wrong if the client ha= s a
bad SSL stack. The cipher suite that was used is a specific piece of factua= l
data. If 10 weeks ago we used a cipher suite that was suddenly recognized a= s
broken today, the cipher suite used information is quite valuable, but the<= br> server's opinion of its effective key size or strength will be worthless.

The various details about what gets repo= rted are certainly open for discussion.  I'm mostly arguing that there= 's something here worth looking at, and that A-R is the right place to put = it.

Finally, the draft does not state how this TLS information would be used. I= 'm
opposed to adding all this clutter to headers unless there is some plausibl= e
utility.

Yes, a use case example would = be good to include in any case.

I think many questions about the usefulness of AR are ans= wered in http://tools.ietf.o= rg/html/rfc7001 remembers this is just an update of this RFC.
=

Some example could be useful indeed.

=
While this information should also be in Received Headers, I nev= er succeeded to teach appropriately a tech support to read correctly receiv= ed headers and not be tricked. It is way much easier to say read the AR hea= der.

Finally, SMTP servers work in dual mode (= client+server) while HTTP servers works in sever mode only. The server cert= ificate in SMTP is often used as the client certificate too. This is why yo= u may see more client certificates with SMTP than with HTTP.
=
Is the information useful, may be. I'm not sure all the fiel= ds described in the protocol are useful. As it is the early days, I just wa= nt them there, so implementation can pick what they think is useful, and if= adopted by the workgroup some fields will be culled as we get better under= standing and data.

However one may envision that = one day, TLS authentication may be used in policy protocols like DMARC.
=
------=_Part_27914_1889869319.1415664213150-- From nobody Mon Nov 10 16:49:17 2014 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 5E7031AD371 for ; Mon, 10 Nov 2014 16:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 t5kjfLkWMWy7 for ; Mon, 10 Nov 2014 16:49:12 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7CC1AD36F for ; Mon, 10 Nov 2014 16:49:11 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAB0nAk2016946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Nov 2014 00:49:10 GMT Received: from hermes-fe-2.easd.brm.oracle.com (hermes-fe-2.easd.brm.oracle.com [10.79.248.11]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAB0n9OV028007 for ; Tue, 11 Nov 2014 00:49:09 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from [10.175.237.151] (dhcp-ukc1-twvpn-3-vpnpool-10-175-237-151.vpn.oracle.com [10.175.237.151]) by hermes-fe-2.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0NEU0025ENLSZS00@hermes-fe-2.easd.brm.oracle.com> for apps-discuss@ietf.org; Mon, 10 Nov 2014 16:49:09 -0800 (PST) Date: Mon, 10 Nov 2014 14:49:05 -1000 From: Chris Newman To: "Murray S. Kucherawy" Message-id: <40083C4B3048495991CE736E@96B2F16665FF96BAE59E9B90> In-reply-to: References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QKJccT_F6EfR4b1b_DwppIfX5Xo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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, 11 Nov 2014 00:49:14 -0000 --On November 10, 2014 12:16:16 -1000 "Murray S. Kucherawy" wrote: > On Mon, Nov 10, 2014 at 7:09 AM, Chris Newman > wrote: >> My view of this draft is it adds a lot of clutter to the wrong header and >> that >> information has little or no value. > > I disagree at least with the wrong header argument. We created > Authentication-Results because we need a place to collect information about > email authentication methods' results when the message enters an ADMD, > because Received fields can be reordered, scrubbed, malformed, etc. It > seems to be to be exactly the right place to do it. Point me to the standard that describes the client certificate authentication model for MTA to MTA SMTP relay, and I might agree. Absent that, there's no authentication model and thus no authentication information to record. RFC 3207 clearly defines any form of TLS authentication as a local matter, and thus any information about that authentication is of no relevance to the end-user's client because there is no model for interoperability. > However, it can only > record what the MTA at ADMD ingress saw, so if the STARTTLS information for > the entire handling chain is what's needed, this can't do it (but I also > imagine that can't be done reliably at all). Recording use of STARTTLS cipher suites on a hop-by-hop basis as trace information is quite helpful. It's not authentication information and not reliable, but it can identify weak points in the privacy chain where pressure can be applied to upgrade systems. It can also be correlated with MTA logs in the event a full privacy assessment is necessary. > Would you not want to know the identity of the client, if that's > available? I'm fairly certain that X.509 Subject/Issuer DNs with no defined relationship to SMTP relay are of no value to end-user clients. I'm skeptical they would be useful if a standardized relationship was defined. > At least in the case where the client is actually associated > with a particular sending ADMD (maybe with DANE), that might be useful > information. How would an end-user's client use this information? > The various details about what gets reported are certainly open for > discussion. I'm mostly arguing that there's something here worth looking > at, and that A-R is the right place to put it. An SMTP MTA relay client certificate authentication model could be quite useful. Once such a model existed it may make sense to put the results in an authentication-results header if it provided information that an end-user's mail client could act on in a constructive and useful way. But this proposal is like building the cart before anyone knows what a horse looks like. - Chris From nobody Mon Nov 10 17:28:26 2014 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 B9BD61AD37E for ; Mon, 10 Nov 2014 17:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.083 X-Spam-Level: *** X-Spam-Status: No, score=3.083 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 XQ7rq2-2Xl-F for ; Mon, 10 Nov 2014 17:28:22 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.239]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E201A1BCA for ; Mon, 10 Nov 2014 17:28:22 -0800 (PST) Date: Tue, 11 Nov 2014 02:28:20 +0100 From: Mateusz Karcz To: apps-discuss@ietf.org X-Mailer: interia.pl/pf09 X-Originating-IP: 109.207.150.139 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1415669299; bh=jaZ2nc7QfC6VxGHBl7OlVbejlvBfJcBm5W0S+mYe1fk=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lM1DfrthYhxYYCIK++8s8V9iRkYYxJJsyseA2NtGcfkrLvxSfcJsz1Zw0d6JydF7i oJUm0AhlnP5UMZ9LI+VJgaRA/6VFUaroDrrbivLbQYOKlJ/KW18hwpN4Op0mWmeFwl n8JhfJXfblISkzP2Z+35eGx+vBOuK0l6QVxbRX4c= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QyzrghvTk50PF1I3pJBj_ZA8miA Subject: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 11 Nov 2014 01:28:25 -0000 Welcome. After two years of thinking and two nights of working I've finally written = the second revision of my I-D. I changed construction of the draft, simplif= ied proposed UUAS structure, made a research about security and added some = other, minor changes. I've committed it as draft-karcz-uuas-01. I would like to see Your comments about it. Could You check out this draft = and clarify me a way of developing it? Sincerely, Mateusz Karcz= From nobody Mon Nov 10 17:29:39 2014 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 40A691A1BCA for ; Mon, 10 Nov 2014 17:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAQHxu5tHksk for ; Mon, 10 Nov 2014 17:29:36 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C8C1AD384 for ; Mon, 10 Nov 2014 17:29:36 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so10315621wgh.27 for ; Mon, 10 Nov 2014 17:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pkkinMVeLfMO2x1vWXL5N2DfWMW5FP0DWFkw1WpxN3Y=; b=I0yaQaJRfivqG2C4rFconcp/YiWHcZrrnl7Z1Vj0vcEYb1lEX0JjEWa/IJ89WhHrpz 1PjBJgcpDwbtJO5ezhvrQnePJLN2ATxEqGjBB1nkr6fJTXhva4qumW4zf+hFOB02wHmf qjNqMuJzIj1QOvjXVtJ/0kpkJzf44CNj6du4uJNkK0ifPLPoIiLL+1HGQ7Xrb0+7Up4L XpncoZBB+N+0oouEWjzQzV6Sbu1mJvPzJkKVIW3719GZ7FR1cEXoGI6xnGR4JY0w57K9 J+0AQf8kAS9Lk9AcJrSiI+jF8omnWFg757w9ETs8ou5phXzravuAvy6FxUUia7IrOAGn iWPQ== MIME-Version: 1.0 X-Received: by 10.194.157.137 with SMTP id wm9mr49430520wjb.5.1415669375289; Mon, 10 Nov 2014 17:29:35 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 10 Nov 2014 17:29:35 -0800 (PST) In-Reply-To: <40083C4B3048495991CE736E@96B2F16665FF96BAE59E9B90> References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> <40083C4B3048495991CE736E@96B2F16665FF96BAE59E9B90> Date: Mon, 10 Nov 2014 15:29:35 -1000 Message-ID: From: "Murray S. Kucherawy" To: Chris Newman Content-Type: multipart/alternative; boundary=089e013c6b683bcfd505078b3696 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cyfypHR6cuVZAxCQW5PcdejqK2s Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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, 11 Nov 2014 01:29:38 -0000 --089e013c6b683bcfd505078b3696 Content-Type: text/plain; charset=UTF-8 I don't have good answers to the authentication model questions, so I'll leave Franck to chase that down with you. On this point: On Mon, Nov 10, 2014 at 2:49 PM, Chris Newman wrote: > > > At least in the case where the client is actually associated > > with a particular sending ADMD (maybe with DANE), that might be useful > > information. > > How would an end-user's client use this information? > I imagine in the same way that some MUAs use or are starting to use things like DKIM. Gmail, for example, might say this message is "From Chris Newman via ietf.org" if ietf.org signed it with DKIM. I'm guessing the authenticated SMTP client could be similarly revealed. -MSK --089e013c6b683bcfd505078b3696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't have good answers to the authentication model = questions, so I'll leave Franck to chase that down with you.=C2=A0 On t= his point:

On Mon, Nov 10, 2014 at 2:49 PM, Chris Newman <c= hris.newman@oracle.com> wrote:
=
=
> At least in the case where the client is actually associated
> with a particular sending ADMD (maybe with DANE), that might be useful=
> information.

How would an end-user's client use this information?

I imagine in the same way= that some MUAs use or are starting to use things like DKIM.=C2=A0 Gmail, f= or example, might say this message is "From Chris Newman via ietf.org" if ietf= .org signed it with DKIM.=C2=A0 I'm guessing the authenticated SMTP= client could be similarly revealed.

-MSK
=
--089e013c6b683bcfd505078b3696-- From nobody Mon Nov 10 17:35:00 2014 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 96CB31AD38F for ; Mon, 10 Nov 2014 17:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0zyfMaKphv3 for ; Mon, 10 Nov 2014 17:34:58 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6091ACF12 for ; Mon, 10 Nov 2014 17:34:57 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id r20so188229wiv.16 for ; Mon, 10 Nov 2014 17:34:56 -0800 (PST) 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=e8CQ+P8rACvdcVJTeroPV2VLLs4m13OZPO+4znGQWcw=; b=I+gJaodZ+RW2rx/ws/xoPA4H+0AbNLQPFFsOym8yVKup6UFUdbP2V6/NHsgzkfVgw/ Wq+mf7xjZws9dlYs3RC2hU9HKRuqHVRMO4wuetCDaqLvyMQ4FDlimBWi7YGLt53yrub2 gsHVfwfvzF1qvp+j6k5t62GAfgs9q2K2TxfRCx7tYB/UTUGSidWE5EAq8xZJ9Woc0Hil 0i7Zh9wMQA44o8epgKZK1EP+Ah38G0+2kgYyqBSUmE307xJXTp4LsOkIMz3amk3f0rP5 IVJS5+ms7asFUf7U+I1WLQWKCJMrxDNHmL71/1NNUmbxnUdqVmRBH692BnMq+NzhByRl 2hJQ== MIME-Version: 1.0 X-Received: by 10.180.221.129 with SMTP id qe1mr36424861wic.21.1415669696705; Mon, 10 Nov 2014 17:34:56 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 10 Nov 2014 17:34:56 -0800 (PST) Date: Mon, 10 Nov 2014 15:34:56 -1000 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1133c8fa643c0d05078b494f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EfQfF2juws8fdvUzSD8X2JV4YVQ Subject: [apps-discuss] Various image/* media type drafts 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, 11 Nov 2014 01:34:59 -0000 --001a1133c8fa643c0d05078b494f Content-Type: text/plain; charset=UTF-8 Colleagues, After the meeting today, I proposed that Sean combine all of his image/* media type registrations into a single document. Each registration should be fairly short, just the basic template each time with a reference to the defining document. I concurred with Mark and others in the room who said he should just register the "x-" subtypes as-is, paying appropriate homage to the X- BCP and updated registrations BCP. I suggest that such a consolidation draft would be eligible for a Call For Adoption given the feeling in the room, which is to say that there was no objection to APPSAWG processing of them when I asked. I didn't want to take up a bunch of slots (and do a bunch of WGLCs, LCs, AD Evaluations, etc.) when combining the various proposals would be simpler, with other work also proposed for the WG. Is there any peril to proceeding under those guidelines? If none, then Sean can proceed to produce that at his convenience. -MSK, co-chairin' --001a1133c8fa643c0d05078b494f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

After the meeting today,= I proposed that Sean combine all of his image/* media type registrations i= nto a single document.=C2=A0 Each registration should be fairly short, just= the basic template each time with a reference to the defining document.
I concurred with Mark and others in the room who said he should just r= egister the "x-" subtypes as-is, paying appropriate homage to the= X- BCP and updated registrations BCP.

I suggest that such a c= onsolidation draft would be eligible for a Call For Adoption given the feel= ing in the room, which is to say that there was no objection to APPSAWG pro= cessing of them when I asked.=C2=A0 I didn't want to take up a bunch of= slots (and do a bunch of WGLCs, LCs, AD Evaluations, etc.) when combining = the various proposals would be simpler, with other work also proposed for t= he WG.

Is there any peril to proceeding under those guidelines= ?=C2=A0 If none, then Sean can proceed to produce that at his convenience.<= br>
-MSK, co-chairin'
--001a1133c8fa643c0d05078b494f-- From nobody Mon Nov 10 17:54:16 2014 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 408551AD3EC for ; Mon, 10 Nov 2014 17:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNDr4trn1CoP for ; Mon, 10 Nov 2014 17:54:04 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859041AD3ED for ; Mon, 10 Nov 2014 17:54:03 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.1.11.14; Tue, 11 Nov 2014 01:54:02 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0011.000; Tue, 11 Nov 2014 01:54:02 +0000 From: Dave Thaler To: "Murray S. Kucherawy" , IETF Apps Discuss Thread-Topic: [apps-discuss] Various image/* media type drafts Thread-Index: AQHP/U+6SGS3kLpnS027R4HkmdOnJJxaqdJQ Date: Tue, 11 Nov 2014 01:54:02 +0000 Message-ID: <9e415492c64849feaf05b5aa76cd8343@BY2PR03MB412.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [31.133.166.252] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB409; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB409; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(33646002)(76576001)(46102003)(15202345003)(87936001)(2656002)(15975445006)(101416001)(16236675004)(19580395003)(19580405001)(74316001)(19300405004)(122556002)(97736003)(62966003)(77156002)(40100003)(31966008)(86612001)(92566001)(86362001)(50986999)(76176999)(120916001)(19625215002)(54356999)(108616004)(99396003)(107886001)(107046002)(106116001)(105586002)(20776003)(106356001)(99286002)(95666004)(4396001)(21056001)(64706001)(66066001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_9e415492c64849feaf05b5aa76cd8343BY2PR03MB412namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/O1Mg91kq8LoYrJkFdKOItt4c9cc Subject: Re: [apps-discuss] Various image/* media type drafts 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, 11 Nov 2014 01:54:10 -0000 --_000_9e415492c64849feaf05b5aa76cd8343BY2PR03MB412namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgb25lIG9mIHRoZSByZXZpZXdlcnMgb2YgdGhlIGN1cnJlbnQgZG9jcywgdGhpcyBzb3VuZHMg Z29vZCB0byBtZS4NCi1EYXZlDQoNCkZyb206IGFwcHMtZGlzY3VzcyBbbWFpbHRvOmFwcHMtZGlz Y3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVycmF5IFMuIEt1Y2hlcmF3eQ0K U2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMCwgMjAxNCAzOjM1IFBNDQpUbzogSUVURiBBcHBzIERp c2N1c3MNClN1YmplY3Q6IFthcHBzLWRpc2N1c3NdIFZhcmlvdXMgaW1hZ2UvKiBtZWRpYSB0eXBl IGRyYWZ0cw0KDQpDb2xsZWFndWVzLA0KDQpBZnRlciB0aGUgbWVldGluZyB0b2RheSwgSSBwcm9w b3NlZCB0aGF0IFNlYW4gY29tYmluZSBhbGwgb2YgaGlzIGltYWdlLyogbWVkaWEgdHlwZSByZWdp c3RyYXRpb25zIGludG8gYSBzaW5nbGUgZG9jdW1lbnQuICBFYWNoIHJlZ2lzdHJhdGlvbiBzaG91 bGQgYmUgZmFpcmx5IHNob3J0LCBqdXN0IHRoZSBiYXNpYyB0ZW1wbGF0ZSBlYWNoIHRpbWUgd2l0 aCBhIHJlZmVyZW5jZSB0byB0aGUgZGVmaW5pbmcgZG9jdW1lbnQuDQoNCkkgY29uY3VycmVkIHdp dGggTWFyayBhbmQgb3RoZXJzIGluIHRoZSByb29tIHdobyBzYWlkIGhlIHNob3VsZCBqdXN0IHJl Z2lzdGVyIHRoZSAieC0iIHN1YnR5cGVzIGFzLWlzLCBwYXlpbmcgYXBwcm9wcmlhdGUgaG9tYWdl IHRvIHRoZSBYLSBCQ1AgYW5kIHVwZGF0ZWQgcmVnaXN0cmF0aW9ucyBCQ1AuDQpJIHN1Z2dlc3Qg dGhhdCBzdWNoIGEgY29uc29saWRhdGlvbiBkcmFmdCB3b3VsZCBiZSBlbGlnaWJsZSBmb3IgYSBD YWxsIEZvciBBZG9wdGlvbiBnaXZlbiB0aGUgZmVlbGluZyBpbiB0aGUgcm9vbSwgd2hpY2ggaXMg dG8gc2F5IHRoYXQgdGhlcmUgd2FzIG5vIG9iamVjdGlvbiB0byBBUFBTQVdHIHByb2Nlc3Npbmcg b2YgdGhlbSB3aGVuIEkgYXNrZWQuICBJIGRpZG4ndCB3YW50IHRvIHRha2UgdXAgYSBidW5jaCBv ZiBzbG90cyAoYW5kIGRvIGEgYnVuY2ggb2YgV0dMQ3MsIExDcywgQUQgRXZhbHVhdGlvbnMsIGV0 Yy4pIHdoZW4gY29tYmluaW5nIHRoZSB2YXJpb3VzIHByb3Bvc2FscyB3b3VsZCBiZSBzaW1wbGVy LCB3aXRoIG90aGVyIHdvcmsgYWxzbyBwcm9wb3NlZCBmb3IgdGhlIFdHLg0KSXMgdGhlcmUgYW55 IHBlcmlsIHRvIHByb2NlZWRpbmcgdW5kZXIgdGhvc2UgZ3VpZGVsaW5lcz8gIElmIG5vbmUsIHRo ZW4gU2VhbiBjYW4gcHJvY2VlZCB0byBwcm9kdWNlIHRoYXQgYXQgaGlzIGNvbnZlbmllbmNlLg0K LU1TSywgY28tY2hhaXJpbicNCg== --_000_9e415492c64849feaf05b5aa76cd8343BY2PR03MB412namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5 NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBvbmUgb2YgdGhlIHJldmlld2Vy cyBvZiB0aGUgY3VycmVudCBkb2NzLCB0aGlzIHNvdW5kcyBnb29kIHRvIG1lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LURhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBhcHBzLWRpc2N1c3MgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TXVycmF5IFMuIEt1Y2hlcmF3eTxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDEwLCAyMDE0IDM6MzUgUE08YnI+DQo8Yj5U bzo8L2I+IElFVEYgQXBwcyBEaXNjdXNzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFthcHBzLWRpc2N1 c3NdIFZhcmlvdXMgaW1hZ2UvKiBtZWRpYSB0eXBlIGRyYWZ0czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkNvbGxlYWd1ZXMsPGJyPg0KPGJyPg0KQWZ0ZXIg dGhlIG1lZXRpbmcgdG9kYXksIEkgcHJvcG9zZWQgdGhhdCBTZWFuIGNvbWJpbmUgYWxsIG9mIGhp cyBpbWFnZS8qIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9ucyBpbnRvIGEgc2luZ2xlIGRvY3VtZW50 LiZuYnNwOyBFYWNoIHJlZ2lzdHJhdGlvbiBzaG91bGQgYmUgZmFpcmx5IHNob3J0LCBqdXN0IHRo ZSBiYXNpYyB0ZW1wbGF0ZSBlYWNoIHRpbWUgd2l0aCBhIHJlZmVyZW5jZSB0byB0aGUgZGVmaW5p bmcgZG9jdW1lbnQuPGJyPg0KPGJyPg0KSSBjb25jdXJyZWQgd2l0aCBNYXJrIGFuZCBvdGhlcnMg aW4gdGhlIHJvb20gd2hvIHNhaWQgaGUgc2hvdWxkIGp1c3QgcmVnaXN0ZXIgdGhlICZxdW90O3gt JnF1b3Q7IHN1YnR5cGVzIGFzLWlzLCBwYXlpbmcgYXBwcm9wcmlhdGUgaG9tYWdlIHRvIHRoZSBY LSBCQ1AgYW5kIHVwZGF0ZWQgcmVnaXN0cmF0aW9ucyBCQ1AuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBz dWdnZXN0IHRoYXQgc3VjaCBhIGNvbnNvbGlkYXRpb24gZHJhZnQgd291bGQgYmUgZWxpZ2libGUg Zm9yIGEgQ2FsbCBGb3IgQWRvcHRpb24gZ2l2ZW4gdGhlIGZlZWxpbmcgaW4gdGhlIHJvb20sIHdo aWNoIGlzIHRvIHNheSB0aGF0IHRoZXJlIHdhcyBubyBvYmplY3Rpb24gdG8gQVBQU0FXRyBwcm9j ZXNzaW5nIG9mIHRoZW0gd2hlbiBJIGFza2VkLiZuYnNwOyBJIGRpZG4ndA0KIHdhbnQgdG8gdGFr ZSB1cCBhIGJ1bmNoIG9mIHNsb3RzIChhbmQgZG8gYSBidW5jaCBvZiBXR0xDcywgTENzLCBBRCBF dmFsdWF0aW9ucywgZXRjLikgd2hlbiBjb21iaW5pbmcgdGhlIHZhcmlvdXMgcHJvcG9zYWxzIHdv dWxkIGJlIHNpbXBsZXIsIHdpdGggb3RoZXIgd29yayBhbHNvIHByb3Bvc2VkIGZvciB0aGUgV0cu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SXMgdGhlcmUgYW55IHBlcmlsIHRvIHByb2NlZWRpbmcgdW5kZXIg dGhvc2UgZ3VpZGVsaW5lcz8mbmJzcDsgSWYgbm9uZSwgdGhlbiBTZWFuIGNhbiBwcm9jZWVkIHRv IHByb2R1Y2UgdGhhdCBhdCBoaXMgY29udmVuaWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1NU0ssIGNvLWNoYWlyaW4nPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9e415492c64849feaf05b5aa76cd8343BY2PR03MB412namprd03pro_-- From nobody Mon Nov 10 17:57:44 2014 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 D10991AD400 for ; Mon, 10 Nov 2014 17:57:42 -0800 (PST) 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_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 cFlcz4APTTjF for ; Mon, 10 Nov 2014 17:57:41 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25F31AD3FD for ; Mon, 10 Nov 2014 17:57:40 -0800 (PST) Received: from dhcp-bbc0.meeting.ietf.org (unknown [31.133.187.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 60EC222E253; Mon, 10 Nov 2014 20:57:32 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_0AB70F30-5520-488D-A9B3-0B540896DB54"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Mon, 10 Nov 2014 15:56:36 -1000 Message-Id: <5D32EA67-3EEE-4369-B44B-3FCE9E2F64FA@seantek.com> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tOnUtcDDJlJt4KxKTyTTXmMeVic Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Various image/* media type drafts 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, 11 Nov 2014 01:57:43 -0000 --Apple-Mail=_0AB70F30-5520-488D-A9B3-0B540896DB54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi colleagues, I wanted to both concur with what Murray said, and offer elaboration = (which is somewhat contradictory). I don=92t mind combining the image registrations. However there are three ways that the registered types could go: #1 image/x-FOO only #2 image/FOO, with image/x-FOO as deprecated aliases #3 something else Based on my understanding of this subject matter, my (experienced?) = opinion is that #2 is the way to go. Unlike say =93application/x-www-form-urlencoded=94, these image types = are not quite as hard-coded into the Internet (specifically Web) = infrastructure as one might think. Historically web browsers and HTML = viewers have taken the image media type as a hint only, passing the = stream to its all-purpose image processing library (=93libpr0n=94). Of these three types, =93image/bmp=94 has actually been used in = practice. It was served as such by Apache software across the board = until 2010, when in a bug report in TIKA = , it was renamed to = =93image/x-ms-bmp=94 in that piece of software. But Apache httpd itself = still serves =93image/bmp=94: = .= Furthermore, the media type =93image/bmp=94 has been baked into Windows = for years, see HKEY_CLASSES_ROOT\Mime\Database\Content Type\image/bmp in = your friendly local Windows build. So at least for Windows Bitmaps, the shoe is on the other foot: it is = arguably more harmful to register image/x-*** (even in deprecated alias = types) compared to just saying image/bmp and being done with it. Maybe = image/bmp was wrong at the time, but it=92s the right position to be in = now (and it=92s compatible with the relevant BCPs). As for the metafiles, if people are serving WMFs and EMFs in webpages = for general consumption, we have a more serious issue than futzing with = the label. Thus I don=92t see the interoperability harm in standardizing = image/wmf and image/emf=85at least pending resolution of what Microsoft = wants to do or recognize. Cheers, Sean On Nov 10, 2014, at 3:34 PM, Murray S. Kucherawy = wrote: > Colleagues, >=20 > After the meeting today, I proposed that Sean combine all of his = image/* media type registrations into a single document. Each = registration should be fairly short, just the basic template each time = with a reference to the defining document. >=20 > I concurred with Mark and others in the room who said he should just = register the "x-" subtypes as-is, paying appropriate homage to the X- = BCP and updated registrations BCP. >=20 > I suggest that such a consolidation draft would be eligible for a Call = For Adoption given the feeling in the room, which is to say that there = was no objection to APPSAWG processing of them when I asked. I didn't = want to take up a bunch of slots (and do a bunch of WGLCs, LCs, AD = Evaluations, etc.) when combining the various proposals would be = simpler, with other work also proposed for the WG. >=20 > Is there any peril to proceeding under those guidelines? If none, = then Sean can proceed to produce that at his convenience. >=20 > -MSK, co-chairin' > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_0AB70F30-5520-488D-A9B3-0B540896DB54 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTExMTAxNTczMVowIwYJKoZIhvcNAQkEMRYEFICsI4/mUbfzMXnjRutlpcDB TJblMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAY8CJj9xRHTk4zO9KJuXKWg8hAR68M4pfLh38/3F3pBXU0WU9ie94Sht6PJwdmFo9/B+gx0kB n31ODVX+DrSgUn5B+DTt2qwUZ1ZGZT9DjMEV+ft1rZANqMo04bFO+BFwNGsv1n2s78KAKs9oGH3O GDvkgwHzLkiRhBmnfkCVOr34tTmASdTh7qRcCMix1t4+Jh3Ab1P4ItqsAeF7RzbJD4PihLoVDhZk 3U4KUWgXfl0wl0fZzBq8Tocckh7TMeSeAqQ5Tzx1MoOD25aWmsiwl/ZHWWtja+6yzZeIayt398kr lpDqRnLadzhFm/cwNgNhtlF/yihYBUNdHzO0UB2MMwAAAAAAAA== --Apple-Mail=_0AB70F30-5520-488D-A9B3-0B540896DB54-- From nobody Mon Nov 10 18:01:37 2014 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 2ECCB1AC39F for ; Mon, 10 Nov 2014 18:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8bXxGDGjY5w for ; Mon, 10 Nov 2014 18:01:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:727]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB4B1A6F9E for ; Mon, 10 Nov 2014 18:01:32 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.1.11.14; Tue, 11 Nov 2014 02:01:09 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0011.000; Tue, 11 Nov 2014 02:01:08 +0000 From: Dave Thaler To: Sean Leonard , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] Various image/* media type drafts Thread-Index: AQHP/U+6SGS3kLpnS027R4HkmdOnJJxaqtMAgAABFvA= Date: Tue, 11 Nov 2014 02:01:08 +0000 Message-ID: References: <5D32EA67-3EEE-4369-B44B-3FCE9E2F64FA@seantek.com> In-Reply-To: <5D32EA67-3EEE-4369-B44B-3FCE9E2F64FA@seantek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [31.133.166.252] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(189002)(24454002)(13464003)(120916001)(76576001)(74316001)(64706001)(21056001)(19580395003)(33646002)(66066001)(20776003)(122556002)(40100003)(19580405001)(99396003)(97736003)(101416001)(87936001)(2656002)(50986999)(76176999)(54356999)(15975445006)(4396001)(99286002)(95666004)(107046002)(86612001)(108616004)(46102003)(92566001)(106356001)(106116001)(105586002)(62966003)(86362001)(77156002)(575784001)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LsMN25Dh9_2ipMCLgX1fLDkUIvY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Various image/* media type drafts 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, 11 Nov 2014 02:01:35 -0000 For wmf and emf, #1 is what I heard people arguing for, and I think is the = best approach. -Dave > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Se= an > Leonard > Sent: Monday, November 10, 2014 3:57 PM > To: Murray S. Kucherawy > Cc: IETF Apps Discuss > Subject: Re: [apps-discuss] Various image/* media type drafts >=20 > Hi colleagues, >=20 > I wanted to both concur with what Murray said, and offer elaboration (whi= ch > is somewhat contradictory). >=20 > I don't mind combining the image registrations. >=20 > However there are three ways that the registered types could go: > #1 image/x-FOO only > #2 image/FOO, with image/x-FOO as deprecated aliases > #3 something else >=20 > Based on my understanding of this subject matter, my (experienced?) opini= on > is that #2 is the way to go. >=20 > Unlike say "application/x-www-form-urlencoded", these image types are not > quite as hard-coded into the Internet (specifically Web) infrastructure a= s one > might think. Historically web browsers and HTML viewers have taken the > image media type as a hint only, passing the stream to its all-purpose im= age > processing library ("libpr0n"). >=20 > Of these three types, "image/bmp" has actually been used in practice. It = was > served as such by Apache software across the board until 2010, when in a = bug > report in TIKA , it was > renamed to "image/x-ms-bmp" in that piece of software. But Apache httpd > itself still serves "image/bmp": > > . Furthermore, the media type "image/bmp" has been baked into Windows > for years, see HKEY_CLASSES_ROOT\Mime\Database\Content > Type\image/bmp in your friendly local Windows build. >=20 > So at least for Windows Bitmaps, the shoe is on the other foot: it is arg= uably > more harmful to register image/x-*** (even in deprecated alias types) > compared to just saying image/bmp and being done with it. Maybe > image/bmp was wrong at the time, but it's the right position to be in now > (and it's compatible with the relevant BCPs). >=20 > As for the metafiles, if people are serving WMFs and EMFs in webpages for > general consumption, we have a more serious issue than futzing with the > label. Thus I don't see the interoperability harm in standardizing image/= wmf > and image/emf...at least pending resolution of what Microsoft wants to do= or > recognize. >=20 > Cheers, >=20 > Sean >=20 > On Nov 10, 2014, at 3:34 PM, Murray S. Kucherawy > wrote: >=20 > > Colleagues, > > > > After the meeting today, I proposed that Sean combine all of his image/= * > media type registrations into a single document. Each registration shoul= d be > fairly short, just the basic template each time with a reference to the d= efining > document. > > > > I concurred with Mark and others in the room who said he should just > register the "x-" subtypes as-is, paying appropriate homage to the X- BCP= and > updated registrations BCP. > > > > I suggest that such a consolidation draft would be eligible for a Call = For > Adoption given the feeling in the room, which is to say that there was no > objection to APPSAWG processing of them when I asked. I didn't want to t= ake > up a bunch of slots (and do a bunch of WGLCs, LCs, AD Evaluations, etc.) > when combining the various proposals would be simpler, with other work > also proposed for the WG. > > > > Is there any peril to proceeding under those guidelines? If none, then= Sean > can proceed to produce that at his convenience. > > > > -MSK, co-chairin' > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Nov 10 18:05:21 2014 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 3EE711ACD70; Mon, 10 Nov 2014 18:04:59 -0800 (PST) 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 h4tIwYZU3s76; Mon, 10 Nov 2014 18:04:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 332D21ACD51; Mon, 10 Nov 2014 18:04:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141111020432.28433.2255.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 18:04:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wQNoOySVxqTy19vte2kt9k1ntB0 Cc: slim@ietf.org, randy@qti.qualcomm.com, apps-discuss@ietf.org Subject: [apps-discuss] New Non-WG Mailing List: Slim -- Selection of Language for Internet Media X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:04:59 -0000 A new IETF non-working group email list has been created. List address: slim@ietf.org Archive: http://www.ietf.org/mail-archive/web/slim/ To subscribe: https://www.ietf.org/mailman/listinfo/slim Purpose: A mutually comprehensible language is helpful for human communication. This is true across a range of circumstances and environments. In general, the problem is most acute in situations where there is not a clear choice for a single language, such as environments lacking contextual or out-of-band information regarding the identity of the parties and the language to be used. This list is for discussion of mechanisms to present and select human language options for Internet applications. Initial drafts address two specific cases that most urgently need a technical solution: One problem space is non-real-time communication, specifically email for one-to-many or where the set of recipients is dynamic or different recipients require different languages; the other is real-time communication, especially emergency calling, and also including other cases where the parties may not know each other personally or where one party wishes to accommodate people with varying language and media needs. Especially for real-time communication, language and media are intrinsically linked, for example, signed languages require a video media. For additional information, please contact the list administrators. From nobody Mon Nov 10 18:12:36 2014 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 C00FF1AD403 for ; Mon, 10 Nov 2014 18:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 Jxe3ptZkdz1f for ; Mon, 10 Nov 2014 18:12:31 -0800 (PST) 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 C26C11AD422 for ; Mon, 10 Nov 2014 18:11:24 -0800 (PST) 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 sAB2BUBm004294; Mon, 10 Nov 2014 21:11:31 -0500 (EST) (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] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Karl Dubost In-Reply-To: Date: Tue, 11 Nov 2014 11:11:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> References: To: Mateusz Karcz X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7GedkWLTF2nG4ADoiCtweleL4F0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 11 Nov 2014 02:12:34 -0000 Mateusz, Interesting. What was the initial motivation for the draft? Below some comments. Le 11 nov. 2014 =C3=A0 10:28, Mateusz Karcz a = =C3=A9crit : > After two years of thinking and two nights of working I've finally = written the second revision of my I-D. I changed construction of the = draft, simplified proposed UUAS structure, made a research about = security and added some other, minor changes. I've committed it as = draft-karcz-uuas-01. And the full link=20 https://tools.ietf.org/html/draft-karcz-uuas-01 In https://tools.ietf.org/html/draft-karcz-uuas-01#section-2 2. Use of the User-Agent strings You are writing, [=E2=80=A6] However, in modern browsers these limitations greatly decreased and "user agent spoofing" is now unnecessary. Unfortunately, there are a lot of websites still discriminating particular web browsers. [=E2=80=A6] I really wish it was true, given it is 80% of what I do all day long ;) = aka discovering, analyzing, and contacting Web sites with a kind of UA = sniffing (be client side or server side). There are a load of issues = which I'm not happy about but are still a reality. User Agent sniffing = is a future fail strategy, but is widely used not only because of the = disparity in between browsers. Here are some of the use cases that UA sniffing has been used for. We = collected these during a survey this year from Web developers, Bizdev = people and UA databases companies. http://www.otsukare.info/2014/03/31/ua-detection-use-cases There are other headers which have been popping up=20 = http://mobiforge.com/research-analysis/x-device-user-agent-header-appearin= g-requests Also have you seen the draft=20 https://tools.ietf.org/html/draft-brown-device-stock-ua-00 The background behind this draft. https://dev.opera.com/blog/introducing-device-stock-ua/ Another source you might want to read = http://www.nczonline.net/blog/2010/01/12/history-of-the-user-agent-string/= --=20 Karl Dubost =F0=9F=90=84 http://www.la-grange.net/karl/ From nobody Mon Nov 10 18:14:34 2014 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 DBEB81AD3F2 for ; Mon, 10 Nov 2014 18:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmkidBlFwzIL for ; Mon, 10 Nov 2014 18:14:31 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4701AD3EF for ; Mon, 10 Nov 2014 18:14:31 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id n3so473239wiv.0 for ; Mon, 10 Nov 2014 18:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xe6u5hh343pXBfJEK9wKbqI6WatPDfU1uqnYqPnQIM8=; b=WgYQE2yNSVKkTm8y0CX5SHhex7pmtAdoNVxFRN65UHXiw5TehskrJnhyZ94zecCX3h vCrEysZaZZpkLHv+/6oJW9/zhHlC6ajwGPytlsDqzfEFLIlril9bIwlu9XHkD6OUMHW4 vMAaZeqPRII3KBm8KBzfIDwu/FqkKovCLl9WXoDzat1dfnGuvqY5RhNv4348DfuKYEy5 t62H2PF4JwXvD/kerzOIObYhNWQ2hKwJ6kweMH2tTB1IFi/QeC60fM0puZ/cfZTZ1ZW2 WBxjLrEyj1avhJvYacdH/8JVqXcJIAYmcATlT8YUPQRvvt6qQAvx2/4/aYD+3ojBrhHV zb4Q== MIME-Version: 1.0 X-Received: by 10.181.13.208 with SMTP id fa16mr35553943wid.61.1415672069949; Mon, 10 Nov 2014 18:14:29 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 10 Nov 2014 18:14:29 -0800 (PST) In-Reply-To: References: <5D32EA67-3EEE-4369-B44B-3FCE9E2F64FA@seantek.com> Date: Mon, 10 Nov 2014 16:14:29 -1000 Message-ID: From: "Murray S. Kucherawy" To: Dave Thaler Content-Type: multipart/alternative; boundary=f46d043c7de4d9106805078bd644 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kcAtrKRkNRizVsJUdISc7urewnI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Various image/* media type drafts 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, 11 Nov 2014 02:14:33 -0000 --f46d043c7de4d9106805078bd644 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 4:01 PM, Dave Thaler wrote: > For wmf and emf, #1 is what I heard people arguing for, and I think is the > best approach. > +1, and image/bmp for that one. I don't think image/wmf and image/emf are likely to see actual adoption at this point. -MSK (presently hatless) --f46d043c7de4d9106805078bd644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 4:01 PM, Dave Thaler <dthaler= @microsoft.com> wrote:
For wmf and emf, #1 is wh= at I heard people arguing for, and I think is the best approach.

+1, and image/bmp for that one.=C2=A0 I don't= think image/wmf and image/emf are likely to see actual adoption at this po= int.

-MSK (presently hatless)

--f46d043c7de4d9106805078bd644-- From nobody Mon Nov 10 18:32:03 2014 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 712D11AD471 for ; Mon, 10 Nov 2014 18:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.184 X-Spam-Level: * X-Spam-Status: No, score=1.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 CLZF0u62k4ul for ; Mon, 10 Nov 2014 18:31:59 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.239]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2721A8871 for ; Mon, 10 Nov 2014 18:31:59 -0800 (PST) Date: Tue, 11 Nov 2014 03:31:57 +0100 From: Mateusz Karcz To: Karl Dubost X-Mailer: interia.pl/pf09 In-Reply-To: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> X-Originating-IP: 109.207.150.139 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1415673117; bh=7D+wea60qA8KXqTaloBJ2mDasEAKhR24YHf+4EB7nVg=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=WOJU68CrolqR/wEjPE/GkPfKCVg90RuabD9XiP0PgnYu58kpiB08+2r+Vvp4m7LxG Zm4OTn2tmTpcajZZ7SCJXIoDpegww29Trfb/Dn0JkxdkIngGeSuPOdrzG3gsE8iXa4 moL0v4kmhTl7UqvhBdZgSHkpzVx6ciFh70KW+/VA= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D_eljnm36qnS9xtTtTOn8yEu5dc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 11 Nov 2014 02:32:01 -0000 My intention was to propose a way of simplification, clarification and stan= dardization of complex User-Agent string syntax. I've faced these publications before (except the survey). The problem is: T= hese headers are still experimental and work-in-progress. However, by their= definition they would just "inherit" characteristics of UUAS. A word about UA sniffing, yeah, I should precise, what do I mean by "unnece= ssary". I mean, by definition my "web browser UUAS" would be applied to new= and standards-compliant web browsers. U=C5=BCytkownik "Karl Dubost" napisa=C5=82(a):=20 > Temat: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) > Data: 2014-11-11 3:11 > Nadawca: "Karl Dubost" > Adresat: "Mateusz Karcz" ;=20 >=20 > Mateusz, > Interesting. What was the initial motivation for the draft? >=20 > Below some comments. >=20 > Le 11 nov. 2014 =C3=A0 10:28, Mateusz Karcz a =C3=A9crit : > > After two years of thinking and two nights of working I've finally writ= ten the second revision of my I-D. I changed construction of the draft, sim= plified proposed UUAS structure, made a research about security and added s= ome other, minor changes. I've committed it as draft-karcz-uuas-01. >=20 > And the full link=20 > https://tools.ietf.org/html/draft-karcz-uuas-01 >=20 > In https://tools.ietf.org/html/draft-karcz-uuas-01#section-2 > 2. Use of the User-Agent strings >=20 > You are writing, >=20 > [=E2=80=A6] > However, in modern browsers these limitations greatly decreased and > "user agent spoofing" is now unnecessary. Unfortunately, there are a > lot of websites still discriminating particular web browsers. > [=E2=80=A6] >=20 > I really wish it was true, given it is 80% of what I do all day long ;) a= ka discovering, analyzing, and contacting Web sites with a kind of UA sniff= ing (be client side or server side). There are a load of issues which I'm n= ot happy about but are still a reality. User Agent sniffing is a future fai= l strategy, but is widely used not only because of the disparity in between= browsers. >=20 > Here are some of the use cases that UA sniffing has been used for. We col= lected these during a survey this year from Web developers, Bizdev people a= nd UA databases companies. > http://www.otsukare.info/2014/03/31/ua-detection-use-cases >=20 >=20 > There are other headers which have been popping up=20 > http://mobiforge.com/research-analysis/x-device-user-agent-header-appeari= ng-requests >=20 > Also have you seen the draft=20 > https://tools.ietf.org/html/draft-brown-device-stock-ua-00 > The background behind this draft. > https://dev.opera.com/blog/introducing-device-stock-ua/ >=20 > Another source you might want to read > http://www.nczonline.net/blog/2010/01/12/history-of-the-user-agent-string= / >=20 >=20 >=20 > --=20 > Karl Dubost =F0=9F=90=84 > http://www.la-grange.net/karl/ >=20 >=20= From nobody Mon Nov 10 18:33:14 2014 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 40F821AD478 for ; Mon, 10 Nov 2014 18:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWtQTIwRJHWV for ; Mon, 10 Nov 2014 18:33:11 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC99C1AD476 for ; Mon, 10 Nov 2014 18:33:10 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id x12so10438735wgg.17 for ; Mon, 10 Nov 2014 18:33:09 -0800 (PST) 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=Qi7BHrkXYakrB2c9MVvEQzsHdDxR+gHYwtv9yKIfJzc=; b=Xnex92eCOdIHx+0SXztf2nGdgaW0LeWWbpGh7tJ6IQ3/yq0qLrVP+za/JMjsiXk9nE alwJI2Ts1/h+dsJt2eA1lftY7ik2nMs3oDxOjkpdM+F03yE3mZPcBCKWSQowAS+pbvym LWO/V/98cfEChAu4ALtVeiEO6x8S9fFlFst3y7waY6D1iwy7/hjMxzbthr/DA7E4QlLj mInUZ0ROZNybTAY1OZvHJOWn8oWjYUk/OlS/oZoInvys1AM7r4MApu4bDtI98IUclXgO k85rJwdydmDiXBKF9pX+LxM+QLIjYXM5Q8K8P4qzjHZz+3g2jl9z6rrosHrcyRYvUgid 6vNw== MIME-Version: 1.0 X-Received: by 10.194.3.2 with SMTP id 2mr49223437wjy.89.1415673189590; Mon, 10 Nov 2014 18:33:09 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 10 Nov 2014 18:33:09 -0800 (PST) Date: Mon, 10 Nov 2014 16:33:09 -1000 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b343c18956a9505078c192e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BVMRofRCJPpVBAQKtH9ybsKqoQY Subject: [apps-discuss] On the markdown documents 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, 11 Nov 2014 02:33:12 -0000 --047d7b343c18956a9505078c192e Content-Type: text/plain; charset=UTF-8 Colleagues, Alexey and I have discussed it, and we recommend that the WG not adopt draft-seantek-text-markdown-use-cases at this time. We would like the WG to focus on developing draft-ietf-appsawg-text-markdown with Sean until it's ready to go at least to WGLC, or preferably to the IESG, and then we can adopt draft-seantek-text-markdown-use-cases if there's still the energy and desire to publish it at that time. If there are no objections to that call, we encourage the WG to reviewing the -03 version of the main markdown draft and check on the open questions Sean brought up today (see the meeting materials). Or perhaps Sean could re-state what he sees as the open issues on this or another thread. Thanks, -MSK, APPSAWG co-chair --047d7b343c18956a9505078c192e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Alexey and I = have discussed it, and we recommend that the WG not adopt draft-seantek-tex= t-markdown-use-cases at this time.=C2=A0 We would like the WG to focus on d= eveloping draft-ietf-appsawg-text-markdown with Sean until it's ready t= o go at least to WGLC, or preferably to the IESG, and then we can adopt dra= ft-seantek-text-markdown-use-cases if there's still the energy and desi= re to publish it at that time.

If there are no objections to t= hat call, we encourage the WG to reviewing the -03 version of the main mark= down draft and check on the open questions Sean brought up today (see the m= eeting materials).=C2=A0 Or perhaps Sean could re-state what he sees as the= open issues on this or another thread.

Thanks,
-MSK,= APPSAWG co-chair

--047d7b343c18956a9505078c192e-- From nobody Mon Nov 10 18:43:18 2014 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 791371A882F for ; Mon, 10 Nov 2014 18:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAxECpGloQky for ; Mon, 10 Nov 2014 18:43:14 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5C41AD46E for ; Mon, 10 Nov 2014 18:43:14 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so9563217pab.19 for ; Mon, 10 Nov 2014 18:43:13 -0800 (PST) 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:cc :content-transfer-encoding:message-id:references:to; bh=p2G5NQ6DZ15iYWLseSJxu6GTQ3CnEd5vptGnoZ0RXd4=; b=rnvQGZf7N4xlPd3gsWDDmrAP611RdXQ+Q+6na4JKTRm4TIRgowyIaxBFVdG4SOsND7 uAMO0vRMOMvVnZ74qGM8gScvmYCJdilMsaCWrEiySelXcOR14SD51Pz5Q0BVFF/XYXZF DiUFKJtrgSHV8ztkoIDkfrYbV0t1eX0HGHIjlp4P2rYiFtahzc4ogNQYENIufqwwaPyX FrGSYq1nWIGP8NUXpAOW0SxWzmPY9Ji017oOCGFlmqECBkM7jZWd5IFGwlScUsg/0mkF YqXf9ciI/JD67FE6QCQeONA1qTQTVrNdbcqCP0Tyl+uduzD8Qj9/wg6rL2CuxjXYVH31 mSLQ== X-Received: by 10.66.168.238 with SMTP id zz14mr12037903pab.62.1415673793433; Mon, 10 Nov 2014 18:43:13 -0800 (PST) Received: from [192.168.2.243] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id fm15sm17763509pdb.58.2014.11.10.18.43.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 18:43:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Mon, 10 Nov 2014 18:43:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <97DAD165-1276-4195-AC07-B280284A8B0B@gmail.com> References: <5D32EA67-3EEE-4369-B44B-3FCE9E2F64FA@seantek.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/N3lSUe3IQclS0WmPlo_g9S1JyUc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Various image/* media type drafts 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, 11 Nov 2014 02:43:15 -0000 On Nov 10, 2014, at 6:14 PM, Murray S. Kucherawy = wrote: > On Mon, Nov 10, 2014 at 4:01 PM, Dave Thaler = wrote: > For wmf and emf, #1 is what I heard people arguing for, and I think is = the best approach. >=20 > +1, and image/bmp for that one. I don't think image/wmf and image/emf = are likely to see actual adoption at this point. Dear Murray, Agreed. Security issues related to wmf such as mice and codec redirects = did not help. Regards, Douglas Otis =20= From nobody Mon Nov 10 19:25:43 2014 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 DED9F1AD4E3 for ; Mon, 10 Nov 2014 19:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 OAG6XOjZ5mW5 for ; Mon, 10 Nov 2014 19:25:40 -0800 (PST) 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 2D4B81AD4F2 for ; Mon, 10 Nov 2014 19:25:40 -0800 (PST) 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 sAB3PkCw004874; Mon, 10 Nov 2014 22:25:47 -0500 (EST) (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] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Karl Dubost In-Reply-To: Date: Tue, 11 Nov 2014 12:25:33 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> To: Mateusz Karcz X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nZMvTUb38fGs2f-HoolCvs0vIMA Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 11 Nov 2014 03:25:42 -0000 Mateusz, Le 11 nov. 2014 =C3=A0 11:31, Mateusz Karcz a = =C3=A9crit : > I mean, by definition my "web browser UUAS" would be applied to new = and standards-compliant web browsers. This is part of the issue at stake and how your effort could be = successful or fail. Mozilla has taken a step forward by simplifying Firefox OS and Firefox = Android user agent strings. [1]=20 Firefox OS: "Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0" Firefox Android: "Mozilla/5.0 (Android; Mobile; rv:30.0) Gecko/30.0 = Firefox/30.0" It creates Web Compatibility issues. And it's what the Web Compatibility = activity [2][3] is trying to solve. Basically the issue is not about = having a cleaner UA, but more about the Web itself. We can't reboot the = Web, there is a huge legacy of sites which stop working when the UA is = not shaped like scripts are expecting them.=20 What am I saying is that you will be able to simplify the UA by making = the UA useless and adding features to the Web platform that will answer = some of the needs of Web developers. It's really unfortunate but not = that much solutions apart of that. These 3 blogs will give you the = extent of the issues.=20 https://miketaylr.com/posts http://whatcouldbewrong.com/ http://www.otsukare.info/ Another issue is related to the capabilities of the device itself. When = the browser version is the same but the device is different. We still = lack a good and simple way to advertise some of the capabilities. We = became better with feature detections, it helped a lot to remove some = burden. But still not enough. In the Mobile world, the practices of = phone Operators is also a big issue: Device X =3D=3D Promotion/Benefits = X =3D=3D UA Sniffing [1]: = https://developer.mozilla.org/en-US/docs/Web/HTTP/Gecko_user_agent_string_= reference#Firefox_OS [2]: https://webcompat.com/ [3]: https://wiki.mozilla.org/Compatibility/ --=20 Karl Dubost =F0=9F=90=84 http://www.la-grange.net/karl/ From nobody Mon Nov 10 19:54:58 2014 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 A320F1AD539 for ; Mon, 10 Nov 2014 19:54:52 -0800 (PST) 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_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 AWb2X0t5ZgW9 for ; Mon, 10 Nov 2014 19:54:50 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD92D1AD542 for ; Mon, 10 Nov 2014 19:54:49 -0800 (PST) Received: from dhcp-b3ac.meeting.ietf.org (unknown [31.133.179.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB0FD22E253 for ; Mon, 10 Nov 2014 22:54:42 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_3596E2B6-B4CA-4F5B-896C-B22FDE7FE8AE"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <5F099A1D-314F-462B-874C-A7CE626502B9@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 10 Nov 2014 17:53:23 -1000 References: To: IETF Apps Discuss In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pvI5ZObco57XTHCa7vJsWr3jvCs Subject: Re: [apps-discuss] On the markdown documents 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, 11 Nov 2014 03:54:53 -0000 --Apple-Mail=_3596E2B6-B4CA-4F5B-896C-B22FDE7FE8AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 10, 2014, at 4:33 PM, Murray S. Kucherawy = wrote: > Colleagues, >=20 > Alexey and I have discussed it, and we recommend that the WG not adopt = draft-seantek-text-markdown-use-cases at this time. We would like the = WG to focus on developing draft-ietf-appsawg-text-markdown with Sean = until it's ready to go at least to WGLC, or preferably to the IESG, and = then we can adopt draft-seantek-text-markdown-use-cases if there's still = the energy and desire to publish it at that time. Well, I object to not adopting it. Just one vote, but 1 > 0. :) Nevertheless I agree that the main document be the priority. I am not = sure what the feeling of the WG is, however, on the exemplary = registrations that are in the use-cases document. There was that BCP (do = not recall the number) about how an IANA registry should be filled in = the same document. Note that the IANA registry is populated in the main = text-markdown draft, but only with one entry: Gruber=92s Original = Markdown variant (syntax, whatever). Since I don=92t have the BCP in = front of me I=92m not sure if that satisfies it. >=20 > If there are no objections to that call, we encourage the WG to = reviewing the -03 version of the main markdown draft and check on the = open questions Sean brought up today (see the meeting materials). Or = perhaps Sean could re-state what he sees as the open issues on this or = another thread. The open issues are mostly covered by the Thursday e-mail = =93text/markdown: Simplifying the syntax parameter and the draft=94; = archived at = . If we can get agreement on that (or at least, no objections), I = can at least output a draft-04 and we can keep it moving. Best regards, Sean --Apple-Mail=_3596E2B6-B4CA-4F5B-896C-B22FDE7FE8AE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTExMTAzNTQ0MVowIwYJKoZIhvcNAQkEMRYEFBJLu6XXj0PyuHRdy+XZZaFf bdNzMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAm2/YwsmmUSe9/y3xNnmOOFXhIvRK88zzB4/udn6JiVP7S7u526SXFP+9JpHhUy5/KI+vnw/m Bl24U++vfUvmPS+NIby4cdzVscfSyU0k1xnbx4SgTjgeFG0J7iJKT4YS4WkAuUh+0ZrEEVp1Xoc7 7DUqCuOlQTBYB9Z+Dg2Psb5i/7FVUsjDJhjbVV0gQRnou6RnCtKo7DyYP5pBl7bPzwQn5sJSw2vU NN0QyyFgcqcy59wlc39SP/G5fxiFbiMf4NqxYZmw9XSOXVJB++jhycTYkANzJOqu7N9ulonwctF4 trLnb+hMPzEnbwwtzqP9B6jfTk4YUH/F8EEEnejzoAAAAAAAAA== --Apple-Mail=_3596E2B6-B4CA-4F5B-896C-B22FDE7FE8AE-- From nobody Mon Nov 10 20:21:46 2014 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 791B01AD44C for ; Mon, 10 Nov 2014 20:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.184 X-Spam-Level: * X-Spam-Status: No, score=1.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 UPEVstpxHtQv for ; Mon, 10 Nov 2014 20:21:41 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.239]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B981A88B1 for ; Mon, 10 Nov 2014 20:21:34 -0800 (PST) Date: Tue, 11 Nov 2014 05:21:32 +0100 From: Mateusz Karcz To: Karl Dubost X-Mailer: interia.pl/pf09 In-Reply-To: References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> X-Originating-IP: 109.207.150.139 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1415679692; bh=M8eYss0FEpwyvTTZ2y4exLdIcW9atZgQlCmBoeb3ZI4=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=XbYRH+u0uL60F0lgtgJvm4YgBTAsuvHHFJjh/B7HXzDfTlMHdcltd/RrEABv9ety1 9GfWLDAAmHi/7SINTeEqMHauJ/ttvQaXRlZIES4WlVxqDcDrtM1cMWqSuUsEmaSNpy Ay8JHIPbb9PAuWT8KIT1oO9JlOr/T8bquQfjpimw= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3HEyx2DBH4o8m_5Y3TXoUtgAYcw Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 11 Nov 2014 04:21:44 -0000 One of main goal on which I was working was to maintain existing solutions.= Believe me or not, but UAs of Firefox, IE11, Chrome, Safari, Opera and Kon= qeror are 100% valid web browser UUAS. Firefox OS and Firefox Mobile are no= w 100% valid regular UUAS, but it can be made "web browser UUAS just by cha= nging 1 rule in ABNF definition. I thought a lot before designing this draf= t and compared a lot of recent UAs. And one another thing: This memo is not= intended to make existing software useless. It is intended to make an advi= ce for present and future developers, how to generate good UAs preserving b= ehavior of legacy websites. A word about devices: if Device-UA becomes a standard, it will behave as to= day. And that will also be UUAS-valid. Why? There is a point in backwards c= ompatibility, so I preserved it. "Standard string" is almost copy-paste fro= m httpbis. "Regular string" just adds obligatory platform signature. "Web b= rowser string" is designed in conformance with W3C Recomendation on client = software identification.=20 There will be no need to re-create the Web! U=C5=BCytkownik "Karl Dubost" napisa=C5=82(a):=20 > Temat: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) > Data: 2014-11-11 4:25 > Nadawca: "Karl Dubost" > Adresat: "Mateusz Karcz" ;=20 >=20 > Mateusz, >=20 > Le 11 nov. 2014 =C3=A0 11:31, Mateusz Karcz a =C3=A9crit : > > I mean, by definition my "web browser UUAS" would be applied to new and= standards-compliant web browsers. >=20 > This is part of the issue at stake and how your effort could be successfu= l or fail. >=20 > Mozilla has taken a step forward by simplifying Firefox OS and Firefox An= droid user agent strings. [1]=20 >=20 > Firefox OS: "Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0" > Firefox Android: "Mozilla/5.0 (Android; Mobile; rv:30.0) Gecko/30.0 Firef= ox/30.0" >=20 > It creates Web Compatibility issues. And it's what the Web Compatibility = activity [2][3] is trying to solve. Basically the issue is not about having= a cleaner UA, but more about the Web itself. We can't reboot the Web, ther= e is a huge legacy of sites which stop working when the UA is not shaped li= ke scripts are expecting them.=20 >=20 >=20 > What am I saying is that you will be able to simplify the UA by making th= e UA useless and adding features to the Web platform that will answer some = of the needs of Web developers. It's really unfortunate but not that much s= olutions apart of that. These 3 blogs will give you the extent of the issue= s.=20 >=20 > https://miketaylr.com/posts > http://whatcouldbewrong.com/ > http://www.otsukare.info/ >=20 >=20 > Another issue is related to the capabilities of the device itself. When t= he browser version is the same but the device is different. We still lack a= good and simple way to advertise some of the capabilities. We became bette= r with feature detections, it helped a lot to remove some burden. But still= not enough. In the Mobile world, the practices of phone Operators is also = a big issue: Device X =3D=3D Promotion/Benefits X =3D=3D UA Sniffing >=20 >=20 > [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Gecko_user_agent_s= tring_reference#Firefox_OS > [2]: https://webcompat.com/ > [3]: https://wiki.mozilla.org/Compatibility/ >=20 > --=20 > Karl Dubost =F0=9F=90=84 > http://www.la-grange.net/karl/ >=20 >=20= From nobody Mon Nov 10 21:03:04 2014 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 3B60E1AD54C for ; Mon, 10 Nov 2014 21:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtmfSegMqI_9 for ; Mon, 10 Nov 2014 21:03:01 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D221AD55D for ; Mon, 10 Nov 2014 21:03:00 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id h11so487994wiw.0 for ; Mon, 10 Nov 2014 21:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/kN7XiM8yAiP1a/SXVn91Pe82K/kGo2ehETADVO/Hqo=; b=fVo8rizyBnZ9ybHyiWTOV8/U6QSiCJ4OJLWiTr5BULHRoQHwApNAI/sw4uZnQ7wRS0 7ThrbYlTXkGYyi1jA8eRGEQ7CcniZ280NoOBUsBuEpR+7sik+r3aJpYxJZ3boYBlusXK OKIVhYIFNGv1570adx0R+PXybcI1w1yZPaOZ3sjCQ2z249fF9L8JkafFHwb8UFMqeclS z4iW+1EAyVqraCHjVf5XZY81dDTyUikuo4PH5WG6Yj3leRaxgqxWcieJm5FG5qakhg1D jB6yYLePtJU7cCcyU3d/7LXoJk2DjbYeRdFI7WPR8EtSVI4MMWC5T/TgEtVzT9Pq8msh g08g== MIME-Version: 1.0 X-Received: by 10.180.91.49 with SMTP id cb17mr36503806wib.30.1415682179355; Mon, 10 Nov 2014 21:02:59 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 10 Nov 2014 21:02:59 -0800 (PST) In-Reply-To: <5F099A1D-314F-462B-874C-A7CE626502B9@seantek.com> References: <5F099A1D-314F-462B-874C-A7CE626502B9@seantek.com> Date: Mon, 10 Nov 2014 19:02:59 -1000 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=f46d043c7b2a6a57bf05078e3180 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vZ6H1L1W13U92WEUrPSjXAnnp0c Cc: IETF Apps Discuss Subject: Re: [apps-discuss] On the markdown documents 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, 11 Nov 2014 05:03:03 -0000 --f46d043c7b2a6a57bf05078e3180 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 10, 2014 at 5:53 PM, Sean Leonard wrote: > Nevertheless I agree that the main document be the priority. I am not sur= e > what the feeling of the WG is, however, on the exemplary registrations th= at > are in the use-cases document. There was that BCP (do not recall the > number) about how an IANA registry should be filled in the same document. > Note that the IANA registry is populated in the main text-markdown draft, > but only with one entry: Gruber=E2=80=99s Original Markdown variant (synt= ax, > whatever). Since I don=E2=80=99t have the BCP in front of me I=E2=80=99m = not sure if that > satisfies it. > The discussion in the room today seemed to be fine with the idea of having the initial registration set in the second document despite what the BCP says (Barry made the point and I saw some gentle nodding in the room, and no objection). So I think the layout you just described, with just the one in the main document, will be fine. > The open issues are mostly covered by the Thursday e-mail =E2=80=9Ctext/m= arkdown: > Simplifying the syntax parameter and the draft=E2=80=9D; archived at < > http://mailarchive.ietf.org/arch/msg/apps-discuss/kaSgQOOolkXUdmYKeh78npL= AlXQ>. > If we can get agreement on that (or at least, no objections), I can at > least output a draft-04 and we can keep it moving. > Have at it, please! -MSK --f46d043c7b2a6a57bf05078e3180 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 5:53 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:
Nevertheless I agree that the main document be the priority. I am not sure = what the feeling of the WG is, however, on the exemplary registrations that= are in the use-cases document. There was that BCP (do not recall the numbe= r) about how an IANA registry should be filled in the same document. Note t= hat the IANA registry is populated in the main text-markdown draft, but onl= y with one entry: Gruber=E2=80=99s Original Markdown variant (syntax, whate= ver). Since I don=E2=80=99t have the BCP in front of me I=E2=80=99m not sur= e if that satisfies it.

The discussion = in the room today seemed to be fine with the idea of having the initial reg= istration set in the second document despite what the BCP says (Barry made = the point and I saw some gentle nodding in the room, and no objection).=C2= =A0 So I think the layout you just described, with just the one in the main= document, will be fine.
=C2=A0
The open issues are mostly covered by the Thursday e-mail =E2=80=9Ctext/mar= kdown: Simplifying the syntax parameter and the draft=E2=80=9D; archived at= <http://mailarchive.ietf.org/arch/msg/= apps-discuss/kaSgQOOolkXUdmYKeh78npLAlXQ>. If we can get agreement o= n that (or at least, no objections), I can at least output a draft-04 and w= e can keep it moving.

Have at it, pleas= e!

-MSK
--f46d043c7b2a6a57bf05078e3180-- From nobody Tue Nov 11 04:15:19 2014 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 649FA1A1B3D for ; Tue, 11 Nov 2014 04:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oXqLhNno3jZc for ; Tue, 11 Nov 2014 04:15:14 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0757.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::757]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C6A1A1AB9 for ; Tue, 11 Nov 2014 04:15:13 -0800 (PST) Received: from pc6 (86.184.62.161) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.16.15; Tue, 11 Nov 2014 12:14:50 +0000 Message-ID: <045a01cffda8$b3f45120$4001a8c0@gateway.2wire.net> From: t.petch To: Salvatore Loreto , IETF Apps Discuss References: <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> Date: Tue, 11 Nov 2014 11:11:55 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: DB3PR05CA0023.eurprd05.prod.outlook.com (25.160.41.151) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-Forefront-PRVS: 0392679D18 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(22974006)(13464003)(189002)(88136002)(84392001)(87286001)(42186005)(44736004)(23746002)(101416001)(15975445006)(61296003)(40100003)(47776003)(64706001)(20776003)(19580405001)(19580395003)(89996001)(87976001)(99396003)(62236002)(93886004)(14496001)(116806002)(4396001)(50226001)(44716002)(120916001)(81686999)(21056001)(76176999)(81816999)(102836001)(50986999)(107886001)(107046002)(86362001)(104166001)(92726001)(95666004)(92566001)(93916002)(105586002)(106356001)(31966008)(50466002)(77096003)(46102003)(77156002)(62966003)(15202345003)(66066001)(230783001)(122386002)(97736003)(33646002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/auqgZ0LxlZlaZYe_CfmIal-iec4 Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data 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, 11 Nov 2014 12:15:17 -0000 I note that this I-D specifies Encoding considerations: Common use is BINARY. Looking at http://www.iana.org/assignments/media-types/multipart/related I see Encoding considerations: Multipart content-types cannot have encodings. I have looked at more recent RFC, such as RFC6838, and can see nothing to gainsay this. Does this restriction still apply? (and yes, I have told IANA that http://www.iana.org/assignments/media-types/multipart/report yields 404) Tom Petch ----- Original Message ----- From: "Salvatore Loreto" To: "IETF Apps Discuss" Sent: Thursday, November 06, 2014 2:28 PM Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data Hi there, I am acting as shepherd for the appsawg-mutlipart-form-data The wg lc for this draft has been issued on September 16, but since then nobody has sent any comment/feedback to the list. We really need people reviewing this document and providing their feedback in order to determine if there is or not working group consensus to be publish this draft. best regards Salvatore ---------- Forwarded message ---------- From: Murray S. Kucherawy > Date: Tue, Sep 16, 2014 at 1:09 PM Subject: Working Group Last Call on draft-ietf-appsawg-multipart-form-data To: IETF Apps Discuss > Working Group Last Call: draft-ietf-appsawg-multipart-form-data Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-multipart-form-data. The document seems to have stabilized and I believe Larry got the help he needed in setting up test cases he needed. Please provide review comments or expressions of support for the current version either on this list or privately to draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org on or before October 3, 2014. Be as detailed as possible. The co-chairs need to determine if the document has working group consensus, which means we need to know people have read the latest version and agree with its content and with the idea that it is ready to proceed. A simple “+1” doesn’t tell us anything. Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79. is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Nov 11 08:38:47 2014 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 EAFEC1A0024 for ; Tue, 11 Nov 2014 08:38:44 -0800 (PST) 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 673u_FCRuuM6 for ; Tue, 11 Nov 2014 08:38:43 -0800 (PST) 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 7D9601A0022 for ; Tue, 11 Nov 2014 08:38:43 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sABGccfS015817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 08:38:41 -0800 Message-ID: <54623B89.6050808@dcrocker.net> Date: Tue, 11 Nov 2014 08:38:33 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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, 11 Nov 2014 08:38:41 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8RA4_pzCOAyEA6h0emA0lHR6poM Subject: Re: [apps-discuss] On the markdown documents 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, 11 Nov 2014 16:38:45 -0000 On 11/10/2014 6:33 PM, Murray S. Kucherawy wrote: > Colleagues, > > Alexey and I have discussed it, and we recommend that the WG not adopt > draft-seantek-text-markdown-use-cases at this time. We would like the > WG to focus on developing draft-ietf-appsawg-text-markdown with Sean > until it's ready to go at least to WGLC, or preferably to the IESG, and > then we can adopt draft-seantek-text-markdown-use-cases if there's still > the energy and desire to publish it at that time. Use cases can serve two different purposes. I think the intent of the use case document, here, could affect whether it should come before or after the actual spec. So I think we should be clear about that intent. One purpose is to guide design of the solution. The other is to explain what has been designed, to those who might use it, specifically by giving them likely scenarios to use it in. If the current spec document is far enough along, in purpose and detail, then I assume the use case document is for educating the mass of potential adopters. However from the discussions about markdown, I really can't tell how settled design issues are. So I'll reduce to a simple question: Could/Should having a use case document make it easier to resolve disagreements about the choices in the text-markdown document? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 11 08:43:14 2014 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 E8FAB1A003B; Tue, 11 Nov 2014 08:43:11 -0800 (PST) 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 rRusEwEEHBuD; Tue, 11 Nov 2014 08:43:10 -0800 (PST) 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 3931D1A0016; Tue, 11 Nov 2014 08:43:10 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sABGh5vE015967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 08:43:09 -0800 Message-ID: <54623C95.1090303@dcrocker.net> Date: Tue, 11 Nov 2014 08:43:01 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Casey Deccio , "dbound@ietf.org" , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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, 11 Nov 2014 08:43:09 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NDE8rCtkcNVsdkpZ162hi7c0RTA Subject: Re: [apps-discuss] [Dbound] DBOUND side meeting - new time/location 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, 11 Nov 2014 16:43:12 -0000 On 11/11/2014 12:07 AM, Casey Deccio wrote: > The time and location for the DBOUND meeting have changed. The > DBOUND side meeting (as opposed to (non) bar BoF) will be held from > 1440 - 1910 on Thursday in South Pacific II. > > > *sigh*. The start time should read *1640* (i.e., 4:40pm). 4 1/2 hours? Any chance of an audio link for remote access? That room isn't on the list of regular audio. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 11 09:07:06 2014 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 2CB421A88BA; Mon, 10 Nov 2014 19:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 3wDQ-pyztNm3; Mon, 10 Nov 2014 19:22:09 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2834D1AD4CD; Mon, 10 Nov 2014 19:22:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=btIFZlPVq4C3JmJvL1/StxCeq0GMufFmO3m7Jh1B9Xwf0o9PMdLDZbt7iIYOXAfV; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Xo21s-0004is-MJ; Mon, 10 Nov 2014 22:22:04 -0500 Received: from 99.101.142.218 by webmail.earthlink.net with HTTP; Mon, 10 Nov 2014 22:22:04 -0500 Message-ID: <18779291.1415676124573.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Mon, 10 Nov 2014 19:22:04 -0800 (GMT-08:00) From: Randy Presuhn To: ietf@ietf.org, IETF Announcement List Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f9da3f706ce683329fb5d06cbbaae401b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Zi-Y85vLbnN28-3XYkPtA-vEIBU X-Mailman-Approved-At: Tue, 11 Nov 2014 09:06:45 -0800 Cc: slim@ietf.org, randy@qti.qualcomm.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New Non-WG Mailing List: Slim -- Selection of Language for Internet Media X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:22:11 -0000 Hi - How is this related to the work of the old ltru working group? Randy -----Original Message----- >From: IETF Secretariat >Sent: Nov 10, 2014 6:04 PM >To: IETF Announcement List >Cc: slim@ietf.org, randy@qti.qualcomm.com, apps-discuss@ietf.org >Subject: New Non-WG Mailing List: Slim -- Selection of Language for Internet Media > >A new IETF non-working group email list has been created. > >List address: slim@ietf.org >Archive: http://www.ietf.org/mail-archive/web/slim/ >To subscribe: https://www.ietf.org/mailman/listinfo/slim > >Purpose: > >A mutually comprehensible language is helpful for human communication. >This is true across a range of circumstances and environments. In >general, the problem is most acute in situations where there is not a >clear choice for a single language, such as environments lacking >contextual or out-of-band information regarding the identity of the >parties and the language to be used. > >This list is for discussion of mechanisms to present and select human >language options for Internet applications. Initial drafts address >two specific cases that most urgently need a technical solution: One >problem space is non-real-time communication, specifically email for >one-to-many or where the set of recipients is dynamic or different >recipients require different languages; the other is real-time >communication, especially emergency calling, and also including other >cases where the parties may not know each other personally or where >one party wishes to accommodate people with varying language and media >needs. Especially for real-time communication, language and media are >intrinsically linked, for example, signed languages require a video >media. > >For additional information, please contact the list administrators. > From nobody Tue Nov 11 09:07:22 2014 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 7F91A1AD0CD; Mon, 10 Nov 2014 21:37:52 -0800 (PST) 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.595 X-Spam-Level: X-Spam-Status: No, score=-7.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 xvfdf6BUSZtc; Mon, 10 Nov 2014 21:37:50 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE86F1ACFEB; Mon, 10 Nov 2014 21:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1415684271; x=1447220271; h=x-ojodefuego:message-id:in-reply-to:references:x-mailer: date:to:from:subject:cc:content-type; bh=5hryPtr9O+m5CdP32PGxqu8YybXm/rD/Dmh1xIYlMV8=; b=SqKTggTET3ChSabVT46MajPFYpmx2fBKQAnQbXhM2DQEOXO1PuaDb2jL B3VuNHdQsSuAyzgJZIZbz1145WGVTnrK6KrYhpiwJ9q/T9rkvRZJKKO5M /TBUcFmVEGcT73TcF4tXivyxDgcnPcTmEJffMuVxcOY2aeRz+oTYdZ0Dv Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7618"; a="83196897" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 21:37:51 -0800 X-IronPort-AV: E=Sophos;i="5.07,358,1413270000"; d="scan'208";a="842437667" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 21:37:50 -0800 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id sAB5bmhS005058; Mon, 10 Nov 2014 21:37:49 -0800 X-IronPort-AV: E=Sophos;i="5.07,358,1413270000"; d="scan'208";a="787827137" X-ojodefuego: yes Received: from unknown (HELO dhcp-97d8.meeting.ietf.org) ([10.64.235.175]) by Ironmsg03-R.qualcomm.com with ESMTP; 10 Nov 2014 21:37:46 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <18779291.1415676124573.JavaMail.root@mswamui-valley.atl.sa.earthlink. net> References: <18779291.1415676124573.JavaMail.root@mswamui-valley.atl.sa.earthlink. net> X-Mailer: Eudora for Mac OS X Date: Mon, 10 Nov 2014 21:37:45 -0800 To: Randy Presuhn , 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: http://mailarchive.ietf.org/arch/msg/apps-discuss/NKv4n2sPUCDlLDQa3FqwFxZ8uFs X-Mailman-Approved-At: Tue, 11 Nov 2014 09:06:50 -0800 Cc: slim@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] New Non-WG Mailing List: Slim -- Selection of Language for Internet Media 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, 11 Nov 2014 05:37:52 -0000 At 7:22 PM -0800 11/10/14, Randy Presuhn wrote: > How is this related to the work of the old ltru working group? This work makes use of the language tags registry, which the old group worked on. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- People are not homeless if they're sleeping in the streets of their own hometowns. --Dan Quayle (U.S. Vice-President) From nobody Tue Nov 11 09:07:24 2014 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 A62A21ACDFE for ; Mon, 10 Nov 2014 22:07:36 -0800 (PST) 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 lcMlcSFmhz4b for ; Mon, 10 Nov 2014 22:07:30 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E97E1ACCED for ; Mon, 10 Nov 2014 22:07:28 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id tr6so10967967ieb.28 for ; Mon, 10 Nov 2014 22:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=1Y13hIONcYXNR70gULf03FVKx7rDNrgqHejq3Rfj9A8=; b=eMxkhOIAj+oOMWjt/hIeWFHqCZvVMdmhBBBR/Ng92LJx423rGgpUiP37lsdpyZFapH xRjp+W66l63QSqw+9xIzGPMmk6wKhGD7HDCKSqgzjWxTwoMc2lmEj+PdUWLRvp7XqfRD X9qBWXI6SWqfTTiBTZVALawWldoIZwbXxatzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1Y13hIONcYXNR70gULf03FVKx7rDNrgqHejq3Rfj9A8=; b=Wm8oUtgy07aFUKewPg3nTZI3mtT+NsUw45XIsZTE0SYOSGNh8zidPkznCZ8HzmYAJi Y1ZAxBTNmsV704vy8BpyoYfNjIFt9edls38a6pXE35gRsgPUqUxlVjHAnMkfH4R+t+Md ZQORutpwCaY1WssnQ9OT6p/OITdN5TGtLFEijurgfaJKnAwCMAONkth6cFqkbc6L4HLj ihzdN3523IcYGskFSBmGzVCJ89UAOszechWq+AI1qu3u4w5WXO/B43ajnjQXuuWMxBxL IwN+caN9uiw+WMErjKMKnf5OFoNhpNqxBDkGeP6cWIxd33L4ox5960ZvBurXt7iDkc0C lVvg== X-Gm-Message-State: ALoCoQlJ8aor+9iTLWnoY6bq9GDDuodWA/nKRMAnCcKQ/ts914qs88BL+GosT88S25wwlKm2crsI MIME-Version: 1.0 X-Received: by 10.43.81.135 with SMTP id zy7mr6916727icb.63.1415686046365; Mon, 10 Nov 2014 22:07:26 -0800 (PST) Received: by 10.50.108.107 with HTTP; Mon, 10 Nov 2014 22:07:26 -0800 (PST) Date: Mon, 10 Nov 2014 20:07:26 -1000 Message-ID: From: Casey Deccio To: "dbound@ietf.org" , apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=bcaec5186adee8558405078f1745 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bHhzTZn2Mu0kJUnRVPKamDTpvTs X-Mailman-Approved-At: Tue, 11 Nov 2014 09:06:45 -0800 Subject: [apps-discuss] DBOUND side meeting - new time/location 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, 11 Nov 2014 06:07:39 -0000 --bcaec5186adee8558405078f1745 Content-Type: text/plain; charset=UTF-8 [adding apps-discuss] The time and location for the DBOUND meeting have changed. The DBOUND side meeting (as opposed to (non) bar BoF) will be held from 1440 - 1910 on Thursday in South Pacific II. Thanks to Kurt Anderson for helping track down a room. The objectives of the meeting are to review the principles and background behind domain boundaries, identify applications and protocols for which there is demand for such, and come up with a problem statement. Since I've called for the meeting, I'll come up with a loose agenda for accomplishing this, but I'm happy to take feedback and suggestions from other interested parties. I plan to use the proposed draft problem statement [1] as a starting place. Best regards, Casey [1] http://www.ietf.org/mail-archive/web/dbound/current/msg00087.html P.S. If anyone is unable to meet at the designated time, I'm happy to meet up earlier to discuss the subject ahead of time, which perspectives can be incorporated into the later meeting. I'll be available in Iolani 3 (Tapa Tower) at 0900 tomorrow (the original proposed time). --bcaec5186adee8558405078f1745 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[adding apps-discuss]

The time= and location for the DBOUND meeting have changed.=C2=A0 The DBOUND side me= eting (as opposed to (non) bar BoF) will be held from 1440 - 1910 on Thursd= ay in South Pacific II.=C2=A0 Thanks to Kurt Anderson for helping track dow= n a room.

The objectives of the meeting are to review the principles and background=20 behind domain boundaries, identify applications and protocols for which=20 there is demand for such, and come up with a problem statement.=C2=A0 Since= =20 I've called for the meeting, I'll come up with a loose agenda for= =20 accomplishing this, but I'm happy to take feedback and suggestions from= =20 other interested parties.=C2=A0 I plan to use the proposed draft problem=20 statement [1] as a starting place.

Best regards,
Casey

[1= ] http://www.ietf.org/mail-archive/web/dbound/current/= msg00087.html

P.S. If anyone is unable to meet at the designated= time, I'm happy to meet up earlier to discuss the subject ahead of tim= e, which perspectives can be incorporated into the later meeting.=C2=A0 I&#= 39;ll be available in Iolani 3 (Tapa Tower) at 0900 tomorrow (the original = proposed time).
--bcaec5186adee8558405078f1745-- From nobody Tue Nov 11 09:07:27 2014 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 F112B1AD5C2 for ; Tue, 11 Nov 2014 00:07:31 -0800 (PST) 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 RSCzr3b3YSE1 for ; Tue, 11 Nov 2014 00:07:30 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C141AD5E3 for ; Tue, 11 Nov 2014 00:07:30 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so10858468ieb.4 for ; Tue, 11 Nov 2014 00:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qmx5Iemcl0EvDmmO64kodfz1rPBXbHS6tKFaVc3gPL0=; b=go8KIeU0cEb2t0rqAWNxDEeU8cGfjfVeRXhi9Nf1ZWXkfbV+X8dC4GhSaxqpS8wmVh 16mGFhgDwl7KP1u8HT/sNwQk1c44MgDXtIMDd+B+PgQGfRnDfmyTPYKMM5otBG72MaWf AMBcZ0OBezN0EaXtDQSdRB7yEyYHDY4CNkX4U= 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:content-type; bh=qmx5Iemcl0EvDmmO64kodfz1rPBXbHS6tKFaVc3gPL0=; b=X5QmcKk0mxaSa+gJ41LIg7ND5D9JJKnTgldnATjxv9x9UTZb/LJ2xjlsI3niQjX75D Zjiexn9fMtDQavvjHtFUL5P4DuYUzBoi5Tt7Gc7xIPClbsMoYpMf/MN3DyCF5E689pzy VvhcrSoIVqSMNXMUeAA5ZAU6CMzfVElzKcgUqEPCR4oa4MLImUfNq1pcZ00r3LErMKPn hjKFye1fSJEzUz+Wvqzef5MVRDF+kUHlweQDGUrHge9ZVFb+0yOw9QLSZ4Lf9xUZqfXv ObwwXQefK49a2gAho4Vrjx9MmGIk7i0V/flNKvDxONqW4qoym3EqdJt1DxcWIITMu1Q8 lW3g== X-Gm-Message-State: ALoCoQkPz3mdyG+vUtA15gi6Kuqk2iR3TGnKp3zXd1VVC3dAGxV1tuaS5MGX+j06ivfeNZuPTyzs MIME-Version: 1.0 X-Received: by 10.107.5.79 with SMTP id 76mr1830010iof.74.1415693249238; Tue, 11 Nov 2014 00:07:29 -0800 (PST) Received: by 10.50.108.107 with HTTP; Tue, 11 Nov 2014 00:07:29 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 22:07:29 -1000 Message-ID: From: Casey Deccio To: "dbound@ietf.org" , apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a113ee6463b7530050790c502 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9RFeZEGmBXfGEseRv_w9gczN3wk X-Mailman-Approved-At: Tue, 11 Nov 2014 09:06:49 -0800 Subject: Re: [apps-discuss] DBOUND side meeting - new time/location 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, 11 Nov 2014 08:07:32 -0000 --001a113ee6463b7530050790c502 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio wrote: > The time and location for the DBOUND meeting have changed. The DBOUND > side meeting (as opposed to (non) bar BoF) will be held from 1440 - 1910 on > Thursday in South Pacific II. > *sigh*. The start time should read *1640* (i.e., 4:40pm). Casey --001a113ee6463b7530050790c502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio <casey@decci= o.net> wrote:
The time and loca= tion for the DBOUND meeting have changed.=C2=A0 The DBOUND side meeting (as= opposed to (non) bar BoF) will be held from 1440 - 1910 on Thursday in Sou= th Pacific II.

*sigh*.=C2=A0 The = start time should read *1640* (i.e., 4:40pm).

Casey
<= /div>
--001a113ee6463b7530050790c502-- From nobody Tue Nov 11 09:26:09 2014 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 131E81A00E9; Tue, 11 Nov 2014 09:26:06 -0800 (PST) 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 gtK2F15g2HMq; Tue, 11 Nov 2014 09:26:04 -0800 (PST) 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 F359B1A00E6; Tue, 11 Nov 2014 09:26:00 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sABHPpsE017395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 09:25:54 -0800 Message-ID: <5462469B.6040903@dcrocker.net> Date: Tue, 11 Nov 2014 09:25:47 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Casey Deccio , dcrocker@bbiw.net References: <54623C95.1090303@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, 11 Nov 2014 09:25:55 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/weE7uuU2_vkWrACT1MUKngsM0_I Cc: apps-discuss@ietf.org, "dbound@ietf.org" Subject: Re: [apps-discuss] [Dbound] DBOUND side meeting - new time/location 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, 11 Nov 2014 17:26:06 -0000 On 11/11/2014 9:20 AM, Casey Deccio wrote: > Any chance of an audio link for remote access? That room isn't on the > list of regular audio. > > > I will check around to see if there's something available. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 11 10:50:50 2014 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 CAB191A1A99 for ; Tue, 11 Nov 2014 10:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, LOTS_OF_MONEY=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 zzin8-_WqaCX for ; Tue, 11 Nov 2014 10:50:32 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3AA1A1A7F for ; Tue, 11 Nov 2014 10:50:29 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so2595189wib.5 for ; Tue, 11 Nov 2014 10:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w0u4wg8ryjTgHxvEv3GhANRiFxO+V7RALYlIdo7nwr0=; b=QUPZ9zg9Yq+m8Z1FnnZZUY7+istxyuMkKOqgdznZDxDkKU71qp88E361bQxaeOwVXG u8ywsiL6alljJccMKUkElwZWJ06A/zVRzpnLj1xYaDu15edK3FFepTCgT3nLFsZSEH1C zLffpDxSNXka+mymAaNahN0vkMHdHGOF4YTO0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w0u4wg8ryjTgHxvEv3GhANRiFxO+V7RALYlIdo7nwr0=; b=fqqvjwLWJOnee2zs208OL/HCWQVDqJSCR+YDwPL7aX1vMZDGvEoEopcX4yPN3ddeLI O+9eNwxJgz/mGHNsEmvyWOccQhNlmMWUEanVcVPkCcvz34R63nDH3AsMT4b9EDeUxMgj tPP3x9L6jERTRmb8yQ3uPkxzOqfeXjUHU2poDSJ2cQO6ap8GWdp9WtWumTCH6nniVNfT HspXPc3dyzbkdivQ3g70nRQMeBsRGTbTSv9Y1qQQ/mY8O42OxqVp/M4AOoioQVi346yH BEPuMtx/CJFtmLoSVwxjkrjzG/VmzCbmmR7Ymof1gQ+CVvo/cypPOO1+8AnCGW/OWsvM H0HA== X-Gm-Message-State: ALoCoQn/usmKj1MW1xbsoCsz9/tk9sRT9K/8NiVv5HpnwOmfRpX+jpWEzbZyAjya6KzEYn7dwdxB MIME-Version: 1.0 X-Received: by 10.180.84.198 with SMTP id b6mr43667282wiz.41.1415731827865; Tue, 11 Nov 2014 10:50:27 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.188.115 with HTTP; Tue, 11 Nov 2014 10:50:27 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 08:50:27 -1000 X-Google-Sender-Auth: Rv46ijAnA75ZF8bH9va9L8rNpOY Message-ID: From: Kurt Andersen To: Casey Deccio Content-Type: multipart/alternative; boundary=f46d0418264ab2cdad050799c0b6 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yb_AelfryRURo2Z399mpCljn4gs Cc: IETF Apps Discuss , "dbound@ietf.org" Subject: Re: [apps-discuss] [Dbound] DBOUND side meeting - new time/location 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, 11 Nov 2014 18:50:34 -0000 --f46d0418264ab2cdad050799c0b6 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio wrote: > . . .The DBOUND side meeting (as opposed to (non) bar BoF) will be held > from 1640 - 1910 HST (UTC-1000) on Thursday in South Pacific II. > For those who wish to participate remotely, we will have an audio feed via a polycom phone in the room. Please connect to: To join via Browser: https://bluejeans.com/966106876/browser Or to join via Phone: 1) Dial: +1 408 740 7256 +1 888 240 2560(US Toll Free) +1 408 317 9253(Alternate Number) (see all numbers - http://bluejeans.com/numbers) 2) Enter Conference ID: 9661-06876 --Kurt Andersen --f46d0418264ab2cdad050799c0b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 8:07 PM, Casey Deccio <casey@decci= o.net> wrote:
. . .The DBOUND side meeting (as opposed to (non) bar BoF) will be held f= rom 1640 - 1910 HST (UTC-1000) on Thursday in South Pacific II.=C2=A0
<= /div>

For those who wish t= o participate remotely, we will have an audio feed via a polycom phone in t= he room. Please connect to:

To join via Browser: https://bluejeans.com/966106876/browser
Or to join via Phone:
1) Dial:
+1 408 740 7256
= +1 888 240 2560(US Toll Free)
+1 408 317 9253(Alternate = Number)
(see all numbers - http://bluejeans.com/numbers)
2) Enter Conference ID: 9661-068= 76

--Kurt Andersen
<= /div> --f46d0418264ab2cdad050799c0b6-- From nobody Tue Nov 11 13:18:05 2014 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 851A21ACE01 for ; Tue, 11 Nov 2014 13:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUbUrJb8wY_6 for ; Tue, 11 Nov 2014 13:18:02 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D821ACE04 for ; Tue, 11 Nov 2014 13:18:02 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so2943813wiw.9 for ; Tue, 11 Nov 2014 13:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CKCXd7c6UShHuCqthov/CxWLoP4jGicPFgIIw05FgDU=; b=ToDK1eiFVIgeZFjQFvingi3VcFHrjM4X827uyrX3uBOTyKYpQ8+2fewy+LGhV2TYKD JZeOcDJbOE/SXmBE0qOOITQcIMs4SuGp8KP4ISx40LVRhMqNLiFMV7MFXCzSIGWDZ6md QEr95eW2NPVF1Mp6e5a7q5lxFxnrVxx4icBu4gEyLInntnuGDeWFuKx6rlJUpZO1QWQE D4eYSltnm5MARHOSgWCeW1WA3NpFemIcmzxUM524C/5ZE5hvlORsdegyr/iEvcJvHNGC BgvgyE7HXkEnUnlOn+wrR5Ru3tJBs9C+5fXUsodqp9WsnLLciJKMOmYZQ8ldq5yAGNEq EscA== MIME-Version: 1.0 X-Received: by 10.180.14.226 with SMTP id s2mr43363142wic.61.1415740680843; Tue, 11 Nov 2014 13:18:00 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 11 Nov 2014 13:18:00 -0800 (PST) In-Reply-To: References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> Date: Tue, 11 Nov 2014 11:18:00 -1000 Message-ID: From: "Murray S. Kucherawy" To: Mateusz Karcz Content-Type: multipart/alternative; boundary=f46d04138c9f603a7505079bd073 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NZaUdCJZqUq-fpkpYK6UXSKYPsw Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 11 Nov 2014 21:18:03 -0000 --f46d04138c9f603a7505079bd073 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 6:21 PM, Mateusz Karcz wrote: > One of main goal on which I was working was to maintain existing > solutions. Believe me or not, but UAs of Firefox, IE11, Chrome, Safari, > Opera and Konqeror are 100% valid web browser UUAS. Firefox OS and Firefox > Mobile are now 100% valid regular UUAS, but it can be made "web browser > UUAS just by changing 1 rule in ABNF definition. I thought a lot before > designing this draft and compared a lot of recent UAs. And one another > thing: This memo is not intended to make existing software useless. It is > intended to make an advice for present and future developers, how to > generate good UAs preserving behavior of legacy websites. > [...] > It's been suggested that you might find support in HTTPBIS since it is more related to work they're doing. Have you proposed your draft to that working group? -MSK --f46d04138c9f603a7505079bd073 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 6:21 PM, Mateusz Karcz <= mateusz.karcz@interia.eu> wrote:
One of main goa= l on which I was working was to maintain existing solutions. Believe me or = not, but UAs of Firefox, IE11, Chrome, Safari, Opera and Konqeror are 100% = valid web browser UUAS. Firefox OS and Firefox Mobile are now 100% valid re= gular UUAS, but it can be made "web browser UUAS just by changing 1 ru= le in ABNF definition. I thought a lot before designing this draft and comp= ared a lot of recent UAs. And one another thing: This memo is not intended = to make existing software useless. It is intended to make an advice for pre= sent and future developers, how to generate good UAs preserving behavior of= legacy websites.
[...]

It's been suggested that you = might find support in HTTPBIS since it is more related to work they're = doing.=C2=A0 Have you proposed your draft to that working group?

-MSK
--f46d04138c9f603a7505079bd073-- From nobody Tue Nov 11 13:51:22 2014 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 82B731ACECC for ; Tue, 11 Nov 2014 13:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.184 X-Spam-Level: * X-Spam-Status: No, score=1.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 vz8zRPJRQtVP for ; Tue, 11 Nov 2014 13:51:06 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.239]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3891ACEA5 for ; Tue, 11 Nov 2014 13:51:06 -0800 (PST) Date: Tue, 11 Nov 2014 22:51:04 +0100 From: Mateusz Karcz To: "Murray S. Kucherawy" X-Mailer: interia.pl/pf09 In-Reply-To: References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> X-Originating-IP: 109.207.150.139 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1415742664; bh=W/TWuOKwC0AYwufoU2HV6bg+A7HAnd1eK5ZjrVRGDqM=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=l7hW5DuAESs9ZiO6U69c5UcVvTH21Nv36tsXoG74SrjJ2iG1B82qN5cj3/95Z+R+w vjhr6YmNDauP9MYNVJ5FnTgb6j1lwbHeGfJqpUEsYeS+CSLmX3BQfnbnv5paE3fROD FSTa9eRh/VhQFOEBfIuBVtDfs7V80gfc2BrHMYFk= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GSyeUNZ_VU8uonrprOhLKExQ9mA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 11 Nov 2014 21:51:09 -0000 No, not yet. While I was submitting my I-D two years ago RFC Editor (I don'= t really remember who exactly) claimed, that I should look for help in Apps= AWG or W3C, so I came here. But now I think it would be a good idea to writ= e on HTTPBis. U=C5=BCytkownik "Murray S. Kucherawy" napisa=C5=82(a)= :=20 > Temat: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) > Data: 2014-11-11 22:18 > Nadawca: "Murray S. Kucherawy" > Adresat: "Mateusz Karcz" ;=20 >=20 > On Mon, Nov 10, 2014 at 6:21 PM, Mateusz Karcz = wrote:One of main goal on which I was working was to maintain existing sol= utions. Believe me or not, but UAs of Firefox, IE11, Chrome, Safari, Opera = and Konqeror are 100% valid web browser UUAS. Firefox OS and Firefox Mobile= are now 100% valid regular UUAS, but it can be made "web browser UUAS just= by changing 1 rule in ABNF definition. I thought a lot before designing th= is draft and compared a lot of recent UAs. And one another thing: This memo= is not intended to make existing software useless. It is intended to make = an advice for present and future developers, how to generate good UAs prese= rving behavior of legacy websites. > [...]It's been suggested that you might find support in HTTPBIS since it = is more related to work they're doing.=C2=A0 Have you proposed your draft t= o that working group?-MSK >=20= From nobody Tue Nov 11 18:13:30 2014 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 D33631A88F4 for ; Tue, 11 Nov 2014 18:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 fgm4VaXjEdfe for ; Tue, 11 Nov 2014 18:13:20 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6501A88D9 for ; Tue, 11 Nov 2014 18:13:20 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PEU0Q10RBK006BWS@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 11 Nov 2014 18:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1415758098; bh=Xz0/HI29KihmDHI67Jz2zA3t8T+tF0mkBYRekj2+OJg=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=SmtPXPC5vrXtx4a/t9FvKJz7Ddx5o1x1ScRNHTL7Xjyav3LgawqTrrCRQmOA+pDXC aqkQ/E6dVFnkeaHcN3U1pLce8FSWM4UbVrzHR6rDdEWJje6M5UhpYrUOS7NkSemUkw 2lJOXjw0SoDdqRU8OszVr7PV5cAD75pNo9QxHUeE= 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 <01PERBST8S8G00530M@mauve.mrochek.com>; Tue, 11 Nov 2014 18:08:14 -0800 (PST) Message-id: <01PEU0PZ53PM00530M@mauve.mrochek.com> Date: Tue, 11 Nov 2014 18:01:10 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 11 Nov 2014 11:11:55 +0000" <045a01cffda8$b3f45120$4001a8c0@gateway.2wire.net> References: <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> <045a01cffda8$b3f45120$4001a8c0@gateway.2wire.net> To: "t.petch" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hpda5J7SH4BR1AwTButW6fVUCn8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data 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, 12 Nov 2014 02:13:27 -0000 > I note that this I-D specifies > Encoding considerations: Common use is BINARY. > Looking at > http://www.iana.org/assignments/media-types/multipart/related > I see > Encoding considerations: Multipart content-types cannot have > encodings. > I have looked at more recent RFC, such as RFC6838, and can see nothing > to gainsay this. Does this restriction still apply? Atually, both of these are more or less correct. It's all in how you look at it: A multipart cannot have a non-identity content-transfer-encoding, but you can talk about its encoding considerations, which are effectively the union of all the parts. That said, I find the first to be preferable. For one thing, it provides more information. But perhaps more importantly, it's not beyond possibility that the restriction on encodings of multipart will be lifted at some point just as the restriction on message types was. Ned From nobody Wed Nov 12 07:30:51 2014 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 EB8AF1A1BBB for ; Wed, 12 Nov 2014 07:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, 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 bhk824ueRvsr for ; Wed, 12 Nov 2014 07:30:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4D31A1B26 for ; Wed, 12 Nov 2014 07:30:24 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PEUSK7Z8GG006H5D@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 12 Nov 2014 07:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1415805922; bh=DayAJm91M3oZYjIsMq1LGEytbNJfhvHpAFY3ZDmctU8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=LyhmZggaYkRnIWxOabdoLroRzjH+xtURP0faez0w9EFLqf7ihB4CLyn6XSFFTOHkp +V1WwLWuGFSyxCfbIrfWf0N/5jHWwCbdptShVj0ifK2o/4t9J1C0ZmSn+qsLbN92V3 Th2QxHC691xPAik7+ZhhxeNbl1EzMRG8BwMI81oM= 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 <01PEUS757OUO00005L@mauve.mrochek.com>; Wed, 12 Nov 2014 07:25:18 -0800 (PST) Message-id: <01PEUSK6Q2TY00005L@mauve.mrochek.com> Date: Wed, 12 Nov 2014 07:24:28 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 10 Nov 2014 10:09:01 -0700" <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> To: Chris Newman Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/k64loNyXqFMjOhNlqR-zwEbxq1A Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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, 12 Nov 2014 15:30:39 -0000 I agree with Chris on all the points he raises here, especially the one about putting ciptersiute information in Received: fields. Ned > --On October 21, 2014 15:07:43 -0500 Franck Martin > wrote: > > I incorporated the previous feedback I received on this list into > > http://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/ > > > > I have not seen comments since. Several people were supportive of the work. > > > > I'd like to submit this document to become a WG document for eventual > > publication. > > > > If you have any comments on the current version, I'll update it as much as I > > can before the deadline for drafts submission 27 October. > > > > I have some code running, tho I need to do some fixes in the code (and it is > > not public yet), but it helped me to better understand what needs to be > > exposed on how to do it. > My view of this draft is it adds a lot of clutter to the wrong header and that > information has little or no value. > The one useful piece of information is the negotiated cipher suite, but that is > most useful if the information is provided on a hop-by-hop basis so it belongs > in the Received header, IMHO. > In my experience, client certificate authentication in SSL/TLS is very uncommon > in all protocols. The general model for client certificate authentication is > that the server has a CA that is used to sign all client certificates that are > used with that server. That model doesn't work for SMTP relay (although it's a > model I have implemented and works fine for SMTP Submission). For client > certificate authentication to work, the server has to request a client > certificate, the client has to have one configured and to use it to > authenticate the session. I'd like to see data on how many deployed SMTP > servers that support TLS request a client certificate. I know the servers I > work on do not request that by default. I also doubt most SSL/TLS appliances > request client certificates by default. > There's also no standard for how to use client certificates with SMTP relay. > Server certificate authentication is widely used in SSL/TLS, but it's not > useful in SMTP relay today because there is no standard for how to do it, and > in particular for how it relates to MX records and non-primary MX hosts. Until > such a standard is published, I'm opposed to recording misleading information > about server authentication. I'll also point out that server authentication is > performed by the client and only the client knows if it verified the server's > identity. So server identity and authentication is completely contrary to the > model of authentication used by other Authentication-Results uses because the > server-authentication information for the "long hop" can only be generated from > outside the recipient's administrative domain. > I also do not view the server's opinion of the key strength of a TLS cipher > suite to have any value. The server's opinion can be wrong if the client has a > bad SSL stack. The cipher suite that was used is a specific piece of factual > data. If 10 weeks ago we used a cipher suite that was suddenly recognized as > broken today, the cipher suite used information is quite valuable, but the > server's opinion of its effective key size or strength will be worthless. > Finally, the draft does not state how this TLS information would be used. I'm > opposed to adding all this clutter to headers unless there is some plausible > utility. > - Chris > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Nov 12 07:38:31 2014 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 150851A19FB for ; Wed, 12 Nov 2014 07:38:28 -0800 (PST) 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 Mo6Ro5s4MQtT for ; Wed, 12 Nov 2014 07:38:26 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6D71A036F for ; Wed, 12 Nov 2014 07:38:25 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4CD61FA0077; Wed, 12 Nov 2014 15:38:24 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1415806703-4330-4329/12/131; Wed, 12 Nov 2014 15:38:23 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Wed, 12 Nov 2014 16:38:22 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: In-Reply-To: <01PEUSK6Q2TY00005L@mauve.mrochek.com> References: <44757941.49835.1413922063168.JavaMail.zimbra@peachymango.org> <8C22D80F14C7500B7BEFCAC1@96B2F16665FF96BAE59E9B90> <01PEUSK6Q2TY00005L@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IuN4gdmQ2FCP25OXeF2jYin5D88 Subject: Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ? 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, 12 Nov 2014 15:38:28 -0000 I add my voice to the chorus, and in particular wish to repeat this: >> Finally, the draft does not state how this TLS information >> would be used. I'm >> opposed to adding all this clutter to headers unless there is >> some plausible >> utility. What Chris says here is "tell me a use case". Yes. Please do. Solutions made before any use cases are known have such an icky tendency to miss. Arnt From nobody Wed Nov 12 09:11:37 2014 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 9EF0A1A8F41 for ; Wed, 12 Nov 2014 09:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.184 X-Spam-Level: * X-Spam-Status: No, score=1.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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 H3lihcnmtBPe for ; Wed, 12 Nov 2014 09:11:23 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.155]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0BA1A8F48 for ; Wed, 12 Nov 2014 09:08:54 -0800 (PST) Date: Wed, 12 Nov 2014 18:08:52 +0100 From: Mateusz Karcz To: "Murray S. Kucherawy" X-Mailer: interia.pl/pf09 In-Reply-To: References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> X-Originating-IP: 31.61.131.158 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1415812132; bh=sEhhcz3zuxGXMY4FQbQsWhSVjMj/1yCRUHW0s2RYtro=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=eZiBNyyuHBP5qLaJPhmor3XSkX1THaxG2LCsT+WEAcdjowZCCuhnJhO6oh7H7g404 dE3MDPU8hU0/ewEo3ShtKfgSt4XgowoTnfyrTfDpTzsQDL86x270NGHHryDneadDvO ESDpv5Y3js65roDO+NezN9n/b6yVZuGQGCi441sU= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TIOVIaj6ga02XxEz-Y86cHi4b0U Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 12 Nov 2014 17:11:31 -0000 I've checked out and (please correct me if I'm wrong) and if I want to writ= e anything to HTTPBis, I have to join W3C, what is not very simple for me. = However, I truly understand that proposing my draft there would be more app= ropriate. -M.Karcz U=C5=BCytkownik "Murray S. Kucherawy" napisa=C5=82(a)= :=20 > Temat: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) > Data: 2014-11-11 22:18 > Nadawca: "Murray S. Kucherawy" > Adresat: "Mateusz Karcz" ;=20 >=20 > It's been suggested that you might find support in HTTPBIS since it is mo= re related to work they're doing.=C2=A0 Have you proposed your draft to tha= t working group?-MSK= From nobody Wed Nov 12 09:48:55 2014 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 4E32F1A8FD2 for ; Wed, 12 Nov 2014 09:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsF_O-rtBXuY for ; Wed, 12 Nov 2014 09:48:50 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F13B1A8733 for ; Wed, 12 Nov 2014 09:48:47 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id r20so5718392wiv.3 for ; Wed, 12 Nov 2014 09:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xX+m1j0pPOYxlndXcZ2YTwMvSy52CYN+YVo87Nv/I08=; b=oYD8nH/UpG+h0XpVWNDGB16+NWyJIty9Xlg1V2UMPhQoZZK2f7Hj0l8CVFlqv2rRfq oPF+1jMveudFOn04KTCfhNNEaIOHXp2a1KDIe6M53EA3RX9GjI9k2h3wqT1FvgHbIPDC hsH7cZcE1v2/lsY5MBMDvDMUKDDL6L/OoNmftfP1XFjVVW7nY9msJLVyMxpGeYLw1ToH EA2+L/9L94kHdH2rb+hNNfacTomlNaIijywQ7jVSsIBLNGWxR0O+Vcrv+bDJpt1pR0l7 wWj1V80FA5BCSL0CZENoNaTyPST4DCGrxefyamHI6w266WV7qdv74Q0cMoiUNLkuepD2 y1ow== MIME-Version: 1.0 X-Received: by 10.194.3.2 with SMTP id 2mr65994925wjy.89.1415814526040; Wed, 12 Nov 2014 09:48:46 -0800 (PST) Received: by 10.27.76.134 with HTTP; Wed, 12 Nov 2014 09:48:45 -0800 (PST) In-Reply-To: References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> Date: Wed, 12 Nov 2014 07:48:45 -1000 Message-ID: From: "Murray S. Kucherawy" To: Mateusz Karcz Content-Type: multipart/alternative; boundary=047d7b343c18e492850507ad01d0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/w-6x0LXBJzGYoUdgbDmbS6JTMQc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 12 Nov 2014 17:48:52 -0000 --047d7b343c18e492850507ad01d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I can't imagine that's correct. Mark Nottingham, care to comment? Simply posting to httpbis@ietf.org should be all you need to do. -MSK On Wed, Nov 12, 2014 at 7:08 AM, Mateusz Karcz wrote: > I've checked out and (please correct me if I'm wrong) and if I want to > write anything to HTTPBis, I have to join W3C, what is not very simple fo= r > me. However, I truly understand that proposing my draft there would be mo= re > appropriate. > -M.Karcz > > U=C5=BCytkownik "Murray S. Kucherawy" napisa=C5=82(= a): > > Temat: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) > > Data: 2014-11-11 22:18 > > Nadawca: "Murray S. Kucherawy" > > Adresat: "Mateusz Karcz" ; > > > > It's been suggested that you might find support in HTTPBIS since it is > more related to work they're doing. Have you proposed your draft to that > working group?-MSK > --047d7b343c18e492850507ad01d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can't imagine that's correct.=C2=A0 Mark Notting= ham, care to comment?

Simply posting to httpbis@ietf.org should be all you need to do.

-MSK
=

On Wed, Nov= 12, 2014 at 7:08 AM, Mateusz Karcz <mateusz.karcz@interia.eu&g= t; wrote:
I've checked out and= (please correct me if I'm wrong) and if I want to write anything to HT= TPBis, I have to join W3C, what is not very simple for me. However, I truly= understand that proposing my draft there would be more appropriate.
-M.Karcz

U=C5=BCytkownik "Murray S. Kucherawy" <superuser@gmail.com> napisa=C5=82(a):
> Temat: Re: [apps-discuss] Unified User-Agent= String (draft-karcz-uuas)
> Data: 2014-11-11 22:18
> Nadawca: "Murray S. Kucherawy" <superuser@gmail.com>
> Adresat: "Mateusz Karcz" <mateusz.karcz@interia.eu>;
>
> It's been suggested= that you might find support in HTTPBIS since it is more related to work th= ey're doing.=C2=A0 Have you proposed your draft to that working group?-= MSK

--047d7b343c18e492850507ad01d0-- From nobody Wed Nov 12 09:49:12 2014 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 4AF371A00ED for ; Tue, 11 Nov 2014 09:20:07 -0800 (PST) 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 Is9a7q91SBlu for ; Tue, 11 Nov 2014 09:20:04 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1E61A00CA for ; Tue, 11 Nov 2014 09:20:03 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so11801449ieb.18 for ; Tue, 11 Nov 2014 09:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EPDzTZm/Jw9o+9tH8s68Y6kExCOp1AN4uBDvS1DKYGw=; b=TTa1alS1rF/v7omNaOvRvN7aDsS1GheahHy9+6vmsd7Vf2owQ7DImIQVI07q0WYpNI j+A1erj3SaIVIrdelL4DNhC9HXOegqy7tHwEuKSfHakok5ToUPl9QRFanE9IfXj5MKoT 3sIRC3laf7N5SEoXyiWfCTwEaqIwkxx2JHTA8= 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=EPDzTZm/Jw9o+9tH8s68Y6kExCOp1AN4uBDvS1DKYGw=; b=dSHufuIUQOGo4An3MMui1NXTALJjtujbPukfMh9mayY9cRhicHDEfoV73IWrxmXpoA FCvaa3kEfYrJQoXGS9o9xCLh4FA41u0ONvke8CsV1gOSYU6YKVTN95YdftlYdF51i7TH LJnDBJdxcg5BAxe8cNcJ4XX/t7EL7eoVff5isq40lRfliy57dObZVYxgx7/mcKbU/xrI 8magfjXmqRWqQ6UhL0XxlV18rw3ZI5sC1/6VRgDJgedOnBWgkdqGKSyIwnzjcU31bOma zGq5R7yDsHnKIdFSiza1QwJd5AuGx5dSVOxe+JzBm4xfw7QED8xASRdn71WkbDgwGCEP jUTQ== X-Gm-Message-State: ALoCoQmfZ894ezi7+UxZ65iKAQ/TWQH8kzpIy6ckaiTU4Evu8InhvpgYX8lzyWWzCpt9Fjk1gzH2 MIME-Version: 1.0 X-Received: by 10.42.184.74 with SMTP id cj10mr3123244icb.80.1415726403138; Tue, 11 Nov 2014 09:20:03 -0800 (PST) Received: by 10.50.108.107 with HTTP; Tue, 11 Nov 2014 09:20:03 -0800 (PST) In-Reply-To: <54623C95.1090303@dcrocker.net> References: <54623C95.1090303@dcrocker.net> Date: Tue, 11 Nov 2014 07:20:03 -1000 Message-ID: From: Casey Deccio To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=20cf303f6ea85bd2a20507987d60 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pRi7usD0B0vpf5kvltE5Sn4EMhE X-Mailman-Approved-At: Wed, 12 Nov 2014 09:49:10 -0800 Cc: apps-discuss@ietf.org, "dbound@ietf.org" Subject: Re: [apps-discuss] [Dbound] DBOUND side meeting - new time/location 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, 11 Nov 2014 17:20:07 -0000 --20cf303f6ea85bd2a20507987d60 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 11, 2014 at 6:43 AM, Dave Crocker wrote: > On 11/11/2014 12:07 AM, Casey Deccio wrote: > > The time and location for the DBOUND meeting have changed. The > > DBOUND side meeting (as opposed to (non) bar BoF) will be held from > > 1440 - 1910 on Thursday in South Pacific II. > > > > > > *sigh*. The start time should read *1640* (i.e., 4:40pm). > > 4 1/2 hours? > My communication skills are being challenged with this announcement. The correct start and end times for the meeting are: 1640 - 1910 HST (2.5 hours) Any chance of an audio link for remote access? That room isn't on the > list of regular audio. > > I will check around to see if there's something available. Cheers, Casey --20cf303f6ea85bd2a20507987d60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 11, 2014 at 6:43 AM, Dave Crocker <dhc@dcrocke= r.net> wrote:
On 11/11/2014 12:= 07 AM, Casey Deccio wrote:
>=C2=A0 =C2=A0 =C2=A0The time and location for the DBOUND meeting have c= hanged.=C2=A0 The
>=C2=A0 =C2=A0 =C2=A0DBOUND side meeting (as opposed to (non) bar BoF) w= ill be held from
>=C2=A0 =C2=A0 =C2=A01440 - 1910 on Thursday in South Pacific II.
>
>
> *sigh*.=C2=A0 The start time should read *1640* (i.e., 4:40pm).

4 1/2 hours?

My communication sk= ills are being challenged with this announcement.=C2=A0 The correct start a= nd end times for the meeting are:

1640 - 1910 HST (2.5 ho= urs)

Any chance of an audio link for remote access?=C2=A0 That room isn't on= the
list of regular audio.


I will check around to see if there's something = available.

Cheers,
Casey
--20cf303f6ea85bd2a20507987d60-- From nobody Wed Nov 12 10:19:36 2014 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 F298E1AC3F4 for ; Wed, 12 Nov 2014 10:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.594, 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 KzMLPPHXAXib for ; Wed, 12 Nov 2014 10:19:31 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 366EB1AC408 for ; Wed, 12 Nov 2014 10:19:23 -0800 (PST) Received: from [31.133.138.149] (unknown [31.133.138.149]) (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 05DD115A1738; Wed, 12 Nov 2014 19:19:18 +0100 (CET) Message-ID: <5463A49D.7030300@greenbytes.de> Date: Wed, 12 Nov 2014 19:19:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mateusz Karcz , "Murray S. Kucherawy" References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bujAOONvhN5zZ6pc7UmudJPG8fA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 12 Nov 2014 18:19:33 -0000 On 2014-11-12 18:08, Mateusz Karcz wrote: > I've checked out and (please correct me if I'm wrong) and if I want to write anything to HTTPBis, I have to join W3C, what is not very simple for me. However, I truly understand that proposing my draft there would be more appropriate. > -M.Karcz HTTPbis is an IETF Working Group. The reason for your confusion might be that we are using a W3C mailing list (mainly for historical reasons). Best regards, Julian From nobody Wed Nov 12 11:17:38 2014 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 024BB1ACE4C for ; Wed, 12 Nov 2014 11:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLy_PzwzXVwn for ; Wed, 12 Nov 2014 11:17:33 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E951A0AF8 for ; Wed, 12 Nov 2014 11:17:30 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id b6so9815299lbj.2 for ; Wed, 12 Nov 2014 11:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=d0+cZ5qU+JQOhIk4vK4PpJF/YaI0vPC9UL7stMWq/F8=; b=kWr9s8RtGFtTfaELKXFzrxk9abs9DH9J7hr9OhRcFJ7XkZ4yUR0+QHoktxi7Jc0msA hQb0qsy89ZVrx95G7WGKcSUf8EBb72V1Nd/BBSxeiBOMfCXqe+1XkxBMhIXvUiu0OFia oj375A0a5jaoSBaBPvEbOLW6ELxO7oAP9GnKFHY7CABR7skWwdauujnXHCnaIFpS6e6g TlZhCLXVb1E9d1z9h54r1nf1vKhUKkF7jCgMA0+YdpMzXrcRhWTKMRjdXzZYd9hepHFb G/WvRkzVcbL+hY9zP4oMeeCfVNXivFXPzrDi8cAYhybjb+jsPSjTOhXN5o3kNYxl70y4 G5cg== MIME-Version: 1.0 X-Received: by 10.112.162.73 with SMTP id xy9mr3795094lbb.94.1415819849005; Wed, 12 Nov 2014 11:17:29 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.163.227 with HTTP; Wed, 12 Nov 2014 11:17:28 -0800 (PST) Date: Wed, 12 Nov 2014 09:17:28 -1000 X-Google-Sender-Auth: oDIW86eHiOrH7nsmGBHq_mBNhY4 Message-ID: From: Applications Area Directors To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7yQdfLubGXWRsdoqTIuy9p2czOI Cc: "app-ads@tools.ietf.org" Subject: [apps-discuss] Designated experts needed: looking for volunteers 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, 12 Nov 2014 19:17:35 -0000 The App area needs one or two volunteers each for designated experts to review registration requests in the following registries: 1. IETF XML Registry, schema sub-registry: http://www.iana.org/assignments/xml-registry#schema We particularly need an expert or two for non-IODEF schemas. You'll need a good understanding of XML and XML schemas. This is not a particularly busy registry, but there are some pending requests that need review. 2. Multipurpose Internet Mail Extensions (MIME) and Media Types, Media Types sub-registry: http://www.iana.org/assignments/media-types This is a particularly busy registry, and Ned Freed has been doing it by himself for a long time. We need a couple of additional volunteers to join him. You'll need to have a good understanding of the concerns involved in registering new media subtypes, and Ned will help get you on board. Please let us know off list if you're willing to take one of these on. Barry and Pete From nobody Wed Nov 12 15:10:29 2014 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 182D91A1AD0 for ; Wed, 12 Nov 2014 15:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq_z7LOg5JM9 for ; Wed, 12 Nov 2014 15:10:24 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1256B1A1ACD for ; Wed, 12 Nov 2014 15:10:18 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id y20so14215334ier.25 for ; Wed, 12 Nov 2014 15:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qX1W14xCu8KQ2joJLd61Z3i/4bkDO10fNVR0+qsKTqo=; b=jtXnUOtEmowv+g5DT5flWJTVEHFNBCTvMe1l9tHdu08YDPgoAnP4EeTFcRud+PWKVH um9PuVlyNQfJndUQVq23hyhJ3b58kCJHLt9jy7rn6VNb4R7PND4mlxt00ufu6lKIXZr8 kd5vCVtBTLaYd1/EwZ9TWPy5C0OSvmr9N9J7B2Z0rLspr2VPeD6Tr3nmMWbBdm9LJm19 zy9IqeFANt5jRkG4B4WeAT+mCWVoIqenXGqA0h7Q3NX7zzVXCqDwoCZwrcFkjEx0j6HV sSsyBzuY2/jO4HS+tyGCxQSk0V1wKPU+eevnAyYLFm6K+RBPQmBssAuKlFbv9h9ubJ+m uv8g== MIME-Version: 1.0 X-Received: by 10.107.9.2 with SMTP id j2mr5424330ioi.82.1415833817277; Wed, 12 Nov 2014 15:10:17 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.173.29 with HTTP; Wed, 12 Nov 2014 15:10:17 -0800 (PST) In-Reply-To: References: <1A5CC580-C8AA-48A0-8C7E-C9C9716A51D9@la-grange.net> Date: Wed, 12 Nov 2014 13:10:17 -1000 X-Google-Sender-Auth: Xqt82u55lGbaAri6QeY_IQFZXfo Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ftzRHwOjN2BPEmWyQn65YWrSTLo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Unified User-Agent String (draft-karcz-uuas) 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, 12 Nov 2014 23:10:26 -0000 > Simply posting to httpbis@ietf.org should be all you need to do. That's not the address for the httpbis working group. It's -- as Julian said, on the W3C servers, for historical reasons. But there's no W3C membership required, of course. Barry From nobody Wed Nov 12 20:18:48 2014 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 7E0FA1A1B72 for ; Wed, 12 Nov 2014 20:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.114 X-Spam-Level: ** X-Spam-Status: No, score=2.114 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 Y2zFkipIjZdG for ; Wed, 12 Nov 2014 20:18:39 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 40C311A1B5D for ; Wed, 12 Nov 2014 20:18:38 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 6621332E543; Thu, 13 Nov 2014 13:17:53 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 60b9_6be9_b713c452_f54d_43f2_85cb_f20eebedf313; Thu, 13 Nov 2014 13:17:52 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C264FBF511; Thu, 13 Nov 2014 13:17:52 +0900 (JST) Message-ID: <546430EF.5080505@it.aoyama.ac.jp> Date: Thu, 13 Nov 2014 13:17:51 +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.2.0 MIME-Version: 1.0 To: "t.petch" , Salvatore Loreto , IETF Apps Discuss References: <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> <02cc01cffab6$bf1bdd60$4001a8c0@gateway.2wire.net> In-Reply-To: <02cc01cffab6$bf1bdd60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Xm9yAP1BivecYauglO7Xvg1O0uU Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data 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, 13 Nov 2014 04:18:42 -0000 On 2014/11/08 03:14, t.petch wrote: > Saving the RFC Editor a little work mostly > > s.4 > > /there are a generally series of fields,/there are generally aseries of > fields,/ /there are a generally series of fields,/there are generally a series of fields,/ (missing space) Regards, Martin. From nobody Wed Nov 12 21:23:35 2014 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 50B881A1B7F for ; Wed, 12 Nov 2014 21:23:33 -0800 (PST) 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 3vzNk4svXt6d for ; Wed, 12 Nov 2014 21:23:32 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067F21A1B7A for ; Wed, 12 Nov 2014 21:23:31 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so14370681pab.26 for ; Wed, 12 Nov 2014 21:23:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ka0uEXGb1ZimXnwI48F2sgdmRb1S2XLeSNgPt+UbsjI=; b=JMoOuucX5H+7CblTlIsyWhILW6TJYOSbgSkfD74+QZqjdXEpaAAxU4ePLkj1R53ZG1 NMTy3/V26b31F2eEKTyucYe7AkpdlT3XWWzvspKeotgNgEEWEjxnvIlsCL20HZxemtMf XujOnDtVvHzObUre59eIrOudwJK2GxfMo3eP3fj8GCh+5Nm161L6UTJlAG8PuS+uJ2bl v3comWoDFNfjMPjN9rEjDWNQxDj48cHmUJONERzwwmVdgB+eAq/Ipr4aVXub99Ym9oH2 tXJSXEfmIZIe/2G479fRcwH970An/luj7vfIIrkpnRYRcv0rfmeYUZElgnN14azRATQy Pykw== X-Gm-Message-State: ALoCoQmLIjjECpP9jaJsvOb4e3YMhfii2YdvBnBLaKOxR1qYt2wAxSICLkPFXC7VtjnhJdt6z/QT MIME-Version: 1.0 X-Received: by 10.70.45.233 with SMTP id q9mr378881pdm.24.1415856209750; Wed, 12 Nov 2014 21:23:29 -0800 (PST) Sender: mark@coactus.com Received: by 10.70.48.199 with HTTP; Wed, 12 Nov 2014 21:23:29 -0800 (PST) X-Originating-IP: [65.123.81.194] In-Reply-To: References: Date: Thu, 13 Nov 2014 00:23:29 -0500 X-Google-Sender-Auth: kYv1xxp1qnqftbdJ_H9ZFvfMJ2Q Message-ID: From: Mark Baker To: Applications Area Directors Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fI_ftSwyq_8aF7SijptAQoLMBgM Cc: Apps Discuss Subject: Re: [apps-discuss] Designated experts needed: looking for volunteers 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, 13 Nov 2014 05:23:33 -0000 On Wed, Nov 12, 2014 at 2:17 PM, Applications Area Directors wrote: > 2. Multipurpose Internet Mail Extensions (MIME) and Media Types, Media > Types sub-registry: > http://www.iana.org/assignments/media-types > > This is a particularly busy registry, and Ned Freed has been doing it > by himself for a long time. We need a couple of additional volunteers > to join him. You'll need to have a good understanding of the concerns > involved in registering new media subtypes, and Ned will help get you > on board. FYI, Bjoern Hoehrmann and I are currently secondary DEs for media types; http://www.iana.org/assignments/media-types/media-types.xhtml I remain available to help. Mark. From nobody Thu Nov 13 19:02:57 2014 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 9FC1B1A00D0 for ; Thu, 13 Nov 2014 19:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zollwoB_zoGX for ; Thu, 13 Nov 2014 19:02:53 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F9E1A1B1B for ; Thu, 13 Nov 2014 19:02:53 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so1419143wiw.2 for ; Thu, 13 Nov 2014 19:02:52 -0800 (PST) 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=EgKGTf97MiXoISdcZ0Xs3Ssu9StEsD/Iu34Qm0czYGI=; b=kimso9jK/DR1clK9qUDJDrddPL3xk8R1xOnZ/N5E+LSZwTLbWdFxFbvVytny4a7AxZ PWZaz44+JE8BDSqPCPiIqpBV7V4dnduIMLmZknslxgMJUua3RNxvdsALFQG7PUf0bIPr deDYKzZP1NpaUONpi17K3HIOb8ZLoTn29UxhGRneewEH2y6ijZ//rcTKdK+6TBVfuo5Y UZ1KxgisA0/u10b24TUo0wG2E/lVqXd1g+gctT1rxYtXdDre4CykJgA5Tek1jcrIWX1Q 1sftCnD0sO0PWeBerWeuL4Q408K4nC7bT8My6reKqprN8S5ZKrbppoFnRRtXS4B8gw8X S7qQ== MIME-Version: 1.0 X-Received: by 10.194.3.2 with SMTP id 2mr9441597wjy.89.1415934171960; Thu, 13 Nov 2014 19:02:51 -0800 (PST) Received: by 10.27.76.134 with HTTP; Thu, 13 Nov 2014 19:02:51 -0800 (PST) Date: Thu, 13 Nov 2014 17:02:51 -1000 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b343c18585e6b0507c8dd13 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o36SleVoZomFrlpRFSVDCjoHZ6U Subject: [apps-discuss] Proposed charter for arcmedia 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, 14 Nov 2014 03:02:56 -0000 --047d7b343c18585e6b0507c8dd13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some text I threw together for a possible arcmedia charter. Feel free to hack on it. Also, if anyone is interested in participating in the management of this working group, please let Barry know. It is likely at this point that this will be a short-lived working group which will never actually meet. --- snip --- There has been recent work to register media types for archive formats such as =E2=80=9Ctar=E2=80=9D (a POSIX standard format). There are already seve= ral similar media types for archive formats, such as =E2=80=9Cgzip=E2=80=9D and =E2=80= =9Czip=E2=80=9D (see, for example, RFC6713), all of which are registered under the top-level media type =E2=80=9Capplication=E2=80=9D. We create top-level media types only rarely, only with Standards Track RFCs, and only when one or more media types get special (or common, in the case of more than one) handling that does not fit under an existing top-level media type. RFC6838 defines this process. This working group will create an =E2=80=9Carchive=E2=80=9D top-level media= type in a Standards Track document, using draft-seantek-kerwin-arcmedia-type as its initial input. It will specify rules for registering subtypes under that new top-level type. All of the usual things will be considered, including type suffixes, fragment identifiers, and internationalization. Either in that same document or in a second one, it will produce an initial set of registrations under the new top-level media type. The main document will include an Implementation Status section, described by RFC6982, to record known projects that will either produce or consume content using the new media type. If by the first milestone there appears to be no implementations of the new media type expected, the working group will fold having produced no RFCs. No other work is in scope for this working group. Milestones: - June 2015: Base document - December 2015: Registrations document (if separate) --047d7b343c18585e6b0507c8dd13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some text I threw together for a possible arcmedia ch= arter.=C2=A0 Feel free to hack on it.

Also, if anyone is = interested in participating in the management of this working group, please= let Barry know.=C2=A0 It is likely at this point that this will be a short= -lived working group which will never actually meet.

--- snip = ---

There has been recent work to register media types for arch= ive formats such as =E2=80=9Ctar=E2=80=9D (a POSIX standard format).=C2=A0 = There are already several similar media types for archive formats, such as = =E2=80=9Cgzip=E2=80=9D and =E2=80=9Czip=E2=80=9D (see, for example, RFC6713= ), all of which are registered under the top-level media type =E2=80=9Cappl= ication=E2=80=9D.

We create top-level media types only rarely, only = with Standards Track RFCs, and only when one or more media types get specia= l (or common, in the case of more than one) handling that does not fit unde= r an existing top-level media type.=C2=A0 RFC6838 defines this process.
=
This working group will create an =E2=80=9Carchive=E2=80=9D top-level m= edia type in a Standards Track document, using draft-seantek-kerwin-arcmedi= a-type as its initial input.=C2=A0 It will specify rules for registering su= btypes under that new top-level type.=C2=A0 All of the usual things will be= considered, including type suffixes, fragment identifiers, and internation= alization.

Either in that same document or in a second one, it will = produce an initial set of registrations under the new top-level media type.=

The main document will include an Implementation Status section, de= scribed by RFC6982, to record known projects that will either produce or co= nsume content using the new media type.=C2=A0 If by the first milestone the= re appears to be no implementations of the new media type expected, the wor= king group will fold having produced no RFCs.

No other work is in sc= ope for this working group.

Milestones:
- June 2015: Base documen= t
- December 2015: Registrations document (if separate)
--047d7b343c18585e6b0507c8dd13-- From nobody Fri Nov 14 08:02:29 2014 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 31C661A0140 for ; Fri, 14 Nov 2014 08:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 sAVrxLof2ZYA for ; Fri, 14 Nov 2014 08:02:16 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BB81A0035 for ; Fri, 14 Nov 2014 08:02:15 -0800 (PST) Received: from dhcp-8c2d.meeting.ietf.org (unknown [31.133.140.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CB66350A73 for ; Fri, 14 Nov 2014 11:02:13 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_25C6203C-5058-48C5-926B-8446105CB14F"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <6C8B5BC9-E191-4554-ABE7-8F9AFA8FD405@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 14 Nov 2014 06:00:54 -1000 References: <5D32EA67-3EEE-4369-B44B-3FCE9E2F64FA@seantek.com> To: IETF Apps Discuss In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gUTfsmQ14v6ONJBx72phBwTXoG0 Subject: Re: [apps-discuss] Various image/* media type drafts 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, 14 Nov 2014 16:02:21 -0000 --Apple-Mail=_25C6203C-5058-48C5-926B-8446105CB14F Content-Type: multipart/alternative; boundary="Apple-Mail=_B4D2A592-4FF7-4F21-8109-83F4D66B6661" --Apple-Mail=_B4D2A592-4FF7-4F21-8109-83F4D66B6661 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 10, 2014, at 4:14 PM, Murray S. Kucherawy = wrote: > On Mon, Nov 10, 2014 at 4:01 PM, Dave Thaler = wrote: > For wmf and emf, #1 is what I heard people arguing for, and I think is = the best approach. >=20 > +1, and image/bmp for that one. I don't think image/wmf and image/emf = are likely to see actual adoption at this point. I did an implementation survey to arrive at my position on this. It = looks like image/wmf and image/emf are in the wild. I would like to point out some flaws in this rationale for (or against) = image/wmf and image/emf. Stuff gets adopted if people choose to adopt = it. I wrote the drafts in significant part because I wanted to use the = correct media types in software that I supervise, which includes e-mail = clients. I did not invent the MIME type names=97I just used what is actually out = there. There is software out there that uses image/wmf and image/emf (do = a web search=97you will find some). Microsoft Windows and Apache are not = among them; however, should market adoption matter? What is the = threshold of market success for this WG? If we want to interoperate with these pieces of software, should = image/emf and image/wmf be =93Deprecated alias types=94, while = image/x-emf and image/x-wmf be the official types? That doesn=92t make = sense. The combination of RFC 6838 [BCP 13] and RFC 6648 [BCP 178] suggest that = x- is deprecated for new registrations, and when given a choice between = x- and no x-, the no-x- option is the way to go. Unless there is a = concrete interoperability problem, speculative statements about = likelihood of adoption should not derail the non-prefixed approach. = (Especially when the point is that an implementer is trying to adopt the = non-x- way.) Admittedly the draft does not address prevalence issues=97if folks think = that it should be addressed, I can add that to the next draft. Not clear = if it should be in the registration template, or elsewhere. When it comes to media types, we are in a regime where there are = numerous formats that have multiple type names. I have a lot of = experience with application/pkcs7-mime and application/x-pkcs7-mime (and = /pkcs7-signature), for example. With reference to Postel=92s law, receivers should be prepared to accept = multiple type names. We should give prospective guidance to senders to = pick the best one, which from what I know of WMF and EMF, is probably = image/wmf and image/emf rather than the x- versions. With all this said, I am not resolutely opposed to making the x- = versions the default. Yet as I said above, that means that the non x- = versions would be =93deprecated alias types=94 and that just does not = seem to make sense. Respectfully submitted, Sean= --Apple-Mail=_B4D2A592-4FF7-4F21-8109-83F4D66B6661 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Nov 10, 2014, at 4:14 PM, Murray S. = Kucherawy <superuser@gmail.com> = wrote:

On Mon, Nov 10, 2014 at 4:01 PM, Dave = Thaler <dthaler@microsoft.com> wrote:
For wmf and emf, #1 is what I heard people = arguing for, and I think is the best = approach.

+1, and image/bmp for that = one.  I don't think image/wmf and image/emf are likely to see = actual adoption at this = point.

I did = an implementation survey to arrive at my position on this. It looks like = image/wmf and image/emf are in the wild.

I = would like to point out some flaws in this rationale for (or against) = image/wmf and image/emf. Stuff gets adopted if people choose to adopt = it. I wrote the drafts in significant part because I wanted to use the = correct media types in software that I supervise, which includes e-mail = clients.

I did not invent the MIME type names=97I= just used what is actually out there. There is software out there that = uses image/wmf and image/emf (do a web search=97you will find some). = Microsoft Windows and Apache are not among them; however, should market = adoption matter? What is the threshold of market success for this = WG?

If we want to interoperate with these = pieces of software, should image/emf and image/wmf be =93Deprecated = alias types=94, while image/x-emf and image/x-wmf be the official types? = That doesn=92t make sense.

The combination of = RFC 6838 [BCP 13] and RFC 6648 [BCP 178] suggest that x- is deprecated = for new registrations, and when given a choice between x- and no x-, the = no-x- option is the way to go. Unless there is a concrete = interoperability problem, speculative statements about likelihood of = adoption should not derail the non-prefixed approach. (Especially when = the point is that an implementer is trying to adopt the non-x- = way.)

Admittedly the draft does not address = prevalence issues=97if folks think that it should be addressed, I can = add that to the next draft. Not clear if it should be in the = registration template, or elsewhere.

When it = comes to media types, we are in a regime where there are numerous = formats that have multiple type names. I have a lot of experience with = application/pkcs7-mime and application/x-pkcs7-mime (and = /pkcs7-signature), for example.

With reference = to Postel=92s law, receivers should be prepared to accept multiple type = names. We should give prospective guidance to senders to pick the best = one, which from what I know of WMF and EMF, is probably image/wmf and = image/emf rather than the x- versions.

With all = this said, I am not resolutely opposed to making the x- versions the = default. Yet as I said above, that means that the non x- versions would = be =93deprecated alias types=94 and that just does not seem to make = sense.

Respectfully = submitted,

Sean
= --Apple-Mail=_B4D2A592-4FF7-4F21-8109-83F4D66B6661-- --Apple-Mail=_25C6203C-5058-48C5-926B-8446105CB14F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO7TCCBJ0w ggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsG AQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlfsXzw PlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1ctxE +2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj2iC0 o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRowggQCoAMCAQICEG0Z 6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZp cnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAw NTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdC lOD5J3EHxcZppLkyxPFAGpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh3 37EXrMLaggLW1DJq1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJA AVtIaN3FSrTg7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJy ZCaRTqWSD//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOC AUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VU Ti1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEE aDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1G1rF0q0bc24+6SZ85kyY wTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA8XV6L566k3nK/uKRHlZ0sviN 0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6 PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrR eTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqT PDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0EwHhcNMTMxMTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J 9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2g uKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G 53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia33JN+ oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50 ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMf WE2/5myX518DB+kTa5iQDbKYRuJp3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmI H4kfI4LWrY8XrPhlX3JmHjD6hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3 jx9VF/gA3vqYpL+jNumInz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d 9ljRDEiAts5OopkeeFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYID rjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MTExNDE2MDIxMlowIwYJKoZIhvcNAQkEMRYEFIYUjrkKG7DeLvkgW0uCSDfa PtzZMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQDKkzwxu6lupsyQvhKSvQd8MIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcNAQEBBQAE ggEAfSKlUjGMqBZg58oiX1cmFO/HncjDhZo+0Cbc3m6ScWTlmDOEXV0disCRHDVe3Pv+FWX1DNG3 b1Gy17j1k46BG0iRJL2vRWQN3IKbogiD8NXX4zyBV7kmXvi/H5fsbTyNoqGEJNpsFX6og9PHOv7K a7ms1SJaPIyOtjgiiRiPiM4Wi7/DZmervS5vkbAdGIRlOa++6EVbQZemDQaUfnueKVin64qoZ8pS uNx2kxW1X9+g9ZbjwzIOZnngUH+YYTZPlQP7amfTnxIIz5F5K5H82LZmf1AfeZxZM/u3BvSEqY0g vNTN1akCBDXua/NugF5hV2KlJV386bHA7/6kvO8powAAAAAAAA== --Apple-Mail=_25C6203C-5058-48C5-926B-8446105CB14F-- From nobody Fri Nov 14 09:11:52 2014 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 65C691A8A89 for ; Thu, 13 Nov 2014 08:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkHq7o3pw-im for ; Thu, 13 Nov 2014 08:37:25 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014EE1A8A93 for ; Thu, 13 Nov 2014 08:37:25 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id lj1so15528175pab.36 for ; Thu, 13 Nov 2014 08:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=LT3Wcj0zFwdn7xXHAwlwIspfEq/rVzP7b72kRNgxyeM=; b=yO0buoSInhx8OXXEV4eqZ9KBUpyeZv0Rtg6xFTDirBVUJndKFLCt7ZEYVZYutEP68i +7ldGlSZV37eeHRHiXleaF/39gaLc4vHYHqFVCANWAlzsR4ge4P54Dse49WHOVW61U8d 9Da5RJ2Qwg3q8RibI4pBocS4hZ5CV7nJW9n0t2C1TCM/0hWEUBBokKKIHFKpJN3Rjw0J CCklfnK3M6gOO7TBdFrd5j501dPb7pdoVwtezrOC532aFx7p3OL98G5EqAmNBDt1Xc/q pzyQUwHjurCHIMJsjWLgRQlMVbvFw2zx9LjdKGaS0OAR6yVXA1wmZ0AoAh+YVTru/4yX RTrQ== X-Received: by 10.68.69.6 with SMTP id a6mr3084762pbu.163.1415896644249; Thu, 13 Nov 2014 08:37:24 -0800 (PST) Received: from [192.168.0.6] (ip70-176-14-71.ph.ph.cox.net. [70.176.14.71]) by mx.google.com with ESMTPSA id r4sm25259711pdm.93.2014.11.13.08.37.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 08:37:23 -0800 (PST) From: "Adam W. Montville" Content-Type: multipart/alternative; boundary="Apple-Mail=_4B9CC216-CB17-4CDC-9667-C6D15AD3D640" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Date: Thu, 13 Nov 2014 09:37:20 -0700 References: To: ht@inf.ed.ac.uk X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zOHofBj7DB1vTfLrCRzAXDrnYAE X-Mailman-Approved-At: Fri, 14 Nov 2014 09:11:36 -0800 Cc: Takeshi Takahashi , draft-ietf-mile-enum-reference-format.all@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Fwd: Should IODEF Enumeration Reference Format request IANA to create redirect URIs? 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, 13 Nov 2014 16:37:28 -0000 --Apple-Mail=_4B9CC216-CB17-4CDC-9667-C6D15AD3D640 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Henry, Thanks again for your early appsdir review of the IODEF Enumeration = Reference Format. There is an open question that has been posted to the = MILE list regarding one of your issues with the draft. =20 How strongly do you feel that the Enum Ref draft should request that = IANA provide redirect URIs? The discussion during the MILE session this = week was strongly against for a variety of reasons - creating work for = IANA and operational utility of a redirect to a specification for each = identified enumeration value (there are tens of thousands of identified = elements in some cases, and this is likely to grow substantially over = time). We are preparing to advance this draft and would appreciate your quick = comments on the above. Regards, Adam > Begin forwarded message: >=20 > From: "Adam W. Montville" > Subject: Should IODEF Enumeration Reference Format request IANA to = create redirect URIs? > Date: November 10, 2014 at 4:36:43 PM MST > To: MILE IETF >=20 > The other open issue that David covered during today=E2=80=99s session = was whether the IODEF Enumeration Reference Format should request that = IANA provide redirect URIs for each entry. >=20 > An early AppsDir review suggested that this be the case, such that = every referenced enumeration would ultimately redirect to the correct = specification as such: = http://www.iana.org/assignments/enumeration-reference-type/CXI_2.5 = >=20 > The overall sense in the room was that this would NOT be a good idea = and would cause unnecessary work. >=20 > Open question: Does anyone strongly believe that the IODEF Enumeration = Reference Format request IANA to create redirect URIs? >=20 > Please provide your opinion by November 24th. >=20 > Regards, >=20 > Adam --Apple-Mail=_4B9CC216-CB17-4CDC-9667-C6D15AD3D640 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Henry,

Thanks again for your early appsdir review of the IODEF = Enumeration Reference Format.  There is an open question that has = been posted to the MILE list regarding one of your issues with the = draft.  

How strongly do you feel that the Enum Ref draft should = request that IANA provide redirect URIs?  The discussion during the = MILE session this week was strongly against for a variety of reasons - = creating work for IANA and operational utility of a redirect to a = specification for each identified enumeration value (there are tens of = thousands of identified elements in some cases, and this is likely to = grow substantially over time).

We are preparing to advance this draft = and would appreciate your quick comments on the above.

Regards,

Adam

Begin forwarded message:

From: = "Adam W. Montville" <adam.w.montville@gmail.com>
Subject: = Should IODEF = Enumeration Reference Format request IANA to create redirect = URIs?
Date: = November 10, 2014 at 4:36:43 PM = MST
To: = MILE IETF <mile@ietf.org>

The other open = issue that David covered during today=E2=80=99s session was whether the = IODEF Enumeration Reference Format should request that IANA provide = redirect URIs for each entry.

An early AppsDir review suggested that this be the case, such = that every referenced enumeration would ultimately redirect to the = correct specification as such: http://www.iana.org/assignments/enumeration-reference-type/CXI_= 2.5

The = overall sense in the room was that this would NOT be a good idea and = would cause unnecessary work.

Open question: Does anyone strongly = believe that the IODEF Enumeration Reference Format request IANA to = create redirect URIs?

Please provide your opinion by November 24th.

Regards,

Adam

= --Apple-Mail=_4B9CC216-CB17-4CDC-9667-C6D15AD3D640-- From nobody Fri Nov 14 09:16:58 2014 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 5E6C21A1AF5 for ; Fri, 14 Nov 2014 09:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTmDIruAoP96 for ; Fri, 14 Nov 2014 09:16:37 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327001A1B21 for ; Fri, 14 Nov 2014 09:16:25 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so3346625wib.11 for ; Fri, 14 Nov 2014 09:16:14 -0800 (PST) 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=xOoZdPWiP5zJl87DMuaoXSD2DBZzXs/NSrhKQCgXwE0=; b=K4kiAMnODGrKFL21A3uNBfX+6/IhFy4Q8ZKPzLSDVICNyK9U/4Wkg4q6BaDdBopLen VUHXihCydwfUnIYVq8qrVy7O3X1uewmhDGXPr4dqRWYZbpa3bWoeQs9oBbf8pXl7DQbz pvkhbqrpW8sIaXXtOSnPgKlbXJu8yPJUbNJMpO2XiToAENtVgUTriD8a93YKMDPeURW8 0lTL6lynnq11ZPGMnT73YczYNlHyp3H/q9BnfT7XIXpUmDvwPkGVe/4MObLj27SFkdz7 Q71eggZdHElCuhoKKexpce86PwxbAKOnpC3qdqaUdIGkQz+cLsM5YpU+2fqkxLPRLixI fGzA== MIME-Version: 1.0 X-Received: by 10.194.143.7 with SMTP id sa7mr16012155wjb.110.1415985373712; Fri, 14 Nov 2014 09:16:13 -0800 (PST) Received: by 10.27.76.134 with HTTP; Fri, 14 Nov 2014 09:16:13 -0800 (PST) Date: Fri, 14 Nov 2014 07:16:13 -1000 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0115e73236b63e0507d4c999 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2EsKDngiJ2FZrvtUEvHlAAl_gxg Subject: [apps-discuss] arcmedia list has been created 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, 14 Nov 2014 17:16:41 -0000 --089e0115e73236b63e0507d4c999 Content-Type: text/plain; charset=UTF-8 A new mailing list has been created as a result of the arcmedia BoF yesterday. Those interested in being involved in that work are invited to subscribe: https://www.ietf.org/mailman/listinfo/arcmedia -MSK --089e0115e73236b63e0507d4c999 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A new mailing list has been created as a result of th= e arcmedia BoF yesterday.=C2=A0 Those interested in being involved in that = work are invited to subscribe:

https://www.ietf.org/mailman/listinfo/arcmedia
-MSK
--089e0115e73236b63e0507d4c999-- From nobody Sat Nov 22 07:36:57 2014 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 769BA1ACC87 for ; Sat, 22 Nov 2014 07:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 iHFfXjDK388T for ; Sat, 22 Nov 2014 07:36:55 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8F11AC82C for ; Sat, 22 Nov 2014 07:36:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3D90141C2D7 for ; Sat, 22 Nov 2014 10:36:54 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoX-UuW6BYFJ for ; Sat, 22 Nov 2014 10:36:54 -0500 (EST) Received: from [10.0.1.25] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id B826141C2C7 for ; Sat, 22 Nov 2014 10:36:53 -0500 (EST) Date: Sat, 22 Nov 2014 10:36:52 -0500 From: Cyrus Daboo To: IETF Apps Discuss Message-ID: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=993 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4xhIHMn3sV_QzKRqZF8QQMxzoOc Subject: [apps-discuss] ietf-appsawg-http-problem 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, 22 Nov 2014 15:36:56 -0000 Hi, I recently added a normative reference to ietf-appsawg-http-problem in draft-ietf-tzdist-service-03. I know the chairs of TZDIST are keen to complete work on that draft and send it to the IESG, but of course we will want ietf-appsawg-http-problem to progress too. So what is the status of that draft in appsawg? I did not that Murray had asked for a shepherd - if none has been assigned I am happy to volunteer to do that to help move it along. However, I do have one issue with the current draft: the TZDIST protocol is primarily a non-human HTTP protocol. tzdist defines its own set of error codes (e.g., "invalid-start", "tzid-not-found", etc) to better identify problems in requests. However, http-problem only defines a "type" member that is a URI that references a "human-readable" resource. As a result I added an "error-code" member for the tzdist specific codes. I wonder if it makes sense to include that in http-problem to cover similar use cases? -- Cyrus Daboo From nobody Sat Nov 22 19:34:08 2014 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 4435A1A1A83 for ; Sat, 22 Nov 2014 19:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zws6Lbp5ZaWA for ; Sat, 22 Nov 2014 19:34:00 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE84A1A0130 for ; Sat, 22 Nov 2014 19:33:59 -0800 (PST) Received: from [192.168.1.73] (unknown [118.209.79.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A14EB509B5; Sat, 22 Nov 2014 22:33:55 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: Date: Sun, 23 Nov 2014 14:33:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <68CDCC24-7A32-4B41-BBE7-428998D2D4C7@mnot.net> References: To: Cyrus Daboo X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Tr74b0TR7cGod97IN1STW7SXYdM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ietf-appsawg-http-problem 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, 23 Nov 2014 03:34:04 -0000 > On 23 Nov 2014, at 2:36 am, Cyrus Daboo wrote: >=20 > Hi, > I recently added a normative reference to ietf-appsawg-http-problem in = draft-ietf-tzdist-service-03. I know the chairs of TZDIST are keen to = complete work on that draft and send it to the IESG, but of course we = will want ietf-appsawg-http-problem to progress too. So what is the = status of that draft in appsawg? I did not that Murray had asked for a = shepherd - if none has been assigned I am happy to volunteer to do that = to help move it along. I think Alexey is shepherding. > However, I do have one issue with the current draft: the TZDIST = protocol is primarily a non-human HTTP protocol. tzdist defines its own = set of error codes (e.g., "invalid-start", "tzid-not-found", etc) to = better identify problems in requests. However, http-problem only defines = a "type" member that is a URI that references a "human-readable" = resource. Well, that=E2=80=99s a guideline. A bit of text that allows = machine-readable responses too =E2=80=94 whether that be HTML micro data = or another format via conneg =E2=80=94 might help. All of that said, what=E2=80=99s your use case for a machine readable = response? Fetching the error resources at runtime seems like a bad = practice, as it=E2=80=99s going to cause load on the server, as well as = more chances for failure... > As a result I added an "error-code" member for the tzdist specific = codes. I wonder if it makes sense to include that in http-problem to = cover similar use cases? That seems like an anti-pattern; having two identifiers for the same = thing leads to problems. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Sun Nov 23 08:21:00 2014 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 A563A1A0378 for ; Sun, 23 Nov 2014 08:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] 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 rmGh1NNfiNGl for ; Sun, 23 Nov 2014 08:20:56 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 047F31A0382 for ; Sun, 23 Nov 2014 08:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1416759650; d=isode.com; s=selector; i=@isode.com; bh=fSNGZ1wq8P+aMI5QEP2sGVsgof3oIm3n6Ac92MvQmTI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HAPmnVuui7fmfzKMyC65CF0UID8rsNg5WcIm1cw/9HX6F0btA44NED9e50h00nZ0G57Knp gZzAZutHHYkn+HRLphEebKtS1adY6NkkPnsIFDHT5IKmA06YUoGZtp4ipVUqcLOwPpc+Yi 4LvN8/+HOQ/eoMRF1vPKQMzUFeudOms=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Nov 2014 16:20:48 +0000 Message-ID: <5472095B.90403@isode.com> Date: Sun, 23 Nov 2014 16:20:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: "apps-discuss@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xvfWiBFCzVd0-7oxc8C9ymHRjV0 Subject: [apps-discuss] Preliminary IETF 91 minutes posted 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, 23 Nov 2014 16:20:57 -0000 http://www.ietf.org/proceedings/91/minutes/minutes-91-appsawg Thank you to John Levine for taking notes. Let me know if anything is missing or inaccurate. From nobody Sun Nov 23 10:59:10 2014 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 1B4911A1A33; Sun, 23 Nov 2014 10:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 WthZAcgfg-vF; Sun, 23 Nov 2014 10:59:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B81A1A47; Sun, 23 Nov 2014 10:59:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141123185906.26239.51497.idtracker@ietfa.amsl.com> Date: Sun, 23 Nov 2014 10:59:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/c7g9bODe7yLJvW8jK105DmExjLk Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 18:59:08 -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 : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-06.txt Pages : 12 Date : 2014-11-23 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 23 11:04:42 2014 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 CEE821A1A34 for ; Sun, 23 Nov 2014 11:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[J_CHICKENPOX_15=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 YS2P5LK9qzIr for ; Sun, 23 Nov 2014 11:04:39 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0687.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:687]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6321A1A25 for ; Sun, 23 Nov 2014 11:04:38 -0800 (PST) Received: from DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) by DM2PR0201MB0912.namprd02.prod.outlook.com (25.160.215.28) with Microsoft SMTP Server (TLS) id 15.1.16.15; Sun, 23 Nov 2014 19:04:16 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) with Microsoft SMTP Server (TLS) id 15.1.16.15; Sun, 23 Nov 2014 19:04:15 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0016.006; Sun, 23 Nov 2014 19:04:15 +0000 From: Larry Masinter To: Ned Freed , Salvatore Loreto Thread-Topic: response to WG last call comments for draft-ietf-appsawg-multipart-form-data Thread-Index: AdAHS1WFtCoQz8PzSAyDi7M3X4NQPQ== Date: Sun, 23 Nov 2014 19:04:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:9456:7c8:b58c:ecfb] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0958;UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0958; x-forefront-prvs: 04041A2886 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(377454003)(51444003)(51704005)(189002)(229853001)(101416001)(2656002)(106356001)(107046002)(46102003)(4396001)(99286002)(54356999)(92566001)(105586002)(31966008)(50986999)(33646002)(19580395003)(15975445006)(87936001)(230783001)(108616004)(15395725005)(120916001)(99396003)(86362001)(15202345003)(21056001)(77096003)(77156002)(62966003)(122556002)(40100003)(97736003)(74316001)(95666004)(76576001)(64706001)(20776003)(3826002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0958; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0912; X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Y7llvd3h4bDm9AnhQUZJZR1Seko Cc: Sam Ruby , IETF Apps Discuss Subject: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data 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, 23 Nov 2014 19:04:41 -0000 DQpJJ3ZlIHRyaWVkIHRvIGFkZHJlc3MgIFdHIGxhc3QgY2FsbCBjb21tZW50cywgYW5kIHN1Ym1p dHRlZA0KYSBuZXcgdmVyc2lvbiAod2l0aCBhIGZldyBlZGl0b3JpYWwgY2xhcmlmaWNhdGlvbnMg dG9vKS4NCg0KSSdkIGxpa2Ugc3VnZ2VzdGlvbnMgZm9yIGhvdyB0byBhZGRyZXNzIHRoZSByZXF1 ZXN0IGZvciAnc3Ryb25nZXInDQogc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIChTZWUgYmVsb3cp DQo9PT09PQ0KPiBOZWQgRnJlZWQgU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA2LCAyMDE0IDg6 MDIgQU0NCg0KPiBUaGUgd29yZGluZyBpbiBzZWN0aW9uIDUuMSBpcyBhIGxpdHRsZSBvZGQuIFF1 b3RlcyBhcmUgb25seSByZXF1aXJlZA0KPiBhcm91bmQgcGFyYW1ldGVyIHZhbHVlcyB3aGVuIGEg dHNwZWNpYWwgY2hhcmFjdGVyIGlzIHByZXNlbnQuIEJ1dCB0aGUNCj4gd2F5IHRoaXMgc2VjdGlv biBpcyB3b3JkZWQgbWFrZXMgaXQgc291bmQgbGlrZSBwYXJhbWV0ZXJzIGFsd2F5cyBoYXZlIHRv IGJlDQo+IHF1b3RlZCBhbmQgc3lzdGVtcyB0aGF0IGVtaXQgYW4gdW5xdW90ZWQgcGFyYW1ldGVy IGFyZSBkb2luZw0KPiBzb21ldGhpbmcgdGhhdCdzIGF0IGEgbWluaW11bSB3aWVyZCBpZiBub3Qg ZG93bnJpZ2h0IGluY29ycmVjdC4gSSBkb24ndCBoYXZlDQo+IGFsdGVybmF0ZSB3b3JkaW5nIHRv IHN1Z2dlc3QsIGJ1dCBzb21lIGNsYXJpZmljYXRpb24gd291bGQgYmUgZ29vZC4NCg0KSSB3b3Vu ZCB1cCByZXdyaXRpbmcgdGhpcyB0byBlbGltaW5hdGUgdGhlIGNvbmZ1c2luZyB0ZXh0LCBhbmQg anVzdA0KYmUgY2xlYXJlciB0aGF0IG11bHRpcGFydC9mb3JtLWRhdGEgZm9sbG93cyBtdWx0aXBh cnQgcnVsZXMgaGVyZS4NCg0KPiBJIHF1ZXN0aW9uIHRoZSBuZWVkIHRvIHJlZmVyZW5jZSBSRkMg MTgwNiBpbiBzZWN0aW9uIDUuMi4gUkZDIDIxODMgIGlzDQo+IHRoZSBzdGFuZGFyZHMtdHJhY2sg c3BlY2lmaWNhdGlvbiBvZiBjb250ZW50LWRpc3Bvc2l0aW9uIHdoaWNoIHJlcGxhY2VkIHRoZQ0K PiBleHBlcmltZW50YWwgUkZDIDE4MDYuIChPVE9ILCB0aGUgZG9jdW1lbnRzIHNheSB0aGF0IFJG QyAyMTgzDQo+IHVwZGF0ZXMgUkZDIDE4MDY7IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgaXQgZGlk bid0IG9ic29sZXRlIGl0LiBTbyBtYXliZSB0aGVyZSdzIHNvbWUNCj4gbmVlZCB0byByZWZlcmVu Y2UgaXQuLi4pDQoNCkkgdG9vayBvdXQgdGhlIHJlZmVyZW5jZSB0byAxODA2LCBJIGRvbid0IHRo aW5rIGl0J3MgbmVlZGVkLg0KDQo+IFNlY3Rpb24gNS4yIG1ha2VzIHVzZSBvZiB0aGUgY29udGVu dC1kaXNwb3NpdGlvbiAibmFtZSIgcGFyYW1ldGVyLg0KPiBXaGVuIEkgY2hlY2tlZCB0aGUgSUFO QSByZWdpc3RyeSBmb3IgdGhpcyBwYXJhbWV0ZXINCj4gKGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvY29udC1kaXNwL2NvbnQtZGlzcC54aHRtbCNjb250LQ0KPiBkaXNwLTIpIEkgbm90 aWNlZCBzb21ldGhpbmcgb2RkOiBUaGUgcGFyYW1ldGVyIGlzIHN1cHBvc2VkbHkgZGVmaW5lZCBp biBSRkMNCj4gMjM4OCwgd2hpY2ggaXMgdGhlIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGlzIGRvY3Vt ZW50LiBNb3Jlb3ZlciwgUkZDIDIzODgganVzdCB0YWxrcw0KPiBhYm91dCB0aGUgcGFyYW1ldGVy LCBpdCBkb2Vzbid0IGFjdHVhbGx5IHNheSBpdCByZWdpc3RlcnMgaXQuDQo+IA0KPiBJIHN1Z2dl c3QgYWRkaW5nIGFwcHJvcHJpYXRlIHJlZ2lzdHJhdGlvbiB0ZXh0IHRvIHRoZSBJQU5BIENvbnNp ZGVyYXRpb25zDQo+IHNlY3Rpb24gYW5kIHVwZGF0aW5nIHRoZSByZWdpc3RyeSB0byBwb2ludCB0 byB0aGlzIGRvY3VtZW50Lg0KDQpEb25lLg0KDQo+IFNlY3Rpb24gNS45IHRhbGtzIGFib3V0IHdo YXQgTUlNRSBmaWVsZHMgYXJlIHN1cHBvcnRlZCBpbiBmb3JtIGRhdGENCj4gcGFydHMsIGJ1dCBk b2Vzbid0IGdvIHNvIGZhciBhcyB0byBzYXkgdGhleSBNVVNUIE5PVCBiZSBwcmVzZW50LiBJdCBt aWdodCBiZQ0KPiBhIGdvb2QgdGhpbmcgdG8gY2xhcmlmeSB3aGV0aGVyIHRoZXkgYXJlIHNpbXBs eSBpZ25vcmVkIGlmIHByZXNlbnQgb3INCj4gd2hldGhlciB0aGV5IG1pZ2h0IGFjdHVhbGx5IHNj cmV3IHRoaW5ncyB1cCBpZiB5b3UgaW5jbHVkZSB0aGVtLg0KDQpCZWx0ICYgc3VzcGVuZGVyczog SSBzcGVjJ2QgTVVTVCBOT1QgYmUgc2VudCBhbmQgTVVTVCBiZSBpZ25vcmVkLg0KDQo+IFNlY3Rp b24gOCBhbmQvb3IgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHNlY3Rpb24gOSBwcm9i YWJseSBzaG91bGQNCj4gc2F5IHNvbWV0aGluZyBhYm91dCBwcml2YWN5IGFuZCBpbnRlZ3JpdHkg cHJvdGVjdGlvbiBmb3IgZm9ybSBkYXRhLg0KDQoqKioqIEknbSBub3Qgc3VyZSB3aGF0IHRvIHNh eSwgc3VnZ2VzdGlvbnM/ICoqKioNCiANCj4gQWxsIG1lZGlhIHR5cGVzIGFyZSBzdXBwb3NlZCB0 byBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB0aGV5IGludm9sdmUNCj4gZXhlY3V0YWJsZSBjb250ZW50 LCBzbyB0aGlzIG5lZWRzIHRvIGJlIG1lbnRpb25lZCBpbiBzZWN0aW9uIDkuDQoNCkFkZGVkIGEg bm90ZS4NCg0KDQo9PT09PT09PT09PT09PT0NCkZyb20gdC5wZXRjaCA3IE5vdiAyMDE0DQoNClR5 cG9zIGZpeGVkLg0KDQo+ICcgcmVzdHJpY3RpbmcgZmllbGQgbmFtZXMgdG8gQVNDSUkgIHdpbGwg aGVscCBhdm9pZCBzb21lIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLicNCj4gd29ydGggbWFraW5n IGEgU0hPVUxEPw0KDQpUaGVyZSdzIGEgc2VjdGlvbiBvbiBub24tYXNjaWkgZmllbGQgbmFtZXMg SSByZWZlcmVuY2VkIA0KDQo+IHMuNS4zDQo+IFNob3VsZCB0aGVyZSBiZSBhIHJlZmVyZW5jZSBm b3IgJyJmaWxlOiIgVVJJJyBvciBoYXMgdGhhdCBiZWVuIG9taXR0ZWQNCj4gYmVjYXVzZSB0aGVy ZSBpcyBubyBnb29kIG9uZTotKA0KDQpUaGVyZSBpcyBubyBnb29kIG9uZS4gIFRoZSBtb3N0IHJl Y2VudCBhbmQgKElNTyBwcm9taXNpbmcpIHRha2UgaXMNCmh0dHA6Ly9pbnRlcnR3aW5nbHkubmV0 L3Byb2plY3RzL3BlZ3VybC91cmwuaHRtbCNmaWxlLXVybCAgYnV0IHRoYXQncw0Kbm90IHJlYWR5 IHlldC4NCg0KSSBkaWQgYWRkIGFuIGV4cGxpY2l0IG5vdGUgbm90IHRvIGZvbGxvdyBSRkMgNTk4 NyAoY29udGVudC1kaXNwb3NpdGlvbg0KSW4gSFRUUCkgYmVjYXVzZSBldmVuIHRob3VnaCBtdWx0 aXBhcnQvZm9ybS1kYXRhIGlzIHR5cGljYWxseSBzZW50DQpieSBIVFRQIHdpdGggUE9TVCwgSSBk b24ndCB0aGluayBhbnlvbmUgYWRkcyBhICdmaWxlbmFtZSonIHBhcmFtZXRlci4NCkkgcmV3b3Jk ZWQgJ2dlbmVyYWxseSB0aGUgd2F5IHRoYXQgYSAiZmlsZToiIFVSSSB3b3VsZCBiZSBlbmNvZGVk Jw0KDQo+IHMuOA0KPiBJIHRoaW5rIHRoYXQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNo b3VsZCBiZSBzdHJvbmdlciBhYm91dA0KPiBwcm90ZWN0aW5nIHRoZSBwcml2YWN5IG9mIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbg0KDQpOZWQgbWFkZSBhIHNpbWlsYXIgY29tbWVudCBidXQgSSdt IG5vdCBzdXJlIHdoYXQgdG8gYWRkLg0KSSBtb3ZlZCBhIHNlbnRlbmNlIGZyb20gdGhlIHRlbXBs YXRlIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0Kc2VjdGlvbiwgYnV0IEkgZG9uJ3Qg aGF2ZSBhbnkgZ29vZCBpZGVhcyBob3cgdG8gbWFrZSBpdCAnc3Ryb25nZXInLiANCg0KPiBUaGUg cmVnaXN0cmF0aW9uIGhhcyB0d28gcmVmZXJlbmNlcyB0byB0aGlzIGRvY3VtZW50IC0gdGhlc2Ug c2hvdWxkDQo+IHByb2JhYmx5IGJlIGNhbGxlZCBvdXQgYXMgUkZDeHh4eCB3aXRoIHRoZSB1c3Vh bCBub3RlIHRvIHJlcGxhY2UgeHh4eA0KPiB3aXRoIHRoZSBSRkMgbnVtYmVyDQoNClRoZSBtZWRp YSB0eXBlIHJlZ2lzdHJ5IHBvaW50cyB0byB0aGlzIGRvY3VtZW50IGZvciB0aGUgdGVtcGxhdGUu DQpJdCBkb2Vzbid0IGNvcHkgdGhlIHJlZ2lzdHJhdGlvbiwgc28gc2FtZS1kb2N1bWVudCByZWZl cmVuY2VzIGFyZWEgT0suDQoNCg0K From nobody Tue Nov 25 04:59:49 2014 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 E13BF1A0262 for ; Tue, 25 Nov 2014 04:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, 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 7IVnvgzs71_P for ; Tue, 25 Nov 2014 04:59:46 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::797]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D411A0263 for ; Tue, 25 Nov 2014 04:59:46 -0800 (PST) Received: from pc6 (86.184.62.161) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 12:56:40 +0000 Message-ID: <05aa01d008af$4c22ea40$4001a8c0@gateway.2wire.net> From: t.petch To: Larry Masinter , Ned Freed , Salvatore Loreto References: Date: Tue, 25 Nov 2014 12:56:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: AM3PR03CA019.eurprd03.prod.outlook.com (10.141.191.147) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(7)(6); SRVR:AMXPR07MB053; X-Forefront-PRVS: 040655413E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51444003)(51704005)(13464003)(199003)(189002)(50466002)(95666004)(66066001)(105586002)(106356001)(31966008)(14496001)(107046002)(44716002)(62236002)(101416001)(23756003)(40100003)(47776003)(20776003)(116806002)(61296003)(64706001)(42186005)(230783001)(102836001)(104166001)(92726001)(551934003)(92566001)(21056001)(50986999)(81816999)(81686999)(33646002)(99396003)(15202345003)(15395725005)(76176999)(84392001)(19580405001)(19580395003)(15975445006)(120916001)(87286001)(97736003)(46102003)(86362001)(62966003)(93916002)(77096003)(77156002)(88136002)(50226001)(4396001)(89996001)(1556002)(87976001)(122386002)(44736004)(1456002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1Q9nvjgRIvsKhnK3Xmz9kxAloC8 Cc: IETF Apps Discuss , Sam Ruby Subject: Re: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data 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, 25 Nov 2014 12:59:49 -0000 Looks good. On security, my thinking is that a form can be used to solicit data which is confidential, personal or which might be damaging if revealed to a wider audience or modified in transit. I think that most of the 'Security with everything' proposals are misplaced and that encrypting every client-server transaction gives a worse service, not worth any increase in the quality of the data. Here, however, I think we should call out the obvious and say that where the data is or should be confidential, then suitably strong encryption should be used; and, much harder to achieve, the client should authenticate the server before sending any data. Something along those lines. Tom Petch ----- Original Message ----- From: "Larry Masinter" To: "Ned Freed" ; "Salvatore Loreto" Cc: "Sam Ruby" ; "IETF Apps Discuss" Sent: Sunday, November 23, 2014 7:04 PM Subject: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data > > I've tried to address WG last call comments, and submitted > a new version (with a few editorial clarifications too). > > I'd like suggestions for how to address the request for 'stronger' > security considerations. (See below) > ===== > > Ned Freed Sent: Thursday, November 06, 2014 8:02 AM > > > The wording in section 5.1 is a little odd. Quotes are only required > > around parameter values when a tspecial character is present. But the > > way this section is worded makes it sound like parameters always have to be > > quoted and systems that emit an unquoted parameter are doing > > something that's at a minimum wierd if not downright incorrect. I don't have > > alternate wording to suggest, but some clarification would be good. > > I wound up rewriting this to eliminate the confusing text, and just > be clearer that multipart/form-data follows multipart rules here. > > > I question the need to reference RFC 1806 in section 5.2. RFC 2183 is > > the standards-track specification of content-disposition which replaced the > > experimental RFC 1806. (OTOH, the documents say that RFC 2183 > > updates RFC 1806; I don't understand why it didn't obsolete it. So maybe there's some > > need to reference it...) > > I took out the reference to 1806, I don't think it's needed. > > > Section 5.2 makes use of the content-disposition "name" parameter. > > When I checked the IANA registry for this parameter > > (http://www.iana.org/assignments/cont-disp/cont-disp.xhtml#cont- > > disp-2) I noticed something odd: The parameter is supposedly defined in RFC > > 2388, which is the earlier version of this document. Moreover, RFC 2388 just talks > > about the parameter, it doesn't actually say it registers it. > > > > I suggest adding appropriate registration text to the IANA Considerations > > section and updating the registry to point to this document. > > Done. > > > Section 5.9 talks about what MIME fields are supported in form data > > parts, but doesn't go so far as to say they MUST NOT be present. It might be > > a good thing to clarify whether they are simply ignored if present or > > whether they might actually screw things up if you include them. > > Belt & suspenders: I spec'd MUST NOT be sent and MUST be ignored. > > > Section 8 and/or the security considerations in section 9 probably should > > say something about privacy and integrity protection for form data. > > **** I'm not sure what to say, suggestions? **** > > > All media types are supposed to state whether or not they involve > > executable content, so this needs to be mentioned in section 9. > > Added a note. > > > =============== > From t.petch 7 Nov 2014 > > Typos fixed. > > > ' restricting field names to ASCII will help avoid some interoperability issues.' > > worth making a SHOULD? > > There's a section on non-ascii field names I referenced > > > s.5.3 > > Should there be a reference for '"file:" URI' or has that been omitted > > because there is no good one:-( > > There is no good one. The most recent and (IMO promising) take is > http://intertwingly.net/projects/pegurl/url.html#file-url but that's > not ready yet. > > I did add an explicit note not to follow RFC 5987 (content-disposition > In HTTP) because even though multipart/form-data is typically sent > by HTTP with POST, I don't think anyone adds a 'filename*' parameter. > I reworded 'generally the way that a "file:" URI would be encoded' > > > s.8 > > I think that the Security Considerations should be stronger about > > protecting the privacy of confidential information > > Ned made a similar comment but I'm not sure what to add. > I moved a sentence from the template to the Security Considerations > section, but I don't have any good ideas how to make it 'stronger'. > > > The registration has two references to this document - these should > > probably be called out as RFCxxxx with the usual note to replace xxxx > > with the RFC number > > The media type registry points to this document for the template. > It doesn't copy the registration, so same-document references area OK. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Nov 25 11:57:53 2014 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 36BF01A0367 for ; Tue, 25 Nov 2014 11:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gv_lXOzYEHG for ; Tue, 25 Nov 2014 11:56:29 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED5A1A6EED for ; Tue, 25 Nov 2014 11:56:28 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so10262080wiv.17 for ; Tue, 25 Nov 2014 11:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=D+iRU+J7a9KKfq+HUUv2JcNBjm++YMEBzOfzBUAD2zQ=; b=zT6Lr1jlvmNbVWDTW941KLyhpCluhy2i1RYrEwHlwNDULbVEQLxVkyXhHfm4Ief2ex A9pM0GzMOAGacqRV3hzhSHHlOBrVkivM6ab99kP84Xli/3WK5sHjHhT+os8PIqDDuefW vaIkxbTihV8UfjmTeyB21UoEsa23cTEOgxUMEiY7vyR4XDYg0iVhL3lYzcZjntIouiDw h+8waNjnL8df7+xvvkIarBCd0N2wKcb3hcDq7qftC4cf6wW4xPq+H0wIna4io23Z7lY4 yFeDgbHBQ+N0LqX6RSfnzVI7fZLpyCB16IhScXJdsbvjIZZZjPrBFb+Na+FEPBWUyr/c ha9A== MIME-Version: 1.0 X-Received: by 10.181.8.98 with SMTP id dj2mr21806997wid.81.1416945387429; Tue, 25 Nov 2014 11:56:27 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 25 Nov 2014 11:56:27 -0800 (PST) In-Reply-To: <20140911173054.27154.22464.idtracker@ietfa.amsl.com> References: <20140911173054.27154.22464.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 11:56:27 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1135e41e7be4bb0508b44eb1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sjPBrPIxjl83jvlU9RjynmD7Jw4 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-00.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: Tue, 25 Nov 2014 19:56:32 -0000 --001a1135e41e7be4bb0508b44eb1 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 11, 2014 at 10:30 AM, 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 : Message Disposition Notification > Authors : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-mdn-3798bis-00.txt > Pages : 32 > Date : 2014-09-11 > > Abstract: > This memo defines a MIME content-type that may be used by a mail user > agent (MUA) or electronic mail gateway to report the disposition of a > message after it has been successfully delivered to a recipient. > This content-type is intended to be machine-processable. Additional > message header fields are also defined to permit Message Disposition > Notifications (MDNs) to be requested by the sender of a message. The > purpose is to extend Internet Mail to support functionality often > found in other messaging systems, such as X.400 and the proprietary > "LAN-based" systems, and often referred to as "read receipts," > "acknowledgements", or "receipt notifications." The intention is to > do this while respecting privacy concerns, which have often been > expressed when such functions have been discussed in the past. > > Because many messages are sent between the Internet and other > messaging systems (such as X.400 or the proprietary "LAN-based" > systems), the MDN protocol is designed to be useful in a multi- > protocol messaging environment. To this end, the protocol described > in this memo provides for the carriage of "foreign" addresses, in > addition to those normally used in Internet Mail. Additional > attributes may also be defined to support "tunneling" of foreign > notifications through Internet Mail. > There's been no activity on this draft since it was posted. Are there any issues to be addressed, or are we ready for Working Group Last Call as-is? -MSK --001a1135e41e7be4bb0508b44eb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 11, 2014 at 10:30 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Applications Area Working Group Work= ing Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Disposition Notification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tony= Hansen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alexey Melnikov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-mdn-3798bis-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-09-11

Abstract:
=C2=A0 =C2=A0This memo defines a MIME content-type that may be used by a ma= il user
=C2=A0 =C2=A0agent (MUA) or electronic mail gateway to report the dispositi= on of a
=C2=A0 =C2=A0message after it has been successfully delivered to a recipien= t.
=C2=A0 =C2=A0This content-type is intended to be machine-processable.=C2=A0= Additional
=C2=A0 =C2=A0message header fields are also defined to permit Message Dispo= sition
=C2=A0 =C2=A0Notifications (MDNs) to be requested by the sender of a messag= e.=C2=A0 The
=C2=A0 =C2=A0purpose is to extend Internet Mail to support functionality of= ten
=C2=A0 =C2=A0found in other messaging systems, such as X.400 and the propri= etary
=C2=A0 =C2=A0"LAN-based" systems, and often referred to as "= read receipts,"
=C2=A0 =C2=A0"acknowledgements", or "receipt notifications.&= quot;=C2=A0 The intention is to
=C2=A0 =C2=A0do this while respecting privacy concerns, which have often be= en
=C2=A0 =C2=A0expressed when such functions have been discussed in the past.=

=C2=A0 =C2=A0Because many messages are sent between the Internet and other<= br> =C2=A0 =C2=A0messaging systems (such as X.400 or the proprietary "LAN-= based"
=C2=A0 =C2=A0systems), the MDN protocol is designed to be useful in a multi= -
=C2=A0 =C2=A0protocol messaging environment.=C2=A0 To this end, the protoco= l described
=C2=A0 =C2=A0in this memo provides for the carriage of "foreign" = addresses, in
=C2=A0 =C2=A0addition to those normally used in Internet Mail.=C2=A0 Additi= onal
=C2=A0 =C2=A0attributes may also be defined to support "tunneling"= ; of foreign
=C2=A0 =C2=A0notifications through Internet Mail.

=
There's been no activity on this draft since it was posted.= =C2=A0 Are there any issues to be addressed, or are we ready for Working Gr= oup Last Call as-is?

-MSK
--001a1135e41e7be4bb0508b44eb1-- From nobody Tue Nov 25 14:13:22 2014 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 D7F5C1A710C for ; Tue, 25 Nov 2014 14:12:00 -0800 (PST) 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 Xjj_mZUn652P for ; Tue, 25 Nov 2014 14:11:57 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0066.outbound.protection.outlook.com [65.55.169.66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9686B1A1A5F for ; Tue, 25 Nov 2014 14:11:57 -0800 (PST) Received: from BN3PR0201MB0945.namprd02.prod.outlook.com (25.160.155.25) by BN3PR0201MB0946.namprd02.prod.outlook.com (25.160.155.26) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 22:11:55 +0000 Received: from BN3PR0201MB0945.namprd02.prod.outlook.com ([25.160.155.25]) by BN3PR0201MB0945.namprd02.prod.outlook.com ([25.160.155.25]) with mapi id 15.01.0026.003; Tue, 25 Nov 2014 22:11:55 +0000 From: Larry Masinter To: t.petch , Ned Freed , Salvatore Loreto Thread-Topic: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data Thread-Index: AdAHS1WFtCoQz8PzSAyDi7M3X4NQPQBZBSktABKs9/A= Date: Tue, 25 Nov 2014 22:11:55 +0000 Message-ID: <458f822bea25443884fb24819a47fd8c@BN3PR0201MB0945.namprd02.prod.outlook.com> References: <05aa01d008af$4c22ea40$4001a8c0@gateway.2wire.net> In-Reply-To: <05aa01d008af$4c22ea40$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:cd2:64fc:938a:ccc2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB0946; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB0946; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(86362001)(31966008)(76176999)(46102003)(15975445006)(92566001)(15202345003)(54356999)(50986999)(19580395003)(108616004)(230783001)(74316001)(64706001)(4396001)(97736003)(99396003)(101416001)(105586002)(120916001)(33646002)(561944003)(20776003)(2656002)(87936001)(107046002)(106356001)(77096003)(21056001)(76576001)(95666004)(77156002)(40100003)(62966003)(122556002)(99286002)(7059030)(24736002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0201MB0946; H:BN3PR0201MB0945.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eAzFqTogXvM1Ial3oZvDhJw2sn8 Cc: IETF Apps Discuss , Sam Ruby Subject: Re: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data 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, 25 Nov 2014 22:12:01 -0000 PiBIZXJlLCBob3dldmVyLCBJIHRoaW5rIHdlIHNob3VsZCBjYWxsIG91dCB0aGUgb2J2aW91cyBh bmQgc2F5IHRoYXQNCj4gd2hlcmUgdGhlIGRhdGEgaXMgb3Igc2hvdWxkIGJlIGNvbmZpZGVudGlh bCwgdGhlbiBzdWl0YWJseSBzdHJvbmcgZW5jcnlwdGlvbg0KPiBzaG91bGQgYmUgdXNlZDsgYW5k LCBtdWNoIGhhcmRlciB0byBhY2hpZXZlLCB0aGUgY2xpZW50IHNob3VsZA0KPiBhdXRoZW50aWNh dGUgdGhlIHNlcnZlciBiZWZvcmUgc2VuZGluZyBhbnkgZGF0YS4NCg0KVGhpcyBpcyBhIGdlbmVy YWwgY29uY2VybiwgaW5kZXBlbmRlbnQgb2YgdGhlIG1lZGlhIHR5cGUuIEl0IHdvdWxkIGFwcGx5 IGVxdWFsbHkgdG8gDQpodHRwOi8vZGFyb2Jpbi5naXRodWIuaW8vZm9ybWljL3NwZWNzL2pzb24v IChhIHByb3Bvc2FsIGZvciBhIEpTT04gZm9ybS1kYXRhKS4NCg0KSSdtIHJlbHVjdGFudCB0byBz YXkgc29tZXRoaW5nIHRoYXQgc2VlbXMgdXNlbGVzcyBhbmQgbm90IHJlYWxseSB0aGUgZG9tYWlu IG9mIHRoZSBmb3JtIGVuY29kaW5nIGF0IGFsbC4gDQoNCkhvdyBhYm91dDoNCg0KIkFsbCBmb3Jt IHByb2Nlc3Npbmcgc29mdHdhcmUgc2hvdWxkIHRyZWF0IHVzZXIgc3VwcGxpZWQgZm9ybS1kYXRh IHdpdGggc2Vuc2l0aXZpdHksIGFzIGl0IG9mdGVuIGNvbnRhaW5zIGNvbmZpZGVudGlhbCBvciBw ZXJzb25hbGx5IGlkZW50aWZ5aW5nIGluZm9ybWF0aW9uLiAgTXVsdGlwYXJ0L2Zvcm0tZGF0YSBk b2VzIG5vdCBzdXBwbHkgYW55IGZlYXR1cmVzIGZvciBjaGVja2luZyBpbnRlZ3JpdHksIGVuc3Vy aW5nIGNvbmZpZGVudGlhbGl0eTsgdGhvc2UgY29uY2VybnMgbXVzdCBiZSBhZGRyZXNzZWQgYnkg dGhlIGZvcm0tZmlsbGluZyBhbmQgZm9ybS1kYXRhLWludGVycHJldGluZyBhcHBsaWNhdGlvbnMu Ig0KDQoNCg0KDQoNCg== From nobody Wed Nov 26 09:19:56 2014 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 61BB21A0395 for ; Wed, 26 Nov 2014 09:19:54 -0800 (PST) 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 KW1GZJnHX_p2 for ; Wed, 26 Nov 2014 09:19:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id DA5FC1A017A for ; Wed, 26 Nov 2014 09:19:52 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PFEGGSHKFK003CFB@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 26 Nov 2014 09:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1417022089; bh=coin+DfKVfshpGz9fruGehVAqtKKuUvdPS5G3CN7cIw=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=fmrS52TJiBSdnjcw7TgwbAr1iwAj7RC/P37aEWFYO+DjiHPis9sZHo8gTAzKumz80 8OoDIV0Rm6VSm/NZrtXRNWPDOaJvHqipEdbr61LfrqKBtvR5jL5WgiG5kq5zK3gJ6m bMMAekMjRJv5R5hHnue425NxIizQ+FEQBqlh/Zew= 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 <01PEV4HDAQXS00005K@mauve.mrochek.com>; Wed, 26 Nov 2014 09:14:46 -0800 (PST) Message-id: <01PFEGGQFUBK00005K@mauve.mrochek.com> Date: Wed, 26 Nov 2014 09:11:48 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 25 Nov 2014 22:11:55 +0000" <458f822bea25443884fb24819a47fd8c@BN3PR0201MB0945.namprd02.prod.outlook.com> References: <05aa01d008af$4c22ea40$4001a8c0@gateway.2wire.net> <458f822bea25443884fb24819a47fd8c@BN3PR0201MB0945.namprd02.prod.outlook.com> To: Larry Masinter Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/l3e78gSyuRElto0mBFPQupk6TEs Cc: Ned Freed , IETF Apps Discuss , Sam Ruby Subject: Re: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data 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, 26 Nov 2014 17:19:54 -0000 > > Here, however, I think we should call out the obvious and say that > > where the data is or should be confidential, then suitably strong encryption > > should be used; and, much harder to achieve, the client should > > authenticate the server before sending any data. > This is a general concern, independent of the media type. It would apply equally to > http://darobin.github.io/formic/specs/json/ (a proposal for a JSON form-data). Actually, it isn't. There are media types whose sole purpose is to convey public information; privacy protection for those types is irrelevant. There are also media types that provide privacy and/or integrity protection internally. The point here is to expose what concerns there are and how they may be addressed. > I'm reluctant to say something that seems useless and not really the domain > of the form encoding at all. > How about: > "All form processing software should treat user supplied form-data with > sensitivity, as it often contains confidential or personally identifying > information. Multipart/form-data does not supply any features for checking > integrity, ensuring confidentiality; those concerns must be addressed by the > form-filling and form-data-interpreting applications." Looks good to me. Ned From nobody Thu Nov 27 02:46:37 2014 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 8CFE11A88CA for ; Thu, 27 Nov 2014 02:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.453 X-Spam-Level: ** X-Spam-Status: No, score=2.453 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FRT_ADOBE2=2.455, 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 rKDiYFE_J9xu for ; Thu, 27 Nov 2014 02:46:33 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::749]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62351A88C6 for ; Thu, 27 Nov 2014 02:46:32 -0800 (PST) Received: from pc6 (86.184.62.161) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 27 Nov 2014 10:46:04 +0000 Message-ID: <02d901d00a2f$63bfcfc0$4001a8c0@gateway.2wire.net> From: t.petch To: Ned Freed , Larry Masinter References: <05aa01d008af$4c22ea40$4001a8c0@gateway.2wire.net> <458f822bea25443884fb24819a47fd8c@BN3PR0201MB0945.namprd02.prod.outlook.com> <01PFEGGQFUBK00005K@mauve.mrochek.com> Date: Thu, 27 Nov 2014 10:45:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: DB4PR05CA0021.eurprd05.prod.outlook.com (25.160.40.31) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Forefront-PRVS: 040866B734 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(51704005)(189002)(199003)(81816999)(50986999)(92726001)(15202345003)(101416001)(122386002)(76176999)(561944003)(66066001)(40100003)(44716002)(102836001)(31966008)(120916001)(47776003)(92566001)(230783001)(62236002)(99396003)(86362001)(93916002)(116806002)(61296003)(81686999)(33646002)(20776003)(93886004)(14496001)(64706001)(21056001)(46102003)(88136002)(97736003)(84392001)(95666004)(89996001)(44736004)(107046002)(50466002)(106356001)(1556002)(105586002)(15975445006)(42186005)(104166001)(4396001)(23756003)(50226001)(62966003)(77156002)(87976001)(87286001)(77096003)(19580395003)(19580405001)(1456002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AeF-RHBmaYC7pESyslxufdHiraE Cc: Ned Freed , Sam Ruby , IETF Apps Discuss Subject: Re: [apps-discuss] response to WG last call comments for draft-ietf-appsawg-multipart-form-data 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, 27 Nov 2014 10:46:35 -0000 ----- Original Message ----- From: "Ned Freed" To: "Larry Masinter" Cc: "t.petch" ; "Ned Freed" ; "Salvatore Loreto" ; "IETF Apps Discuss" ; "Sam Ruby" Sent: Wednesday, November 26, 2014 5:11 PM > > > Here, however, I think we should call out the obvious and say that > > > where the data is or should be confidential, then suitably strong encryption > > > should be used; and, much harder to achieve, the client should > > > authenticate the server before sending any data. > > > This is a general concern, independent of the media type. It would apply equally to > > http://darobin.github.io/formic/specs/json/ (a proposal for a JSON form-data). > > Actually, it isn't. There are media types whose sole purpose is to convey > public information; privacy protection for those types is irrelevant. > > There are also media types that provide privacy and/or integrity protection > internally. > > The point here is to expose what concerns there are and how they may be > addressed. > > > I'm reluctant to say something that seems useless and not really the domain > > of the form encoding at all. > > > How about: > > > "All form processing software should treat user supplied form-data with > > sensitivity, as it often contains confidential or personally identifying > > information. Multipart/form-data does not supply any features for checking > > integrity, ensuring confidentiality; those concerns must be addressed by the > > form-filling and form-data-interpreting applications." > > Looks good to me. And would address my concern as well, Tom Petch > > Ned > From nobody Fri Nov 28 22:34:38 2014 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 D9E4C1A00A3 for ; Fri, 28 Nov 2014 22:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57ZxCfk_DFII for ; Fri, 28 Nov 2014 22:34:36 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82E11A008F for ; Fri, 28 Nov 2014 22:34:35 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so20146450wiv.11 for ; Fri, 28 Nov 2014 22:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VBWk7e9+9m99OmYyThfO5iPpE1SiuSAVHF8phMFAB0Y=; b=rMLz0vdy4E6fbuj5AA+JRFtOiNvMwb+XSG4R4H7AbxvfAxJWF7vxDeCxINicrxapqZ mzFvNdVEOsTrJkVftVhU9PJDAHnoAkP1tqCaLui52XAcyVFrxe6cpGma8NwQB0V/cUo6 2AkQkaIAq+dJjVI7Q/Yc1d2nEMnXc0gfvNz3nS+5wO887HW3ETKPtt8f96vHtNKIKw2T OPsDvdkc524F33oj+mkQyYQtxRHiGJtJMqLCAVn5ek6hDB0sgNb54ZlyJyETPcwQWE3R 1SoMrRw9SodLyWx6jrneEY9BHmux0DbZz2M+Jb4Rn3moCfe/F9h1NAoPlC6nHOI1Wxqs RacA== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr67518566wiw.21.1417242874529; Fri, 28 Nov 2014 22:34:34 -0800 (PST) Received: by 10.27.76.134 with HTTP; Fri, 28 Nov 2014 22:34:34 -0800 (PST) In-Reply-To: <20141128152445.12986.70985.idtracker@ietfa.amsl.com> References: <20141128152445.12986.70985.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 22:34:34 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0438957718d0000508f99235 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HNmGwz4YWZnvzDCQAaSFXAKVmqY Subject: [apps-discuss] Fwd: I-D Action: draft-hoffman-dns-terminology-00.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: Sat, 29 Nov 2014 06:34:38 -0000 --f46d0438957718d0000508f99235 Content-Type: text/plain; charset=UTF-8 Of potential interest here. -MSK ---------- Forwarded message ---------- From: Date: Fri, Nov 28, 2014 at 7:24 AM Subject: I-D Action: draft-hoffman-dns-terminology-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS Terminology Authors : Paul Hoffman Andrew Sullivan Kazunori Fujiwara Filename : draft-hoffman-dns-terminology-00.txt Pages : 9 Date : 2014-11-28 Abstract: The DNS is defined in literally dozens of different RFCs. The terminology used in by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-hoffman-dns-terminology-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --f46d0438957718d0000508f99235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Of potential interest here.

-MSK

=
---------- Forwarded message ---------= -
From: <internet-drafts@ietf.org>
Date: Fri, Nov 28, 2014 at 7:24 AM
Subject: I-D Action: draft-hoffm= an-dns-terminology-00.txt
To: i= -d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= DNS Terminology
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Paul= Hoffman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Andrew Sullivan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kazunori Fujiwara
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-hof= fman-dns-terminology-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-11-28

Abstract:
=C2=A0 =C2=A0The DNS is defined in literally dozens of different RFCs.=C2= =A0 The
=C2=A0 =C2=A0terminology used in by implementers and developers of DNS prot= ocols,
=C2=A0 =C2=A0and by operators of DNS systems, has sometimes changed in the = decades
=C2=A0 =C2=A0since the DNS was first defined.=C2=A0 This document gives cur= rent
=C2=A0 =C2=A0definitions for many of the terms used in the DNS in a single<= br> =C2=A0 =C2=A0document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hoffman-dns-termi= nology/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hoffman-dns-terminology-00<= /a>


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--f46d0438957718d0000508f99235--