From nobody Sun Dec 14 07:17:16 2014
Return-Path: <nico@cryptonector.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5DE1A1EE9 for <media-types@ietfa.amsl.com>; Sat, 13 Dec 2014 19:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVPSYjNbva6S for <media-types@ietfa.amsl.com>; Sat, 13 Dec 2014 19:30:01 -0800 (PST)
Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A0D1A1E10 for <media-types@ietf.org>; Sat, 13 Dec 2014 19:29:59 -0800 (PST)
Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id sBE3TdAU024681 for <media-types@iana.org>; Sun, 14 Dec 2014 03:29:59 GMT
Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id B98EC20047B84; Sat, 13 Dec 2014 19:29:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Zhua6B80x6i34a HWNHYICYzVPpU=; b=XupVrlmKA4uaHZasU6PoWA4V9eweOB2HzkDpNo2G+cD+Un LXr5bye7/hPc8YgXHBre/ukUeUWqEgUkGkW+jLOThn0akvsIIDe5p+ho1r64EVqE qhy07d9QEGuk1hoTSJ3IW/s6t0JXiJAuyH7vzASpdOKxSJqHFsiGaAewkcxIU=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 5A36720047B83; Sat, 13 Dec 2014 19:29:38 -0800 (PST)
Date: Sat, 13 Dec 2014 21:29:37 -0600
From: Nico Williams <nico@cryptonector.com>
To: media-types@iana.org
Message-ID: <20141214032931.GZ3448@localhost>
References: <20141213164641.30100.14864.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141213164641.30100.14864.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/BllHsF5lpztcpUy-5Myjr3S1PyI
X-Mailman-Approved-At: Sun, 14 Dec 2014 07:17:15 -0800
Cc: json-chairs@tools.ietf.org, Barry Leiba <barryleiba@computer.org>, draft-ietf-json-text-sequence@tools.ietf.org
Subject: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Dec 2014 03:30:03 -0000

   The MIME media type for JSON text sequences is application/json-seq.

   Type name: application

   Subtype name: json-seq

   Required parameters: N/A

   Optional parameters: N/A

   Encoding considerations: binary

   Security considerations: See <this document, once published>,
   Section 3.

   Interoperability considerations: Described herein.

   Published specification: <this document, once published>.

   Applications that use this media type: <by publication time
   <https://stedolan.github.io/jq> is likely to support this format>.

   Fragment identifier considerations: N/A.

   Additional information:

   o  Deprecated alias names for this type: N/A.

   o  Magic number(s): N/A

   o  File extension(s): N/A.

   o  Macintosh file type code(s): N/A.

   o  Person & email address to contact for further information:

      *  json@ietf.org

   o  Intended usage: COMMON

   o  Author: See the "Authors' Addresses" section of this document.

   o  Change controller: IETF


