On Thu, Nov 2, 2017 at 4:50 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:

I'd be happ= ier if we got some sort of signal that people liked the
format and planned to deploy it.=C2=A0 We just added a new compression
content coding, so this might not be so easy to justify.=C2=A0 That said, any item in the registry is easy to ignore, so it's no great expense to have it exist.

The draft has an Implementation Status section that talks abo= ut a few, though there are no browsers among them at this point.=C2=A0 But = the latter's not a specific requirement for a Content-Encoding, is it?<= /div>

-MSK

--001a1149dca0bb5f09055d0efa18-- From nobody Mon Nov 6 06:53:34 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2257513FC2C for ; Mon, 6 Nov 2017 06:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KOQrmbMgMN2 for ; Mon, 6 Nov 2017 06:53:30 -0800 (PST) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9050B13F698 for ; Mon, 6 Nov 2017 06:53:30 -0800 (PST) Received: from smtp25.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DBCF9204BA; Mon, 6 Nov 2017 09:53:29 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp25.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 833052044D; Mon, 6 Nov 2017 09:53:29 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.62.96] ([UNAVAILABLE]. [128.107.241.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 06 Nov 2017 09:53:29 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2017 06:54:17 -0800 Message-Id: Cc: Ben Campbell To: DISPATCH Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dispatch] Review of draft-campbell-sip-messaging-smime-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 14:53:32 -0000 Relevant comments ... I have implement S/MIME for encryption with SIP and Simple and I think = this document provides some excellent clarifications and updates.=20 I agree with the the new MTI ciphers.=20 Overall, I think the update in this draft improves the security defined = in SIMPLE and MSRP.=20 Some random food for thought .... Getting a cert that says sip:fluffy@cisco.com signed by a LE^H^H some CA = is hard. However, getting a cert that says fluffy._sip._users.cisco.com = is easy and now can be highly automated. Why not allow certs that looks = like that. I realize this is going to cause people to just go "that is = so wrong", issues certs with the right thing. But back up for a second = and ask what the hardest part of any PKI is. If th cisco.com domain = issues me the email address fluffy, it is pretty easy for it to also = publish the TXT records I need for domain validation with the CA. This = suggestion does not relevantly reduce the security and is is pretty = pragmatic. The problem is not making it hard for the bad guys, the = thing we need most is making it easy for the good guys. From nobody Mon Nov 6 07:21:20 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7844413FC44 for ; Mon, 6 Nov 2017 07:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTYCJNKDP632 for ; Mon, 6 Nov 2017 07:21:16 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F82E13FC37 for ; Mon, 6 Nov 2017 07:21:16 -0800 (PST) X-AuditID: c1b4fb2d-bf5ff7000000268d-be-5a007dea5273 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DB.A6.09869.AED700A5; Mon, 6 Nov 2017 16:21:14 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Mon, 6 Nov 2017 16:21:14 +0100 From: Christer Holmberg To: Ben Campbell , "dispatch@ietf.org" CC: Russ Housley Thread-Topic: [dispatch] E2E Secure Messaging for SIP/SIMPLE Thread-Index: AQHTUnj52iNISz9ukkGYWEO9it9RQaMHgu6A Date: Mon, 6 Nov 2017 15:21:13 +0000 Message-ID: References: <25B9F35E-BAE3-42A5-8621-5664246AE2E7@nostrum.com> In-Reply-To: <25B9F35E-BAE3-42A5-8621-5664246AE2E7@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <670F1C8D16CBE44C856D4A8C54555C85@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7me6rWoYogyfH9Czmd55mt1g6aQGr xasXN9kdmD2WLPnJ5DFr5xMWj1V3vrAGMEdx2aSk5mSWpRbp2yVwZZye+YWtoIevYsLxPqYG xoXcXYycHBICJhJTLk1i7mLk4hASOMwocbbrE5SzCMjZOJupi5GDg03AQqL7nzZIg4iAt8T8 bR9YQGxmAXWJ5yv72EBsYQFric62V6wg5SICNhJ3PthBmEYSs9qyQEwWARWJx9v1QIp5gYob W/eCNQoJ2EmsWPsIbCCngL3El5uLwGxGATGJ76fWMEEsEpe49WQ+E8TFAhJL9pxnhrBFJV4+ /scKYosK6ElsOHGbHWSVhICixPJ+OYhWPYkbU6ewQdjWEsvvfmWFsLUlli18zQxxjqDEyZlP WCYwis9Csm0WkvZZSNpnIWmfhaR9ASPrKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzA2Du4 5bfuDsbVrx0PMQpwMCrx8F7JZIgSYk0sK67MPcQowcGsJMK7XR0oxJuSWFmVWpQfX1Sak1p8 iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dUA2PUeRvtH7M6gjYoztidbXDQ9FTJN89o b+/3VfoOrnJNxbtERPyLSs+UXb9TXGWoOyfAbyL/QR3npQeSFgqxfr665FTLrxc/2E6ui49Z /W53ufjSBKeYAxx7Zoex98fvnPAo40faqWV39u2dbfPI518mR//qGafky18sLWHKLxN593pq 3poJoeuVWIozEg21mIuKEwGVhAt5uQIAAA== Archived-At: Subject: Re: [dispatch] E2E Secure Messaging for SIP/SIMPLE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:21:18 -0000 Hi, A few initial comments: Q1: The text says: "This document discusses the use of S/MIME with SIP based messaging.=B2 However, the document also covers MSRP, and I don=B9t know if that counts a= s =B3SIP based=B2. Perhaps it would be better to explicitly say =B3SIP based messaging and MSRP=B2, =B3SIP- and MSRP based messaging=B2, or something? Q2: While section 4 describes the applicability of S/MIME, I think it would be good to mention in section 1 and/or 3 exactly what encryption you are talking about (i.e., encryption of bodies/content). Q3: Section 3 says: "encryption across a session of messages" What does that mean? Thanks! Regards, Christer On 31/10/17 20:47, "dispatch on behalf of Ben Campbell" wrote: >(strictly as an individual) > >Hi everyone, > >Russ and I submitted a draft [1] on the use of S/MIME for the SIP MESSAGE >method and for MSRP. It mainly offers clarifications of the S/MIME >guidance in RFCs 3261, 3428, and 4975, but it also makes a few updates. > >The main use case we have in mind is for where organizations want to send >secure notifications to their users. For example, financial organizations >send transaction notices, organizations send password update notices, 2FA >notices, etc. Much of that is currently done over various mobile >messaging systems (SMS, etc). Most of that is done with no e2e >authentication or integrity protection. We=B9d like to enable at least >end-to-end signed messaging for SIP based mobile messaging systems. > >We would appreciate it if people would take a look, and send your >comments. > >[1] https://tools.ietf.org/html/draft-campbell-sip-messaging-smime-00 > >Thanks! > >Ben. From nobody Mon Nov 6 07:43:11 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5164613FC0D for ; Mon, 6 Nov 2017 07:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEjydGm-pbUG for ; Mon, 6 Nov 2017 07:43:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05BC13FAD9 for ; Mon, 6 Nov 2017 07:43:08 -0800 (PST) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA6Fh2YQ090361 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 09:43:03 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A1F206AF-6739-42B2-8E4B-DF2F11D0B0FF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 6 Nov 2017 09:43:01 -0600 In-Reply-To: Cc: "dispatch@ietf.org" , Russ Housley To: Christer Holmberg References: <25B9F35E-BAE3-42A5-8621-5664246AE2E7@nostrum.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [dispatch] E2E Secure Messaging for SIP/SIMPLE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:43:10 -0000 --Apple-Mail=_A1F206AF-6739-42B2-8E4B-DF2F11D0B0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the comments! Responses inline: > On Nov 6, 2017, at 9:21 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > A few initial comments: >=20 > Q1: >=20 > The text says: >=20 > "This document discusses the use of S/MIME with SIP based messaging.=C2=B2= >=20 >=20 > However, the document also covers MSRP, and I don=C2=B9t know if that = counts as > =C2=B3SIP based=C2=B2. Perhaps it would be better to explicitly say = =C2=B3SIP based > messaging and MSRP=C2=B2, =C2=B3SIP- and MSRP based messaging=C2=B2, = or something? You are probably right. We were trying to keep the description short, = but it=E2=80=99s probably too short. >=20 >=20 > Q2: >=20 > While section 4 describes the applicability of S/MIME, I think it = would be > good to mention in section 1 and/or 3 exactly what encryption you are > talking about (i.e., encryption of bodies/content). Agreed. >=20 >=20 > Q3: >=20 > Section 3 says: >=20 > "encryption across a session of messages" >=20 >=20 > What does that mean? This is talking about negotiating a session encryption key, where all = (or some) of the messages sent over an MSRP session are encrypted with = the same key. We will clarify. Thanks! Ben. --Apple-Mail=_A1F206AF-6739-42B2-8E4B-DF2F11D0B0FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAloAgwUACgkQgFZKbJXz 1A3IHRAAvzTH/v5tR4SHzTRzdYxfytNA4HZBJVqGG/Y+GazPaWN8DW9JLbj5ls/F 2CI2cjFADy6ZseMkAbRfVpIbW0+hFroeIrw0P79x2wXgnsJphD+Fcn8u5/I0OeFK xWhILzrPcXiA9E21s6RR6yICTXl8wc6rxiN+wgdFR3OO/URVUi4bj/vZDkJs4BlP wYLdRbAP4rXFfnoqwdsgWWso/oQ6wpQ/NiMfpJ+yqtAwgJ676t3innX8JtxeIp+7 HwcYqgw+YfSlH1OXLvIyURZx/I0VUoOsGmKk4Q5hFpBn665YNuR5BXF8Zf7o8zpZ wnnIbaZKpfqqlpK4IoouzZVjTphWarWHGbSzsY4HIJAVZ6Oyh2H+3bO4GxYeYhHf H4zfkr2L+o44l1xivp3aRaRSGdfW4NdGszGydgS7DEJmSGlN/ZAD/krx7y2m0ciO j2t31TCItoIzKDLNhdz20NpZSTg/1e+hXSuupCY7+1t1k/lbZq1ENXpSWXcQROJh vFnTNQFhY02DisjRtNSPoA+VmkPyg16ozeBxejQc3I67k9dDkoY/kE5BjsbnpTEO sDNyjEBeqG2joYSUKIpsFqGRwNVtEszqaK2jPLSVtJ1R+QyOmdhkoZ3zR/M16isE Sd3rFFLTvN2sstb3zpduFg8tzpkipmBGxHj9LXdmXD0/iNRn/ms= =x5r8 -----END PGP SIGNATURE----- --Apple-Mail=_A1F206AF-6739-42B2-8E4B-DF2F11D0B0FF-- From nobody Mon Nov 6 07:48:21 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A21A13FC4A for ; Mon, 6 Nov 2017 07:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGpRanDiGfYR for ; Mon, 6 Nov 2017 07:48:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036D013FAD9 for ; Mon, 6 Nov 2017 07:48:17 -0800 (PST) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA6FmEx2090941 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 09:48:17 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1112914B-99FF-4D5A-9EDC-B962050420C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 6 Nov 2017 09:48:14 -0600 In-Reply-To: Cc: DISPATCH , Russ Housley To: Cullen Jennings References: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [dispatch] Review of draft-campbell-sip-messaging-smime-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:48:19 -0000 --Apple-Mail=_1112914B-99FF-4D5A-9EDC-B962050420C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the feedback! Your comment about cert naming is interesting. = Russ, do you have thought there? Thanks! Ben. > On Nov 6, 2017, at 8:54 AM, Cullen Jennings wrote: >=20 >=20 > Relevant comments ... >=20 > I have implement S/MIME for encryption with SIP and Simple and I think = this document provides some excellent clarifications and updates. >=20 > I agree with the the new MTI ciphers. >=20 > Overall, I think the update in this draft improves the security = defined in SIMPLE and MSRP. >=20 >=20 > Some random food for thought .... >=20 > Getting a cert that says sip:fluffy@cisco.com signed by a LE^H^H some = CA is hard. However, getting a cert that says = fluffy._sip._users.cisco.com is easy and now can be highly automated. = Why not allow certs that looks like that. I realize this is going to = cause people to just go "that is so wrong", issues certs with the right = thing. But back up for a second and ask what the hardest part of any PKI = is. If th cisco.com domain issues me the email address fluffy, it is = pretty easy for it to also publish the TXT records I need for domain = validation with the CA. This suggestion does not relevantly reduce the = security and is is pretty pragmatic. The problem is not making it hard = for the bad guys, the thing we need most is making it easy for the good = guys. >=20 >=20 >=20 >=20 --Apple-Mail=_1112914B-99FF-4D5A-9EDC-B962050420C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAloAhD4ACgkQgFZKbJXz 1A04cA//WFWPeulpL9ds7Jj0Be039YsT0ePjDXHJX5laDlrarV1XnF6wtwL/tD67 PPOl9DhJKqP7hOS5ezJSEZy1gdYDa4Yldbg9wpGqJYntVmcD3C6H/y4XSmEWA0jK IDGyomqyOpiegZ0BeHlC0H5nIQ5BVH1ukYc5+DCjr9PMf31q2WkPLo7QiHZkiuKl OoTy9wG2YC1DOn905CGQw0dY+l1iwd1RLylfn6vkThi+G9r6qArNziAzdFQZw5r/ ndq/bg2cNSBHadcWcPAsqJ3PNZqsX4ijvgNGZsMnJ2TBvQEOGc1v8nJGhsDaJWpS T5SVDpusTPMROi8tutbRqHpGiKJ70ui05OtCMl36ffyooMNS+xTK5UPX8mqI545y avSJLJNo+rEOJ8JcC8sCIpDzgPcr8iPFM6D8HXwej9gwkojxuDnlDj8SeqGjSz2D k1aNhGM0Im/tZE7jflNfmMhWCgszH+QzT890VV4Q8Y+syFTghmi+ZVkp8CAN9jdj XdwdGTkX3ivO4S0AKFy4Yxi7cKKMIvjTY386LhX6+RgCtxX0sXpjxb8hlt8WQrkh N1H7fwdF3HJ9kWW740RTbczJw+xdrz8gzjbqnHV7taGIL8L8bGGfoYUVZxnrqjPp FOES0GNy4bmla9hN6EEVRoE6NZ5f7mJ8oK4MzWcyic6b/7TSmWM= =MfeX -----END PGP SIGNATURE----- --Apple-Mail=_1112914B-99FF-4D5A-9EDC-B962050420C7-- From nobody Wed Nov 8 03:38:05 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB6A131A2D for ; Wed, 8 Nov 2017 03:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=nSyAtAm4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eD0kDeiH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzH8DHyD-8eo for ; Wed, 8 Nov 2017 03:38:02 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5511131A08 for ; Wed, 8 Nov 2017 03:38:02 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2FFCF20E75 for ; Wed, 8 Nov 2017 06:38:02 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 08 Nov 2017 06:38:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=esZu5uoGMavO0Vr2HAGoi/chf0dia yNFneIQtHwYaVw=; b=nSyAtAm4mp3cfSUQUEh1w/8wYObBBIAcfsAgAzQwTTTuA hfGb4KwMDCP3ZSrBdjyr2RtO7tRA3QhKxK2iocqrYS2LKNf/QTrj6QaalzqmYJ8X 2SUmFuUaksmd/IgJXdj1o6rNg5+uuzKFVphDb/4S0CKhoNo+XPrFp6GLDJqfL0xC eptFs2nsLV7tly7mDPWX+DZKjefJsidKNDjUj2l2Gk9sdXV6bkNBOoogx/RKjwPp PFWTjMpFYCGFZ/TS+klaT1CwM8FCfuy6FmgYgcMUllL6mqwMx2JUjFDkAEbD6aYG focIfue3y44XzKNWRUrCCbylT5uCIBWxUAvWMNNXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=esZu5u oGMavO0Vr2HAGoi/chf0diayNFneIQtHwYaVw=; b=eD0kDeiH8haEQp0OMCT1uv 04DtpDlZdJvhUO4d/lZiN7P2dAT5ErMp9HQx44QdoBACxIBBFtk67S4SVaFLT9Vt CukU5F86CslrHp9HZ8VmlOQZtNZH6lMNVP7tI1AbG1lK8opnYN7Vivc7J/vsNbYj 5nR3O3MOOcyyGwzoSSGayCsfb1uqZtbJpa7AkaSTZKpIwrt6CuSaZqAQQmWKFCzo yf2N3A0Fx9/Qkcm4c+5TZCqZsO/ngjP7JpG+NGrwiAjqRZ5jkrUSN2Io2sxIR7cz V0DMTOzoz3PZcYgUprmDhtulhBWC0TyO2gBaDfKR9/ZY0ZGsLut0lHc8k5H2o+VA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 123C79E236; Wed, 8 Nov 2017 06:38:02 -0500 (EST) Message-Id: <1510141081.2708699.1165592200.65CD490D@webmail.messagingengine.com> From: Alexey Melnikov To: dispatch@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9 In-Reply-To: References: Date: Wed, 08 Nov 2017 11:38:01 +0000 Archived-At: Subject: Re: [dispatch] Review of draft-campbell-sip-messaging-smime-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 11:38:04 -0000 On Mon, Nov 6, 2017, at 02:54 PM, Cullen Jennings wrote: > > Relevant comments ... > > I have implement S/MIME for encryption with SIP and Simple and I think > this document provides some excellent clarifications and updates. I have implemented S/MIME signing and encryption in email. I found the document to be well written and have good level of details. > I agree with the the new MTI ciphers. I think I mostly agree with this, although I have to ask why certain EC curves (like 25519) are not recommended, considering recent work in Curdle/Lamps WG. > Overall, I think the update in this draft improves the security defined > in SIMPLE and MSRP. From nobody Wed Nov 8 17:01:19 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165E0124B0A for ; Wed, 8 Nov 2017 17:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IsYgUpZtuGK for ; Wed, 8 Nov 2017 17:01:16 -0800 (PST) Received: from smtp120.ord1c.emailsrvr.com (smtp120.ord1c.emailsrvr.com [108.166.43.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D28D128B44 for ; Wed, 8 Nov 2017 17:01:16 -0800 (PST) Received: from smtp16.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B963EC0228; Wed, 8 Nov 2017 20:01:13 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 73729C0288; Wed, 8 Nov 2017 20:01:13 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.101.93] ([UNAVAILABLE]. [128.107.241.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 08 Nov 2017 20:01:13 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 8 Nov 2017 17:02:08 -0800 Cc: DISPATCH list Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 01:01:18 -0000 Dispatch seems like a fine place to figure out where to dispatch this.=20= It seems to me that most our people with compression expertise tend to = be places other that HTTPBIS. Very similar work has been done in the = NETVC and codec groups for their entropy encoders. This might be a good = candidate for a small mini WG that just did this.=20 > On Nov 1, 2017, at 2:35 PM, Murray S. Kucherawy = wrote: >=20 > >=20 > In September, I submitted draft-kucherawy-dispatch-zstd, which = introduces a new compression mechanism and seeks to register media = types and content encodings for it. The most obvious application for it = is HTTP payloads, but it has other possible applications. >=20 > I don't know of IETF venues other than this one and maybe the ART list = where this kind of thing might be discussed, or how we might dispatch = it. Offlist conversation with Mark Nottingham suggested maybe HTTPBIS = might like to at least discuss this, but I haven't looked to see if it = fits within their current charter. >=20 > Suggestions for discussion venues or processing options are welcome. >=20 > -MSK > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Nov 12 15:58:33 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966EF124F57 for ; Sun, 12 Nov 2017 15:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkSNR0f9ZXR3 for ; Sun, 12 Nov 2017 15:58:30 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F631205F0 for ; Sun, 12 Nov 2017 15:58:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 29C5D7C327E for ; Mon, 13 Nov 2017 00:58:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erUyiN80Fax8 for ; Mon, 13 Nov 2017 00:58:26 +0100 (CET) Received: from [31.133.156.124] (dhcp-9c7c.meeting.ietf.org [31.133.156.124]) by mork.alvestrand.no (Postfix) with ESMTPSA id F2FA17C0CEB for ; Mon, 13 Nov 2017 00:58:25 +0100 (CET) To: dispatch@ietf.org References: From: Harald Alvestrand Message-ID: <00d1e900-243f-7e0f-46b3-5b8c4e8bf28f@alvestrand.no> Date: Mon, 13 Nov 2017 00:58:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D3ABABF09F1A8EE69F610E67" Content-Language: en-US Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 23:58:32 -0000 This is a multi-part message in MIME format. --------------D3ABABF09F1A8EE69F610E67 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable stuff that I couldn't see addressed in the draft or in the thread: - choice of name - is it still open? (anything with "standard" in the name probably isn't) - target application domain (text, video, images, "other") - performance (I don't think any of these techniques are novel, so performance should be known) - IPR If I were choosing to take this up, pass it along as Info or try to block it altogether, those would be things I'd want to know. On 11/01/2017 10:35 PM, Murray S. Kucherawy wrote: > > > In September, I submitted draft-kucherawy-dispatch-zstd, which > introduces a new compression=C2=A0 mechanism and seeks to register medi= a > types and content encodings for it.=C2=A0 The most obvious application = for > it is HTTP payloads, but it has other possible applications. > > I don't know of IETF venues other than this one and maybe the ART list > where this kind of thing might be discussed, or how we might dispatch > it.=C2=A0 Offlist conversation with Mark Nottingham suggested maybe HTT= PBIS > might like to at least discuss this, but I haven't looked to see if it > fits within their current charter. > > Suggestions for discussion venues or processing options are welcome. > > -MSK > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 Surveillance is pervasive. Go Dark. --------------D3ABABF09F1A8EE69F610E67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

stuff that I couldn't see addressed in the draft or in the thread:

- choice of name - is it still open? (anything with "standard" in the name probably isn't)
- target application domain (text, video, images, "other")
- performance (I don't think any of these techniques are novel, so performance should be known)
- IPR

If I were choosing to take this up, pass it along as Info or try to block it altogether, those would be things I'd want to know.

On 11/01/2017 10:35 PM, Murray S. Kucherawy wrote:

<chair hat clearly off>

In September, I submitted draft-kucherawy-dispatch-zstd, which introduces a new compression mechanism and seeks to register media types and content encodings for it. The most obvious application for it is HTTP payloads, but it has other possible applications.

I don't know of IETF venues other than this one and maybe the ART list where this kind of thing might be discussed, or how we might dispatch it. Offlist conversation with Mark Nottingham suggested maybe HTTPBIS might like to at least discuss this, but I haven't looked to see if it fits within their current charter.

Suggestions for discussion venues or processing options are welcome.

-MSK
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

-- 
Surveillance is pervasive. Go Dark.

--------------D3ABABF09F1A8EE69F610E67-- From nobody Sun Nov 12 16:16:07 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE7A126C26 for ; Sun, 12 Nov 2017 16:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT0yMSnLq7-f for ; Sun, 12 Nov 2017 16:16:03 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8561201F2 for ; Sun, 12 Nov 2017 16:16:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0C8AC7C327E for ; Mon, 13 Nov 2017 01:16:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzajBOxcXOdl for ; Mon, 13 Nov 2017 01:15:59 +0100 (CET) Received: from [31.133.156.124] (dhcp-9c7c.meeting.ietf.org [31.133.156.124]) by mork.alvestrand.no (Postfix) with ESMTPSA id 925E67C0CEB for ; Mon, 13 Nov 2017 01:15:58 +0100 (CET) To: dispatch@ietf.org References: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net>

From: Harald Alvestrand Message-ID: <7ea5fe01-47f4-773a-7686-f32116ddbafb@alvestrand.no> Date: Mon, 13 Nov 2017 01:15:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5A3DD7D5039080D0F7F11173" Content-Language: en-US Archived-At: Subject: Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:16:05 -0000 This is a multi-part message in MIME format. --------------5A3DD7D5039080D0F7F11173 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 08/17/2017 12:03 PM, Bradley Meck wrote: > Hiya! > > > My initial reaction to this statement was: so why aren't we seeing a > request for a new media type? > > This was discussed in a few different places, ultimately culminating > in no body wanting to take that route. You can read some info on that > in the link to the informative TC39 > issue https://github.com/tc39/ecma262/issues/322. It appears you might > be more interested in the HTML side of things, which would be that a > new media type would not load with the specification they have already > started deploying ( there was an issue about this on HTML side > in https://github.com/whatwg/html/issues/558 ). Some discussion about > a `mode` parameter instead of media type is in an issue on this > proposal https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 > . That might be the better route since it will work in web browsers. > > > You neglect to mention that uses of the module on the web do not > depend on additional distinguishing marks because they have the > type="module" attribute on script tags. > > This is out of band information not based upon content. I did not > think it necessary. Should it be mentioned if it is not based upon > message content nor information in the media type fields? I think that > this statement also applies to some tools such as module bundlers as > well that are using fields in package.json files. Why isn't a MIME type parameter with the format "type=module" the Right Answer for the MIME type registration? > > > Nit: There Are So Many Proper Nouns In This Document. Is that really > necessary? > > I think this is in part a stylistic thing of my writing. I tend to > avoid pronouns and am capitalizing grammar productions in the same > manner as the ECMAScript specification. We could make stylistic > changes though! > > -Brad > > On Thu, Aug 17, 2017 at 12:14 AM, Martin Thomson > > wrote: > > Hi Matt, > > First, this seems fine, almost trivial. > > This statement implies a problem of greater scope than what you > are solving: > > It is not possible to fully determine if a Source Text of > ECMAScript > is meant to be parsed in the Module or Script grammar goals based > upon content alone. > > My initial reaction to this statement was: so why aren't we seeing a > request for a new media type? > > You neglect to mention that uses of the module on the web do not > depend on additional distinguishing marks because they have the > type="module" attribute on script tags. > > Nit: There Are So Many Proper Nouns In This Document. Is that > really necessary? > > On 17 August 2017 at 14:03, Matthew A. Miller >

> wrote: > > Hello DISPATCH, > > > > The ECMAScript/JavaScript media types are in need of some updates. > > We've started an informational document[1] to address that. There > > hasn't been much mailing list discussion yet, but we are asking now > > where to direct the work. > > > > In consultation with the ART Directors, we ask this document be > adopted > > by DISPATCH as one of its simple administrative documents. > > > > The document is < > > https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs > >. > > > > Issues can be filed on the GitHub repository at < > > https://github.com/bmeck/I-D/issues > >. > > > > > > Thank you, > > > > -- > > - m&m > > > > Matthew A. Miller > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. --------------5A3DD7D5039080D0F7F11173 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 08/17/2017 12:03 PM, Bradley Meck wrote:

Hiya!

> My initial reaction to this statement was: so why aren't we seeing a
request for a new media type?

This was discussed in a few different places, ultimately culminating in no body wanting to take that route. You can read some info on that in the link to the informative TC39 issue https://github.com/tc39/ecma262/issues/322. It appears you might be more interested in the HTML side of things, which would be that a new media type would not load with the specification they have already started deploying ( there was an issue about this on HTML side in https://github.com/whatwg/html/issues/558 ). Some discussion about a `mode` parameter instead of media type is in an issue on this proposal https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 . That might be the better route since it will work in web browsers.

> You neglect to mention that uses of the module on the web do not
depend on additional distinguishing marks because they have the
type="module" attribute on script tags.

This is out of band information not based upon content. I did not think it necessary. Should it be mentioned if it is not based upon message content nor information in the media type fields? I think that this statement also applies to some tools such as module bundlers as well that are using fields in package.json files.

Why isn't a MIME type parameter with the format "type=module" the Right Answer for the MIME type registration?

> Nit: There Are So Many Proper Nouns In This Document. Is that really necessary?

I think this is in part a stylistic thing of my writing. I tend to avoid pronouns and am capitalizing grammar productions in the same manner as the ECMAScript specification. We could make stylistic changes though!

-Brad

On Thu, Aug 17, 2017 at 12:14 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

Hi Matt,

First, this seems fine, almost trivial.

This statement implies a problem of greater scope than what you are solving:

It is not possible to fully determine if a Source Text of ECMAScript
is meant to be parsed in the Module or Script grammar goals based
upon content alone.

My initial reaction to this statement was: so why aren't we seeing a
request for a new media type?

You neglect to mention that uses of the module on the web do not
depend on additional distinguishing marks because they have the
type="module" attribute on script tags.

Nit: There Are So Many Proper Nouns In This Document. Is that really necessary?

On 17 August 2017 at 14:03, Matthew A. Miller

<linuxwolf+ietf@outer-planes.net> wrote:
> Hello DISPATCH,
>
> The ECMAScript/JavaScript media types are in need of some updates.
> We've started an informational document[1] to address that. There
> hasn't been much mailing list discussion yet, but we are asking now
> where to direct the work.
>
> In consultation with the ART Directors, we ask this document be adopted
> by DISPATCH as one of its simple administrative documents.
>
> The document is <
> https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs >.
>
> Issues can be filed on the GitHub repository at <
> https://github.com/bmeck/I-D/issues >.
>
>
> Thank you,
>
> --
> - m&m
>
> Matthew A. Miller
>
>

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

-- 
Surveillance is pervasive. Go Dark.

--------------5A3DD7D5039080D0F7F11173-- From nobody Sun Nov 12 16:18:08 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90F91270A3 for ; Sun, 12 Nov 2017 16:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ee9g8UJsG79 for ; Sun, 12 Nov 2017 16:17:57 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25873126E7A for ; Sun, 12 Nov 2017 16:17:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 849927C359E for ; Mon, 13 Nov 2017 01:17:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baltIK0FBsCK for ; Mon, 13 Nov 2017 01:17:54 +0100 (CET) Received: from [31.133.156.124] (dhcp-9c7c.meeting.ietf.org [31.133.156.124]) by mork.alvestrand.no (Postfix) with ESMTPSA id DC0B67C327E for ; Mon, 13 Nov 2017 01:17:53 +0100 (CET) To: dispatch@ietf.org References: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net>

<7ea5fe01-47f4-773a-7686-f32116ddbafb@alvestrand.no> From: Harald Alvestrand Message-ID: <7de32264-6d01-11ba-be8f-8c66c04048f6@alvestrand.no> Date: Mon, 13 Nov 2017 01:17:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7ea5fe01-47f4-773a-7686-f32116ddbafb@alvestrand.no> Content-Type: multipart/alternative; boundary="------------7EBCF817ED492519043E3C61" Content-Language: en-US Archived-At: Subject: Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:18:07 -0000 This is a multi-part message in MIME format. --------------7EBCF817ED492519043E3C61 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/13/2017 01:15 AM, Harald Alvestrand wrote: > On 08/17/2017 12:03 PM, Bradley Meck wrote: >> Hiya! >> >> > My initial reaction to this statement was: so why aren't we seeing a >> request for a new media type? >> >> This was discussed in a few different places, ultimately culminating >> in no body wanting to take that route. You can read some info on that >> in the link to the informative TC39 >> issue https://github.com/tc39/ecma262/issues/322. It appears you >> might be more interested in the HTML side of things, which would be >> that a new media type would not load with the specification they have >> already started deploying ( there was an issue about this on HTML >> side in https://github.com/whatwg/html/issues/558 ). Some discussion >> about a `mode` parameter instead of media type is in an issue on this >> proposal https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 >> . That might be the better route since it will work in web browsers. >> >> > You neglect to mention that uses of the module on the web do not >> depend on additional distinguishing marks because they have the >> type="module" attribute on script tags. >> >> This is out of band information not based upon content. I did not >> think it necessary. Should it be mentioned if it is not based upon >> message content nor information in the media type fields? I think >> that this statement also applies to some tools such as module >> bundlers as well that are using fields in package.json files. > > Why isn't a MIME type parameter with the format "type=module" the > Right Answer for the MIME type registration? Apologies; I missed the "goal" parameter that does exactly this. I do wonder why the MIME registration departs from the HTML tag practice and calls it "goal" rather than "type". --------------7EBCF817ED492519043E3C61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/13/2017 01:15 AM, Harald Alvestrand wrote:

On 08/17/2017 12:03 PM, Bradley Meck wrote:

Hiya!

> My initial reaction to this statement was: so why aren't we seeing a
request for a new media type?

This was discussed in a few different places, ultimately culminating in no body wanting to take that route. You can read some info on that in the link to the informative TC39 issue https://github.com/tc39/ecma262/issues/322. It appears you might be more interested in the HTML side of things, which would be that a new media type would not load with the specification they have already started deploying ( there was an issue about this on HTML side in https://github.com/whatwg/html/issues/558 ). Some discussion about a `mode` parameter instead of media type is in an issue on this proposal https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 . That might be the better route since it will work in web browsers.

> You neglect to mention that uses of the module on the web do not
depend on additional distinguishing marks because they have the
type="module" attribute on script tags.

This is out of band information not based upon content. I did not think it necessary. Should it be mentioned if it is not based upon message content nor information in the media type fields? I think that this statement also applies to some tools such as module bundlers as well that are using fields in package.json files.

Why isn't a MIME type parameter with the format "type=module" the Right Answer for the MIME type registration?

Apologies; I missed the "goal" parameter that does exactly this.
I do wonder why the MIME registration departs from the HTML tag practice and calls it "goal" rather than "type".

--------------7EBCF817ED492519043E3C61-- From nobody Sun Nov 12 17:55:53 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416611241F5 for ; Sun, 12 Nov 2017 17:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKy1OmzycpNU for ; Sun, 12 Nov 2017 17:55:48 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C395127698 for ; Sun, 12 Nov 2017 17:55:48 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9EF7227543; Sun, 12 Nov 2017 20:55:45 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: Date: Mon, 13 Nov 2017 09:55:42 +0800 Cc: Cullen Jennings Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170619174225.10412.qmail@ary.lan> <33E62B35-8048-4EBA-A5D8-409564D5B667@iii.ca> To: John R Levine , Dispatch WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 01:55:50 -0000 Did this draft get followed up on? I think it=E2=80=99s a good idea. I have seen form submission systems = include this information in e-mail payload data, so there is a use case. I do not share the privacy worries: if the system does not want to = include it, it does not have to. It is up to the system and the local = regulations under which it operates. Other than the obvious need to clarify the ABNF, I think that it would = be reasonable to reuse some syntax from another Internet standard for IP = addresses, to handle =E2=80=9CIPvFuture=E2=80=9D (see, e.g., RFC 3986; = General-address-literal of RFC 5321, etc.) without needing to update = this document. On the other hand, if you take the exact syntax from = another Internet standard, you may not be able to redact the IP address = so easily: the ABNF would be different so the implementation would also = be different. Sean > On Jun 21, 2017, at 2:27 AM, John R Levine wrote: >=20 >> For v6, how much would typically be redacted ? >=20 > I get the impression it'd usually either be the high half or the low = half. We worked this out with some German ISPs who had strong opinions = about what they would be allowed to include. >=20 > Keep in mind that the alternative to a redacted IP is not a full IP, = it's no IP at all. >=20 > R's, > John >=20 >>> On Jun 19, 2017, at 11:42 AM, John Levine wrote: >>>=20 >>> This draft came out of a discussion last week at M3AAWG. The issue = is >>> that bad guys (or more likely bad bots) fill out web forms and = include >>> fake mail addresses, the forms provoke confirmation mail which then >>> mailbombs the address(es). >>>=20 >>> This draft adds a new header to indicate that a message is in = response >>> to a form submission: >>>=20 >>> Form-Sub: v=3D1; ip4=3D198.51.x.x >>>=20 >>> The IP address is that of the web client, which may be partly = redacted >>> with "x" for privacy reasons. If a recipient mail system sees too >>> many of them, it may block the system that's sending them. The = draft >>> also asks for an enhanced status code which means we rejected this >>> message because it's part of a flood with Form-Sub headers. >>>=20 >>> When we had the discussion there were people from at least two large >>> consumer mail systems and a dozen hosters and (sending) mail service >>> providers in the room, so it is likely this will be implemented >>> enough to see if it's useful. >>>=20 >>> At this point the main point of writing the draft was to have a >>> reference so I could ask IANA to register the header and status = code. >>> If it does turn out to be useful I'll come back and ask for it to be >>> dispatched into a standards track document. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Nov 12 17:58:04 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F83128656 for ; Sun, 12 Nov 2017 17:58:02 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlXHZFZkdJrH for ; Sun, 12 Nov 2017 17:57:58 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A63127B73 for ; Sun, 12 Nov 2017 17:57:54 -0800 (PST) Received: (qmail 37142 invoked from network); 13 Nov 2017 01:57:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id:user-agent; s=9114.5a08fc22.k1711; bh=Y0Ax2RzJeu8SakvWmpitlin1RN9ck2tocuCkl3uOfCU=; b=gtWjR4LonYWWTWsKSwfISvjqyJWtR0EyvfkYVMuBAJc+Rg2kjpz9xn6s0xP1lrMIT6nWiD+KLzfO7CTcrHZcDiHAsXKo5G8DW1AY29sG27h8eGThKK1Td7M6Il9SrB6pXxQc5VA+IOgL7rddS4zavGj7bl7Pv45tOI+vXJHKFvqLC3Zd41bnBqPhdaJBlTt9UYCv+PwN1xHkJLrEd99cLrX4VnxKGtpaItHiTS41Mjp4qA11L0QB8ej8IKcvbZrE Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 13 Nov 2017 01:57:53 -0000 Date: 13 Nov 2017 09:57:50 +0800 Message-ID: From: "John R. Levine" To: "Dispatch WG" User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-821259074-1510538240=:6356" Content-ID: Archived-At: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 (fwd) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 01:58:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-821259074-1510538240=:6356 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Mon, 13 Nov 2017, Sean Leonard wrote: > Did this draft get followed up on? Not yet, but Gmail and others M3 people are implementing it. After next M3 I will bring it back with reports from the field. > > I think it’s a good idea. I have seen form submission systems include this > information in e-mail payload data, so there is a use case. > > I do not share the privacy worries: if the system does not want to include > it, it does not have to. It is up to the system and the local regulations > under which it operates. > > Other than the obvious need to clarify the ABNF, I think that it would be > reasonable to reuse some syntax from another Internet standard for IP > addresses, to handle “IPvFuture” (see, e.g., RFC 3986; > General-address-literal of RFC 5321, etc.) without needing to update this > document. On the other hand, if you take the exact syntax from another > Internet standard, you may not be able to redact the IP address so easily: > the ABNF would be different so the implementation would also be different. > > Sean > >> On Jun 21, 2017, at 2:27 AM, John R Levine wrote: >> >>> For v6, how much would typically be redacted ? >> >> I get the impression it'd usually either be the high half or the low half. >> We worked this out with some German ISPs who had strong opinions about what >> they would be allowed to include. >> >> Keep in mind that the alternative to a redacted IP is not a full IP, it's >> no IP at all. >> >> R's, >> John >> >>>> On Jun 19, 2017, at 11:42 AM, John Levine wrote: >>>> >>>> This draft came out of a discussion last week at M3AAWG. The issue is >>>> that bad guys (or more likely bad bots) fill out web forms and include >>>> fake mail addresses, the forms provoke confirmation mail which then >>>> mailbombs the address(es). >>>> >>>> This draft adds a new header to indicate that a message is in response >>>> to a form submission: >>>> >>>> Form-Sub: v=1; ip4=198.51.x.x >>>> >>>> The IP address is that of the web client, which may be partly redacted >>>> with "x" for privacy reasons. If a recipient mail system sees too >>>> many of them, it may block the system that's sending them. The draft >>>> also asks for an enhanced status code which means we rejected this >>>> message because it's part of a flood with Form-Sub headers. >>>> >>>> When we had the discussion there were people from at least two large >>>> consumer mail systems and a dozen hosters and (sending) mail service >>>> providers in the room, so it is likely this will be implemented >>>> enough to see if it's useful. >>>> >>>> At this point the main point of writing the draft was to have a >>>> reference so I could ask IANA to register the header and status code. >>>> If it does turn out to be useful I'll come back and ask for it to be >>>> dispatched into a standards track document. >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-821259074-1510538240=:6356-- From nobody Sun Nov 12 18:22:57 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D10127136 for ; Sun, 12 Nov 2017 18:22:55 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6po4dzdUiTN for ; Sun, 12 Nov 2017 18:22:53 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB01F127077 for ; Sun, 12 Nov 2017 18:22:53 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 108612754E; Sun, 12 Nov 2017 21:22:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: Date: Mon, 13 Nov 2017 10:22:48 +0800 Cc: DISPATCH list Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:22:55 -0000 Checked out the draft. To simplify it, it looks like it is most analogous to the RFC 1950 / RFC = 1951 documents that describe the algorithm(s) for ZLIB / DEFLATE, for = compression of arbitrary data streams. Those documents do not specify MIME types, and I do not think this = document draft-kucherawy-dispatch-zstd should do so either. The media = type registration is weak: there is no way to signal inside the format = what is inside other than an arbitrary stream of bytes. It is not a file = archive format, or another kind of container format that identifies = parts. 3.2. Content Encoding is fine. I request that we get an OID registration for this for use with = Compressed Data Content Type for CMS, RFC 3274. That way it could be = used with S/MIME or other formats that use CMS or S/MIME (seeing as how = CMS / S/MIME are general container formats). Surveying other container formats and doing the appropriate = registrations with them in this draft would be appropriate, if one can = articulate a use case in those respective formats. Sean > On Nov 2, 2017, at 5:35 AM, Murray S. Kucherawy = wrote: >=20 > >=20 > In September, I submitted draft-kucherawy-dispatch-zstd, which = introduces a new compression mechanism and seeks to register media = types and content encodings for it. The most obvious application for it = is HTTP payloads, but it has other possible applications. >=20 > I don't know of IETF venues other than this one and maybe the ART list = where this kind of thing might be discussed, or how we might dispatch = it. Offlist conversation with Mark Nottingham suggested maybe HTTPBIS = might like to at least discuss this, but I haven't looked to see if it = fits within their current charter. >=20 > Suggestions for discussion venues or processing options are welcome. >=20 > -MSK > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Nov 12 19:20:29 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B31128AFE for ; Sun, 12 Nov 2017 19:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMmkqtaO8BTS for ; Sun, 12 Nov 2017 19:20:26 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498431274D0 for ; Sun, 12 Nov 2017 19:20:26 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id 31so17983369qtz.9 for ; Sun, 12 Nov 2017 19:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jEIpANAO2M/7rU/4G1lRODyTRTSMV+MK4B5EtKj/LLs=; b=oPYGKAMgypnUQV5iZaF3eIeX3+KU2ESMkyGV6UXl9sjdOdUX7Pb3YqnJW8pfkZv0UF oKI1l5brNpm/3gm17SXNWXBMEyVa+5L8U9TzaZAjoQvzmPumUHxY/D6r2PwvhGQGil7V gfu6hYSJKdy6WI4ueCL9fdkZdYYRiH5q9Rr1bFBNg4ev4EgRxg8Gk+5aBa6ob5AcZI/9 KqQFTxVKRzkUkI01GJuemADncf6rpO7iQxy6nAjHoxJKDDnyovXFHV6P02Tu1D+0OsQ8 q13WE3VcXdjHt0ty+rYmSXpFdReGMdoVJ+8moabgSxlyC6mg9IcEFC9aTxf0hhXRkQnL mxkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jEIpANAO2M/7rU/4G1lRODyTRTSMV+MK4B5EtKj/LLs=; b=Vzqm1H4cdB43oA5SM9IuF1BY/DZpKYkw/JA6ZX9yzdtmyZzPqjnFrlECghw1HX1Odc soBgpo2rbtD6jGmB7n4mg9IChTkL8LsNO946dO2SE4j/TUtyDvHEjBFJsAxJLHizD1XC sensNgPmYBEuQAsNW9miml1OaoRgCb7wp7pUpk2SSr4PGytmBMUr/2vTJmxQ8xHGpSZi sBe1pYBlu984hhlmJhdTiS3Is2ZEslB+reuE9qBUIaxMUDpWw2VZoFrjXU4g8T8ZefTd NqnvJ74yBIYmcU5FGr8LCDLLiUadn+/MdWXzIlLuYdA6WQ+NHAXN05FmfQ7U6crD0kqz tohg== X-Gm-Message-State: AJaThX7HLBtme+LsTI5FIHHxEtorn2BJma89lfYGNaqQGB0puNdLQmbv VjHS99wqhYL/gZ9XtTXFxvpOs2oQ86p9KKEsuhDliA== X-Google-Smtp-Source: AGs4zMZAqQ4GzLwZSbFNHegyi7rG3nXtOAxBiFVC5KfN8Z0pMUWKo+Mbr/JMcNopN4wqZ91SRYFH/Gt1mJKQ3a8Rx98= X-Received: by 10.237.57.1 with SMTP id l1mr11689621qte.302.1510543225120; Sun, 12 Nov 2017 19:20:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Sun, 12 Nov 2017 19:20:24 -0800 (PST) In-Reply-To: <00d1e900-243f-7e0f-46b3-5b8c4e8bf28f@alvestrand.no> References: <00d1e900-243f-7e0f-46b3-5b8c4e8bf28f@alvestrand.no> From: "Murray S. Kucherawy" Date: Mon, 13 Nov 2017 11:20:24 +0800 Message-ID: To: Harald Alvestrand Cc: DISPATCH list Content-Type: multipart/alternative; boundary="001a1140512a59ebea055dd4c047" Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:20:28 -0000 --001a1140512a59ebea055dd4c047 Content-Type: text/plain; charset="UTF-8" Keeping in mind that I'm mostly running process here and not competent in the underlying technologies: On Mon, Nov 13, 2017 at 7:58 AM, Harald Alvestrand wrote: > stuff that I couldn't see addressed in the draft or in the thread: > > - choice of name - is it still open? (anything with "standard" in the name > probably isn't) > I can ask what the origin of the name is, but given the number of implementations that already exist, changing it now might be rather annoying. - target application domain (text, video, images, "other") > Arbitrary. The web site where the work is based (http://www.zstd.net) doesn't identify a specific use case that's targeted. - performance (I don't think any of these techniques are novel, so > performance should be known) > Substantial performance comparison is available at the above URL. - IPR > In compliance with BCPs 78 and 79. -MSK --001a1140512a59ebea055dd4c047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Keeping in mind that I'm mostly running process here a= nd not competent in the underlying technologies:

On Mon, Nov 13= , 2017 at 7:58 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

=20 =20 =20

stuff that I couldn= 't see addressed in the draft or in the thread:

- choice of name - is it still open? (anything with "standard&qu= ot; in the name probably isn't)

I can ask what the origin of the name is, but given the number of i= mplementations that already exist, changing it now might be rather annoying= .

- target application domain (text, video, images, "other")<= br>

Arbitrary.=C2=A0 The web si= te where the work is based (http://www.zstd= .net) doesn't identify a specific use case that's targeted.
=

- performance (I don't think any of these techniques are novel, s= o performance should be known)

Substantial performance comparison is available at the above URL.

- IPR

In compliance w= ith BCPs 78 and 79.

-MSK

--001a1140512a59ebea055dd4c047-- From nobody Sun Nov 12 19:22:18 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11224126DCA for ; Sun, 12 Nov 2017 19:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfmAtHZyZY9i for ; Sun, 12 Nov 2017 19:22:15 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C50F1293E0 for ; Sun, 12 Nov 2017 19:22:15 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id c36so11814109qtc.11 for ; Sun, 12 Nov 2017 19:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kwVRUldIgAbqU100waqY76//t/VZjqbQifv7xDtuZCk=; b=MQSJM+bW8TXB2dLcAFOzpnNhPMyhqT4RJe86kGkF4Z2ylYgB9MWVUt9WiPnDfjwKzw YV4IDaQdOrpcOOBMPNwrPN6Hdugt7XTie1Hrxy3fFAbxdUz3PTxnJskt5euMeEuWyZZn v0R1bIp0Iv4vel0lB1KnBGLpy9j5lpbwXkFlqB4WKg9eJqwNgAQhQrboS+V+rHMDLR6I Lbh7Tx3dHS0BnlnfvJymzWmt3fnPaVd7VjwZXsYRZSgX1/f52K7MAFgpQ/s2Pskhn1ed L5lAtnj5ChmTBZf5A/cQCfwGR1bVLTmj9hICPYRHS2x8BpgM/u9JVYRiWnpSBnPZPb1d aPCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kwVRUldIgAbqU100waqY76//t/VZjqbQifv7xDtuZCk=; b=KShWCQLETE2AWteUXpP2f0/tw++D6WCOEGUMn9B4i/C9mr7xbzb7DEni9Ygops7C1v IDBbtLSzLV/6Un/Ax7IbDNL2yCP+n2B7x7hKBkD5/dG7IuVr8x7n61KxB0wv2DV0pwgu kFhnGUVRaH7Z89vv4uMjzk2rOU/sBOpRY0Kf7u+1LvqM9uCqFsxxFQyO/Xy8Hm+nsXc0 eyNagHex4ZPgeKWjt4oVpjDXI8se+gGY16BbJDU0T4/NPb1DZhWMGE46TAG03ZzFSOhJ PZzJX1hftAWo73YhHSYYaRwCYHnlqt8uPJuY0cujnijr/xYkUf/TtP9OIok+4s393Bax +cMg== X-Gm-Message-State: AJaThX7mOm0GLRhFiecUZZbNr84JK9RTgNCd34FYzyZGPGrOe6rimM0T Rs8d4rqlYoWAKpp6tVkN9GEEHXqdK01tz+y0ug3JKg== X-Google-Smtp-Source: AGs4zMY8DhcR1hXW7nN++qMe0w85MFaPfxkZmGDwsoahpE+6aOWdErBr//IPII2QJV9r4a0sxG1P1NTJhJPL4rBlOTs= X-Received: by 10.200.50.78 with SMTP id y14mr475844qta.84.1510543334505; Sun, 12 Nov 2017 19:22:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Sun, 12 Nov 2017 19:22:13 -0800 (PST) In-Reply-To: References:

From: "Murray S. Kucherawy" Date: Mon, 13 Nov 2017 11:22:13 +0800 Message-ID: To: Sean Leonard Cc: DISPATCH list Content-Type: multipart/alternative; boundary="001a113bef4cdf01c8055dd4c614" Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:22:17 -0000 --001a113bef4cdf01c8055dd4c614 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 13, 2017 at 10:22 AM, Sean Leonard wrote: > Those documents do not specify MIME types, and I do not think this > document draft-kucherawy-dispatch-zstd should do so either. The media type > registration is weak: there is no way to signal inside the format what is > inside other than an arbitrary stream of bytes. It is not a file archive > format, or another kind of container format that identifies parts. > Why does that imply that a media type is not appropriate? A module receiving this content for processing needs to know what format it's in, and I believe that's what these are for. I request that we get an OID registration for this for use with Compressed > Data Content Type for CMS, RFC 3274. That way it could be used with S/MIME > or other formats that use CMS or S/MIME (seeing as how CMS / S/MIME are > general container formats). > Wilco. Surveying other container formats and doing the appropriate registrations > with them in this draft would be appropriate, if one can articulate a use > case in those respective formats. > Can you suggest an example? -MSK --001a113bef4cdf01c8055dd4c614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2017 at 10:22 AM, Sean Leonard <dev+= ietf@seantek.com> wrote:

Those documents do not = specify MIME types, and I do not think this document draft-kucherawy-dispat= ch-zstd should do so either. The media type registration is weak: there is = no way to signal inside the format what is inside other than an arbitrary s= tream of bytes. It is not a file archive format, or another kind of contain= er format that identifies parts.

Why do= es that imply that a media type is not appropriate?=C2=A0 A module receivin= g this content for processing needs to know what format it's in, and I = believe that's what these are for.

I request that we get an OID registration for this for = use with Compressed Data Content Type for CMS, RFC 3274. That way it could = be used with S/MIME or other formats that use CMS or S/MIME (seeing as how = CMS / S/MIME are general container formats).

Wilco.

Surveying other container formats and doing the appropriate registrations w= ith them in this draft would be appropriate, if one can articulate a use ca= se in those respective formats.

Can you= suggest an example?

-MSK

--001a113bef4cdf01c8055dd4c614-- From nobody Sun Nov 12 19:24:02 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38B71293F2 for ; Sun, 12 Nov 2017 19:24:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBB0MnY7-cnN for ; Sun, 12 Nov 2017 19:24:00 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA11128B88 for ; Sun, 12 Nov 2017 19:24:00 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id f8so18003231qta.5 for ; Sun, 12 Nov 2017 19:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6Lfeegp5dzgxUdlzpvosKrwbtTTCdSrWUDPVA8cGuzQ=; b=kcyLE3gr2AUg9SACtSFGfkTTt5QdjvwkVV8CskL14qpNHbz06o2rt+LusCMF7HN+Hr aj1dL2QGrFJ8RxzJXTyLVCoY10c3QxSgh9Y0O9sjW0EQ/WN2KuV+NQPz45NlRA0aaWjZ fAjQcZUJTYdoiIWYj7nOH1350SLboXVziS4LnJe3kjLVIdlwHW4o0WflMHGnCiag+45J R1v0QQVvTDoWL8s91mCt6H8IhzWVCRMR2iGRXQBR9BN16ZaXPGEPX8C0TdNiwHutPV82 jgWw4zuD8Ux3FvaBRiMCdD8Wb7it2LEzaTPp7a2TIGqV5A2di/kkNFXUIDfFaKK+o9ZZ Fk1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6Lfeegp5dzgxUdlzpvosKrwbtTTCdSrWUDPVA8cGuzQ=; b=U0A5lvO3kjk42IsvrEjH+z0YYctJeHEguz4m6tKR1x3TIv0rjZj9A94v733RzdaBB/ FnELjpU6XN4PfmqEyxEqryUraZrLr7qy33wIwh3ljNi8nRLr88sxDhDNbRT7vXxqdL8J XcsdWU7hDjtTKTarJmN9SzglY3bZLWeyDKz+ddypuIGISBA1LERc1FRzuG/Unw3qwg/Q 5DucN8oX2RD2cnqQZvbOgbJ6aC6juJlADDU+vYmuKpGgaNBtxWuxuai/yb4WH2FPCoWn P/LpqlLY2cW6mIh7GhiNqxKnggTkzBOeZmsDhob2irXav16m6qdW/pEs1BlkMB01v2rP booQ== X-Gm-Message-State: AJaThX5zg+p+5KzByHFxv9OPliDAB0l//OABA+RHAyPNPe5g3fGfZHlN D052jgmWGCGcdx26PXDVi04ivFQQdqsBu8kEib8RIQ== X-Google-Smtp-Source: AGs4zMb2i33bEsDcCtGNRktX+VdLB8bMhU5HGCiw5mDkBwOa0AbImQdbfyMAc1IuRyDoD23iGDpgseCPSbM6yuToJSM= X-Received: by 10.237.41.37 with SMTP id s34mr2762750qtd.154.1510543439008; Sun, 12 Nov 2017 19:23:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Sun, 12 Nov 2017 19:23:58 -0800 (PST) In-Reply-To: References:

From: "Murray S. Kucherawy" Date: Mon, 13 Nov 2017 11:23:58 +0800 Message-ID: To: Sean Leonard Cc: DISPATCH list Content-Type: multipart/alternative; boundary="94eb2c124a221998a9055dd4cd80" Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:24:02 -0000 --94eb2c124a221998a9055dd4cd80 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 13, 2017 at 11:22 AM, Murray S. Kucherawy wrote: > I request that we get an OID registration for this for use with Compressed >> Data Content Type for CMS, RFC 3274. That way it could be used with S/MIME >> or other formats that use CMS or S/MIME (seeing as how CMS / S/MIME are >> general container formats). >> > > Wilco. > RFC3274 doesn't describe a process for registering an OID. Can you point me in the right direction? -MSK --94eb2c124a221998a9055dd4cd80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2017 at 11:22 AM, Murray S. Kucherawy <= superuser@gmail.com> wrote:

=
I request that we get an OI= D registration for this for use with Compressed Data Content Type for CMS, = RFC 3274. That way it could be used with S/MIME or other formats that use C= MS or S/MIME (seeing as how CMS / S/MIME are general container formats).

Wilco.

RFC3274 doesn't describe a process for reg= istering an OID.=C2=A0 Can you point me in the right direction?
<= br>
-MSK

--94eb2c124a221998a9055dd4cd80-- From nobody Sun Nov 12 22:01:15 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3871287A5 for ; Sun, 12 Nov 2017 22:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYFmRE6rsy5i for ; Sun, 12 Nov 2017 22:01:11 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54015127977 for ; Sun, 12 Nov 2017 22:01:11 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8E9D227530; Mon, 13 Nov 2017 01:01:09 -0500 (EST) From: Sean Leonard Message-Id: <2A0764E1-1ADA-4510-A717-23095A4362F0@seantek.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_024AACA5-14A0-47B3-ACC2-26DD688673E3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 14:01:06 +0800 In-Reply-To: Cc: DISPATCH list To: "Murray S. Kucherawy" References:

X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 06:01:13 -0000 --Apple-Mail=_024AACA5-14A0-47B3-ACC2-26DD688673E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2017, at 11:22 AM, Murray S. Kucherawy = wrote: >=20 > On Mon, Nov 13, 2017 at 10:22 AM, Sean Leonard > wrote: > Those documents do not specify MIME types, and I do not think this = document draft-kucherawy-dispatch-zstd should do so either. The media = type registration is weak: there is no way to signal inside the format = what is inside other than an arbitrary stream of bytes. It is not a file = archive format, or another kind of container format that identifies = parts. >=20 > Why does that imply that a media type is not appropriate? A module = receiving this content for processing needs to know what format it's in, = and I believe that's what these are for. Working on this. It strikes me as either=E2=80=A6odd=E2=80=A6or just not = really that useful for the purpose. It is a format, but it=E2=80=99s = just a format for a stream of arbitrary bytes. There is no way to label = it internally beyond the implicit =E2=80=9Capplication/octet-stream=E2=80=9D= type. Content-Encoding is therefore very appropriate, but that is for HTTP, = not (as of yet) for mail or other messaging formats. May I ask, what is the reason why you need a media type? Let me think about it=E2=80=A6maybe it would be good to ask the = media-types ML. >=20 > I request that we get an OID registration for this for use with = Compressed Data Content Type for CMS, RFC 3274. That way it could be = used with S/MIME or other formats that use CMS or S/MIME (seeing as how = CMS / S/MIME are general container formats). >=20 > Wilco. >=20 > Surveying other container formats and doing the appropriate = registrations with them in this draft would be appropriate, if one can = articulate a use case in those respective formats. >=20 > Can you suggest an example? Not offhand, just thought of those two (Content-Encoding, and RFC 3274 = CompressedData media type). Well there=E2=80=99s TLS v1.2 compression methods. Just joking! :-) Sean >=20 > -MSK --Apple-Mail=_024AACA5-14A0-47B3-ACC2-26DD688673E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 13, 2017, at 11:22 AM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Mon, Nov 13, 2017 at 10:22 AM, Sean Leonard = <dev+ietf@seantek.com> = wrote:
Those documents do = not specify MIME types, and I do not think this document = draft-kucherawy-dispatch-zstd should do so either. The media type = registration is weak: there is no way to signal inside the format what = is inside other than an arbitrary stream of bytes. It is not a file = archive format, or another kind of container format that identifies = parts.

Why does that imply that a media type = is not appropriate? A module receiving this content for processing = needs to know what format it's in, and I believe that's what these are = for.

Working on this. It strikes me as = either=E2=80=A6odd=E2=80=A6or just not really that useful for the = purpose. It is a format, but it=E2=80=99s just a format for a stream of = arbitrary bytes. There is no way to label it internally beyond the = implicit =E2=80=9Capplication/octet-stream=E2=80=9D type.

Content-Encoding is therefore very appropriate, = but that is for HTTP, not (as of yet) for mail or other messaging = formats.

May I ask, what is the = reason why you need a media type?

Let = me think about it=E2=80=A6maybe it would be good to ask the media-types = ML.

I request that we get = an OID registration for this for use with Compressed Data Content Type = for CMS, RFC 3274. That way it could be used with S/MIME or other = formats that use CMS or S/MIME (seeing as how CMS / S/MIME are general = container formats).

Wilco.

Surveying other container formats and doing the appropriate = registrations with them in this draft would be appropriate, if one can = articulate a use case in those respective formats.

Can you suggest an = example?

Not offhand, just thought of those two = (Content-Encoding, and RFC 3274 CompressedData media = type).

Well there=E2=80=99s TLS v1.2 = compression methods. Just joking! :-)

Sean

-MSK

= --Apple-Mail=_024AACA5-14A0-47B3-ACC2-26DD688673E3-- From nobody Sun Nov 12 22:19:04 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0201129353 for ; Sun, 12 Nov 2017 22:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T27pf85sPQOa for ; Sun, 12 Nov 2017 22:19:00 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A59B129471 for ; Sun, 12 Nov 2017 22:19:00 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id n32so2148601qtb.2 for ; Sun, 12 Nov 2017 22:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d+fiGO+Vx74hlcF65P8B1vRyjhATsJrEg3Pukf1XyB8=; b=duSbUBsaL09pLd+hD78cljZjobvCmnjLnJUz+R0Lie6Z1RIFtU8EXlX+7vmblxX41+ BR6RxDAaNZjrGroheTu/yL85WUjFRWeK/660dGUEk93DFGeH7Id87x1H+dKR13o4onQa QKWoUFbePwYfW2L5Aqw3OBxypJjnkisDshAbouCW/j6m9neBxkDzCdcr8ZMlrQD8/XHF eC0aqlNvGzlPVSpOo7qagSpxvVwzNKS6Jw0fdpZCJIFCF1A0Ubj4tPsoIQCNGZ4rC79S GHUSGn3cwT41BNZwcAyBHtLK1+8/ygdKln2U7EvzpYk8glHEODeB3VaI2vyy/kbF7msz u7Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d+fiGO+Vx74hlcF65P8B1vRyjhATsJrEg3Pukf1XyB8=; b=eBBoqv8Qc1wHRViMW/Yj8Xv0TphWbIeE/P7qRmvd6QclYPECvHRuV/jDScb+2vMChV DBNLVxt/ZEWzudAvTqlyHsB4N+L0a9vB7DFCeGjqEW3EKIu+UxXoJms3ABNX9twMyrZJ Gmmqy6/Qa+w/QXtZzTCzIgo7vueGRSI7pZdId6tleHq3AI/vM+g4zMUf+yJr0sLbEi3o fg/g11dRGzsxTOCfbtxN8SKooqKHbtt53BqUZZibUR5B5Xsfy9gYBbv9399IAEmMcv6A hghO2JFsrw4w5SMT8d8SVs66avlknJu7gzSNqe9pBLu1pdk+5SxA03Tk8TjOARFeKt+t zdKg== X-Gm-Message-State: AJaThX7UES0Od4VE5utDmeQZwNfK5w/aaOadZnlNQQy7/hShUl1Xaxm6 jGDpsavyIcAOp1ILzVE/iLz5t7YXdgBX8QW2Npo= X-Google-Smtp-Source: AGs4zMZOPbDzMEitKDqVPZaBsM72YorJwhVEZR0AhlZPDlK6XteqhSfT6qOyFHR0A4AwUghxUrpIxr/aDD5bZpgtvnE= X-Received: by 10.200.50.78 with SMTP id y14mr924539qta.84.1510553939031; Sun, 12 Nov 2017 22:18:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Sun, 12 Nov 2017 22:18:58 -0800 (PST) In-Reply-To: <2A0764E1-1ADA-4510-A717-23095A4362F0@seantek.com> References:

<2A0764E1-1ADA-4510-A717-23095A4362F0@seantek.com> From: "Murray S. Kucherawy" Date: Mon, 13 Nov 2017 14:18:58 +0800 Message-ID: To: Sean Leonard Cc: DISPATCH list Content-Type: multipart/alternative; boundary="001a113bef4cf3394e055dd73ef9" Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 06:19:02 -0000 --001a113bef4cf3394e055dd73ef9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2017 at 2:01 PM, Sean Leonard wrote: > Why does that imply that a media type is not appropriate? A module > receiving this content for processing needs to know what format it's in, > and I believe that's what these are for. > > > Working on this. It strikes me as either=E2=80=A6odd=E2=80=A6or just not = really that > useful for the purpose. It is a format, but it=E2=80=99s just a format fo= r a stream > of arbitrary bytes. There is no way to label it internally beyond the > implicit =E2=80=9Capplication/octet-stream=E2=80=9D type. > Don't you need a hint as to how to decode an octet stream that's encoded in some way? The kind of signaling Content-Encoding provides is something that's needed more generally, and this is what a media type would solve. -MSK --001a113bef4cf3394e055dd73ef9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2017 at 2:01 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:

=
Why does that im= ply that a media type is not appropriate?=C2=A0 A module receiving this con= tent for processing needs to know what format it's in, and I believe th= at's what these are for.

Working on this. = It strikes me as either=E2=80=A6odd=E2=80=A6or just not really that useful = for the purpose. It is a format, but it=E2=80=99s just a format for a strea= m of arbitrary bytes. There is no way to label it internally beyond the imp= licit =E2=80=9Capplication/octet-stream=E2=80=9D type.

Don't you need a hint as to how to= decode an octet stream that's encoded in some way?

T= he kind of signaling Content-Encoding provides is something that's need= ed more generally, and this is what a media type would solve.

-MSK

--001a113bef4cf3394e055dd73ef9-- From nobody Mon Nov 13 01:25:53 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F0C129505 for ; Mon, 13 Nov 2017 01:25:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_1-Z9jkOOhc for ; Mon, 13 Nov 2017 01:25:50 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0138.outbound.protection.outlook.com [104.47.93.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AF61294F7 for ; Mon, 13 Nov 2017 01:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ViOaxE1im5nKpQJTbRvTGEnePg0omMMfLVpskqRSuCc=; b=YwNjs5/rWZ1NWqiCFOVBiPY5k/r2odtnh92O2RaQCuPdpReHKd4Zboav1wnU07Tt3Bi2IoxGPEIYnSEJMMfXubBLuzDKktuNTxSTaVvIXtNHnKnqw08cyJ2lYXNFkdWPOkvDoqQXJycx7aQtu4wztnYuJkw6PQ3/UKPWlI/30PM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [100.70.12.254] (133.2.59.38) by OS1PR01MB0245.jpnprd01.prod.outlook.com (2a01:111:e400:ac0c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 09:25:47 +0000 To: "Murray S. Kucherawy" , Sean Leonard Cc: DISPATCH list References:

<2A0764E1-1ADA-4510-A717-23095A4362F0@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Mon, 13 Nov 2017 18:25:46 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.59.38] X-ClientProxiedBy: KAWPR01CA0052.jpnprd01.prod.outlook.com (2603:1096:402:b::12) To OS1PR01MB0245.jpnprd01.prod.outlook.com (2a01:111:e400:ac0c::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fc8d5ebd-194a-4578-2621-08d52a7885f9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:OS1PR01MB0245; X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0245; 3:AVtjaLVcDRnyPRJ4fwLFv1/jAq6+OJidgoc0bO/YoYaDG6mssSY/iYaRRkYiUFdG0IqLe2BoYCF0U5RQbg+FcB350cVCK+FWxCGuVRoII5zBgsBL+jF39VLLsmXtwnVBXxskGpB5LIBg+X398N3YjQSbcaCga9CElaRcjb02fxY1WMbbGVieF1JWwfl5OU8IgkA+oN9TaUF2D9sMEASyPR2t/q77fcTFYSxUvBCCgDPz79i/gJQPxS5cBoTZubxB; 25:gGNFt92dL3QfX3frv5SClvJMsOLwViL7cqz7o1W+kiUNgl4fL5r6z5FWFX+cK8aJYE51ZV+T4Dde41xKi3ht2AQjUmbHVy2LyCqbGkkqIZQzEQan6w/d3Z7RDR0KyxoBQQpJBaInf6FQOAHtjNtsTz3UB1hVi66Hn/Zpbz6ercqGOxE0YPYGauh94AcQQcxxsHKlF0x8JOpEFNbZaAvdxHSe0BFMIY37osVNOs8QOlZGG1HQVsrhDH0rFPOON0HE0ONYe1Lr3SQ1a0kIcENhIiPIsURU5aVUIoHQiWuU1/ODHC0wSa4PZxfUoS7lrCnjlLtEv6DcQ5UBmnvXhs6X9oTWHrB3zh3FmQrStPeVah4=; 31:6/2BpxU149k0yBnAaBjop0rFS1fO2Y1XLJ3s9Ii3obYyxfud4p4QWNNudjQor2lUZlNeV153aXWU2nndFu2fZ+qaDGShQ/FybD2ul10MClQ8GnLxixpEhc+1fyb25ueb+ER2uvKQ/11AKikrm5oOqPyGW+eqvsY2lvqBAkhtDQYfrCd33cdSHrYfIb2OnyrLNDD5S537tllSy+2QZ8B5LZ1EG/HKjLlEhq5ksSemu8E= X-MS-TrafficTypeDiagnostic: OS1PR01MB0245: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231022)(100000703101)(100105400095)(10201501046)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201703061421075)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:OS1PR01MB0245; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:OS1PR01MB0245; X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0245; 4:C/B4jb3PEzrr6gziHYc08GqJF60pu4Kc/tr4udLf01+TrSrTWAzmdas+GZikvY//q7EiK6zRH6L+WDiRqb/tYtBz5BNULt1A+mJTrkZ0Boe64NU3Z3HKSqWgRJIPC99dQCLyJ69avmUe6Duz0jLyx1T+15n8jd/uMq+Z3MtPRzXt0wYE57AQebXGMX4JcSzK3bbRpGQHMSCDEOLAc1GxkeY0bF2+UWxK/4G9HDRR5QqU8UWrF4kp8MEhFBpL581lGt16qE2kYIcCKtOOaFlKQQ== X-Forefront-PRVS: 0490BBA1F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(346002)(376002)(199003)(24454002)(189002)(68736007)(76176999)(54356999)(110136005)(65826007)(5660300001)(53546010)(2950100002)(42882006)(101416001)(16576012)(786003)(58126008)(83506002)(16526018)(7736002)(74482002)(305945005)(8676002)(50466002)(81166006)(50986999)(64126003)(49976008)(6116002)(25786009)(106356001)(3846002)(508600001)(105586002)(81156014)(2870700001)(2906002)(93886005)(33646002)(31686004)(189998001)(8936002)(86362001)(65956001)(6246003)(66066001)(47776003)(65806001)(31696002)(53936002)(67846002)(6486002)(23676003)(229853002)(97736004)(4326008)(39060400002)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0245; H:[100.70.12.254]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMjQ1OzIzOm9tVkI2QVJZd2xkZVUwWmZINmJsa2RHM2pl?= =?utf-8?B?L1l4TVFabE9qK0RrUEZLK2VMeU5qRUkzVFhJdEFhNWZEcWs4cVEwZnp3K0Jk?= =?utf-8?B?c0QydjEwcHd5RUhqTDMrRjdCeFZmSk9rWWxrbUJsOXV0dTdIN2JzS3RUaHBa?= =?utf-8?B?cUdKT1pDbG0yRCtieFpvWUFqOElpbGtZczEzM1dEbUdJdERIMmw4QUt4SjB3?= =?utf-8?B?L0lwSDdEcmdid3U4czJ0cDkzVFIxSHVpaFd3YVBSY3BsOEFYZzZKUFVEWkFj?= =?utf-8?B?K0w5MDB6NXUxSlRrQm5iekwwbWxZNXhUenQ5NDYraG1tUktFWjJFTVdpeTlv?= =?utf-8?B?OHdCVnBjT204VVQwZThQR0VYb1VoNyt0VzRMT2h2SnRlcUlEUnZaTC8xTXZr?= =?utf-8?B?NG4wZks4SXNCcC9Sa0Yzb0hQSThYZEFDNVV6U1hSUEg0RWd5Q0hOUDdQeFNJ?= =?utf-8?B?ZXhuQjJ1SDBVYXRqTDcwblBUTG1YV3ZFNlpJYkJjVVZubHYyYXU3emp4Wlor?= =?utf-8?B?VVlWWVd0SmpJREVtVThiNGJPYi9ld2RpWXA4bk9NTTlyS2R6LzZrcDFJT2l0?= =?utf-8?B?ZmpTaDRzSk82ZG81aDhzUGtRbi9LVmRvSm9za0VOU1RadFFjdFNqZ3lka3ZU?= =?utf-8?B?WEZiT2UrZExFM1JhcUZTVDZXU3RUVkpYTHhhbnEwdzNhMXB6ZTNUVDRkNy9E?= =?utf-8?B?aGg2ZzBsd0d3Q3h0UWdhN3RKaHNJQUl4Z3IvY3JhZHM2VldxZU9vQ2djUlB5?= =?utf-8?B?K3d3YkJQL05aZTl4L2hJREUvaXB4MWJPN0d3ejVrbTE4OHY4aUZDVDJldVFy?= =?utf-8?B?d0VkV2dEaDY2Ryt1cG5IMjlyRWtnOXJ6RkhJKzV1bk5URUVrMHVpcFZ4MG91?= =?utf-8?B?aTRYNDgxNlI1WExFcXhsMjVZa3pNdXdUaDhpRUtlMDhMZEVvL0xSZ1o4OEw2?= =?utf-8?B?V1dmaDdNZGFsMzJySFVNeWJTQzV5ODZ2YVRCNEJNUk51TFhkZC9iUmJ6UW96?= =?utf-8?B?bHBqSk13MzJnb2VwWTVYdDNNdFo1cGNRMVkvWHFFNlVsVGJXblRLRDdKT1R6?= =?utf-8?B?U1FvWWx1L25yTU1vWmFMMGYxaTVrSjd3c1NUVDNTcDA0YVZWTm9kbDhBc253?= =?utf-8?B?amR6Nm5qbGVjYUFhN2NpYjBpcm9RWlY1SlQ1cWlHZExVRzMwVmJWeWZiOEFp?= =?utf-8?B?TjdiMUhhcHBqV0NlUFhPM2k2ZzZGRE9zMnMwYkpVQmtQbHlGTVRhczl4bExm?= =?utf-8?B?ckZWNDVUcFZhM0hJcFFYUmJqTnY4OFFjazRWMGZEN09rZFZFNWcrVzBGTzhQ?= =?utf-8?B?WS91WFJTR0pyT2h5Nlpzcmk0K1F0SFNuSzVwc2RDcEdqc2lFWnJOaFVuc2ty?= =?utf-8?B?bDRHUW5mSlJUUGkrbE9rOGZib3VRd0hKNE83TUZEcS92RWVwdFE5c2toYklv?= =?utf-8?B?VkYxQXVlRmhvMUExMnl2WnV6TTQwTlRBNHFZbmk2SHZhNCtac3VBeDFLdHNs?= =?utf-8?B?UkM4c3BHTzFRalZYMUQwZUo4Q0JOZjVIdTduQmk0LzF0dklxSG40M3NxOWxF?= =?utf-8?B?VG9MajJRaE02WmhNRnRkTjFsR1pYeTlwTWRna2JYTHJlVHpsNjhxWnpVOGl4?= =?utf-8?B?WU5QMEoza3N4RTJtWGtza0pLajAya1RiUWl2Wkk3clRpZVdmNUNUQzZORGJl?= =?utf-8?B?dFRjS1VETFcwb2tPUm4vd2s4WW9iWnR0K3lRSG9jRFZHdDZyUFhRTThCOHQ1?= =?utf-8?B?ZmU1Z01YOFdEZjZnbVBuUUl2aHV1OW5Gb28reWdJODdTQlV3SkdhNEloM3ZM?= =?utf-8?B?Yys1MEtSZ1R2aUh2d3dPbjA3OGhBVW44d2xFbGczSE8zdTNzQWVRZHlwZi9y?= =?utf-8?B?dTcrdTZjYlYvTFo1Q0tIUWJNbGhvUlcvY2Y5Q2I0U2ljTGpSS2x0dnUwR1Nz?= =?utf-8?B?Qkc2YStEWGNRPT0=?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0245; 6:v1J+5oGWcuBgrjasQG1bk9g1U/gpJa9lo1WedQMHivABHb5vd9nFSTnW+Pc/ILE971vnhOk7ApWpS5lajWqqZ1Ujx2HpS75w63RePdjT89nP3f6IQh19+SohErUBaCU/AhT4oOzZWSYiGp7IWJ7DJbh9c3UJChLMGtVm+Nltx4Kbs6MD6iT6/Gxhq6gs4Grh2mXmfvGjgTbvCez78PPevWoDBG65IPQ9neVKPO2mx7+MIQ1H39qIQBVSbmH1ych1+xwPTflc2hcjwHnnjW14gKQ10LKHDDm0R9tVJVQSgJfi3XvVrqCaUCnT8mn/tAuzf/i6AStGV9d1pbSXnB5MA+MNjmCAHGOPqhA3Le06nGU=; 5:Api7wzp+3rXyjmlZwo7pqHtHuZaojwi/O4PgNo81BtnSKExK6igBxPoH6VnHAFMolnOB+yYWmsFEobJpowSO+OVlbe6RT5aaLwjcr7YAWffg2K9WZwTzan6bqg72GumELWHcsQXghAwQfW9iKFWahJD4eKREmKbaoGBGZ2mIfs8=; 24:htqALqh3nn1jcb/fmM0f3ODOoxfWAu9vurASWaXavj7RAKyH3BGk7l53ILVwnYFMopMbVSoTbdUlfKuDZpQ2xhLWUPiUGHaeN5O9E7J72zE=; 7:+77tDJzOOd9+IDFXARuCZDWnFTOHnSH7e6JFPkkxdIl9b1Tsap9uSPuW2jW57mm+8n3muBTskIz8GP4L/bxrzC8I7VpbvW+89O7USlEBW4XWUnDcUNhMu7xLasMC05hLdpwBJXp0Te/6Lnq/ES/dcyP2tJ98O39s8Un4lIWbT6w4ac6lbIffx+DDa5e4XLR0MtfYbhLhMfKvVmHyKeTRqnZhqTljStQypqEHjUuLCHYYS+nctiRk9fvCFJQIfKOp SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2017 09:25:47.1808 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fc8d5ebd-194a-4578-2621-08d52a7885f9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0245 Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:25:52 -0000 On 2017/11/13 15:18, Murray S. Kucherawy wrote: > On Mon, Nov 13, 2017 at 2:01 PM, Sean Leonard wrote: >> Working on this. It strikes me as either…odd…or just not really that >> useful for the purpose. It is a format, but it’s just a format for a stream >> of arbitrary bytes. There is no way to label it internally beyond the >> implicit “application/octet-stream” type. >> > > Don't you need a hint as to how to decode an octet stream that's encoded in > some way? Yes. But I think what Sean is saying is that above and beyond that, you'd (in many if not most use cases) also want to know what the decoded octet stream is about. Otherwise, this information has to be transmitted on a side channel. Regards, Martin. From nobody Tue Nov 14 16:26:09 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED4A1250B8 for ; Tue, 14 Nov 2017 16:26:08 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOjs4ZWgxs-g for ; Tue, 14 Nov 2017 16:26:06 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A701270AC for ; Tue, 14 Nov 2017 16:26:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4D7C87C3891 for ; Wed, 15 Nov 2017 01:26:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydNJoBhL0lgr for ; Wed, 15 Nov 2017 01:26:03 +0100 (CET) Received: from [31.133.145.32] (dhcp-9120.meeting.ietf.org [31.133.145.32]) by mork.alvestrand.no (Postfix) with ESMTPSA id D166F7C3862 for ; Wed, 15 Nov 2017 01:26:02 +0100 (CET) To: dispatch@ietf.org References:

<2A0764E1-1ADA-4510-A717-23095A4362F0@seantek.com>

From: Harald Alvestrand Message-ID: Date: Wed, 15 Nov 2017 01:25:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dispatch] Zstandard compression X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 00:26:09 -0000 On 11/13/2017 10:25 AM, Martin J. Dürst wrote: > On 2017/11/13 15:18, Murray S. Kucherawy wrote: >> On Mon, Nov 13, 2017 at 2:01 PM, Sean Leonard >> wrote: > >>> Working on this. It strikes me as either…odd…or just not really that >>> useful for the purpose. It is a format, but it’s just a format for a >>> stream >>> of arbitrary bytes. There is no way to label it internally beyond the >>> implicit “application/octet-stream” type. >>> >> >> Don't you need a hint as to how to decode an octet stream that's >> encoded in >> some way? > > Yes. But I think what Sean is saying is that above and beyond that, > you'd (in many if not most use cases) also want to know what the > decoded octet stream is about. Otherwise, this information has to be > transmitted on a side channel. One (horribly ugly) way of doing this is to have something like a "contains" parameter: mime-type: application/zstandard; contains="text/plain; charset=utf-8" That's one form of side channel for passing the data around. Not sure if anyone would use it. But it's such an ugly way of doing things that it should definitely be suggested on the media-types list, not here. > > Regards, Martin. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. From nobody Tue Nov 14 20:34:05 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE6312785F for ; Tue, 14 Nov 2017 20:34:04 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRTupLGJhDL7 for ; Tue, 14 Nov 2017 20:34:02 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1FFE126E64 for ; Tue, 14 Nov 2017 20:34:02 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4ED6827551; Tue, 14 Nov 2017 23:33:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: Date: Wed, 15 Nov 2017 12:33:57 +0800 Cc: dispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References:

<2A0764E1-1ADA-4510-A717-23095A4362F0@seantek.com>

To: Harald Alvestrand X-Mailer: Apple Mail (2.3273) Archived-At: