From stephen.farrell@cs.tcd.ie Mon Sep 2 14:57:13 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65FB21F9DB4; Mon, 2 Sep 2013 14:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9X5vACuIZMw; Mon, 2 Sep 2013 14:57:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4F25421F9CDF; Mon, 2 Sep 2013 14:57:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93939BE70; Mon, 2 Sep 2013 22:57:02 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0NKLV2-xxD1; Mon, 2 Sep 2013 22:57:01 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.17.45]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8DA06BE6F; Mon, 2 Sep 2013 22:57:01 +0100 (IST) Message-ID: <522509AC.6040907@cs.tcd.ie> Date: Mon, 02 Sep 2013 22:57:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "saag@ietf.org" , smime@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] some s/mime related drafts I've been asked to AD sponsor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 21:57:13 -0000 Folks, Sean, Russ and Jim have authored three s/mime related drafts [1,2,3] and asked me to sponsor them for publication. I've read them and they seem like reasonable additions to the set of s/mime RFCs to me, but I'd like to check that nobody has any issue with that before starting IETF LC in a week or so. I'd specifically be interested in hearing from anyone who'd likely implement these. I'll send my own comments (which are minor) during the IETF LC. Thanks, S. [1] http://tools.ietf.org/html/draft-turner-application-cms-media-type [2] http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error [3] http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-algs From turners@ieca.com Thu Sep 5 10:39:18 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E768411E81CC for ; Thu, 5 Sep 2013 10:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.958 X-Spam-Level: X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulyqEp0HDnYl for ; Thu, 5 Sep 2013 10:39:14 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.39.12]) by ietfa.amsl.com (Postfix) with ESMTP id DA8E511E81FF for ; Thu, 5 Sep 2013 10:39:13 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 4339E30685792; Thu, 5 Sep 2013 12:38:16 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 26E7730685711 for ; Thu, 5 Sep 2013 12:38:16 -0500 (CDT) Received: from [96.231.225.44] (port=61880 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VHdWS-0007za-UO for saag@ietf.org; Thu, 05 Sep 2013 12:39:13 -0500 Message-ID: <5228C1BF.4050405@ieca.com> Date: Thu, 05 Sep 2013 13:39:11 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: saag@ietf.org References: <2DF7D778-A615-4EA3-B0E5-8C7832EECDEB@ietf.org> In-Reply-To: <2DF7D778-A615-4EA3-B0E5-8C7832EECDEB@ietf.org> X-Forwarded-Message-Id: <2DF7D778-A615-4EA3-B0E5-8C7832EECDEB@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:61880 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: Vancouver meeting is coming up fast X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 17:39:19 -0000 Spreading the word! If you're looking to get a BOF in Vancouver it is *much* better to get the request in early. In fact, if you've got even the slightest inclining that you might ask for a BOF letting Stephen or I soonest would be a good thing. spt -------- Original Message -------- Subject: Vancouver meeting is coming up fast Date: Tue, 3 Sep 2013 12:32:10 +0300 From: IETF Chair Reply-To: IETF list To: ietf-announce@ietf.org CC: IETF list , The IESG It seems like yesterday when we were in Berlin, but I wanted to highlight that our Vancouver meeting is coming up soon. Sooner than usual, in fact, given the dates of the meetings this year. I wanted to highlight an important deadline. If you are working on a new proposal for work at the IETF, it needs to be submitted by September 23rd, just three weeks away. If you have a new idea, this would be a good time to start talking about it to others, create lists, submit early drafts. And talk to your ADs. We at the IESG are happy to help you in the process. If you have not submitted a proposal earlier, you should probably read RFC 5434 (http://tools.ietf.org/html/rfc5434) and BOF procedures (http://www.ietf.org/wg/bof-procedures.html). For more information about the meeting, see my recent blog post here: http://www.ietf.org/blog/2013/09/vancouver/ Jari Arkko IETF Chair From barryleiba@gmail.com Fri Sep 6 07:19:26 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B011E817F; Fri, 6 Sep 2013 07:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7pyNHSIdl74; Fri, 6 Sep 2013 07:19:25 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id EF7AD11E8159; Fri, 6 Sep 2013 07:19:24 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ev20so2826843lab.11 for ; Fri, 06 Sep 2013 07:19:23 -0700 (PDT) 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=IMIVNbRVuhCbk2HcnuzmY4HKHrmeVOafaoK6xaCewo0=; b=FU/cOvn86t8YxD0Kk2yNleII9kx8gtgsS2qG6cWuQyGB8M9jiWckAI2N3lg+dagRdL sm6kzeXwiZVTGe4p7hG2cp2O31w8/DgwsK/di9KCI3f+r1800EYFS32N6fh5gKhGMvxH 7yfjVJBHKflI3TQXqT1ytjTSiHnVfqu6cK9+SkOXYlOtttWetYQ/DTH8k/PuAoqSmin7 2efxZSm6KXIXzmo3tXphTska3c//ZAwtO0M+GXIN4LYhLxU1GSDjHTsh5r3ggDndGP76 qNlu2vXmhpa6xTyNJ8NcZvsRpfKU97H1wZC62uXlRPLMEfRCQP+Lmg7yrmbe10m8h3Hr ZEkw== MIME-Version: 1.0 X-Received: by 10.152.2.74 with SMTP id 10mr1688041las.36.1378477163863; Fri, 06 Sep 2013 07:19:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.130.39 with HTTP; Fri, 6 Sep 2013 07:19:23 -0700 (PDT) Date: Fri, 6 Sep 2013 10:19:23 -0400 X-Google-Sender-Auth: 40_MrTzOtw2qaspW6Q-6nVfuQlY Message-ID: From: Barry Leiba To: "saag@ietf.org" , smime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 14:19:26 -0000 In the handling of draft-ietf-pkix-est, it came up that there really ought to be a registry for values of the "smime-type" content-type parameter. Sean and I discussed it, and I put together a quick document (see below) to create the registry and do the magic. We should have a brief discussion of it here before Sean AD-sponsors it and sends it out for last call. In particular, we decided to propose "RFC Required" for the registration policy. Is that the right policy? Does anyone have other comments about the registry or the document? Please, a few reviews and comments will be needed before we can proceed. And it' short. So have at it. Barry > From: > Date: Wed, Aug 28, 2013 at 10:38 AM > Subject: New Version Notification for draft-leiba-smime-type-registry-00.txt > To: Barry Leiba > > A new version of I-D, draft-leiba-smime-type-registry-00.txt > has been successfully submitted by Barry Leiba and posted to the > IETF repository. > > Filename: draft-leiba-smime-type-registry > Revision: 00 > Title: Creation of a registry for smime-type parameter values > Creation date: 2013-08-28 > Group: Individual Submission > Number of pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-leiba-smime-type-registry-00.txt > Status: http://datatracker.ietf.org/doc/draft-leiba-smime-type-registry > Htmlized: http://tools.ietf.org/html/draft-leiba-smime-type-registry-00 > > > Abstract: > Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the > Content-Type parameter "smime-type". As the list of defined values > for that parameter has increased, it has become clear that a registry > is needed to document those values. This document creates that > registry, registers the current values, and specifies the policies > for registration of new values. From paul.hoffman@vpnc.org Fri Sep 6 08:41:58 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2951B11E81B4; Fri, 6 Sep 2013 08:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpYNRAxCA97V; Fri, 6 Sep 2013 08:41:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B6CBC11E8122; Fri, 6 Sep 2013 08:41:57 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r86FfnEp019072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Sep 2013 08:41:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Fri, 6 Sep 2013 08:41:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: "saag@ietf.org" , smime@ietf.org Subject: Re: [saag] [smime] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:41:58 -0000 On Sep 6, 2013, at 7:19 AM, Barry Leiba wrote: > In the handling of draft-ietf-pkix-est, it came up that there really > ought to be a registry for values of the "smime-type" content-type > parameter. Sean and I discussed it, and I put together a quick > document (see below) to create the registry and do the magic. We > should have a brief discussion of it here before Sean AD-sponsors it > and sends it out for last call. > > In particular, we decided to propose "RFC Required" for the > registration policy. Is that the right policy? Does anyone have > other comments about the registry or the document? > > Please, a few reviews and comments will be needed before we can > proceed. And it' short. So have at it. The idea of having a registry seems fine, and "RFC Required" seems fine. --Paul Hoffman From dev+ietf@seantek.com Sat Sep 7 07:46:14 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085B521F9E02; Sat, 7 Sep 2013 07:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmsEwFCOc6iG; Sat, 7 Sep 2013 07:45:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7921F9D15; Sat, 7 Sep 2013 07:45:43 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.173.239.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 10B15509B8; Sat, 7 Sep 2013 10:45:38 -0400 (EDT) Message-ID: <522B3C20.105@seantek.com> Date: Sat, 07 Sep 2013 07:45:52 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: smime@ietf.org, saag@ietf.org References: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> In-Reply-To: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 07 Sep 2013 08:01:43 -0700 Subject: Re: [saag] [smime] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 14:46:14 -0000 On 9/6/2013 8:41 AM, Paul Hoffman wrote: > On Sep 6, 2013, at 7:19 AM, Barry Leiba wrote: > >> In the handling of draft-ietf-pkix-est, it came up that there really >> ought to be a registry for values of the "smime-type" content-type >> parameter. Sean and I discussed it, and I put together a quick >> document (see below) to create the registry and do the magic. We >> should have a brief discussion of it here before Sean AD-sponsors it >> and sends it out for last call. >> >> In particular, we decided to propose "RFC Required" for the >> registration policy. Is that the right policy? Does anyone have >> other comments about the registry or the document? >> >> Please, a few reviews and comments will be needed before we can >> proceed. And it' short. So have at it. > The idea of having a registry seems fine, and "RFC Required" seems fine. The idea of having a registry seems fine, and "RFC Required" seems fine. However, as an active developer in this area, I am weary of having more registries to consult for things that rarely if ever change. I am not in favor of a registry without more evidence that there are significantly more diverse CMS payloads that are expected to be carried in MIME-related bodies. I do have a suggestion: The current registry in draft-leiba-smime-type-registry only has two columns: smime-type value and Reference. Actually, it should have six columns, the additional four columns being: CMS Type, CMS Type (OID), Inner Content, and Inner Content (OID). For example, enveloped-data would be CMS Type: EnvelopedData; CMS Type (OID): 1.2.840.113549.1.7.3; Inner Content: id-data; Inner Content (OID): 1.2.840.113549.1.7.1. This additional information would make the registry more useful. Sean From barryleiba.mailing.lists@gmail.com Sat Sep 7 10:09:57 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C9421E80A9; Sat, 7 Sep 2013 10:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAkFFY8goULf; Sat, 7 Sep 2013 10:09:57 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9F75721E8063; Sat, 7 Sep 2013 10:09:56 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so2932047vbh.40 for ; Sat, 07 Sep 2013 10:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9DImSLLcG8W6xaI2EAkHEuugdn6FbWOWqiRlHwWdZdI=; b=w4DBOJ6o464p90mxqiPeuy1h30Gyi8eabRgQ+FA7ycZGUa+Bc8pnw6Id2UjkG8ltDM D6rh+O+PacjVLSJCxaycIlYJbftcUKPdVco7vbe9B/lRBRQ06Z9qP2RMdAbxxZ+YCNm8 ehyWp/L5Xg/GubO1cdG6edFJEhTVyygupaKaOLO68PnRHxhbJFQnRvMG9TIpvDPjH4y3 3w/SJkLmeO91+TQyvgYXNyqapiHaCWqZnVzcwU+ogqVnYCU7eJzYHrfLBdbp9z7buEtI ayax9BtFmDazkS1fo2rrwdrcR4Kci/fM+pAPthBfyS2+LJoow4wmZc9wwxqHQ3NGVvoi geLw== MIME-Version: 1.0 X-Received: by 10.52.116.74 with SMTP id ju10mr7050749vdb.20.1378573795052; Sat, 07 Sep 2013 10:09:55 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Sat, 7 Sep 2013 10:09:54 -0700 (PDT) In-Reply-To: <522B3C20.105@seantek.com> References: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> <522B3C20.105@seantek.com> Date: Sat, 7 Sep 2013 13:09:54 -0400 X-Google-Sender-Auth: GAeWTF82wYfbBBAYuLA_JhJTo4k Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=ISO-8859-1 Cc: saag , smime@ietf.org Subject: Re: [saag] [smime] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 17:09:57 -0000 Hi, Sean, and thanks for the comments. > The idea of having a registry seems fine, and "RFC Required" seems fine. > However, as an active developer in this area, I am weary of having more > registries to consult for things that rarely if ever change. I am not in > favor of a registry without more evidence that there are significantly more > diverse CMS payloads that are expected to be carried in MIME-related bodies. In general, we often think we don't need a registry. And then we add new values. But we still think we don't need a registry. And then we add new values again. This is the third time we've added values for smime-type. I think that says that we need a registry. Better to consult a registry, where all the values are listed in one place, than to have to find the three different RFCs where values are defined (and to know that you have to find those three), and then to look through them to see the valid values. I bet someone will say that we've defined all the smime-type values that we will, and *now* it's stable and we don't need to add any more. I bet we said that after the second time, as well. > I do have a suggestion: > The current registry in draft-leiba-smime-type-registry only has two > columns: smime-type value and Reference. > > Actually, it should have six columns, the additional four columns being: CMS > Type, CMS Type (OID), Inner Content, and Inner Content (OID). For example, > enveloped-data would be CMS Type: EnvelopedData; CMS Type (OID): > 1.2.840.113549.1.7.3; Inner Content: id-data; Inner Content (OID): > 1.2.840.113549.1.7.1. This additional information would make the registry > more useful. I thought about that, and started to write the document that way. Then I had these thoughts: 1. Not all those columns apply to all the values. How do those columns apply to CMC-Request, CMC-Response, and server-generated-key ? What about "certs-only? 1.5. When there are registry columns that often don't apply, people registering new values get confused about how to do their registrations, and what to specify (or not) for those columns. 2. All that information is documented in the reference document for the value, when that information applies. 3. One really needs to go to the reference document to understand how to use the values anyway. Rather than making the registry more complicated, I'd rather have the values documented with a good reference pointer, and leave it at that. Do others think that additional columns in the registry add enough value to put them there, despite those points above? Barry From paul.hoffman@vpnc.org Sat Sep 7 11:09:41 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB81911E8176; Sat, 7 Sep 2013 11:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVJPX8QsW33P; Sat, 7 Sep 2013 11:09:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3209411E8174; Sat, 7 Sep 2013 11:09:41 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r87I9X46073970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Sep 2013 11:09:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sat, 7 Sep 2013 11:09:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DD1936A-C373-4961-BAAD-103604011C2A@vpnc.org> <522B3C20.105@seantek.com> To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: saag , Sean Leonard , smime@ietf.org Subject: Re: [saag] [smime] Fixing the definition of the smime-type parameter by creating a registry X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 18:09:41 -0000 On Sep 7, 2013, at 10:09 AM, Barry Leiba = wrote: > Hi, Sean, and thanks for the comments. >=20 >> The idea of having a registry seems fine, and "RFC Required" seems = fine. >> However, as an active developer in this area, I am weary of having = more >> registries to consult for things that rarely if ever change. I am not = in >> favor of a registry without more evidence that there are = significantly more >> diverse CMS payloads that are expected to be carried in MIME-related = bodies. >=20 > In general, we often think we don't need a registry. And then we add > new values. But we still think we don't need a registry. And then we > add new values again. This is the third time we've added values for > smime-type. I think that says that we need a registry. Better to > consult a registry, where all the values are listed in one place, than > to have to find the three different RFCs where values are defined (and > to know that you have to find those three), and then to look through > them to see the valid values. >=20 > I bet someone will say that we've defined all the smime-type values > that we will, and *now* it's stable and we don't need to add any more. >=20 > I bet we said that after the second time, as well. +1 to what Barry said. Developers don't need to check the registry if = they already know all the values they care about; registries are for = developers who want to know what they don't already know. >> I do have a suggestion: >> The current registry in draft-leiba-smime-type-registry only has two >> columns: smime-type value and Reference. >>=20 >> Actually, it should have six columns, the additional four columns = being: CMS >> Type, CMS Type (OID), Inner Content, and Inner Content (OID). For = example, >> enveloped-data would be CMS Type: EnvelopedData; CMS Type (OID): >> 1.2.840.113549.1.7.3; Inner Content: id-data; Inner Content (OID): >> 1.2.840.113549.1.7.1. This additional information would make the = registry >> more useful. >=20 > I thought about that, and started to write the document that way. > Then I had these thoughts: >=20 > 1. Not all those columns apply to all the values. How do those > columns apply to CMC-Request, CMC-Response, and server-generated-key ? > What about "certs-only? >=20 > 1.5. When there are registry columns that often don't apply, people > registering new values get confused about how to do their > registrations, and what to specify (or not) for those columns. >=20 > 2. All that information is documented in the reference document for > the value, when that information applies. >=20 > 3. One really needs to go to the reference document to understand how > to use the values anyway. >=20 > Rather than making the registry more complicated, I'd rather have the > values documented with a good reference pointer, and leave it at that. >=20 > Do others think that additional columns in the registry add enough > value to put them there, despite those points above? There is a negative value to duplicating information from RFCs in the = registry. Registries should have the absolute minimum amount of = duplicated information from the RFCs. Any developer who cares at all a = protocol will already be looking in the RFC. A developer who only cares = to know what code points are taken doesn't need the rest. This should = not make anyone "weary". --Paul Hoffman= From ietf@hardjono.net Mon Sep 9 10:33:13 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FE921E80AA for ; Mon, 9 Sep 2013 10:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-5tTMgAt1ac for ; Mon, 9 Sep 2013 10:33:08 -0700 (PDT) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id E1A5821E814D for ; Mon, 9 Sep 2013 10:33:07 -0700 (PDT) Received: (qmail 29519 invoked by uid 0); 9 Sep 2013 17:32:44 -0000 Received: from unknown (HELO box602.bluehost.com) (70.40.220.102) by oproxy1.mail.unifiedlayer.com with SMTP; 9 Sep 2013 17:32:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=LTsH1/5eTp4ghdndEdYH4InAqP//bepetlTphc7DhHI=; b=dZeJZZtZoNQfRpg2DT6Zs7jNvx1IOGKjkuOPTegqeK65HTR8eWsOVUW7QJa4FRZ4qTEB+L5Ikw07QVl1q/CzmbKBOq9xsPKE+ne1RfVbOaxLdwVmrldgfidZwGRXdWh4; Received: from [18.189.26.83] (port=52295 helo=WINCE7P9IL9EJ0) by box602.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VJ5KO-0000BJ-ME for saag@ietf.org; Mon, 09 Sep 2013 11:32:44 -0600 From: "Thomas Hardjono" To: Date: Mon, 9 Sep 2013 13:32:44 -0400 Message-ID: <006801cead82$98199450$c84cbcf0$@hardjono.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6tgpZI2l06qtBlSESARMDizOIJ1g== Content-Language: en-us X-Identified-User: {3727:box602.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.189.26.83 authed with ietf@hardjono.net} Subject: [saag] 2013 MIT Kerberos & Internet Trust Conference X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:33:13 -0000 Folks, The MIT-KIT annual conference will be on "Personal Data on the Internet", a topic which is getting intense interest recently in the news media. The date is Monday 7 October 2013, at the MIT Media Lab. You are cordially invited. Registration is free. Please email me (hardjono[AT]mit.edu) if you are interested in attending. cheers, /thomas/ --------------------------------------------- 2013 MIT Kerberos & Internet Trust Conference --------------------------------------------- Theme: "Personal Data on the Internet: The New Deal on Data" Co-hosted by Prof Sandy Pentland from the MIT Media Lab Date: 7 October 2013 (Monday) Time: 9AM - 6PM Venue: MIT Media Lab, Building E14 Multifunction Room, 6th Floor Corner of Ames & Amherst Sts. Map: http://whereis.mit.edu/?go=E14 Social Event: 6PM to 8PM, MIT Media Lab, Bldg E14 Silverman Skyline room (6th Floor) Program: http://kit.mit.edu/conference-program Registration (free): http://kit.mit.edu/events http://kit.mit.edu/events/annual-conference We look forward to seeing you at the 2013 MIT-KIT Conference. Regards. /thomas/ ____________________________________________ Thomas Hardjono MIT Consortium for Kerberos & Internet Trust e: hardjono[at]mit.edu m: +1 781 729 9559 w: kit.mit.edu ____________________________________________ From cabo@tzi.org Wed Sep 11 06:24:55 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CCF11E8117; Wed, 11 Sep 2013 06:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCsnS1IzbuGx; Wed, 11 Sep 2013 06:24:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0670921E80AA; Wed, 11 Sep 2013 06:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8BDOhZN007410; Wed, 11 Sep 2013 15:24:44 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 904C13AA; Wed, 11 Sep 2013 15:24:43 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann Date: Wed, 11 Sep 2013 15:24:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1508) Cc: IETF Security Area Advisory Group Subject: [saag] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 13:24:56 -0000 (CoRE =3D Constrained RESTful Environments, the application protocol = work for the "Internet of Things".) For those that are interested in the CoRE Authorization work that = started in Berlin, and that haven't already booked their Vancouver = flights: We are planning some informal technical discussion in Vancouver on = Sunday, Nov 3rd, starting about noon. The objective is to achieve mutual understanding of the technical = approaches and maybe some merging/taxonomizing of those. The objective is expressly not to discuss how to do this work in the = IETF (rechartering? BOF?), that must come after understanding what it is = that we want to achieve. This informal meeting will have a strong "we assume you have read the = drafts" component, but otherwise open to all interested attendees. I'm = CCing SAAG because this isn't strictly an applications area subject. = (There sure will be a lot of interest in other aspects of applications = area security in Vancouver, as well...) Details of the meeting (drafts to read, agenda, room, etc.) will emerge = soon. Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Fri Sep 13 19:12:08 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AD011E813F; Fri, 13 Sep 2013 19:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZHPaT70ATkH; Fri, 13 Sep 2013 19:12:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAF521E80C9; Fri, 13 Sep 2013 19:12:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXH63254; Sat, 14 Sep 2013 02:12:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 03:11:42 +0100 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 03:11:58 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.3]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.007; Sat, 14 Sep 2013 10:11:53 +0800 From: Bert Greevenbosch To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd Thread-Index: AQHOrvJbdKBymvrM00mMl/392ngwX5nDCXvg Date: Sat, 14 Sep 2013 02:11:52 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D8E1F63@szxeml558-mbx.china.huawei.com> References: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> In-Reply-To: <8896EFF2-BD1E-4634-8195-34580E1096F0@tzi.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Sat, 14 Sep 2013 16:59:00 -0700 Cc: IETF Security Area Advisory Group Subject: Re: [saag] [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 02:12:08 -0000 Hi Carsten, Indeed I look forward to discuss the scope about the authorisation/authenti= cation work during the Sunday meeting. I think we should not a priori say that the discussion on how to do the wor= k (recharter or BoF) is off-topic. I don't think we need to allocate much t= ime for that discussion, but having it is important in order to move on and= do the work. So I prefer to keep the "how" part in the discussion. Best regards, Bert > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Carsten Bormann > Sent: 11 September 2013 21:25 > To: core@ietf.org WG > Cc: IETF Security Area Advisory Group > Subject: [core] Travel planning: some CoRE-AA work on Sunday, Nov 3rd >=20 > (CoRE =3D Constrained RESTful Environments, the application protocol work > for the "Internet of Things".) >=20 > For those that are interested in the CoRE Authorization work that > started in Berlin, and that haven't already booked their Vancouver > flights: >=20 > We are planning some informal technical discussion in Vancouver on > Sunday, Nov 3rd, starting about noon. > The objective is to achieve mutual understanding of the technical > approaches and maybe some merging/taxonomizing of those. > The objective is expressly not to discuss how to do this work in the > IETF (rechartering? BOF?), that must come after understanding what it > is that we want to achieve. >=20 > This informal meeting will have a strong "we assume you have read the > drafts" component, but otherwise open to all interested attendees. > I'm CCing SAAG because this isn't strictly an applications area subject. > (There sure will be a lot of interest in other aspects of applications > area security in Vancouver, as well...) >=20 > Details of the meeting (drafts to read, agenda, room, etc.) will emerge > soon. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From stephen.farrell@cs.tcd.ie Tue Sep 17 01:38:11 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB99F11E80F3 for ; Tue, 17 Sep 2013 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1VTkZcYHc5s for ; Tue, 17 Sep 2013 01:38:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 584C211E83BA for ; Tue, 17 Sep 2013 01:37:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7235FBE8E for ; Tue, 17 Sep 2013 09:37:48 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwOWY0JvRKxq for ; Tue, 17 Sep 2013 09:37:48 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5508CBE76 for ; Tue, 17 Sep 2013 09:37:48 +0100 (IST) Message-ID: <523814DD.6040406@cs.tcd.ie> Date: Tue, 17 Sep 2013 09:37:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "saag@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: Rough agenda for Vancouver X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 08:38:11 -0000 FYI, if you'll be in Vancouver and are interested in HTTP then please try to include this httpbis session in your schedule. (And no, we won't have a draft agenda for a week or two yet, so I can't say when it'll happen:-) S -------- Original Message -------- Subject: Rough agenda for Vancouver Resent-Date: Tue, 17 Sep 2013 03:28:49 +0000 Resent-From: ietf-http-wg@w3.org Date: Tue, 17 Sep 2013 13:28:09 +1000 From: Mark Nottingham To: IETF HTTP WG After some discussion with Security area people, it seems like holding a joint session with them, much like we did with Transport, might be interesting. So, I've requested two sessions for Vancouver. The rough thinking regarding agenda is: # Joint Session * ALPN review * HPACK review with an eye towards CRIME * Encryption and HTTP/2 * Other privacy-related discussions # "Normal" Session * HTTP/1.1 status update / IETF LC issue discussion * HTTP/2 status update (we'll just be back from Seattle) Suggestions, ideas, etc. are (as always) welcome. We may also have some joint topics with Transport folks, but if that happens, it'll likely be during one of their sessions. Regards, -- Mark Nottingham http://www.mnot.net/