From nobody Mon Dec 15 05:31:38 2014
Return-Path: <derhoermi@gmx.net>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AC41A6EEF for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 05:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, SPF_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oncmoh2-dNES for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 05:31:36 -0800 (PST)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A089E1A6EED for <media-types@ietf.org>; Mon, 15 Dec 2014 05:31:35 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id sBFDVEw9007967 for <media-types@iana.org>; Mon, 15 Dec 2014 13:31:34 GMT
Received: from netb ([89.204.130.234]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LZzY9-1XWvjM39yP-00lmxk; Mon, 15 Dec 2014 14:30:40 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Nico Williams <nico@cryptonector.com>
Date: Mon, 15 Dec 2014 14:30:34 +0100
Message-ID: <9mmt8a1uaopjncvdnpasqur2n6lci15hej@hive.bjoern.hoehrmann.de>
References: <20141213164641.30100.14864.idtracker@ietfa.amsl.com> <20141214032931.GZ3448@localhost>
In-Reply-To: <20141214032931.GZ3448@localhost>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:jBJfi4R/LyAB6xit8bo6RoQF2YiYkW3bvMmPrBc4hcR/XYrcIYy 2M5T1uJkJ78+74vdrN8gv5vLOLLUXqRNfsZHkipLsR1rFZR3SaefdlTpzsujjy4qpbnr6tj uwetQibiyGsI/wnzapAopdReE/+y8oPjr1gSpq0yGhySSJH/Vr8SpSWbgLur2jPqEddOUQL cwiLDvXeXy/6Cx7RbipQg==
X-UI-Out-Filterresults: notjunk:1;
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 15 Dec 2014 13:31:34 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/pZaUlubcVRfHKURRQyxpmyLA-a8
Cc: draft-ietf-json-text-sequence@tools.ietf.org, Barry Leiba <barryleiba@computer.org>, json-chairs@tools.ietf.org, media-types@iana.org
Subject: Re: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 13:31:37 -0000

* Nico Williams wrote:
>   The MIME media type for JSON text sequences is application/json-seq.
>
>   Type name: application
>
>   Subtype name: json-seq
>
>   Required parameters: N/A
>
>   Optional parameters: N/A
>
>   Encoding considerations: binary
>
>   Security considerations: See <this document, once published>,
>   Section 3.

Which says:

   All the security considerations of JSON [RFC7159] apply.  This format
   provides no cryptographic integrity protection of any kind.

   As usual, parsers must operate on as-good-as untrusted input.  This
   means that parsers must fail gracefully in the face of malicious
   inputs.  Note that incremental parsers can produce partial results
   and later indicate failure to parse the remainder of a text.  Note
   that texts that fail to parse and are ignored can be used to smuggle
   data past sequence parsers that don't warn about JSON text failures.

I think the second paragraph is very unclear and should be rewritten. It
seems for instance the first "must" is meant to say that it's a fact of
life rather than state a requirement. It should not say "must" in that
case, and I do not think this is a fact of life. I also do not think the
second sentence follows. The second sentence also seems to use "must" in
a confusing manner. Are parsers required to recover from syntax errors?
The text above can be interpreted like that, but it's not clear. In the
third sentence it is not clear whether parsers are required to report
errors.

Since there are actual conformance requirements related to this in other
sections of the document, it might be better to describe some of the
issues in terms of consequences of failing to implement relevant SHOULD-
level requirements.

>   Applications that use this media type: <by publication time
>   <https://stedolan.github.io/jq> is likely to support this format>.

This field is for the general class of application using the type, like 
3D modeling applications or financial transaction systems. It could say
something like "information exchange systems" or explain that because
this is just multiple JSON documents in one document, applications are
similar in nature as those using ordinary JSON, possibly highlighting
that the features of the format make it more suitable for logging and
related functions. It should not list individual projects or products.

>   Fragment identifier considerations: N/A.
>
>   Additional information:
>
>   o  Deprecated alias names for this type: N/A.
>
>   o  Magic number(s): N/A

As proposed, a non-empty `JSON-sequence` starts with at least one 0x1E
and the characters that can follow in proper documents come from a re-
stricted set. Considering that a leading 0x1E is quite unusual, it may
be reasonable to explain why this field is given as `N/A`.

(There is a typo "JSON textm" in the document.)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 


From nobody Mon Dec 15 08:08:43 2014
Return-Path: <nico@cryptonector.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388081A700D for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 08:08:42 -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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLepotaDNqBf for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 08:08:37 -0800 (PST)
Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300CB1A6FC4 for <media-types@ietf.org>; Mon, 15 Dec 2014 08:08:37 -0800 (PST)
Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id sBFG8GIL012851 for <media-types@iana.org>; Mon, 15 Dec 2014 16:08:36 GMT
Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 8647C2006D30A; Mon, 15 Dec 2014 08:08:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tFBXiYaQ2Nhtra yQZf2Ws+bQURE=; b=MlD++mZRi5FO2Ebm1sUlzSdybqeKBe2ylArsAfvhFZomNf b9Mk0qZIDNIEEGj2pzfzd60PXLOiDYLntDcFMiAn2VXxsZFgeUgOyT/HSGp28vGL vwPoJx4Qsv+O88hJ1gwLYK/ByJ3vbsZI24cVMXK16h7tA1zHAMQd3BZMoN9WU=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 1106D2006D30D; Mon, 15 Dec 2014 08:08:16 -0800 (PST)
Date: Mon, 15 Dec 2014 10:08:15 -0600
From: Nico Williams <nico@cryptonector.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Message-ID: <20141215160809.GC3241@localhost>
References: <20141213164641.30100.14864.idtracker@ietfa.amsl.com> <20141214032931.GZ3448@localhost> <9mmt8a1uaopjncvdnpasqur2n6lci15hej@hive.bjoern.hoehrmann.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9mmt8a1uaopjncvdnpasqur2n6lci15hej@hive.bjoern.hoehrmann.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/OL6Lw2hR_UE2-IdqXOg7QlYFwyU
Cc: draft-ietf-json-text-sequence@tools.ietf.org, Barry Leiba <barryleiba@computer.org>, json-chairs@tools.ietf.org, media-types@iana.org
Subject: Re: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 16:08:42 -0000

On Mon, Dec 15, 2014 at 02:30:34PM +0100, Bjoern Hoehrmann wrote:
> * Nico Williams wrote:
> >   Security considerations: See <this document, once published>,
> >   Section 3.
> 
> Which says:
> 
>    All the security considerations of JSON [RFC7159] apply.  This format
>    provides no cryptographic integrity protection of any kind.
> 
>    As usual, parsers must operate on as-good-as untrusted input.  This
>    means that parsers must fail gracefully in the face of malicious
>    inputs.  Note that incremental parsers can produce partial results
>    and later indicate failure to parse the remainder of a text.  Note
>    that texts that fail to parse and are ignored can be used to smuggle
>    data past sequence parsers that don't warn about JSON text failures.
> 
> I think the second paragraph is very unclear and should be rewritten. It
> seems for instance the first "must" is meant to say that it's a fact of
> life rather than state a requirement. [...]

Correct, it's a fact of life, not a normative requirement.

>                                [...]. It should not say "must" in that
> case, and I do not think this is a fact of life. [...]

How is the need to operate on "as-good-as-untrusted input" not a fact of
life?

>                                           [...]. I also do not think the
> second sentence follows. The second sentence also seems to use "must" in
> a confusing manner. Are parsers required to recover from syntax errors?

They are required to not be exploitable through malformed input,
including syntactically valid as well as syntactically invalid inputs.

No actual requirement as to recovery is given, but it's recommended that
sequence parsers continue; see section 2.3.  The security considerations
should not be read in isolation.

> The text above can be interpreted like that, but it's not clear. In the
> third sentence it is not clear whether parsers are required to report
> errors.

This is covered elsewhere in the document.

> Since there are actual conformance requirements related to this in other
> sections of the document, it might be better to describe some of the
> issues in terms of consequences of failing to implement relevant SHOULD-
> level requirements.

I did not want to repeat normative language in the security
considerations.

> >   Applications that use this media type: <by publication time
> >   <https://stedolan.github.io/jq> is likely to support this format>.
> 
> This field is for the general class of application using the type, like 
> 3D modeling applications or financial transaction systems. It could say
> something like "information exchange systems" or explain that because
> this is just multiple JSON documents in one document, applications are
> similar in nature as those using ordinary JSON, possibly highlighting
> that the features of the format make it more suitable for logging and
> related functions. It should not list individual projects or products.

There are, in fact, protocols using JSON text sequences as specified in
earlier version of the I-D.  We could not reach consensus to adopt that
form.  The format in -11 hopefully will be adopted by those (and other)
protocols.

> >   o  Magic number(s): N/A
> 
> As proposed, a non-empty `JSON-sequence` starts with at least one 0x1E
> and the characters that can follow in proper documents come from a re-
> stricted set. Considering that a leading 0x1E is quite unusual, it may
> be reasonable to explain why this field is given as `N/A`.

A one-byte magic number seems a bit too small to me to count as magic.

This format could be extended to XML.  An XML and a JSON text sequence
would then require further examination than just that one byte.  It
seems to me inadvisable to specify a magic number at this time.

If the list insists on it, I'll make this change.

> (There is a typo "JSON textm" in the document.)

Thanks.

Nico
-- 


From nobody Mon Dec 15 08:21:38 2014
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691461A86DE for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 08:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiSZOsbqaptQ for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 08:21:32 -0800 (PST)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A105D1A802F for <media-types@ietf.org>; Mon, 15 Dec 2014 08:21:27 -0800 (PST)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id sBFGL62O027904 for <media-types@iana.org>; Mon, 15 Dec 2014 16:21:26 GMT
Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBFGL31P067073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 09:21:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20141215160809.GC3241@localhost>
Date: Mon, 15 Dec 2014 08:21:03 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1FC42E1-573F-4F0E-B581-554CD7226C78@vpnc.org>
References: <20141213164641.30100.14864.idtracker@ietfa.amsl.com> <20141214032931.GZ3448@localhost> <9mmt8a1uaopjncvdnpasqur2n6lci15hej@hive.bjoern.hoehrmann.de> <20141215160809.GC3241@localhost>
To: Media Types list <media-types@iana.org>
X-Mailer: Apple Mail (2.1993)
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Mon, 15 Dec 2014 16:21:26 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/sEn4V3FRPEcWLL6m6zYk-dE5_-s
Cc: Nico Williams <nico@cryptonector.com>, json-chairs@tools.ietf.org
Subject: Re: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 16:21:35 -0000

On Dec 15, 2014, at 8:08 AM, Nico Williams <nico@cryptonector.com> =
wrote:
> On Mon, Dec 15, 2014 at 02:30:34PM +0100, Bjoern Hoehrmann wrote:
>> * Nico Williams wrote:
>>>  Security considerations: See <this document, once published>,
>>>  Section 3.
>>=20
>> Which says:
>>=20
>>   All the security considerations of JSON [RFC7159] apply.  This =
format
>>   provides no cryptographic integrity protection of any kind.
>>=20
>>   As usual, parsers must operate on as-good-as untrusted input.  This
>>   means that parsers must fail gracefully in the face of malicious
>>   inputs.  Note that incremental parsers can produce partial results
>>   and later indicate failure to parse the remainder of a text.  Note
>>   that texts that fail to parse and are ignored can be used to =
smuggle
>>   data past sequence parsers that don't warn about JSON text =
failures.
>>=20
>> I think the second paragraph is very unclear and should be rewritten. =
It
>> seems for instance the first "must" is meant to say that it's a fact =
of
>> life rather than state a requirement. [...]
>=20
> Correct, it's a fact of life, not a normative requirement.

I agree with Nico, and disagree that it is "unclear". Saying "parsers =
MUST fail gracefully in the face of malicious inputs" is far less clear.

>=20
>>                               [...]. It should not say "must" in that
>> case, and I do not think this is a fact of life. [...]
>=20
> How is the need to operate on "as-good-as-untrusted input" not a fact =
of
> life?

We can change "must" to "needs to", but this change only applies to =
people who think that 2119 language, even in lowercase, trumps the =
normal interpretation of English.

>>                                          [...]. I also do not think =
the
>> second sentence follows. The second sentence also seems to use "must" =
in
>> a confusing manner. Are parsers required to recover from syntax =
errors?
>=20
> They are required to not be exploitable through malformed input,
> including syntactically valid as well as syntactically invalid inputs.
>=20
> No actual requirement as to recovery is given, but it's recommended =
that
> sequence parsers continue; see section 2.3.  The security =
considerations
> should not be read in isolation.

+1=20

>> The text above can be interpreted like that, but it's not clear. In =
the
>> third sentence it is not clear whether parsers are required to report
>> errors.
>=20
> This is covered elsewhere in the document.

+1

>> Since there are actual conformance requirements related to this in =
other
>> sections of the document, it might be better to describe some of the
>> issues in terms of consequences of failing to implement relevant =
SHOULD-
>> level requirements.
>=20
> I did not want to repeat normative language in the security
> considerations.

+1

>>>  Applications that use this media type: <by publication time
>>>  <https://stedolan.github.io/jq> is likely to support this format>.
>>=20
>> This field is for the general class of application using the type, =
like=20
>> 3D modeling applications or financial transaction systems. It could =
say
>> something like "information exchange systems" or explain that because
>> this is just multiple JSON documents in one document, applications =
are
>> similar in nature as those using ordinary JSON, possibly highlighting
>> that the features of the format make it more suitable for logging and
>> related functions. It should not list individual projects or =
products.
>=20
> There are, in fact, protocols using JSON text sequences as specified =
in
> earlier version of the I-D.  We could not reach consensus to adopt =
that
> form.  The format in -11 hopefully will be adopted by those (and =
other)
> protocols.

Bj=C3=B6rn is saying that the value for this entry should not be =
specific applications, but a general class. "Systems that might have =
long streams of JSON texts" would suffice.

>=20
>>>  o  Magic number(s): N/A
>>=20
>> As proposed, a non-empty `JSON-sequence` starts with at least one =
0x1E
>> and the characters that can follow in proper documents come from a =
re-
>> stricted set. Considering that a leading 0x1E is quite unusual, it =
may
>> be reasonable to explain why this field is given as `N/A`.
>=20
> A one-byte magic number seems a bit too small to me to count as magic.
>=20
> This format could be extended to XML.  An XML and a JSON text sequence
> would then require further examination than just that one byte.  It
> seems to me inadvisable to specify a magic number at this time.
>=20
> If the list insists on it, I'll make this change.

Please do *not*. 0x1E is not a sufficiently magic number to identify a =
blob as a JSON text sequence.

--Paul Hoffman=


From nobody Mon Dec 15 08:59:54 2014
Return-Path: <nico@cryptonector.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86341A7D85 for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 08:59:53 -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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQzGV7eJH7tR for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 08:59:52 -0800 (PST)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162CB1A86E0 for <media-types@ietf.org>; Mon, 15 Dec 2014 08:59:46 -0800 (PST)
Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id sBFGxQKU025120 for <media-types@iana.org>; Mon, 15 Dec 2014 16:59:46 GMT
Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 588234012D695; Mon, 15 Dec 2014 08:59:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=6U+RfUpkJ+nn62hWBrQeav+WDDQ=; b=K8qbEIAdhs5 4KrlmVZFnME1CWy+llcU8KrksCH+GGaI+PRN+BIkkc3UOvOTN9NIXDLyXYD8gaWD PwWHTKpmHTzsDDnD13SVXKE8hanoxZm9mgeSnmS6pDe0jzxCtkq+dTRPY4BzaGXw a0IYlT+KozZdeNSJ2yRjVtMCFbUsc/hg=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id EEE864012D68E; Mon, 15 Dec 2014 08:59:24 -0800 (PST)
Date: Mon, 15 Dec 2014 10:59:09 -0600
From: Nico Williams <nico@cryptonector.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <20141215165903.GE3241@localhost>
References: <20141213164641.30100.14864.idtracker@ietfa.amsl.com> <20141214032931.GZ3448@localhost> <9mmt8a1uaopjncvdnpasqur2n6lci15hej@hive.bjoern.hoehrmann.de> <20141215160809.GC3241@localhost> <B1FC42E1-573F-4F0E-B581-554CD7226C78@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <B1FC42E1-573F-4F0E-B581-554CD7226C78@vpnc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 15 Dec 2014 16:59:46 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/72Hy6keByGLFR_CqElBlLUN8c0k
Cc: json-chairs@tools.ietf.org, Media Types list <media-types@iana.org>
Subject: Re: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 16:59:54 -0000

On Mon, Dec 15, 2014 at 08:21:03AM -0800, Paul Hoffman wrote:
> We can change "must" to "needs to", but this change only applies to
> people who think that 2119 language, even in lowercase, trumps the
> normal interpretation of English.

RFC2119 says nothing about capitalization, but it's widely understood
that an RFC that refers to RFC2119 and uses normative language with
RFC2119 words capitalized and also "must" and so on in lower-case, means
to use the latter as not-RFC2119 words.

> >>>  Applications that use this media type: <by publication time
> >>>  <https://stedolan.github.io/jq> is likely to support this format>.
> >[...]
>=20
> Bj=F6rn is saying that the value for this entry should not be specific
> applications, but a general class. "Systems that might have long
> streams of JSON texts" would suffice.

I see.  I can make this change.  Should I submit a -12?

> >>>  o  Magic number(s): N/A
> >>=20
> >> As proposed, a non-empty `JSON-sequence` starts with at least one 0x=
1E
> >> and the characters that can follow in proper documents come from a r=
e-
> >> stricted set. Considering that a leading 0x1E is quite unusual, it m=
ay
> >> be reasonable to explain why this field is given as `N/A`.
> >=20
> > [...]
> > If the list insists on it, I'll make this change.
>=20
> Please do *not*. 0x1E is not a sufficiently magic number to identify a
> blob as a JSON text sequence.

OK, thanks, I won't.

Nico
--=20


From nobody Mon Dec 15 12:20:34 2014
Return-Path: <nico@cryptonector.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406FB1A885C for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 12:20:29 -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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTXA4r7OfDqe for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 12:20:27 -0800 (PST)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8194D1A8899 for <media-types@ietf.org>; Mon, 15 Dec 2014 12:20:27 -0800 (PST)
Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id sBFKK7eT027396 for <media-types@iana.org>; Mon, 15 Dec 2014 20:20:27 GMT
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id C74259406D; Mon, 15 Dec 2014 12:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=dHkfCrVQcC4bR6 +0a9z9cREXb4A=; b=Pj7CMBlSGYQB9Kl9FhCbU6bCgRWHfO0pI9VUiGVUHAIquc 6L28h7qF2k/6fp1Y1etogkhZpP5a3rrQXtjDp65I4na1BG6Gc+U4TkrFdH2iiqU2 CK1yzBsGQ1aybqy2yGDzvWCB6MKYJcXDLt4JryMI5Gfl6mU+XcM10Sabnjgfk=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 587F89406B; Mon, 15 Dec 2014 12:20:06 -0800 (PST)
Date: Mon, 15 Dec 2014 14:20:05 -0600
From: Nico Williams <nico@cryptonector.com>
To: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <20141215202000.GL3241@localhost>
References: <20141213164641.30100.14864.idtracker@ietfa.amsl.com> <20141214032931.GZ3448@localhost> <9mmt8a1uaopjncvdnpasqur2n6lci15hej@hive.bjoern.hoehrmann.de> <20141215160809.GC3241@localhost> <B1FC42E1-573F-4F0E-B581-554CD7226C78@vpnc.org> <20141215165903.GE3241@localhost> <548F4165.50606@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <548F4165.50606@gmx.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Mon, 15 Dec 2014 20:20:27 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/rWqbyzsLKKW0HL5O31cuFVfwWsw
Cc: json-chairs@tools.ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, Media Types list <media-types@iana.org>
Subject: Re: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 20:20:29 -0000

On Mon, Dec 15, 2014 at 09:15:33PM +0100, Julian Reschke wrote:
> On 2014-12-15 17:59, Nico Williams wrote:
> >On Mon, Dec 15, 2014 at 08:21:03AM -0800, Paul Hoffman wrote:
> >>We can change "must" to "needs to", but this change only applies to
> >>people who think that 2119 language, even in lowercase, trumps the
> >>normal interpretation of English.
> >
> >RFC2119 says nothing about capitalization, but it's widely understood
> >that an RFC that refers to RFC2119 and uses normative language with
> >RFC2119 words capitalized and also "must" and so on in lower-case, means
> >to use the latter as not-RFC2119 words.
> 
> No. That's not widely understood. It's a source of constant confusion.

In the context of this document it surely must be clear.  We could
always add text to that effect.

Nico
-- 


From nobody Mon Dec 15 12:30:45 2014
Return-Path: <julian.reschke@gmx.de>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC091A7008 for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 12:30:44 -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, FREEMAIL_FROM=0.001, SPF_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_Bh5B8cdCMg for <media-types@ietfa.amsl.com>; Mon, 15 Dec 2014 12:30:43 -0800 (PST)
Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF7C1A8958 for <media-types@ietf.org>; Mon, 15 Dec 2014 12:30:43 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id sBFKULIQ020203 for <media-types@iana.org>; Mon, 15 Dec 2014 20:30:42 GMT
Received: from [192.168.2.160] ([93.217.96.252]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LbA4j-1XXv3w0Q13-00ke7i; Mon, 15 Dec 2014 21:15:37 +0100
Message-ID: <548F4165.50606@gmx.de>
Date: Mon, 15 Dec 2014 21:15:33 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>, Paul Hoffman <paul.hoffman@vpnc.org>
References: <20141213164641.30100.14864.idtracker@ietfa.amsl.com> <20141214032931.GZ3448@localhost> <9mmt8a1uaopjncvdnpasqur2n6lci15hej@hive.bjoern.hoehrmann.de> <20141215160809.GC3241@localhost> <B1FC42E1-573F-4F0E-B581-554CD7226C78@vpnc.org> <20141215165903.GE3241@localhost>
In-Reply-To: <20141215165903.GE3241@localhost>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:fYJKytSvBIhZeM0SGK7beGHEm3IUOixhqZX77i4W58OTBwVpgwx 6nYQT1nK5TC5zZ7Hs3dmB6svVqhBlcZSK78BeMcsiYXE797vEtSn1ubvEwklzjuaPQVCo4Z 2yM0+Inx6p95S9UJdujrUgC2RoFEm0658kV9zTCQdfZR0i/uSR4yteTvjcUT6kqqhc4Ajo+ sLQOqTtFmvreuTpe/9IXA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/iBQx3qa5am_1Jpm4pE0uAlJzTRM
Cc: json-chairs@tools.ietf.org, Media Types list <media-types@iana.org>
Subject: Re: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 20:30:44 -0000

On 2014-12-15 17:59, Nico Williams wrote:
> On Mon, Dec 15, 2014 at 08:21:03AM -0800, Paul Hoffman wrote:
>> We can change "must" to "needs to", but this change only applies to
>> people who think that 2119 language, even in lowercase, trumps the
>> normal interpretation of English.
>
> RFC2119 says nothing about capitalization, but it's widely understood
> that an RFC that refers to RFC2119 and uses normative language with
> RFC2119 words capitalized and also "must" and so on in lower-case, means
> to use the latter as not-RFC2119 words.

No. That's not widely understood. It's a source of constant confusion.

Reminder:

"In many standards track documents several words are used to signify the 
requirements in the specification.  These words are often capitalized. 
This document defines these words as they should be   interpreted in 
IETF documents.  Authors who follow these guidelines should incorporate 
this phrase near the beginning of their document:"

> ...


Best regards, Julian


From nobody Mon Dec 29 02:37:22 2014
Return-Path: <dev+ietf@seantek.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6B91A00B7 for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 02:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk6exQzYQAud for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 02:37:17 -0800 (PST)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2421A00B9 for <media-types@ietf.org>; Mon, 29 Dec 2014 02:37:16 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id sBTAatM8015426 for <media-types@iana.org>; Mon, 29 Dec 2014 10:37:15 GMT
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C244F22E200; Mon, 29 Dec 2014 05:36:53 -0500 (EST)
Message-ID: <54A12EBD.3000008@seantek.com>
Date: Mon, 29 Dec 2014 02:36:45 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: media-types@iana.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 29 Dec 2014 10:37:15 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/GEvorOfBh_i8G4PyDzC0IUf8lk4
Cc: Sean Turner <turners@ieca.com>, Russ Housley <housley@vigilsec.com>, draft-moriarty-pkcs12v1-1.all@tools.ietf.org, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 10:37:20 -0000

To Media Types reviewers (et. al.):

This is a first draft of a registration request for the Internet media 
type application/pkcs12, for PKCS #12 content.

Per RFC 6838, I do not believe that this registration requires a formal 
RFC since it is from a recognized standards organization (IETF itself). 
Feedback is appreciated.

This registration is consistent with the recent application/pkcs8 and 
application/pkcs10 registrations. The relevant standard, RFC 7292, is 
primarily a republication of PKCS #12, and does not have its own media 
type registration in the text.

Regards,

Sean

*******

Registration Template [DRAFT]

Type name: application

Subtype name: pkcs12

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations:
PKCS #12 data typically contains one or more private keys encrypted with 
a password using a key derivation function. Poor password choices, weak 
algorithms, or improper parameter selections (e.g., insufficient salting 
rounds) will make the confidential payloads much easier to compromise. 
Additionally, PFX was subject to criticism for being too obtuse and 
cumbersome to implement (see Gutmann, P., PFX - How Not to Design a 
Crypto Protocol/Standard, 
<https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html>). Many of these 
(editorial) shortcomings have been addressed in the latest publications 
of PKCS #12.

Interoperability considerations:
PKCS #12 (formerly PFX, Personal Information Exchange) is a widely 
recognized format for exchange of secret (personal identity) information 
on all modern cryptographic stacks. The format is primarily used for the 
exchange of private keys and certificates, but can also be used to 
exchange symmetric keys, miscellaneous secrets, attributed objects, and 
extensions.

Published specification:
PKCS #12 v1.0, June 1999; PKCS #12 v1.1 (RFC 7292), July 2014

Applications that use this media type:

Machines, applications, browsers, Internet kiosks, and so on, that support this standard allow a user to import, export, and exercise a single set of personal identity information.


Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type: N/A
  Magic number(s): 30h at octet 0
  File extension(s): .p12, .pfx
  Macintosh file type code(s): N/A

Person & email address to contact for further information:
  Sean Leonard <dev+ietf@seantek.com>

Intended usage: COMMON

Restrictions on usage: None.

Author:
(originally Microsoft), RSA, EMC, IETF

Change controller: The IESG (?)

Provisional registration? (standards tree only): No


From nobody Mon Dec 29 07:37:28 2014
Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DAC1A1B2A for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 06:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.335
X-Spam-Level: 
X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Slxva9fXqItN for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 06:03:42 -0800 (PST)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8421A00A7 for <media-types@ietf.org>; Mon, 29 Dec 2014 06:03:41 -0800 (PST)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id sBTE3KE1032046 for <media-types@iana.org>; Mon, 29 Dec 2014 14:03:40 GMT
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBTE3AZp027567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Dec 2014 09:03:11 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBTE3AZp027567
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419861792; bh=xFAxKokPB1SgWX71bzAvXte/Xxs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WBYueJGmA91Vr0XXTeewKHpLg+9JU4BIhxQ11BDVOhMKFTKgbgnlRUYQm9T3jtX53 JUWvwh2K4oO0n1YIzDW/mh4DBz1GIkug4gXwNgfExMPVi3FOJ9TrRdf/cl9qYaM+tV NCzhGea0a/P/Nrp0Bvg6MU1ePa1IhGizT6MIAouk=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBTE3AZp027567
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 29 Dec 2014 09:01:42 -0500
Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBTE2tQk025141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Dec 2014 09:02:56 -0500
Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub31.corp.emc.com (128.222.70.171) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 29 Dec 2014 09:02:55 -0500
Received: from MX103CL02.corp.emc.com ([169.254.6.214]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0195.001; Mon, 29 Dec 2014 09:02:55 -0500
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: Sean Leonard <dev+ietf@seantek.com>
Thread-Topic: Internet media type application/pkcs12; request review
Thread-Index: AQHQI1N34WNnI04ackaJXGITYfze85ymmaLj
Date: Mon, 29 Dec 2014 14:02:55 +0000
Message-ID: <E4D78FE9-1585-43F8-A5AD-F4FB4461BA45@emc.com>
References: <54A12EBD.3000008@seantek.com>
In-Reply-To: <54A12EBD.3000008@seantek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 29 Dec 2014 14:03:40 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/v9-aJkXVrDnrNWSQELssMip-K9g
X-Mailman-Approved-At: Mon, 29 Dec 2014 07:37:27 -0800
Cc: Sean Turner <turners@ieca.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Russ Housley <housley@vigilsec.com>, "media-types@iana.org" <media-types@iana.org>, "draft-moriarty-pkcs12v1-1.all@tools.ietf.org" <draft-moriarty-pkcs12v1-1.all@tools.ietf.org>
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 14:03:44 -0000

Hi Sean,

Thanks for the review.  I just have one comment inline.

Sent from my iPhone

> On Dec 29, 2014, at 5:37 AM, "Sean Leonard" <dev+ietf@seantek.com> wrote:
>=20
> To Media Types reviewers (et. al.):
>=20
> This is a first draft of a registration request for the Internet media ty=
pe application/pkcs12, for PKCS #12 content.
>=20
> Per RFC 6838, I do not believe that this registration requires a formal R=
FC since it is from a recognized standards organization (IETF itself). Feed=
back is appreciated.
>=20
> This registration is consistent with the recent application/pkcs8 and app=
lication/pkcs10 registrations. The relevant standard, RFC 7292, is primaril=
y a republication of PKCS #12, and does not have its own media type registr=
ation in the text.
>=20
> Regards,
>=20
> Sean
>=20
> *******
>=20
> Registration Template [DRAFT]
>=20
> Type name: application
>=20
> Subtype name: pkcs12
>=20
> Required parameters: N/A
>=20
> Optional parameters: N/A
>=20
> Encoding considerations: binary
>=20
> Security considerations:
> PKCS #12 data typically contains one or more private keys encrypted with =
a password using a key derivation function. Poor password choices, weak alg=
orithms, or improper parameter selections (e.g., insufficient salting round=
s) will make the confidential payloads much easier to compromise. Additiona=
lly, PFX was subject to criticism for being too obtuse and cumbersome to im=
plement (see Gutmann, P., PFX - How Not to Design a Crypto Protocol/Standar=
d, <https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html>). Many of these (=
editorial) shortcomings have been addressed in the latest publications of P=
KCS #12.
>=20
> Interoperability considerations:
> PKCS #12 (formerly PFX, Personal Information Exchange) is a widely recogn=
ized format for exchange of secret (personal identity) information on all m=
odern cryptographic stacks. The format is primarily used for the exchange o=
f private keys and certificates, but can also be used to exchange symmetric=
 keys, miscellaneous secrets, attributed objects, and extensions.
>=20
> Published specification:
> PKCS #12 v1.0, June 1999; PKCS #12 v1.1 (RFC 7292), July 2014
>=20
> Applications that use this media type:
>=20
> Machines, applications, browsers, Internet kiosks, and so on, that suppor=
t this standard allow a user to import, export, and exercise a single set o=
f personal identity information.
>=20
>=20
> Fragment identifier considerations: N/A
>=20
> Additional information:
>=20
> Deprecated alias names for this type: N/A
> Magic number(s): 30h at octet 0
> File extension(s): .p12, .pfx
> Macintosh file type code(s): N/A
>=20
> Person & email address to contact for further information:
> Sean Leonard <dev+ietf@seantek.com>
>=20
> Intended usage: COMMON
>=20
> Restrictions on usage: None.
>=20
> Author:
> (originally Microsoft), RSA, EMC, IETF

Magnus was with RSA during his work on this work which was originally done =
at RSA.  He is now at Microsoft.  All of the work was done at RSA and this =
version republished v1.1 from the RSA publication handing over change contr=
ol to the IETF.

Thanks,
Kathleen

>=20
> Change controller: The IESG (?)
>=20
> Provisional registration? (standards tree only): No
>=20


From nobody Mon Dec 29 09:43:59 2014
Return-Path: <dev+ietf@seantek.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3AD1A88BB for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 09:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud6pPHxgCdrO for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 09:43:57 -0800 (PST)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622C51A88AE for <media-types@ietf.org>; Mon, 29 Dec 2014 09:43:56 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id sBTHhZgf017512 for <media-types@iana.org>; Mon, 29 Dec 2014 17:43:56 GMT
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2ACC422E260; Mon, 29 Dec 2014 12:43:33 -0500 (EST)
Message-ID: <54A192BE.4040405@seantek.com>
Date: Mon, 29 Dec 2014 09:43:26 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
References: <54A12EBD.3000008@seantek.com> <E4D78FE9-1585-43F8-A5AD-F4FB4461BA45@emc.com>
In-Reply-To: <E4D78FE9-1585-43F8-A5AD-F4FB4461BA45@emc.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Mon, 29 Dec 2014 17:43:56 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/298dDXhlZKBWVoQKwnyEM8vxgLk
Cc: Sean Turner <turners@ieca.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Russ Housley <housley@vigilsec.com>, "media-types@iana.org" <media-types@iana.org>, "draft-moriarty-pkcs12v1-1.all@tools.ietf.org" <draft-moriarty-pkcs12v1-1.all@tools.ietf.org>
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 17:43:58 -0000

Thank you for the fast response. The revised section is proposed to read:

Author:
RSA, EMC, IETF


On 12/29/2014 6:02 AM, Moriarty, Kathleen wrote:
> Hi Sean,
>
> Thanks for the review.  I just have one comment inline.
>
> Sent from my iPhone
>


From nobody Mon Dec 29 10:33:43 2014
Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDF01A8AE5 for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 10:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.564
X-Spam-Level: 
X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtKPj1KOJhVh for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 10:33:39 -0800 (PST)
Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13081A8ADF for <media-types@ietf.org>; Mon, 29 Dec 2014 10:33:38 -0800 (PST)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id sBTIXIKP003574 for <media-types@iana.org>; Mon, 29 Dec 2014 18:33:38 GMT
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBTIWZg4027282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Dec 2014 13:32:36 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBTIWZg4027282
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419877956; bh=duUMfMHSZEnnXwRrlArcLyrDiYo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=OBa17XWvMJdR5n0UzfClgptBYUawAF409xV53ls9Rl+C2HXWorKP778y2HC5i6HrD OE7rfkSDRA2gEYPYC+3EDT4tq0tpzaQV+r+bCNFw1RwOCXSxUkl75qZAXfhXAF43SA 545WghSWR8xOpdZx1PNZJ4i+mhTSYJJqnQBB7vf8=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBTIWZg4027282
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 29 Dec 2014 13:32:10 -0500
Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBTIWPDo028851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Dec 2014 13:32:25 -0500
Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub32.corp.emc.com (128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 29 Dec 2014 13:32:24 -0500
Received: from MX103CL02.corp.emc.com ([169.254.6.214]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0195.001; Mon, 29 Dec 2014 13:32:24 -0500
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: Sean Leonard <dev+ietf@seantek.com>
Thread-Topic: Internet media type application/pkcs12; request review
Thread-Index: AQHQI1N34WNnI04ackaJXGITYfze85ymmaLjgACRbgD//7ndQw==
Date: Mon, 29 Dec 2014 18:32:24 +0000
Message-ID: <6059087B-23B0-4598-B838-2387026A7F78@emc.com>
References: <54A12EBD.3000008@seantek.com> <E4D78FE9-1585-43F8-A5AD-F4FB4461BA45@emc.com>, <54A192BE.4040405@seantek.com>
In-Reply-To: <54A192BE.4040405@seantek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Mon, 29 Dec 2014 18:33:38 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/goIjni9Xu99SnQjm7KoBgcb8tZ4
Cc: Sean Turner <turners@ieca.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Russ Housley <housley@vigilsec.com>, "media-types@iana.org" <media-types@iana.org>, "draft-moriarty-pkcs12v1-1.all@tools.ietf.org" <draft-moriarty-pkcs12v1-1.all@tools.ietf.org>
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 18:33:41 -0000

Thank you, Sean.

Sent from my iPhone

> On Dec 29, 2014, at 12:43 PM, "Sean Leonard" <dev+ietf@seantek.com> wrote=
:
>=20
> Thank you for the fast response. The revised section is proposed to read:
>=20
> Author:
> RSA, EMC, IETF
>=20
>=20
>> On 12/29/2014 6:02 AM, Moriarty, Kathleen wrote:
>> Hi Sean,
>>=20
>> Thanks for the review.  I just have one comment inline.
>>=20
>> Sent from my iPhone
>=20


From nobody Mon Dec 29 13:09:39 2014
Return-Path: <johnl@taugh.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC471A9086 for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 13:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.663
X-Spam-Level: *
X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndHUQeUm1Ifi for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 13:09:36 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045231A9072 for <media-types@ietf.org>; Mon, 29 Dec 2014 13:09:35 -0800 (PST)
Received: (qmail 90281 invoked from network); 29 Dec 2014 21:09:34 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 29 Dec 2014 21:09:34 -0000
Date: 29 Dec 2014 21:09:12 -0000
Message-ID: <20141229210912.63228.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: media-types@ietf.org
In-Reply-To: <54A12EBD.3000008@seantek.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/vh2Y1vuiutVEQHRVk5vjH76WlLs
Cc: dev+ietf@seantek.com
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 21:09:37 -0000

In article <54A12EBD.3000008@seantek.com> you write:
>To Media Types reviewers (et. al.):
>
>This is a first draft of a registration request for the Internet media 
>type application/pkcs12, for PKCS #12 content.

I have no objection to the type, but I do wonder how likely it is to
be used.  PKCS #12 and PFX have been around for 20 years, and I don't
ever recall seeing a p12 sent as a message body.

R's,
John


From nobody Mon Dec 29 13:15:42 2014
Return-Path: <dev+ietf@seantek.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8131ACD1D for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 13:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyrOfQ9GFxgd for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 13:15:39 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21691ACCE0 for <media-types@ietf.org>; Mon, 29 Dec 2014 13:15:39 -0800 (PST)
Received: from [192.168.123.151] (unknown [23.241.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8551A22E260; Mon, 29 Dec 2014 16:15:20 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Leonard <dev+ietf@seantek.com>
In-Reply-To: <20141229210912.63228.qmail@ary.lan>
Date: Mon, 29 Dec 2014 13:15:22 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <935F800C-F4C7-4132-AABD-D457560FD632@seantek.com>
References: <20141229210912.63228.qmail@ary.lan>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/BJLntuTb7gi1hAZG6RGAM50zyRg
Cc: media-types@ietf.org
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 21:15:41 -0000

On Dec 29, 2014, at 1:09 PM, John Levine <johnl@taugh.com> wrote:

> In article <54A12EBD.3000008@seantek.com> you write:
>> To Media Types reviewers (et. al.):
>>=20
>> This is a first draft of a registration request for the Internet =
media=20
>> type application/pkcs12, for PKCS #12 content.
>=20
> I have no objection to the type, but I do wonder how likely it is to
> be used.  PKCS #12 and PFX have been around for 20 years, and I don't
> ever recall seeing a p12 sent as a message body.

It happens. I have seen them regularly. (Typically the password/secret =
information is sent OOB.) Additionally, they can be uploaded and =
downloaded via HTTP(S).

Currently application/x-pkcs12 is in certain applications, namely =
Apache:
=
https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.type=
s

and MS Windows:
(See HKEY_CLASSES_ROOT\Mime\Database)

Sean=


From nobody Mon Dec 29 16:07:47 2014
Return-Path: <johnl@taugh.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FC1ACE94 for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 16:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level: 
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s07Ka3U7mcUW for <media-types@ietfa.amsl.com>; Mon, 29 Dec 2014 16:06:38 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A001ACE8C for <media-types@ietf.org>; Mon, 29 Dec 2014 16:06:07 -0800 (PST)
Received: (qmail 8603 invoked from network); 30 Dec 2014 00:06:06 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 30 Dec 2014 00:06:06 -0000
Date: 30 Dec 2014 00:05:44 -0000
Message-ID: <20141230000544.65052.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: media-types@ietf.org
In-Reply-To: <935F800C-F4C7-4132-AABD-D457560FD632@seantek.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/Iiw3nyP1y3DliQbYexQlznR-Rr8
Cc: dev+ietf@seantek.com
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 00:07:41 -0000

>Currently application/x-pkcs12 is in certain applications, namely Apache:
>https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types

By golly, there it is in the Apache 2.4 default config.  "Never mind."

R's,
John


From nobody Tue Dec 30 08:21:54 2014
Return-Path: <jwilkes@metabit.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF68E1A000D for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 08:21:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level: 
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jemx8TahnEHy for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 08:21:50 -0800 (PST)
Received: from corwin.metabit.com (corwin.metabit.com [87.234.239.99]) by ietfa.amsl.com (Postfix) with ESMTP id B2C3C1A000C for <media-types@ietf.org>; Tue, 30 Dec 2014 08:21:48 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by corwin.metabit.com (Postfix) with ESMTP id 26C3D42A4109 for <media-types@ietf.org>; Tue, 30 Dec 2014 16:18:42 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at metabit.com.
Received: from corwin.metabit.com ([127.0.0.1]) by localhost (corwin.metabit.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zo7BCPQZhcx for <media-types@ietf.org>; Tue, 30 Dec 2014 16:18:12 +0000 (UTC)
Received: from [192.168.11.15] (port-87-234-239-100.static.qsc.de [87.234.239.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by corwin.metabit.com (Postfix) with ESMTPSA id DC9AE42A409A for <media-types@ietf.org>; Tue, 30 Dec 2014 16:18:12 +0000 (UTC)
Message-ID: <54A2D209.5070206@metabit.com>
Date: Tue, 30 Dec 2014 17:25:45 +0100
From: Jo Wilkes <jwilkes@metabit.com>
Organization: metabit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: media-types@ietf.org
References: <20141230000544.65052.qmail@ary.lan>
In-Reply-To: <20141230000544.65052.qmail@ary.lan>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/vhSX2I_jmDA-DmxGvUEaIPSmWIQ
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 16:21:52 -0000

Had similar doubts, thanks for putting them at rest.

I have seen application/pkcs-12 and application/x-pkcs12 in the wild. I think it's better to have an official media type where the subtype name fits the established pattern without dash (application/pcks10, application/pcks8, application/pcks7-mime). So I'm generally in favour of this request.

One nitpick, still: Specifying 30h at octet 0 as Magic number irritates me. The majority of ASN.1 formats starts with a sequence, so this byte is not a distinctive criterion. If we cannot get an unique value, could we omit this?


Regards, 
and a good new year to you
Jo


From nobody Tue Dec 30 08:52:44 2014
Return-Path: <dev+ietf@seantek.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E731A0371 for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 08:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQDcgUsMGAKG for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 08:52:41 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1D61A036F for <media-types@ietf.org>; Tue, 30 Dec 2014 08:52:40 -0800 (PST)
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B59B22E264; Tue, 30 Dec 2014 11:52:37 -0500 (EST)
Message-ID: <54A2D84D.90809@seantek.com>
Date: Tue, 30 Dec 2014 08:52:29 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: media-types@ietf.org
References: <20141230000544.65052.qmail@ary.lan> <54A2D209.5070206@metabit.com>
In-Reply-To: <54A2D209.5070206@metabit.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/fMMXdU9lC6bBdL4SpgfmLJxFFUg
Cc: draft-moriarty-pkcs12v1-1.all@tools.ietf.org
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 16:52:42 -0000

(Adding pkcs 12 authors back)

On 12/30/2014 8:25 AM, Jo Wilkes wrote:
> Had similar doubts, thanks for putting them at rest.
>
> I have seen application/pkcs-12 and application/x-pkcs12 in the wild. I=
 think it's better to have an official media type where the subtype name =
fits the established pattern without dash (application/pcks10, applicatio=
n/pcks8, application/pcks7-mime). So I'm generally in favour of this requ=
est.

Great!

>
> One nitpick, still: Specifying 30h at octet 0 as Magic number irritates=
 me. The majority of ASN.1 formats starts with a sequence, so this byte i=
s not a distinctive criterion. If we cannot get an unique value, could we=
 omit this?
RFC 6838 says:

    Various sorts of optional information SHOULD be included in the
    specification of a media type if it is available:

    o  Magic number(s) (length, octet values).  Magic numbers are byte
       sequences that are always present at a given place in the file and=

       thus can be used to identify entities as being of a given media
       type.

********

I don't think this language supports the premise that the Magic Number=20
needs to uniquely identify this type of data *and* nothing else in the=20
universe. (I.e., the language is inclusive, not exclusive.) Like file=20
name extensions, there is no way to reserve a particular set of magic=20
numbers for one format's exclusive use: anyone can invent a new format=20
that reuses the magic numbers. Finding 30h at least puts you in the=20
right ballpark, so you can defer to an ASN.1 processor to give you more=20
details.

With regard to PKCS #12 specifically, however, one *might* find the=20
following magic number OIDs throughout the data (BER-encoded):
1.2.840.113549.1.7.1 - PKCS #7 data
1.2.840.113549.1.7.6 - PKCS #7 EncryptedData
1.2.840.113549.1.12.10.1.2 - pkcs-12-pkcs-8-ShroudedKeyBag

Also, the PKCS #12 is guaranteed to have the following ASN.1 data:
SEQUENCE of INTEGER, SEQUENCE, and SEQUENCE (of SEQUENCE, OCTET STRING,=20
and optional INTEGER).
=2E..which is not guaranteed to be DER encoded (it could be=20
indefinite-length BER, for example).

This is based on a non-representative sample (i.e., a p12 file I=20
happened to find lying around).

Per the above guidance however this is delving a bit too much into the=20
byte stream for a magic number analysis.

Cheers,

Sean



From nobody Tue Dec 30 10:17:23 2014
Return-Path: <jwilkes@metabit.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DDA1A0371 for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 10:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdpCwqmUizjj for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 10:17:19 -0800 (PST)
Received: from corwin.metabit.com (corwin.metabit.com [87.234.239.99]) by ietfa.amsl.com (Postfix) with ESMTP id 838AF1A00FD for <media-types@ietf.org>; Tue, 30 Dec 2014 10:17:19 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by corwin.metabit.com (Postfix) with ESMTP id 5B6EB42A4109 for <media-types@ietf.org>; Tue, 30 Dec 2014 18:14:44 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at metabit.com.
Received: from corwin.metabit.com ([127.0.0.1]) by localhost (corwin.metabit.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF718oILB3Rp for <media-types@ietf.org>; Tue, 30 Dec 2014 18:14:14 +0000 (UTC)
Received: from [192.168.11.15] (port-87-234-239-100.static.qsc.de [87.234.239.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by corwin.metabit.com (Postfix) with ESMTPSA id DDF7742A409A for <media-types@ietf.org>; Tue, 30 Dec 2014 18:14:14 +0000 (UTC)
Message-ID: <54A2ED3B.608@metabit.com>
Date: Tue, 30 Dec 2014 19:21:47 +0100
From: Jo Wilkes <jwilkes@metabit.com>
Organization: metabit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: media-types@ietf.org
References: <20141230000544.65052.qmail@ary.lan> <54A2D209.5070206@metabit.com> <54A2D84D.90809@seantek.com>
In-Reply-To: <54A2D84D.90809@seantek.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/yCbm3ngXA23Tt9BXJgDiIRrIIYw
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 18:17:21 -0000

At 2014-12-30 T 17:52 Sean Leonard wrote:
> On 12/30/2014 8:25 AM, Jo Wilkes wrote:
>> One nitpick, still: Specifying 30h at octet 0 as Magic number irritates me. The majority of ASN.1 formats starts with a sequence, so this byte is not a distinctive criterion. If we cannot get an unique value, could we omit this?
> RFC 6838 says:
> 
>    Various sorts of optional information SHOULD be included in the
>    specification of a media type if it is available:
> 
>    o  Magic number(s) (length, octet values).  Magic numbers are byte
>       sequences that are always present at a given place in the file and
>       thus can be used to identify entities as being of a given media
>       type.
> 
> ********
> 
> I don't think this language supports the premise that the Magic Number needs to uniquely identify this type of data *and* nothing else in the universe. (I.e., the language is inclusive, not exclusive.) Like file name extensions, there is no way to reserve a particular set of magic numbers for one format's exclusive use: anyone can invent a new format that reuses the magic numbers. Finding 30h at least puts you in the right ballpark, so you can defer to an ASN.1 processor to give you more details.
> 
> With regard to PKCS #12 specifically, however, one *might* find the following magic number OIDs throughout the data (BER-encoded):
> 1.2.840.113549.1.7.1 - PKCS #7 data
> 1.2.840.113549.1.7.6 - PKCS #7 EncryptedData
> 1.2.840.113549.1.12.10.1.2 - pkcs-12-pkcs-8-ShroudedKeyBag
> 
> Also, the PKCS #12 is guaranteed to have the following ASN.1 data:
> SEQUENCE of INTEGER, SEQUENCE, and SEQUENCE (of SEQUENCE, OCTET STRING, and optional INTEGER).
> ...which is not guaranteed to be DER encoded (it could be indefinite-length BER, for example).
> 
> This is based on a non-representative sample (i.e., a p12 file I happened to find lying around).
> 
> Per the above guidance however this is delving a bit too much into the byte stream for a magic number analysis.

I've written my share of ASN.1 encoding/decoding and PKCS code, so I'm aware this is tricky.
And if I had a perfect magic ID ready (above examples are along my lines of thought), I would have proposed it.

(A partial DER-OID encoding of "1.2.840.113549.1" 06 07 2A 86 48 86 F7 0D 01 => so "2A 86 48 86 F7 0D 01" could be used to match most PKCS#12 files. Maybe not all possible ones, and the position isn't fixed. - BTW, doesn't PCKS#12 require the x509 cert to be DER-encoded?)


But a single h30? In ASCII, that's a "0".

I'm aware that a magic number isn't an reserved unique identifier. But I think it should be specific enough so using it is a benefit.
A rule that uses it should on average deliver more correct matches than false positives.
"File starts with ASCII 0" is not good enough for my taste, so that's why I suggest to omit it. 

YMMV.


Cheers

Jo


From nobody Tue Dec 30 11:06:29 2014
Return-Path: <dev+ietf@seantek.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BF31A1ABE for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 11:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJbFcDvaOdnH for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 11:06:26 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B541A1AB5 for <media-types@ietf.org>; Tue, 30 Dec 2014 11:06:26 -0800 (PST)
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 55C3022E25F for <media-types@ietf.org>; Tue, 30 Dec 2014 14:06:25 -0500 (EST)
Message-ID: <54A2F7A9.9050608@seantek.com>
Date: Tue, 30 Dec 2014 11:06:17 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: media-types@ietf.org
References: <20141230000544.65052.qmail@ary.lan> <54A2D209.5070206@metabit.com> <54A2D84D.90809@seantek.com> <54A2ED3B.608@metabit.com>
In-Reply-To: <54A2ED3B.608@metabit.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/bi0_Q5ktVGhNwHRG5gRtCF0EmYs
Subject: Re: [media-types] Internet media type application/pkcs12; request review
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 19:06:28 -0000

On 12/30/2014 10:21 AM, Jo Wilkes wrote:
> At 2014-12-30 T 17:52 Sean Leonard wrote:
>> On 12/30/2014 8:25 AM, Jo Wilkes wrote:
>>> One nitpick, still: Specifying 30h at octet 0 as Magic number irritates me. The majority of ASN.1 formats starts with a sequence, so this byte is not a distinctive criterion. If we cannot get an unique value, could we omit this?
>> RFC 6838 says:
>>
>>     Various sorts of optional information SHOULD be included in the
>>     specification of a media type if it is available:
>>
>>     o  Magic number(s) (length, octet values).  Magic numbers are byte
>>        sequences that are always present at a given place in the file and
>>        thus can be used to identify entities as being of a given media
>>        type.
>>
>> ********
>>
>> I don't think this language supports the premise that the Magic Number needs to uniquely identify this type of data *and* nothing else in the universe. (I.e., the language is inclusive, not exclusive.) Like file name extensions, there is no way to reserve a particular set of magic numbers for one format's exclusive use: anyone can invent a new format that reuses the magic numbers. Finding 30h at least puts you in the right ballpark, so you can defer to an ASN.1 processor to give you more details.
>>
>> With regard to PKCS #12 specifically, however, one *might* find the following magic number OIDs throughout the data (BER-encoded):
>> 1.2.840.113549.1.7.1 - PKCS #7 data
>> 1.2.840.113549.1.7.6 - PKCS #7 EncryptedData
>> 1.2.840.113549.1.12.10.1.2 - pkcs-12-pkcs-8-ShroudedKeyBag
>>
>> Also, the PKCS #12 is guaranteed to have the following ASN.1 data:
>> SEQUENCE of INTEGER, SEQUENCE, and SEQUENCE (of SEQUENCE, OCTET STRING, and optional INTEGER).
>> ...which is not guaranteed to be DER encoded (it could be indefinite-length BER, for example).
>>
>> This is based on a non-representative sample (i.e., a p12 file I happened to find lying around).
>>
>> Per the above guidance however this is delving a bit too much into the byte stream for a magic number analysis.
> I've written my share of ASN.1 encoding/decoding and PKCS code, so I'm aware this is tricky.
> And if I had a perfect magic ID ready (above examples are along my lines of thought), I would have proposed it.
>
> (A partial DER-OID encoding of "1.2.840.113549.1" 06 07 2A 86 48 86 F7 0D 01 => so "2A 86 48 86 F7 0D 01" could be used to match most PKCS#12 files. Maybe not all possible ones, and the position isn't fixed. - BTW, doesn't PCKS#12 require the x509 cert to be DER-encoded?)

Nope. See draft-josefsson-pkix-textual-10 for extensive discussion on 
why DER encoding can't be assumed.

>
>
> But a single h30? In ASCII, that's a "0".
>
> I'm aware that a magic number isn't an reserved unique identifier. But I think it should be specific enough so using it is a benefit.
> A rule that uses it should on average deliver more correct matches than false positives.
> "File starts with ASCII 0" is not good enough for my taste, so that's why I suggest to omit it.

Well..............

I checked some other PKIX registrations, namely application/pkix-cert, 
application/pkix-crl, application/pkix-attr-cert, application/pkcs8, and 
application/pkcs10...and none of those specify magic numbers. 
(application/pkix-pkipath does but we can just sweep that one under the 
rug.)

I am okay with changing it to "None." Therefore the template is hereby 
revised to say:

   Magic number(s): None.

-Sean


From nobody Wed Dec 31 01:45:13 2014
Return-Path: <abegen@cisco.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8751A8A7E for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 20:46:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.8
X-Spam-Level: 
X-Spam-Status: No, score=-6.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuVQ8oqZqpAo for <media-types@ietfa.amsl.com>; Tue, 30 Dec 2014 20:46:53 -0800 (PST)
Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872FD1A8A80 for <media-types@ietf.org>; Tue, 30 Dec 2014 20:46:53 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id sBV4kWcu016454 for <media-types@iana.org>; Wed, 31 Dec 2014 04:46:52 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6735; q=dns/txt; s=iport; t=1420001212; x=1421210812; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2y2Lq+h+dXllWsoPDKQ8UCblxiBineAFhlV4B1nqLKo=; b=ZJxnQMcZWeif0Xqbj+epq5/UnDZ0FYUFhRAFO+vXHTMkynfZRyRkhGDS glM773Ua0e0gDxQrNHAgXHEFYNXrMQMGQZmZl+IqOFOoGk6Q4fwrsbgPA 1lPytLUQvEoVp5IZFd5k0Xi267jVxB8JydU9M5Wr9a0rZujAhHM16KJg4 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAGt/o1StJV2Z/2dsb2JhbABcgmQiUlgExlmFcYEHFgEBAQEBfYQTOj8SAT4xEScECgQFiBgDEQEMwjANhDkBAQEBAQEBAQEBAQEBAQEBAQEBFQSNTYFICgcBUIMdgRMFjhWDP4NwgUSBDYJliAeFVyKDbm+BAwQCAxcifgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,670,1413244800"; d="scan'208";a="383522332"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 31 Dec 2014 04:46:12 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBV4kCLC019429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Dec 2014 04:46:12 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 30 Dec 2014 22:46:11 -0600
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "media-types@iana.org" <media-types@iana.org>
Thread-Topic: Registration for the Opus media subtype (draft-ietf-payload-rtp-opus-05)
Thread-Index: AQHQJLSzbtnrlSJl40ifCV8TvUtgXA==
Date: Wed, 31 Dec 2014 04:46:12 +0000
Message-ID: <68A0FD31-31D5-42B2-A253-EADDEA2C689B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.75.182]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B1CDC8082D7F834182ABBDA892216E7C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Wed, 31 Dec 2014 04:46:52 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/PCT1b_VFrDOQiPfkMZ76CAkSx1g
X-Mailman-Approved-At: Wed, 31 Dec 2014 01:45:11 -0800
Cc: Roni Even <ron.even.tlv@gmail.com>, "draft-ietf-payload-rtp-opus@tools.ietf.org" <draft-ietf-payload-rtp-opus@tools.ietf.org>
Subject: [media-types] Registration for the Opus media subtype (draft-ietf-payload-rtp-opus-05)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Dec 2014 04:46:59 -0000

Hello

The following draft is in the WGLC process. It registers a media subtype fo=
r the Opus codec. The registration is in Section 6 and below.
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/?include_text=
=3D1

If you have comments, please provide them.

Thanks and happy new year.
Ali C. Begen (Payload Co-chair)


6.1.  Opus Media Type Registration


   Media type registration is done according to [RFC6838] and [RFC4855].

   Type name: audio

   Subtype name: opus

   Required parameters:

   rate:  the RTP timestamp is incremented with a 48000 Hz clock rate
      for all modes of Opus and all sampling rates.  For data encoded
      with sampling rates other than 48000 Hz, the sampling rate has to
      be adjusted to 48000 Hz.

   Optional parameters:

   maxplaybackrate:  a hint about the maximum output sampling rate that
      the receiver is capable of rendering in Hz.  The decoder MUST be
      capable of decoding any audio bandwidth but due to hardware
      limitations only signals up to the specified sampling rate can be
      played back.  Sending signals with higher audio bandwidth results
      in higher than necessary network usage and encoding complexity, so
      an encoder SHOULD NOT encode frequencies above the audio bandwidth
      specified by maxplaybackrate.  This parameter can take any value
      between 8000 and 48000, although commonly the value will match one
      of the Opus bandwidths (Table 1).  By default, the receiver is
      assumed to have no limitations, i.e. 48000.

   sprop-maxcapturerate:  a hint about the maximum input sampling rate
      that the sender is likely to produce.  This is not a guarantee
      that the sender will never send any higher bandwidth (e.g. it
      could send a pre-recorded prompt that uses a higher bandwidth),
      but it indicates to the receiver that frequencies above this
      maximum can safely be discarded.  This parameter is useful to
      avoid wasting receiver resources by operating the audio processing
      pipeline (e.g. echo cancellation) at a higher rate than necessary.
      This parameter can take any value between 8000 and 48000, although
      commonly the value will match one of the Opus bandwidths
      (Table 1).  By default, the sender is assumed to have no
      limitations, i.e. 48000.

   maxptime:  the maximum duration of media represented by a packet
      (according to Section 6 of [RFC4566]) that a decoder wants to
      receive, in milliseconds rounded up to the next full integer
      value.  Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary
      multiple of an Opus frame size rounded up to the next full integer
      value, up to a maximum value of 120, as defined in Section 4.  If
      no value is specified, the default is 120.

   ptime:  the preferred duration of media represented by a packet
      (according to Section 6 of [RFC4566]) that a decoder wants to
      receive, in milliseconds rounded up to the next full integer
      value.  Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary
      multiple of an Opus frame size rounded up to the next full integer
      value, up to a maximum value of 120, as defined in Section 4.  If
      no value is specified, the default is 20.

   stereo:  specifies whether the decoder prefers receiving stereo or
      mono signals.  Possible values are 1 and 0 where 1 specifies that
      stereo signals are preferred, and 0 specifies that only mono
      signals are preferred.  Independent of the stereo parameter every
      receiver MUST be able to receive and decode stereo signals but
      sending stereo signals to a receiver that signaled a preference
      for mono signals may result in higher than necessary network
      utilization and encoding complexity.  If no value is specified,
      the default is 0 (mono).

   sprop-stereo:  specifies whether the sender is likely to produce
      stereo audio.  Possible values are 1 and 0, where 1 specifies that
      stereo signals are likely to be sent, and 0 specifies that the
      sender will likely only send mono.  This is not a guarantee that
      the sender will never send stereo audio (e.g. it could send a pre-
      recorded prompt that uses stereo), but it indicates to the
      receiver that the received signal can be safely downmixed to mono.
      This parameter is useful to avoid wasting receiver resources by
      operating the audio processing pipeline (e.g. echo cancellation)
      in stereo when not necessary.  If no value is specified, the
      default is 0 (mono).

   cbr:  specifies if the decoder prefers the use of a constant bitrate
      versus variable bitrate.  Possible values are 1 and 0, where 1
      specifies constant bitrate and 0 specifies variable bitrate.  If
      no value is specified, the default is 0 (vbr).  When cbr is 1, the
      maximum average bitrate can still change, e.g. to adapt to
      changing network conditions.

   useinbandfec:  specifies that the decoder has the capability to take
      advantage of the Opus in-band FEC.  Possible values are 1 and 0.
      Providing 0 when FEC cannot be used on the receiving side is
      RECOMMENDED.  If no value is specified, useinbandfec is assumed to
      be 0.  This parameter is only a preference and the receiver MUST
      be able to process packets that include FEC information, even if
      it means the FEC part is discarded.

   usedtx:  specifies if the decoder prefers the use of DTX.  Possible
      values are 1 and 0.  If no value is specified, the default is 0.

   Encoding considerations:

      The Opus media type is framed and consists of binary data
      according to Section 4.8 in [RFC6838].

   Security considerations:
   See Section 7 of this document.

   Interoperability considerations: none

   Published specification: none

   Applications that use this media type:

      Any application that requires the transport of speech or audio
      data can use this media type.  Some examples are, but not limited
      to, audio and video conferencing, Voice over IP, media streaming.

   Person & email address to contact for further information:

      SILK Support silksupport@skype.net
      Jean-Marc Valin jmvalin@jmvalin.ca

   Intended usage: COMMON

   Restrictions on usage:

      For transfer over RTP, the RTP payload format (Section 4 of this
      document) SHALL be used.

   Author:

      Julian Spittka jspittka@gmail.com

      Koen Vos koenvos74@gmail.com

      Jean-Marc Valin jmvalin@jmvalin.ca

   Change controller: TBD=