From nobody Fri May 25 00:27:18 2018 Return-Path: X-Original-To: core-parameters@ietfa.amsl.com Delivered-To: core-parameters@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB57126BFD; Fri, 25 May 2018 00:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6smjzvQ24-gA; Fri, 25 May 2018 00:27:14 -0700 (PDT) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1838112420B; Fri, 25 May 2018 00:27:13 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud8.xs4all.net with ESMTPA id M780fSAMuL2mtM780fBwXG; Fri, 25 May 2018 09:27:12 +0200 Received: from AMontpellier-654-1-155-119.w90-0.abo.wanadoo.fr ([90.0.250.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 25 May 2018 09:27:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 May 2018 09:27:08 +0200 From: peter van der Stok To: core-parameters@ietf.org Cc: draft-ietf-ace-coap-est@ietf.org, Hannes Tschofenig Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfDfxB6Qt7ihBtvSaUSE8NTT3mzOVW20+AmmNJy+COCmh1g9oCIXBZKiBZphSC5rLPJEtPSETAkLtOdnv2n/bU1EceBvD1gBOBY36mZRPY2aIJG57Udd6 DvDMbZ3jyLqESzlcm/GWou3mnkC4A2CF/RQWjW1T2yp1j12T2O7G6AK9s0y+PQJG/2b++gaXRPpDqHlonbDGT7LIDRtY8A0+kTP51tLfTPhnPJequWPkSzot vO6nEJDZWcZmA7G8YDI+AAMPWc7IDQ5MdxG2bL07pOfEfsUPg5J/LvJIacUZ+leE Archived-At: Subject: [core-parameters] Core content-format number allocation X-BeenThere: core-parameters@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Expert review of CoAP parameters." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 07:27:17 -0000 Dear core parameter experts, In draft-ietf-ace-coap-est we want to allocate content format numbers to 4 already existing media formats. LWM2M people are implementing the est-coaps specification and want to deploy it as quickly as possible. Therefore, they need to know the allocated numbers to write into their code. An early allocation before publication of the draft as RFC will be appreciated. Below the IANA text from the draft, using TBD1 - TBD4 as allocated numbers. Many thanks, peter __________________________________________________________________________________________________________ 8.1. Content-Format registry Additions to the sub-registry "CoAP Content-Formats", within the "CoRE Parameters" registry are needed for the below media types. These can be registered either in the Expert Review range (0-255) or IETF Review range (256-9999). 1. * application/pkcs7-mime * Type name: application * Subtype name: pkcs7-mime * ID: TBD1 * Required parameters: None * Optional parameters: None * Encoding considerations: binary * Security considerations: As defined in this specification * Published specification: [RFC5751] * Applications that use this media type: EST 2. * application/pkcs8 * Type name: application * Subtype name: pkcs8 * ID: TBD2 * Required parameters: None * Optional parameters: None * Encoding considerations: binary * Security considerations: As defined in this specification * Published specification: [RFC5958] * Applications that use this media type: EST 3. * application/csrattrs * Type name: application * Subtype name: csrattrs * ID: TBD3 * Required parameters: None * Optional parameters: None * Encoding considerations: binary * Security considerations: As defined in this specification * Published specification: [RFC7030] * Applications that use this media type: EST 4. * application/pkcs10 * Type name: application * Subtype name: pkcs10 * ID: TBD4 * Required parameters: None * Optional parameters: None * Encoding considerations: binar * Security considerations: As defined in this specification * Published specification: [RFC5967] * Applications that use this media type: EST ___________________________________________________________________________________________ -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Fri May 25 00:48:56 2018 Return-Path: X-Original-To: core-parameters@ietfa.amsl.com Delivered-To: core-parameters@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5995E1201FA; Fri, 25 May 2018 00:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nenZEsERc8tg; Fri, 25 May 2018 00:48:50 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079C9120454; Fri, 25 May 2018 00:48:49 -0700 (PDT) Received: from mail-qt0-f179.google.com ([209.85.216.179]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fM7Sw-0003I1-Rn; Fri, 25 May 2018 09:48:47 +0200 Received: by mail-qt0-f179.google.com with SMTP id d3-v6so5438300qtp.11; Fri, 25 May 2018 00:48:46 -0700 (PDT) X-Gm-Message-State: ALKqPwcpNAKJKKYjG5RiAuGwF/itTvRwm8qAJzTgzjaDex6qvX7e2ym2 7Xvw0nWrYoVG5pMdKFKnrtoB/+ky/Kt6zTC14rY= X-Google-Smtp-Source: ADUXVKLRhtMpu82pfPB124BEs7AD5iFTTbl0x6sWUNPAt/DLMRkTnvFBjDlExZLiMUvNMHs1vSes09LL2zTPiqXPDUQ= X-Received: by 2002:a0c:e642:: with SMTP id c2-v6mr323686qvn.56.1527234525729; Fri, 25 May 2018 00:48:45 -0700 (PDT) MIME-Version: 1.0 References: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> In-Reply-To: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> From: Klaus Hartke Date: Fri, 25 May 2018 09:48:35 +0200 X-Gmail-Original-Message-ID: Message-ID: To: consultancy@vanderstok.org Cc: Hannes Tschofenig , core-parameters@ietf.org, draft-ietf-ace-coap-est@ietf.org Content-Type: multipart/alternative; boundary="000000000000651935056d02ffe6" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1527234530; 9e18903b; X-HE-SMSGID: 1fM7Sw-0003I1-Rn Archived-At: Subject: Re: [core-parameters] Core content-format number allocation X-BeenThere: core-parameters@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Expert review of CoAP parameters." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 07:48:54 -0000 --000000000000651935056d02ffe6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, I see you=E2=80=99re requesting Content-Format IDs for the following existi= ng media types: - application/pkcs7-mime - application/pkcs8 - application/csrattrs - application/pkcs10 A Content-Format is the combination of a media type and a content coding. Please specify the content coding(s) you want to use with each media type. The possible set of content codings can be found at https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#cont= ent-coding Please format your request as a table that looks like Table 9 in https://tools.ietf.org/html/rfc7252#section-12.3 (one row for each combination of a media type and a content coding) It seems =E2=80=9Capplication/pkcs7-mime=E2=80=9C actually does define a me= dia type parameter, =E2=80=9Csmime-type =E2=80=9D. RFC 5751 says: Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object. The Content-Type header field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections. So it seems the parameter is more or less required. Do you want to register a Content-Format ID for each defined smime-type value? Then the list of media types (that need to be paired with a content coding) looks like this: - application/pkcs7-mime; smime-type=3D=E2=80=9Cenveloped-data=E2=80=9D - application/pkcs7-mime; smime-type=3D=E2=80=9Csigned-data=E2=80=9D - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D - application/pkcs7-mime; smime-type=3D=E2=80=9Ccompressed-data=E2=80=9D - application/pkcs8 - application/csrattrs - application/pkcs10 Klaus On Fri 25. May 2018 at 09:27, peter van der Stok wrote= : > Dear core parameter experts, > > In draft-ietf-ace-coap-est we want to allocate content format numbers to > 4 already existing media formats. > LWM2M people are implementing the est-coaps specification and want to > deploy it as quickly as possible. > Therefore, they need to know the allocated numbers to write into their > code. > An early allocation before publication of the draft as RFC will be > appreciated. > > Below the IANA text from the draft, using TBD1 - TBD4 as allocated > numbers. > > Many thanks, > > peter > > > > _________________________________________________________________________= _________________________________ > > > 8.1. Content-Format registry > > Additions to the sub-registry "CoAP Content-Formats", within the > "CoRE Parameters" registry are needed for the below media types. > These can be registered either in the Expert Review range (0-255) or > IETF Review range (256-9999). > > 1. > > * application/pkcs7-mime > * Type name: application > * Subtype name: pkcs7-mime > * ID: TBD1 > * Required parameters: None > * Optional parameters: None > * Encoding considerations: binary > * Security considerations: As defined in this specification > * Published specification: [RFC5751] > * Applications that use this media type: EST > > 2. > > * application/pkcs8 > * Type name: application > * Subtype name: pkcs8 > * ID: TBD2 > * Required parameters: None > * Optional parameters: None > * Encoding considerations: binary > * Security considerations: As defined in this specification > * Published specification: [RFC5958] > * Applications that use this media type: EST > > 3. > > * application/csrattrs > * Type name: application > * Subtype name: csrattrs > * ID: TBD3 > * Required parameters: None > * Optional parameters: None > * Encoding considerations: binary > * Security considerations: As defined in this specification > * Published specification: [RFC7030] > * Applications that use this media type: EST > > 4. > > * application/pkcs10 > * Type name: application > * Subtype name: pkcs10 > * ID: TBD4 > * Required parameters: None > * Optional parameters: None > * Encoding considerations: binar > * Security considerations: As defined in this specification > * Published specification: [RFC5967] > * Applications that use this media type: EST > > > _________________________________________________________________________= __________________ > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > > _______________________________________________ > core-parameters mailing list > core-parameters@ietf.org > https://www.ietf.org/mailman/listinfo/core-parameters > --000000000000651935056d02ffe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter,

I see you=E2=80=99re requesting Content-Format IDs for the following ex= isting media types:

- ap= plication/pkcs7-mime
- application/pkcs8
- application/csrattrs
- application/pkc= s10

A Content-Format is = the combination of a media type and a content coding. Please specify the co= ntent coding(s) you want to use with each media type. The possible set of c= ontent codings can be found at=C2=A0


= It seems =E2=80=9Capplication/pkcs7-mime=E2=80=9C actually does define a me= dia type parameter, =E2=80=9Csmime-type =E2=80=9D. RFC 5751 says:

   Because=
 there are several types of application/pkcs7-mime objects, a
   sending agent SHOULD do as much as possible to help a receiving agent
   know about the contents of the object without forcing the receiving
   agent to decode the ASN.1 for the object.  The Content-Type header
   field of all application/pkcs7-mime objects SHOULD include the
   optional "smime-type" parameter, as described in the following
   sections.

So it= seems the parameter is more or less required. Do you want to register a Co= ntent-Format ID for each defined smime-type value? Then the list of media t= ypes (that need to be paired with a content coding) looks like this:
<= div dir=3D"auto">
- applicatio= n/pkcs7-mime; smime-type=3D=E2=80=9Cenveloped-data=E2=80=9D
- application/pkcs7-mime; smime-type=3D=E2=80=9Csigned-data=E2=80= =9D
- application/pkcs7-mime; smime-type=3D=E2=80=9C= certs-only=E2=80=9D
- application/pkcs7-mime; smime-= type=3D=E2=80=9Ccompressed-data=E2=80=9D
- applicati= on/pkcs8
- application/csrattrs
- application/pkcs10

= Klaus=C2=A0



On Fri 25. May 2018 at 09:27, = peter van der Stok <stokcons@xs4al= l.nl> wrote:
Dear core param= eter experts,

In draft-ietf-ace-coap-est we want to allocate content format numbers to 4 already existing media formats.
LWM2M people are implementing the est-coaps specification and want to
deploy it as quickly as possible.
Therefore, they need to know the allocated numbers to write into their
code.
An early allocation before publication of the draft as RFC will be
appreciated.

Below the IANA text from the draft, using TBD1 - TBD4 as allocated
numbers.

Many thanks,

peter


___________________________________________________________________________= _______________________________


8.1.=C2=A0 Content-Format registry

=C2=A0 =C2=A0 Additions to the sub-registry "CoAP Content-Formats"= ;, within the
=C2=A0 =C2=A0 "CoRE Parameters" registry are needed for the below= media types.
=C2=A0 =C2=A0 These can be registered either in the Expert Review range (0-= 255) or
=C2=A0 =C2=A0 IETF Review range (256-9999).

=C2=A0 =C2=A0 1.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 application/pkcs7-mime
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Type name: application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Subtype name: pkcs7-mime
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 ID: TBD1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Required parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Optional parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Encoding considerations: binary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Security considerations: As defined in = this specification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Published specification: [RFC5751]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Applications that use this media type: = EST

=C2=A0 =C2=A0 2.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 application/pkcs8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Type name: application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Subtype name: pkcs8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 ID: TBD2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Required parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Optional parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Encoding considerations: binary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Security considerations: As defined in = this specification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Published specification: [RFC5958]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Applications that use this media type: = EST

=C2=A0 =C2=A0 3.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 application/csrattrs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Type name: application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Subtype name: csrattrs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 ID: TBD3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Required parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Optional parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Encoding considerations: binary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Security considerations: As defined in = this specification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Published specification: [RFC7030]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Applications that use this media type: = EST

=C2=A0 =C2=A0 4.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 application/pkcs10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Type name: application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Subtype name: pkcs10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 ID: TBD4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Required parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Optional parameters: None
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Encoding considerations: binar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Security considerations: As defined in = this specification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Published specification: [RFC5967]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Applications that use this media type: = EST

___________________________________________________________________________= ________________

--
Peter van der Stok
vanderstok consultancy
mailto: con= sultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015248

_______________________________________________
core-parameters mailing list
core-paramete= rs@ietf.org
https://www.ietf.org/mailman/listinfo/core-para= meters
--000000000000651935056d02ffe6-- From nobody Fri May 25 01:58:37 2018 Return-Path: X-Original-To: core-parameters@ietfa.amsl.com Delivered-To: core-parameters@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88380124B0A; Fri, 25 May 2018 01:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uab5vmwH3Opv; Fri, 25 May 2018 01:58:32 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4981201FA; Fri, 25 May 2018 01:58:31 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:211]) by smtp-cloud7.xs4all.net with ESMTPA id M8YOfLnlp8U07M8YOf6Afp; Fri, 25 May 2018 10:58:28 +0200 Received: from AMontpellier-654-1-155-119.w90-0.abo.wanadoo.fr ([90.0.250.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 25 May 2018 10:58:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 25 May 2018 10:58:28 +0200 From: peter van der Stok To: Klaus Hartke Cc: consultancy@vanderstok.org, Hannes Tschofenig , core-parameters@ietf.org, draft-ietf-ace-coap-est@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> Message-ID: <24ec93bb245164263df36d81aaf10c43@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfIvB1wP4HT/Sm9fpJGJI0HxgO1ayt/7GKzSYc7XGCbsRKdqTa76HQnzcqvFuHBqoAWn4YfGWNESfXQOjT5FAtRikW6WUzpv4YBRp2GihIv1uedwwZUXa jMNh6m4oyPsOHm3uKXG1HoxxpXJMFYSc8E7SPZcpV1dGWiqb6PK6h02YgFhRu5k3cPB6NjYaVSmnrZIiDwyuL9wXtTqewWPjQ4ad23toNlXr/5Mqv+hoAZFg tbtXcNkJmx8b4FDTm5qAXoOpzGiPcszsXp/iNr3jtAFGw4C348hM5spVpCXDj9h+Un0uQFDpNvOcD8tdUParBxc4bCU+GVUt3uSLZ1QVblli9+roO55Ezf+7 ww/SDmEBueDJCyzFmidL4gEIxUsVCTk1sr13O1kCUGCpgnqw97wHskHN3rQr7oxzGYdN4+EQ Archived-At: Subject: Re: [core-parameters] Core content-format number allocation X-BeenThere: core-parameters@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Expert review of CoAP parameters." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 08:58:35 -0000 HI Klaus, Thanks for the quick reaction, and thanks for pointing out some existing other smime types. I did a search in RFC 7030, and came up with other necessary smime types. Below the table as required for est-coap draft: (I will change the draft accordingly) - application/pkcs7-mime; smime-type=“server-generated-key”; Encoding = "binary"; ID = TBD1; Reference = RFC5751, RFC7030 - application/pkcs7-mime; smime-type=“certs-only”; Encoding = "binary"; ID = TBD2; Reference = RFC5751 - application/pkcs7-mime; smime-type=“CMC-request”; Encoding = "binary"; ID = TBD3; Reference = RFC5751, RFC5273 - application/pkcs8; smime-type = ---; Encoding = "binary"; ID = TBD4; Reference = RFC5958 - application/csrattrs; smime-type = ---; Encoding = "binary"; ID = TBD5; Reference = RFC7030 - application/pkcs10; smime-type = ---; Encoding = "binary"; ID = TBD6; Reference = RFC5967 I expect the Encoding is orthogonal to the media type and smime type specification. Many thanks, peter Klaus Hartke schreef op 2018-05-25 09:48: > Hi Peter, > > I see you’re requesting Content-Format IDs for the following > existing media types: > > - application/pkcs7-mime > - application/pkcs8 > - application/csrattrs > - application/pkcs10 > > A Content-Format is the combination of a media type and a content > coding. Please specify the content coding(s) you want to use with each > media type. The possible set of content codings can be found at > https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding > > Please format your request as a table that looks like Table 9 in > https://tools.ietf.org/html/rfc7252#section-12.3 (one row for each > combination of a media type and a content coding) > > It seems “application/pkcs7-mime“ actually does define a media > type parameter, “smime-type ”. RFC 5751 says: > > Because there are several types of application/pkcs7-mime objects, > a > sending agent SHOULD do as much as possible to help a receiving > agent > know about the contents of the object without forcing the receiving > agent to decode the ASN.1 for the object. The Content-Type header > field of all application/pkcs7-mime objects SHOULD include the > optional "smime-type" parameter, as described in the following > sections. > > So it seems the parameter is more or less required. Do you want to > register a Content-Format ID for each defined smime-type value? Then > the list of media types (that need to be paired with a content coding) > looks like this: > > - application/pkcs7-mime; smime-type=“enveloped-data” > - application/pkcs7-mime; smime-type=“signed-data” > - application/pkcs7-mime; smime-type=“certs-only” > - application/pkcs7-mime; smime-type=“compressed-data” > - application/pkcs8 > - application/csrattrs > - application/pkcs10 > > Klaus > > On Fri 25. May 2018 at 09:27, peter van der Stok > wrote: > >> Dear core parameter experts, >> >> In draft-ietf-ace-coap-est we want to allocate content format >> numbers to >> 4 already existing media formats. >> LWM2M people are implementing the est-coaps specification and want >> to >> deploy it as quickly as possible. >> Therefore, they need to know the allocated numbers to write into >> their >> code. >> An early allocation before publication of the draft as RFC will be >> appreciated. >> >> Below the IANA text from the draft, using TBD1 - TBD4 as allocated >> numbers. >> >> Many thanks, >> >> peter >> >> > __________________________________________________________________________________________________________ >> >> 8.1. Content-Format registry >> >> Additions to the sub-registry "CoAP Content-Formats", within the >> "CoRE Parameters" registry are needed for the below media types. >> These can be registered either in the Expert Review range >> (0-255) or >> IETF Review range (256-9999). >> >> 1. >> >> * application/pkcs7-mime >> * Type name: application >> * Subtype name: pkcs7-mime >> * ID: TBD1 >> * Required parameters: None >> * Optional parameters: None >> * Encoding considerations: binary >> * Security considerations: As defined in this specification >> * Published specification: [RFC5751] >> * Applications that use this media type: EST >> >> 2. >> >> * application/pkcs8 >> * Type name: application >> * Subtype name: pkcs8 >> * ID: TBD2 >> * Required parameters: None >> * Optional parameters: None >> * Encoding considerations: binary >> * Security considerations: As defined in this specification >> * Published specification: [RFC5958] >> * Applications that use this media type: EST >> >> 3. >> >> * application/csrattrs >> * Type name: application >> * Subtype name: csrattrs >> * ID: TBD3 >> * Required parameters: None >> * Optional parameters: None >> * Encoding considerations: binary >> * Security considerations: As defined in this specification >> * Published specification: [RFC7030] >> * Applications that use this media type: EST >> >> 4. >> >> * application/pkcs10 >> * Type name: application >> * Subtype name: pkcs10 >> * ID: TBD4 >> * Required parameters: None >> * Optional parameters: None >> * Encoding considerations: binar >> * Security considerations: As defined in this specification >> * Published specification: [RFC5967] >> * Applications that use this media type: EST >> >> > ___________________________________________________________________________________________ >> >> -- >> Peter van der Stok >> vanderstok consultancy >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org [1] >> tel NL: +31(0)492474673 F: +33(0)966015248 >> >> _______________________________________________ >> core-parameters mailing list >> core-parameters@ietf.org >> https://www.ietf.org/mailman/listinfo/core-parameters > > > Links: > ------ > [1] http://www.vanderstok.org From nobody Fri May 25 02:22:56 2018 Return-Path: X-Original-To: core-parameters@ietfa.amsl.com Delivered-To: core-parameters@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D17B126579; Fri, 25 May 2018 02:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwLZyWZFzuVo; Fri, 25 May 2018 02:22:50 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5581250B8; Fri, 25 May 2018 02:22:50 -0700 (PDT) Received: from mail-qt0-f170.google.com ([209.85.216.170]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fM8vv-0008Ex-C7; Fri, 25 May 2018 11:22:47 +0200 Received: by mail-qt0-f170.google.com with SMTP id f1-v6so5709022qtj.6; Fri, 25 May 2018 02:22:47 -0700 (PDT) X-Gm-Message-State: ALKqPwduHC3Jmk8QUhpxGTFBYaoDTsCwvIYclDVuP2SS+u1LOH8tDqui FZXPw2vx61jmNrTHcpfi5Uqlsb/62Zfr6ybNp24= X-Google-Smtp-Source: ADUXVKLbNv8MZDC9CnkoNhHdINjK2Jnhaxn94P8GZWFKeLCglqo/l7P89f7b/M+BJgHgbqf1dKY0KttiJBPa+d9Fk/U= X-Received: by 2002:a0c:c342:: with SMTP id j2-v6mr1314339qvi.49.1527240166354; Fri, 25 May 2018 02:22:46 -0700 (PDT) MIME-Version: 1.0 References: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> <24ec93bb245164263df36d81aaf10c43@xs4all.nl> In-Reply-To: <24ec93bb245164263df36d81aaf10c43@xs4all.nl> From: Klaus Hartke Date: Fri, 25 May 2018 11:22:35 +0200 X-Gmail-Original-Message-ID: Message-ID: To: consultancy@vanderstok.org Cc: Hannes Tschofenig , core-parameters@ietf.org, draft-ietf-ace-coap-est@ietf.org Content-Type: multipart/alternative; boundary="0000000000009a35da056d044f24" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1527240170; 279fa435; X-HE-SMSGID: 1fM8vv-0008Ex-C7 Archived-At: Subject: Re: [core-parameters] Core content-format number allocation X-BeenThere: core-parameters@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Expert review of CoAP parameters." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 09:22:54 -0000 --0000000000009a35da056d044f24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What about =E2=80=9CCMC-Response=E2=80=9D? There=E2=80=99s a registry for =E2=80=9Csmime-type=E2=80=9D values at https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-p= arameters.xhtml#smime Would it make sense to simply allocate a Content-Format ID to each of them? The media type and the content coding are orthogonal. However, =E2=80=9Cbin= ary=E2=80=9D is not a valid content coding. (It=E2=80=99s really confusing that the column = is labeled =E2=80=9CEncoding=E2=80=9D; content coding is what is meant.) Possi= ble content codings are listed in https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#cont= ent-coding You probably want the =E2=80=9Cidentity=E2=80=9C content coding. =E2=80=9Capplication/pkcs8=E2=80=9D and the other two media types don=E2=80= =99t have the =E2=80=9Csmime-type=E2=80=9D parameter defined, so just remove that bit. Otherwise the table looks good to me. Klaus On Fri 25. May 2018 at 10:58, peter van der Stok wrote= : > HI Klaus, > > Thanks for the quick reaction, and thanks for pointing out some existing > other smime types. > I did a search in RFC 7030, and came up with other necessary smime > types. > > Below the table as required for est-coap draft: (I will change the draft > accordingly) > > - application/pkcs7-mime; smime-type=3D=E2=80=9Cserver-generated-key=E2= =80=9D; Encoding =3D > "binary"; ID =3D TBD1; Reference =3D RFC5751, RFC7030 > - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D; Enco= ding =3D "binary"; > ID =3D TBD2; Reference =3D RFC5751 > - application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-request=E2=80=9D; Enc= oding =3D "binary"; > ID =3D TBD3; Reference =3D RFC5751, RFC5273 > - application/pkcs8; smime-type =3D ---; Encoding =3D "binary"; ID =3D TB= D4; > Reference =3D RFC5958 > - application/csrattrs; smime-type =3D ---; Encoding =3D "binary"; ID =3D > TBD5; Reference =3D RFC7030 > - application/pkcs10; smime-type =3D ---; Encoding =3D "binary"; ID =3D T= BD6; > Reference =3D RFC5967 > > I expect the Encoding is orthogonal to the media type and smime type > specification. > > Many thanks, > > peter > > Klaus Hartke schreef op 2018-05-25 09:48: > > Hi Peter, > > > > I see you=E2=80=99re requesting Content-Format IDs for the following > > existing media types: > > > > - application/pkcs7-mime > > - application/pkcs8 > > - application/csrattrs > > - application/pkcs10 > > > > A Content-Format is the combination of a media type and a content > > coding. Please specify the content coding(s) you want to use with each > > media type. The possible set of content codings can be found at > > > https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#co= ntent-coding > > > > Please format your request as a table that looks like Table 9 in > > https://tools.ietf.org/html/rfc7252#section-12.3 (one row for each > > combination of a media type and a content coding) > > > > It seems =E2=80=9Capplication/pkcs7-mime=E2=80=9C actually does define = a media > > type parameter, =E2=80=9Csmime-type =E2=80=9D. RFC 5751 says: > > > > Because there are several types of application/pkcs7-mime objects, > > a > > sending agent SHOULD do as much as possible to help a receiving > > agent > > know about the contents of the object without forcing the receiving > > agent to decode the ASN.1 for the object. The Content-Type header > > field of all application/pkcs7-mime objects SHOULD include the > > optional "smime-type" parameter, as described in the following > > sections. > > > > So it seems the parameter is more or less required. Do you want to > > register a Content-Format ID for each defined smime-type value? Then > > the list of media types (that need to be paired with a content coding) > > looks like this: > > > > - application/pkcs7-mime; smime-type=3D=E2=80=9Cenveloped-data=E2=80=9D > > - application/pkcs7-mime; smime-type=3D=E2=80=9Csigned-data=E2=80=9D > > - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D > > - application/pkcs7-mime; smime-type=3D=E2=80=9Ccompressed-data=E2=80= =9D > > - application/pkcs8 > > - application/csrattrs > > - application/pkcs10 > > > > Klaus > > > > On Fri 25. May 2018 at 09:27, peter van der Stok > > wrote: > > > >> Dear core parameter experts, > >> > >> In draft-ietf-ace-coap-est we want to allocate content format > >> numbers to > >> 4 already existing media formats. > >> LWM2M people are implementing the est-coaps specification and want > >> to > >> deploy it as quickly as possible. > >> Therefore, they need to know the allocated numbers to write into > >> their > >> code. > >> An early allocation before publication of the draft as RFC will be > >> appreciated. > >> > >> Below the IANA text from the draft, using TBD1 - TBD4 as allocated > >> numbers. > >> > >> Many thanks, > >> > >> peter > >> > >> > > > _________________________________________________________________________= _________________________________ > >> > >> 8.1. Content-Format registry > >> > >> Additions to the sub-registry "CoAP Content-Formats", within the > >> "CoRE Parameters" registry are needed for the below media types. > >> These can be registered either in the Expert Review range > >> (0-255) or > >> IETF Review range (256-9999). > >> > >> 1. > >> > >> * application/pkcs7-mime > >> * Type name: application > >> * Subtype name: pkcs7-mime > >> * ID: TBD1 > >> * Required parameters: None > >> * Optional parameters: None > >> * Encoding considerations: binary > >> * Security considerations: As defined in this specification > >> * Published specification: [RFC5751] > >> * Applications that use this media type: EST > >> > >> 2. > >> > >> * application/pkcs8 > >> * Type name: application > >> * Subtype name: pkcs8 > >> * ID: TBD2 > >> * Required parameters: None > >> * Optional parameters: None > >> * Encoding considerations: binary > >> * Security considerations: As defined in this specification > >> * Published specification: [RFC5958] > >> * Applications that use this media type: EST > >> > >> 3. > >> > >> * application/csrattrs > >> * Type name: application > >> * Subtype name: csrattrs > >> * ID: TBD3 > >> * Required parameters: None > >> * Optional parameters: None > >> * Encoding considerations: binary > >> * Security considerations: As defined in this specification > >> * Published specification: [RFC7030] > >> * Applications that use this media type: EST > >> > >> 4. > >> > >> * application/pkcs10 > >> * Type name: application > >> * Subtype name: pkcs10 > >> * ID: TBD4 > >> * Required parameters: None > >> * Optional parameters: None > >> * Encoding considerations: binar > >> * Security considerations: As defined in this specification > >> * Published specification: [RFC5967] > >> * Applications that use this media type: EST > >> > >> > > > _________________________________________________________________________= __________________ > >> > >> -- > >> Peter van der Stok > >> vanderstok consultancy > >> mailto: consultancy@vanderstok.org > >> www: www.vanderstok.org [1] > >> tel NL: +31(0)492474673 F: +33(0)966015248 > >> > >> _______________________________________________ > >> core-parameters mailing list > >> core-parameters@ietf.org > >> https://www.ietf.org/mailman/listinfo/core-parameters > > > > > > Links: > > ------ > > [1] http://www.vanderstok.org > --0000000000009a35da056d044f24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What about =E2=80=9CCMC-Response=E2=80=9D?

There=E2=80=99s a registry f= or =E2=80=9Csmime-type=E2=80=9D values at=C2=A0
Would it make sense to simply allocate a Content-Format ID to eac= h of them?

Th= e media type and the content coding are orthogonal. However, =E2=80=9Cbinar= y=E2=80=9D is not a valid content coding. (It=E2=80=99s really confusing th= at the column is labeled =E2=80=9CEncoding=E2=80=9D; content coding is what= is meant.) Possible content codings are listed in=C2=A0
You = probably want the =E2=80=9Cidentity=E2=80=9C content coding.

=E2=80=9Capplication/pkcs8=E2=80=9D a= nd the other two media types don=E2=80=99t have the =E2=80=9Csmime-type=E2= =80=9D parameter defined, so just remove that bit.
<= br>
Otherwise the table looks good to me.

Klaus=C2=A0<= /div>


On Fri 25. May 2018 at 10:58, peter van der Stok <stokcons@xs4all.nl> wrot= e:
HI Klaus,

Thanks for the quick reaction, and thanks for pointing out some existing other smime types.
I did a search in RFC 7030, and came up with other necessary smime
types.

Below the table as required for est-coap draft: (I will change the draft accordingly)

- application/pkcs7-mime; smime-type=3D=E2=80=9Cserver-generated-key=E2=80= =9D; Encoding =3D
"binary"; ID =3D TBD1; Reference =3D RFC5751, RFC7030
- application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D; Encodi= ng =3D "binary";
ID =3D TBD2; Reference =3D RFC5751
- application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-request=E2=80=9D; Encod= ing =3D "binary";
ID =3D TBD3; Reference =3D RFC5751, RFC5273
- application/pkcs8; smime-type =3D ---; Encoding =3D "binary"; I= D =3D TBD4;
Reference =3D RFC5958
- application/csrattrs; smime-type =3D ---; Encoding =3D "binary"= ; ID =3D
TBD5; Reference =3D RFC7030
- application/pkcs10; smime-type =3D ---; Encoding =3D "binary"; = ID =3D TBD6;
Reference =3D RFC5967

I expect the Encoding is orthogonal to the media type and smime type
specification.

Many thanks,

peter

Klaus Hartke schreef op 2018-05-25 09:48:
> Hi Peter,
>
> I see you=E2=80=99re requesting Content-Format IDs for the following > existing media types:
>
> - application/pkcs7-mime
> - application/pkcs8
> - application/csrattrs
> - application/pkcs10
>
> A Content-Format is the combination of a media type and a content
> coding. Please specify the content coding(s) you want to use with each=
> media type. The possible set of content codings can be found at
> https://ww= w.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding=
>
> Please format your request as a table that looks like Table 9 in
> https://tools.ietf.org/html/rfc7252#section-12.= 3 (one row for each
> combination of a media type and a content coding)
>
> It seems =E2=80=9Capplication/pkcs7-mime=E2=80=9C actually does define= a media
> type parameter, =E2=80=9Csmime-type =E2=80=9D. RFC 5751 says:
>
>=C2=A0 =C2=A0 Because there are several types of application/pkcs7-mime= objects,
> a
>=C2=A0 =C2=A0 sending agent SHOULD do as much as possible to help a rec= eiving
> agent
>=C2=A0 =C2=A0 know about the contents of the object without forcing the= receiving
>=C2=A0 =C2=A0 agent to decode the ASN.1 for the object.=C2=A0 The Conte= nt-Type header
>=C2=A0 =C2=A0 field of all application/pkcs7-mime objects SHOULD includ= e the
>=C2=A0 =C2=A0 optional "smime-type" parameter, as described i= n the following
>=C2=A0 =C2=A0 sections.
>
> So it seems the parameter is more or less required. Do you want to
> register a Content-Format ID for each defined smime-type value? Then > the list of media types (that need to be paired with a content coding)=
> looks like this:
>
> - application/pkcs7-mime; smime-type=3D=E2=80=9Cenveloped-data=E2=80= =9D
> - application/pkcs7-mime; smime-type=3D=E2=80=9Csigned-data=E2=80=9D > - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D > - application/pkcs7-mime; smime-type=3D=E2=80=9Ccompressed-data=E2=80= =9D
> - application/pkcs8
> - application/csrattrs
> - application/pkcs10
>
> Klaus
>
> On Fri 25. May 2018 at 09:27, peter van der Stok <stokcons@xs4all.nl>
> wrote:
>
>> Dear core parameter experts,
>>
>> In draft-ietf-ace-coap-est we want to allocate content format
>> numbers to
>> 4 already existing media formats.
>> LWM2M people are implementing the est-coaps specification and want=
>> to
>> deploy it as quickly as possible.
>> Therefore, they need to know the allocated numbers to write into >> their
>> code.
>> An early allocation before publication of the draft as RFC will be=
>> appreciated.
>>
>> Below the IANA text from the draft, using TBD1 - TBD4 as allocated=
>> numbers.
>>
>> Many thanks,
>>
>> peter
>>
>>
> ______________________________________________________________________= ____________________________________
>>
>> 8.1.=C2=A0 Content-Format registry
>>
>> Additions to the sub-registry "CoAP Content-Formats", wi= thin the
>> "CoRE Parameters" registry are needed for the below medi= a types.
>> These can be registered either in the Expert Review range
>> (0-255) or
>> IETF Review range (256-9999).
>>
>> 1.
>>
>> *=C2=A0 application/pkcs7-mime
>> *=C2=A0 Type name: application
>> *=C2=A0 Subtype name: pkcs7-mime
>> *=C2=A0 ID: TBD1
>> *=C2=A0 Required parameters: None
>> *=C2=A0 Optional parameters: None
>> *=C2=A0 Encoding considerations: binary
>> *=C2=A0 Security considerations: As defined in this specification<= br> >> *=C2=A0 Published specification: [RFC5751]
>> *=C2=A0 Applications that use this media type: EST
>>
>> 2.
>>
>> *=C2=A0 application/pkcs8
>> *=C2=A0 Type name: application
>> *=C2=A0 Subtype name: pkcs8
>> *=C2=A0 ID: TBD2
>> *=C2=A0 Required parameters: None
>> *=C2=A0 Optional parameters: None
>> *=C2=A0 Encoding considerations: binary
>> *=C2=A0 Security considerations: As defined in this specification<= br> >> *=C2=A0 Published specification: [RFC5958]
>> *=C2=A0 Applications that use this media type: EST
>>
>> 3.
>>
>> *=C2=A0 application/csrattrs
>> *=C2=A0 Type name: application
>> *=C2=A0 Subtype name: csrattrs
>> *=C2=A0 ID: TBD3
>> *=C2=A0 Required parameters: None
>> *=C2=A0 Optional parameters: None
>> *=C2=A0 Encoding considerations: binary
>> *=C2=A0 Security considerations: As defined in this specification<= br> >> *=C2=A0 Published specification: [RFC7030]
>> *=C2=A0 Applications that use this media type: EST
>>
>> 4.
>>
>> *=C2=A0 application/pkcs10
>> *=C2=A0 Type name: application
>> *=C2=A0 Subtype name: pkcs10
>> *=C2=A0 ID: TBD4
>> *=C2=A0 Required parameters: None
>> *=C2=A0 Optional parameters: None
>> *=C2=A0 Encoding considerations: binar
>> *=C2=A0 Security considerations: As defined in this specification<= br> >> *=C2=A0 Published specification: [RFC5967]
>> *=C2=A0 Applications that use this media type: EST
>>
>>
> ______________________________________________________________________= _____________________
>>
>> --
>> Peter van der Stok
>> vanderstok consultancy
>> mailto: consultancy@vanderstok.org
>> www: www.vanderstok.org [1]
>> tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015248
>>
>> _______________________________________________
>> core-parameters mailing list
>> core= -parameters@ietf.org
>> https://www.ietf.org/mailman/listinfo/= core-parameters
>
>
> Links:
> ------
> [1] http://www.vanderstok.org
--0000000000009a35da056d044f24-- From nobody Fri May 25 02:44:05 2018 Return-Path: X-Original-To: core-parameters@ietfa.amsl.com Delivered-To: core-parameters@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCCD12D953; Fri, 25 May 2018 02:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s47fBsE1bbI; Fri, 25 May 2018 02:44:01 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DE6124B0A; Fri, 25 May 2018 02:44:00 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud9.xs4all.net with ESMTPA id M9GOfwv6rRSWtM9GOfQ8Xs; Fri, 25 May 2018 11:43:58 +0200 Received: from AMontpellier-654-1-155-119.w90-0.abo.wanadoo.fr ([90.0.250.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 25 May 2018 11:43:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 25 May 2018 11:43:56 +0200 From: peter van der Stok To: Klaus Hartke Cc: consultancy@vanderstok.org, Hannes Tschofenig , core-parameters@ietf.org, draft-ietf-ace-coap-est@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> <24ec93bb245164263df36d81aaf10c43@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfJa/fgEvHvlASyb42q8QPhBwOzR9pqQx7yI5NkdZanInc1gFPYwZ3O8loZfsJN0DQ+FGN0Wzu5NYWy/4QB+3MZfPC3RfCKzwHIP/BR5fugEPCuTP23C4 anTcczRXrKI36qtkZmq2f/+s1KHYnvWMnDSbiGzZvpDgsmXKyWw12GJdWUOFaTLJ8b7PJnxqMp33KkSIfhGTNarip3XEFHX9dbyAbRibYXz0DeWn2SMgvzXW X3AYdEjzH05AaUSrIjg4n/TEEHpWrSzaE6/kKNvylmB9p1HzMYJf/zLQAqmhqAU787wlRzTwR13KOuP3B0270QohCn2/JwLPg2nd/qdPwhuu+K3YxwpEi0pt IYydRA95daxh/hoPMYw0ZPmDKuS8NTAgGQl1TMbmxw8UXrVJgdbVhnZl26t13v7vsjhZS1DZ Archived-At: Subject: Re: [core-parameters] Core content-format number allocation X-BeenThere: core-parameters@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Expert review of CoAP parameters." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 09:44:03 -0000 Hi Klaus, the updated table. some reactions to your very useful remarks further below. many thanks, greetings, Peter - application/pkcs7-mime; smime-type=“server-generated-key"; Encoding ="identity"; ID = TBD1; Reference = RFC5751, RFC7030, RFC7231 - application/pkcs7-mime; smime-type=“certs-only”; Encoding = "identity"; ID = TBD2; Reference = RFC5751, RFC7231 - application/pkcs7-mime; smime-type=“CMC-request”; Encoding = "identity"; ID = TBD3; Reference = RFC5751, RFC5273, RFC7231 - application/pkcs7-mime; smime-type=“CMC-response”; Encoding = "identity"; ID = TBD4; Reference = RFC5751, RFC5273, RFC7231 - application/pkcs8; Encoding = "identity"; ID = TBD5; Reference = RFC5958, RFC7231 - application/csrattrs; Encoding = "identity"; ID = TBD6; Reference = RFC7030, RFC7231 - application/pkcs10; Encoding = "identity"; ID = TBD7; Reference = RFC5967, RFC7231 Klaus Hartke schreef op 2018-05-25 11:22: > What about “CMC-Response”? thanks, I missed that one. > > There’s a registry for “smime-type” values at > https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml#smime > Would it make sense to simply allocate a Content-Format ID to each of > them? I prefer to only specify those used in RFC7030 > > The media type and the content coding are orthogonal. However, > “binary” is not a valid content coding. (It’s really confusing > that the column is labeled “Encoding”; content coding is what is > meant.) Possible content codings are listed in > https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding > You probably want the “identity“ content coding. You are right. looks most probable one. > > “application/pkcs8” and the other two media types don’t have the > “smime-type” parameter defined, so just remove that bit. > > Otherwise the table looks good to me. > > Klaus > > On Fri 25. May 2018 at 10:58, peter van der Stok > wrote: > >> HI Klaus, >> >> Thanks for the quick reaction, and thanks for pointing out some >> existing >> other smime types. >> I did a search in RFC 7030, and came up with other necessary smime >> types. >> >> Below the table as required for est-coap draft: (I will change the >> draft >> accordingly) >> >> - application/pkcs7-mime; smime-type=“server-generated-key”; >> Encoding = >> "binary"; ID = TBD1; Reference = RFC5751, RFC7030 >> - application/pkcs7-mime; smime-type=“certs-only”; Encoding = >> "binary"; >> ID = TBD2; Reference = RFC5751 >> - application/pkcs7-mime; smime-type=“CMC-request”; Encoding = >> "binary"; >> ID = TBD3; Reference = RFC5751, RFC5273 >> - application/pkcs8; smime-type = ---; Encoding = "binary"; ID = >> TBD4; >> Reference = RFC5958 >> - application/csrattrs; smime-type = ---; Encoding = "binary"; ID = >> TBD5; Reference = RFC7030 >> - application/pkcs10; smime-type = ---; Encoding = "binary"; ID = >> TBD6; >> Reference = RFC5967 >> >> I expect the Encoding is orthogonal to the media type and smime type >> >> specification. >> >> Many thanks, >> >> peter >> >> Klaus Hartke schreef op 2018-05-25 09:48: >>> Hi Peter, >>> >>> I see you’re requesting Content-Format IDs for the following >>> existing media types: >>> >>> - application/pkcs7-mime >>> - application/pkcs8 >>> - application/csrattrs >>> - application/pkcs10 >>> >>> A Content-Format is the combination of a media type and a content >>> coding. Please specify the content coding(s) you want to use with >> each >>> media type. The possible set of content codings can be found at >>> >> > https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding >>> >>> Please format your request as a table that looks like Table 9 in >>> https://tools.ietf.org/html/rfc7252#section-12.3 (one row for each >>> combination of a media type and a content coding) >>> >>> It seems “application/pkcs7-mime“ actually does define a media >>> type parameter, “smime-type ”. RFC 5751 says: >>> >>> Because there are several types of application/pkcs7-mime >> objects, >>> a >>> sending agent SHOULD do as much as possible to help a receiving >>> agent >>> know about the contents of the object without forcing the >> receiving >>> agent to decode the ASN.1 for the object. The Content-Type >> header >>> field of all application/pkcs7-mime objects SHOULD include the >>> optional "smime-type" parameter, as described in the following >>> sections. >>> >>> So it seems the parameter is more or less required. Do you want to >>> register a Content-Format ID for each defined smime-type value? >> Then >>> the list of media types (that need to be paired with a content >> coding) >>> looks like this: >>> >>> - application/pkcs7-mime; smime-type=“enveloped-data” >>> - application/pkcs7-mime; smime-type=“signed-data” >>> - application/pkcs7-mime; smime-type=“certs-only” >>> - application/pkcs7-mime; smime-type=“compressed-data” >>> - application/pkcs8 >>> - application/csrattrs >>> - application/pkcs10 >>> >>> Klaus >>> >>> On Fri 25. May 2018 at 09:27, peter van der Stok >> >>> wrote: >>> >>>> Dear core parameter experts, >>>> >>>> In draft-ietf-ace-coap-est we want to allocate content format >>>> numbers to >>>> 4 already existing media formats. >>>> LWM2M people are implementing the est-coaps specification and >> want >>>> to >>>> deploy it as quickly as possible. >>>> Therefore, they need to know the allocated numbers to write into >>>> their >>>> code. >>>> An early allocation before publication of the draft as RFC will >> be >>>> appreciated. >>>> >>>> Below the IANA text from the draft, using TBD1 - TBD4 as >> allocated >>>> numbers. >>>> >>>> Many thanks, >>>> >>>> peter >>>> >>>> >>> >> > __________________________________________________________________________________________________________ >>>> >>>> 8.1. Content-Format registry >>>> >>>> Additions to the sub-registry "CoAP Content-Formats", within the >>>> "CoRE Parameters" registry are needed for the below media types. >>>> These can be registered either in the Expert Review range >>>> (0-255) or >>>> IETF Review range (256-9999). >>>> >>>> 1. >>>> >>>> * application/pkcs7-mime >>>> * Type name: application >>>> * Subtype name: pkcs7-mime >>>> * ID: TBD1 >>>> * Required parameters: None >>>> * Optional parameters: None >>>> * Encoding considerations: binary >>>> * Security considerations: As defined in this specification >>>> * Published specification: [RFC5751] >>>> * Applications that use this media type: EST >>>> >>>> 2. >>>> >>>> * application/pkcs8 >>>> * Type name: application >>>> * Subtype name: pkcs8 >>>> * ID: TBD2 >>>> * Required parameters: None >>>> * Optional parameters: None >>>> * Encoding considerations: binary >>>> * Security considerations: As defined in this specification >>>> * Published specification: [RFC5958] >>>> * Applications that use this media type: EST >>>> >>>> 3. >>>> >>>> * application/csrattrs >>>> * Type name: application >>>> * Subtype name: csrattrs >>>> * ID: TBD3 >>>> * Required parameters: None >>>> * Optional parameters: None >>>> * Encoding considerations: binary >>>> * Security considerations: As defined in this specification >>>> * Published specification: [RFC7030] >>>> * Applications that use this media type: EST >>>> >>>> 4. >>>> >>>> * application/pkcs10 >>>> * Type name: application >>>> * Subtype name: pkcs10 >>>> * ID: TBD4 >>>> * Required parameters: None >>>> * Optional parameters: None >>>> * Encoding considerations: binar >>>> * Security considerations: As defined in this specification >>>> * Published specification: [RFC5967] >>>> * Applications that use this media type: EST >>>> >>>> >>> >> > ___________________________________________________________________________________________ >>>> >>>> -- >>>> Peter van der Stok >>>> vanderstok consultancy >>>> mailto: consultancy@vanderstok.org >>>> www: www.vanderstok.org [1] [1] >>>> tel NL: +31(0)492474673 F: +33(0)966015248 >>>> >>>> _______________________________________________ >>>> core-parameters mailing list >>>> core-parameters@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core-parameters >>> >>> >>> Links: >>> ------ >>> [1] http://www.vanderstok.org > > > Links: > ------ > [1] http://www.vanderstok.org From nobody Fri May 25 03:00:49 2018 Return-Path: X-Original-To: core-parameters@ietfa.amsl.com Delivered-To: core-parameters@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70D12D95A; Fri, 25 May 2018 03:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keFvPv1hY5TQ; Fri, 25 May 2018 03:00:44 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73B012D958; Fri, 25 May 2018 03:00:43 -0700 (PDT) Received: from mail-qt0-f173.google.com ([209.85.216.173]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fM9Wb-0002my-Is; Fri, 25 May 2018 12:00:41 +0200 Received: by mail-qt0-f173.google.com with SMTP id m5-v6so5826508qti.1; Fri, 25 May 2018 03:00:41 -0700 (PDT) X-Gm-Message-State: ALKqPwcKvOxb2tnk2e8gUL8KafeJsP63fW1fwfx8yOiUSshRp7CSTYZw YWo8C00GfVE5RcfhXgccfVfRWABKgO9Ps6LSTfY= X-Google-Smtp-Source: ADUXVKLjMkbAat5N7Dl5zxYb7cFG+tUxoMSl4BE2ZQfOaoqeIdnHYHul/lo2eabiy1KF6dtSEBlUaB3qv8veX+Ba5D0= X-Received: by 2002:aed:3b49:: with SMTP id q9-v6mr1474288qte.331.1527242440541; Fri, 25 May 2018 03:00:40 -0700 (PDT) MIME-Version: 1.0 References: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> <24ec93bb245164263df36d81aaf10c43@xs4all.nl> In-Reply-To: From: Klaus Hartke Date: Fri, 25 May 2018 12:00:29 +0200 X-Gmail-Original-Message-ID: Message-ID: To: consultancy@vanderstok.org Cc: Hannes Tschofenig , core-parameters@ietf.org, draft-ietf-ace-coap-est@ietf.org Content-Type: multipart/alternative; boundary="00000000000027913a056d04d791" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1527242444; 00c5c915; X-HE-SMSGID: 1fM9Wb-0002my-Is Archived-At: Subject: Re: [core-parameters] Core content-format number allocation X-BeenThere: core-parameters@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Expert review of CoAP parameters." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:00:48 -0000 --00000000000027913a056d04d791 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thumbs up =F0=9F=91=8D On Fri 25. May 2018 at 11:44, peter van der Stok wrote= : > Hi Klaus, > > the updated table. some reactions to your very useful remarks further > below. many thanks, > > greetings, > > Peter > > > - application/pkcs7-mime; smime-type=3D=E2=80=9Cserver-generated-key"; En= coding > =3D"identity"; ID =3D TBD1; Reference =3D RFC5751, RFC7030, RFC7231 > - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D; Enco= ding =3D > "identity"; ID =3D TBD2; Reference =3D RFC5751, RFC7231 > - application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-request=E2=80=9D; Enc= oding =3D > "identity"; ID =3D TBD3; Reference =3D RFC5751, RFC5273, RFC7231 > - application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-response=E2=80=9D; En= coding =3D > "identity"; ID =3D TBD4; Reference =3D RFC5751, RFC5273, RFC7231 > - application/pkcs8; Encoding =3D "identity"; ID =3D TBD5; Reference =3D > RFC5958, RFC7231 > - application/csrattrs; Encoding =3D "identity"; ID =3D TBD6; Reference = =3D > RFC7030, RFC7231 > - application/pkcs10; Encoding =3D "identity"; ID =3D TBD7; Reference =3D > RFC5967, RFC7231 > > Klaus Hartke schreef op 2018-05-25 11:22: > > What about =E2=80=9CCMC-Response=E2=80=9D? > > thanks, I missed that one. > > > > > There=E2=80=99s a registry for =E2=80=9Csmime-type=E2=80=9D values at > > > https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub= -parameters.xhtml#smime > > Would it make sense to simply allocate a Content-Format ID to each of > > them? > I prefer to only specify those used in RFC7030 > > > > The media type and the content coding are orthogonal. However, > > =E2=80=9Cbinary=E2=80=9D is not a valid content coding. (It=E2=80=99s r= eally confusing > > that the column is labeled =E2=80=9CEncoding=E2=80=9D; content coding i= s what is > > meant.) Possible content codings are listed in > > > https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#co= ntent-coding > > You probably want the =E2=80=9Cidentity=E2=80=9C content coding. > > You are right. looks most probable one. > > > > =E2=80=9Capplication/pkcs8=E2=80=9D and the other two media types don= =E2=80=99t have the > > =E2=80=9Csmime-type=E2=80=9D parameter defined, so just remove that bit= . > > > > Otherwise the table looks good to me. > > > > Klaus > > > > On Fri 25. May 2018 at 10:58, peter van der Stok > > wrote: > > > >> HI Klaus, > >> > >> Thanks for the quick reaction, and thanks for pointing out some > >> existing > >> other smime types. > >> I did a search in RFC 7030, and came up with other necessary smime > >> types. > >> > >> Below the table as required for est-coap draft: (I will change the > >> draft > >> accordingly) > >> > >> - application/pkcs7-mime; smime-type=3D=E2=80=9Cserver-generated-key= =E2=80=9D; > >> Encoding =3D > >> "binary"; ID =3D TBD1; Reference =3D RFC5751, RFC7030 > >> - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D; E= ncoding =3D > >> "binary"; > >> ID =3D TBD2; Reference =3D RFC5751 > >> - application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-request=E2=80=9D; = Encoding =3D > >> "binary"; > >> ID =3D TBD3; Reference =3D RFC5751, RFC5273 > >> - application/pkcs8; smime-type =3D ---; Encoding =3D "binary"; ID =3D > >> TBD4; > >> Reference =3D RFC5958 > >> - application/csrattrs; smime-type =3D ---; Encoding =3D "binary"; ID = =3D > >> TBD5; Reference =3D RFC7030 > >> - application/pkcs10; smime-type =3D ---; Encoding =3D "binary"; ID = =3D > >> TBD6; > >> Reference =3D RFC5967 > >> > >> I expect the Encoding is orthogonal to the media type and smime type > >> > >> specification. > >> > >> Many thanks, > >> > >> peter > >> > >> Klaus Hartke schreef op 2018-05-25 09:48: > >>> Hi Peter, > >>> > >>> I see you=E2=80=99re requesting Content-Format IDs for the following > >>> existing media types: > >>> > >>> - application/pkcs7-mime > >>> - application/pkcs8 > >>> - application/csrattrs > >>> - application/pkcs10 > >>> > >>> A Content-Format is the combination of a media type and a content > >>> coding. Please specify the content coding(s) you want to use with > >> each > >>> media type. The possible set of content codings can be found at > >>> > >> > > > https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#co= ntent-coding > >>> > >>> Please format your request as a table that looks like Table 9 in > >>> https://tools.ietf.org/html/rfc7252#section-12.3 (one row for each > >>> combination of a media type and a content coding) > >>> > >>> It seems =E2=80=9Capplication/pkcs7-mime=E2=80=9C actually does defin= e a media > >>> type parameter, =E2=80=9Csmime-type =E2=80=9D. RFC 5751 says: > >>> > >>> Because there are several types of application/pkcs7-mime > >> objects, > >>> a > >>> sending agent SHOULD do as much as possible to help a receiving > >>> agent > >>> know about the contents of the object without forcing the > >> receiving > >>> agent to decode the ASN.1 for the object. The Content-Type > >> header > >>> field of all application/pkcs7-mime objects SHOULD include the > >>> optional "smime-type" parameter, as described in the following > >>> sections. > >>> > >>> So it seems the parameter is more or less required. Do you want to > >>> register a Content-Format ID for each defined smime-type value? > >> Then > >>> the list of media types (that need to be paired with a content > >> coding) > >>> looks like this: > >>> > >>> - application/pkcs7-mime; smime-type=3D=E2=80=9Cenveloped-data=E2=80= =9D > >>> - application/pkcs7-mime; smime-type=3D=E2=80=9Csigned-data=E2=80=9D > >>> - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D > >>> - application/pkcs7-mime; smime-type=3D=E2=80=9Ccompressed-data=E2=80= =9D > >>> - application/pkcs8 > >>> - application/csrattrs > >>> - application/pkcs10 > >>> > >>> Klaus > >>> > >>> On Fri 25. May 2018 at 09:27, peter van der Stok > >> > >>> wrote: > >>> > >>>> Dear core parameter experts, > >>>> > >>>> In draft-ietf-ace-coap-est we want to allocate content format > >>>> numbers to > >>>> 4 already existing media formats. > >>>> LWM2M people are implementing the est-coaps specification and > >> want > >>>> to > >>>> deploy it as quickly as possible. > >>>> Therefore, they need to know the allocated numbers to write into > >>>> their > >>>> code. > >>>> An early allocation before publication of the draft as RFC will > >> be > >>>> appreciated. > >>>> > >>>> Below the IANA text from the draft, using TBD1 - TBD4 as > >> allocated > >>>> numbers. > >>>> > >>>> Many thanks, > >>>> > >>>> peter > >>>> > >>>> > >>> > >> > > > _________________________________________________________________________= _________________________________ > >>>> > >>>> 8.1. Content-Format registry > >>>> > >>>> Additions to the sub-registry "CoAP Content-Formats", within the > >>>> "CoRE Parameters" registry are needed for the below media types. > >>>> These can be registered either in the Expert Review range > >>>> (0-255) or > >>>> IETF Review range (256-9999). > >>>> > >>>> 1. > >>>> > >>>> * application/pkcs7-mime > >>>> * Type name: application > >>>> * Subtype name: pkcs7-mime > >>>> * ID: TBD1 > >>>> * Required parameters: None > >>>> * Optional parameters: None > >>>> * Encoding considerations: binary > >>>> * Security considerations: As defined in this specification > >>>> * Published specification: [RFC5751] > >>>> * Applications that use this media type: EST > >>>> > >>>> 2. > >>>> > >>>> * application/pkcs8 > >>>> * Type name: application > >>>> * Subtype name: pkcs8 > >>>> * ID: TBD2 > >>>> * Required parameters: None > >>>> * Optional parameters: None > >>>> * Encoding considerations: binary > >>>> * Security considerations: As defined in this specification > >>>> * Published specification: [RFC5958] > >>>> * Applications that use this media type: EST > >>>> > >>>> 3. > >>>> > >>>> * application/csrattrs > >>>> * Type name: application > >>>> * Subtype name: csrattrs > >>>> * ID: TBD3 > >>>> * Required parameters: None > >>>> * Optional parameters: None > >>>> * Encoding considerations: binary > >>>> * Security considerations: As defined in this specification > >>>> * Published specification: [RFC7030] > >>>> * Applications that use this media type: EST > >>>> > >>>> 4. > >>>> > >>>> * application/pkcs10 > >>>> * Type name: application > >>>> * Subtype name: pkcs10 > >>>> * ID: TBD4 > >>>> * Required parameters: None > >>>> * Optional parameters: None > >>>> * Encoding considerations: binar > >>>> * Security considerations: As defined in this specification > >>>> * Published specification: [RFC5967] > >>>> * Applications that use this media type: EST > >>>> > >>>> > >>> > >> > > > _________________________________________________________________________= __________________ > >>>> > >>>> -- > >>>> Peter van der Stok > >>>> vanderstok consultancy > >>>> mailto: consultancy@vanderstok.org > >>>> www: www.vanderstok.org [1] [1] > >>>> tel NL: +31(0)492474673 F: +33(0)966015248 > >>>> > >>>> _______________________________________________ > >>>> core-parameters mailing list > >>>> core-parameters@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/core-parameters > >>> > >>> > >>> Links: > >>> ------ > >>> [1] http://www.vanderstok.org > > > > > > Links: > > ------ > > [1] http://www.vanderstok.org > --00000000000027913a056d04d791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thumbs up =F0=9F=91=8D



On Fri = 25. May 2018 at 11:44, peter van der Stok <stokcons@xs4all.nl> wrote:
Hi Klaus,

the updated table. some reactions to your very useful remarks further
below. many thanks,

greetings,

Peter


- application/pkcs7-mime; smime-type=3D=E2=80=9Cserver-generated-key";= Encoding
=3D"identity"; ID =3D TBD1; Reference =3D RFC5751, RFC7030, RFC72= 31
- application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80=9D; Encodi= ng =3D
"identity"; ID =3D TBD2; Reference =3D RFC5751, RFC7231
- application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-request=E2=80=9D; Encod= ing =3D
"identity"; ID =3D TBD3; Reference =3D RFC5751, RFC5273, RFC7231<= br> - application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-response=E2=80=9D; Enco= ding =3D
"identity"; ID =3D TBD4; Reference =3D RFC5751, RFC5273, RFC7231<= br> - application/pkcs8; Encoding =3D "identity"; ID =3D TBD5; Refere= nce =3D
RFC5958, RFC7231
- application/csrattrs; Encoding =3D "identity"; ID =3D TBD6; Ref= erence =3D
RFC7030, RFC7231
- application/pkcs10; Encoding =3D "identity"; ID =3D TBD7; Refer= ence =3D
RFC5967, RFC7231

Klaus Hartke schreef op 2018-05-25 11:22:
> What about =E2=80=9CCMC-Response=E2=80=9D?

thanks, I missed that one.

>
> There=E2=80=99s a registry for =E2=80=9Csmime-type=E2=80=9D values at<= br> > https://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-= parameters.xhtml#smime
> Would it make sense to simply allocate a Content-Format ID to each of<= br> > them?
I prefer to only specify those used in RFC7030
>
> The media type and the content coding are orthogonal. However,
> =E2=80=9Cbinary=E2=80=9D is not a valid content coding. (It=E2=80=99s = really confusing
> that the column is labeled =E2=80=9CEncoding=E2=80=9D; content coding = is what is
> meant.) Possible content codings are listed in
> https://ww= w.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding=
> You probably want the =E2=80=9Cidentity=E2=80=9C content coding.

You are right. looks most probable one.
>
> =E2=80=9Capplication/pkcs8=E2=80=9D and the other two media types don= =E2=80=99t have the
> =E2=80=9Csmime-type=E2=80=9D parameter defined, so just remove that bi= t.
>
> Otherwise the table looks good to me.
>
> Klaus
>
> On Fri 25. May 2018 at 10:58, peter van der Stok <stokcons@xs4all.nl>
> wrote:
>
>> HI Klaus,
>>
>> Thanks for the quick reaction, and thanks for pointing out some >> existing
>> other smime types.
>> I did a search in RFC 7030, and came up with other necessary smime=
>> types.
>>
>> Below the table as required for est-coap draft: (I will change the=
>> draft
>> accordingly)
>>
>> - application/pkcs7-mime; smime-type=3D=E2=80=9Cserver-generated-k= ey=E2=80=9D;
>> Encoding =3D
>> "binary"; ID =3D TBD1; Reference =3D RFC5751, RFC7030 >> - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2=80= =9D; Encoding =3D
>> "binary";
>> ID =3D TBD2; Reference =3D RFC5751
>> - application/pkcs7-mime; smime-type=3D=E2=80=9CCMC-request=E2=80= =9D; Encoding =3D
>> "binary";
>> ID =3D TBD3; Reference =3D RFC5751, RFC5273
>> - application/pkcs8; smime-type =3D ---; Encoding =3D "binary= "; ID =3D
>> TBD4;
>> Reference =3D RFC5958
>> - application/csrattrs; smime-type =3D ---; Encoding =3D "bin= ary"; ID =3D
>> TBD5; Reference =3D RFC7030
>> - application/pkcs10; smime-type =3D ---; Encoding =3D "binar= y"; ID =3D
>> TBD6;
>> Reference =3D RFC5967
>>
>> I expect the Encoding is orthogonal to the media type and smime ty= pe
>>
>> specification.
>>
>> Many thanks,
>>
>> peter
>>
>> Klaus Hartke schreef op 2018-05-25 09:48:
>>> Hi Peter,
>>>
>>> I see you=E2=80=99re requesting Content-Format IDs for the fol= lowing
>>> existing media types:
>>>
>>> - application/pkcs7-mime
>>> - application/pkcs8
>>> - application/csrattrs
>>> - application/pkcs10
>>>
>>> A Content-Format is the combination of a media type and a cont= ent
>>> coding. Please specify the content coding(s) you want to use w= ith
>> each
>>> media type. The possible set of content codings can be found a= t
>>>
>>
> https://ww= w.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding=
>>>
>>> Please format your request as a table that looks like Table 9 = in
>>> https://tools.ietf.org/html/rfc7252#sec= tion-12.3 (one row for each
>>> combination of a media type and a content coding)
>>>
>>> It seems =E2=80=9Capplication/pkcs7-mime=E2=80=9C actually doe= s define a media
>>> type parameter, =E2=80=9Csmime-type =E2=80=9D. RFC 5751 says:<= br> >>>
>>> Because there are several types of application/pkcs7-mime
>> objects,
>>> a
>>> sending agent SHOULD do as much as possible to help a receivin= g
>>> agent
>>> know about the contents of the object without forcing the
>> receiving
>>> agent to decode the ASN.1 for the object.=C2=A0 The Content-Ty= pe
>> header
>>> field of all application/pkcs7-mime objects SHOULD include the=
>>> optional "smime-type" parameter, as described in the= following
>>> sections.
>>>
>>> So it seems the parameter is more or less required. Do you wan= t to
>>> register a Content-Format ID for each defined smime-type value= ?
>> Then
>>> the list of media types (that need to be paired with a content=
>> coding)
>>> looks like this:
>>>
>>> - application/pkcs7-mime; smime-type=3D=E2=80=9Cenveloped-data= =E2=80=9D
>>> - application/pkcs7-mime; smime-type=3D=E2=80=9Csigned-data=E2= =80=9D
>>> - application/pkcs7-mime; smime-type=3D=E2=80=9Ccerts-only=E2= =80=9D
>>> - application/pkcs7-mime; smime-type=3D=E2=80=9Ccompressed-dat= a=E2=80=9D
>>> - application/pkcs8
>>> - application/csrattrs
>>> - application/pkcs10
>>>
>>> Klaus
>>>
>>> On Fri 25. May 2018 at 09:27, peter van der Stok
>> <stokco= ns@xs4all.nl>
>>> wrote:
>>>
>>>> Dear core parameter experts,
>>>>
>>>> In draft-ietf-ace-coap-est we want to allocate content for= mat
>>>> numbers to
>>>> 4 already existing media formats.
>>>> LWM2M people are implementing the est-coaps specification = and
>> want
>>>> to
>>>> deploy it as quickly as possible.
>>>> Therefore, they need to know the allocated numbers to writ= e into
>>>> their
>>>> code.
>>>> An early allocation before publication of the draft as RFC= will
>> be
>>>> appreciated.
>>>>
>>>> Below the IANA text from the draft, using TBD1 - TBD4 as >> allocated
>>>> numbers.
>>>>
>>>> Many thanks,
>>>>
>>>> peter
>>>>
>>>>
>>>
>>
> ______________________________________________________________________= ____________________________________
>>>>
>>>> 8.1.=C2=A0 Content-Format registry
>>>>
>>>> Additions to the sub-registry "CoAP Content-Formats&q= uot;, within the
>>>> "CoRE Parameters" registry are needed for the be= low media types.
>>>> These can be registered either in the Expert Review range<= br> >>>> (0-255) or
>>>> IETF Review range (256-9999).
>>>>
>>>> 1.
>>>>
>>>> *=C2=A0 application/pkcs7-mime
>>>> *=C2=A0 Type name: application
>>>> *=C2=A0 Subtype name: pkcs7-mime
>>>> *=C2=A0 ID: TBD1
>>>> *=C2=A0 Required parameters: None
>>>> *=C2=A0 Optional parameters: None
>>>> *=C2=A0 Encoding considerations: binary
>>>> *=C2=A0 Security considerations: As defined in this specif= ication
>>>> *=C2=A0 Published specification: [RFC5751]
>>>> *=C2=A0 Applications that use this media type: EST
>>>>
>>>> 2.
>>>>
>>>> *=C2=A0 application/pkcs8
>>>> *=C2=A0 Type name: application
>>>> *=C2=A0 Subtype name: pkcs8
>>>> *=C2=A0 ID: TBD2
>>>> *=C2=A0 Required parameters: None
>>>> *=C2=A0 Optional parameters: None
>>>> *=C2=A0 Encoding considerations: binary
>>>> *=C2=A0 Security considerations: As defined in this specif= ication
>>>> *=C2=A0 Published specification: [RFC5958]
>>>> *=C2=A0 Applications that use this media type: EST
>>>>
>>>> 3.
>>>>
>>>> *=C2=A0 application/csrattrs
>>>> *=C2=A0 Type name: application
>>>> *=C2=A0 Subtype name: csrattrs
>>>> *=C2=A0 ID: TBD3
>>>> *=C2=A0 Required parameters: None
>>>> *=C2=A0 Optional parameters: None
>>>> *=C2=A0 Encoding considerations: binary
>>>> *=C2=A0 Security considerations: As defined in this specif= ication
>>>> *=C2=A0 Published specification: [RFC7030]
>>>> *=C2=A0 Applications that use this media type: EST
>>>>
>>>> 4.
>>>>
>>>> *=C2=A0 application/pkcs10
>>>> *=C2=A0 Type name: application
>>>> *=C2=A0 Subtype name: pkcs10
>>>> *=C2=A0 ID: TBD4
>>>> *=C2=A0 Required parameters: None
>>>> *=C2=A0 Optional parameters: None
>>>> *=C2=A0 Encoding considerations: binar
>>>> *=C2=A0 Security considerations: As defined in this specif= ication
>>>> *=C2=A0 Published specification: [RFC5967]
>>>> *=C2=A0 Applications that use this media type: EST
>>>>
>>>>
>>>
>>
> ______________________________________________________________________= _____________________
>>>>
>>>> --
>>>> Peter van der Stok
>>>> vanderstok consultancy
>>>> mailto: consultancy@vanderstok.org
>>>> www: www.vanderstok.org [1] [1]
>>>> tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015= 248
>>>>
>>>> _______________________________________________
>>>> core-parameters mailing list
>>>> core-parameters@ietf.org
>>>> https://www.ietf.org/mailman/l= istinfo/core-parameters
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://www.vanderstok.org
>
>
> Links:
> ------
> [1] http://www.vanderstok.org
--00000000000027913a056d04d791-- From esko.dijk@signify.com Fri May 25 06:12:19 2018 Return-Path: X-Original-To: core-parameters@ietfa.amsl.com Delivered-To: core-parameters@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3EC126CD6; Fri, 25 May 2018 06:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=signify.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzAhpMtW9QJh; Fri, 25 May 2018 06:12:16 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0113.outbound.protection.outlook.com [104.47.2.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548861201F2; Fri, 25 May 2018 06:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=signify.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w3u2OSLyvS+hW4kleb0ZcDwWHRDo3pOOl6zINKFUuCQ=; b=gLeDZbQzkEfNeIqWQKY1Z7BusO0FjoEDQzI1m9dmr1wR8IbBQG1zLbe9rW/WGRSrYJkJqvHNzoibwLsRe2j1pIMkfUdxo0T85539lhthnHr5K3RTCYCNhMU3WT+lqotDS5w8Z153h9NY3cy0TtwmQBb0mantGcYiBx1A3cg8qSw= Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM (129.75.24.213) by VI1P121MB0032.EURP121.PROD.OUTLOOK.COM (129.75.24.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.18; Fri, 25 May 2018 13:12:12 +0000 Received: from VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::3d0f:c3a6:7082:8666]) by VI1P121MB0014.EURP121.PROD.OUTLOOK.COM ([fe80::3d0f:c3a6:7082:8666%14]) with mapi id 15.20.0776.019; Fri, 25 May 2018 13:12:12 +0000 From: Esko Dijk To: "consultancy@vanderstok.org" , Klaus Hartke CC: "draft-ietf-ace-coap-est@ietf.org" , Hannes Tschofenig , "core-parameters@ietf.org" Thread-Topic: [core-parameters] Core content-format number allocation Thread-Index: AQHT8/nUK/yr8C2jYUewLAPCHAKXoaRAEZ2AgAAThwCAAAa9gIAABfcAgAA27qA= Date: Fri, 25 May 2018 13:12:12 +0000 Message-ID: References: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> <24ec93bb245164263df36d81aaf10c43@xs4all.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@signify.com; x-originating-ip: [2001:1c02:3100:4a00:b02c:9091:14bb:782] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1P121MB0032; 7:RCbk3ZEDsd04TyCYvzHbZzHjOyNH65WtLMd2YW79CtsrXo5U0WS5bUYs/p7Z+bZODJDVyQUw+PBprry1c0/pr1FKMyFkSdWB9NBG5/5OduZT3YQZ/Tyy9hl8YcZSfHjbv5eoU++06qa2EMVIDIRERGYLBKHpUoouV+Wl3YiHUHxr+WlUA+CD8xz+J5sfp1wOqcRxfLYYp+OuDVxJdxcbgjJmJZjgxVvu0qXrPjf2Run+VSfFTOvOt7qeMu/6mLCr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:VI1P121MB0032; x-ms-traffictypediagnostic: VI1P121MB0032: soc: Internal x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(248736688235697)(1591387915157); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1P121MB0032; BCL:0; PCL:0; RULEID:; SRVR:VI1P121MB0032; x-forefront-prvs: 06833C6A67 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(39380400002)(396003)(366004)(199004)(189003)(377424004)(51914003)(13464003)(3660700001)(4326008)(68736007)(15974865002)(6306002)(53936002)(486006)(11346002)(446003)(9686003)(55016002)(229853002)(6436002)(54906003)(6246003)(2501003)(86362001)(3280700002)(316002)(305945005)(7736002)(5250100002)(99286004)(2906002)(2900100001)(110136005)(478600001)(8936002)(33656002)(5660300001)(7696005)(6116002)(81166006)(53386004)(966005)(25786009)(106356001)(74316002)(76176011)(46003)(186003)(14454004)(81156014)(59450400001)(476003)(53546011)(105586002)(8676002)(6506007)(102836004)(97736004)(44832011)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P121MB0032; H:VI1P121MB0014.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: signify.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ose34HZ/XzfjOvpLoND5H3VfJetqINa5Av+SYoE0BwQZ0f2q5pZALhUGu1403SABLWfS3GPOCdCFitQYGQ0eF1mwCCGB/bUK6DdQTFCcSEP54gVgA1s1fQ0nWsZBe/B+vq+8qd0dlWShVEAhErwcbJFaCYQsmUuZrGVxw7zaI5M/UNuu8HY2Ekc+OiI0vk1y spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c3c85681-bf31-4689-016d-08d5c24120ec X-OriginatorOrg: signify.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3c85681-bf31-4689-016d-08d5c24120ec X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2018 13:12:12.2387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 75b2f54b-feff-400d-8e0b-67102edb9a23 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0032 Archived-At: X-Mailman-Approved-At: Fri, 25 May 2018 11:13:29 -0700 Subject: Re: [core-parameters] Core content-format number allocation X-BeenThere: core-parameters@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Expert review of CoAP parameters." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 18:08:22 -0000 SGVsbG8gUGV0ZXIgJiBhbGwsDQoNCldvdWxkIGl0IGJlIG5lZWRlZCB0byBjbGFyaWZ5IHRoZSAo YmluYXJ5KSB0cmFuc2ZlciBlbmNvZGluZyBtb3JlPyBSRkMgNTc1MSBzdGF0ZXMgIklmIG5vIENv bnRlbnQtVHJhbnNmZXItRW5jb2RpbmcgaGVhZGVyIGZpZWxkIGlzIHByZXNlbnQsIHRoZSB0cmFu c2ZlciBlbmNvZGluZyBpcyBwcmVzdW1lZCB0byBiZSA3QklUIi4NCkZvciB0aGUgRVNUIG92ZXIg Q29BUCBjYXNlIGFuZCBlbWJlZGRlZCBjYXNlIGluIGdlbmVyYWwsIEkgd291bGQgYXNzdW1lIHRo YXQgbm9kZXMgY2FuIGFzc3VtZSBieSBkZWZhdWx0IDgtYml0IGVuY29kaW5nIGlzIHVzZWQgYW5k IGFjY2VwdGVkLg0KQWxsIHBhcnRpZXMgaW52b2x2ZWQgaW4gdGhlIGV4Y2hhbmdlIHdvdWxkIGtu b3cgaG93IHRvIGhhbmRsZSA4LWJpdCBkYXRhIGFuZCB0aGVyZSdzIG5vIG5lZWQgdG8gYXNzdW1l IGl0IHdpbGwgb25seSBiZSA3LWJpdC4gIFNvIEkgd291bGQgZXhwZWN0IG9uZSBtb3JlIENvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc9WCBhdHRyaWJ1dGUgaXMgbmVlZGVkIGZvciB0aGUgcGtjczct bWltZSB0eXBlcz8gV2l0aCB0aGUgcmlnaHQgdmFsdWUgb2YgWCAoZGlkbid0IGxvb2sgdGhpcyB1 cCB5ZXQpLg0KDQpCZXN0IHJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGNvcmUtcGFyYW1ldGVycyA8Y29yZS1wYXJhbWV0ZXJzLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBwZXRlciB2YW4gZGVyIFN0b2sNClNlbnQ6IEZyaWRheSwgTWF5IDI1 LCAyMDE4IDExOjQ0DQpUbzogS2xhdXMgSGFydGtlIDxoYXJ0a2VAcHJvamVjdGNvb2wuZGU+DQpD YzogZHJhZnQtaWV0Zi1hY2UtY29hcC1lc3RAaWV0Zi5vcmc7IEhhbm5lcyBUc2Nob2ZlbmlnIDxo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PjsgY29yZS1wYXJhbWV0ZXJzQGlldGYub3JnOyBjb25z dWx0YW5jeUB2YW5kZXJzdG9rLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlLXBhcmFtZXRlcnNdIENv cmUgY29udGVudC1mb3JtYXQgbnVtYmVyIGFsbG9jYXRpb24NCg0KSGkgS2xhdXMsDQoNCnRoZSB1 cGRhdGVkIHRhYmxlLiBzb21lIHJlYWN0aW9ucyB0byB5b3VyIHZlcnkgdXNlZnVsIHJlbWFya3Mg ZnVydGhlciBiZWxvdy4gbWFueSB0aGFua3MsDQoNCmdyZWV0aW5ncywNCg0KUGV0ZXINCg0KDQot IGFwcGxpY2F0aW9uL3BrY3M3LW1pbWU7IHNtaW1lLXR5cGU94oCcc2VydmVyLWdlbmVyYXRlZC1r ZXkiOyBFbmNvZGluZyA9ImlkZW50aXR5IjsgSUQgPSBUQkQxOyBSZWZlcmVuY2UgPSBSRkM1NzUx LCBSRkM3MDMwLCBSRkM3MjMxDQotIGFwcGxpY2F0aW9uL3BrY3M3LW1pbWU7IHNtaW1lLXR5cGU9 4oCcY2VydHMtb25seeKAnTsgRW5jb2RpbmcgPSAiaWRlbnRpdHkiOyBJRCA9IFRCRDI7IFJlZmVy ZW5jZSA9IFJGQzU3NTEsIFJGQzcyMzENCi0gYXBwbGljYXRpb24vcGtjczctbWltZTsgc21pbWUt dHlwZT3igJxDTUMtcmVxdWVzdOKAnTsgRW5jb2RpbmcgPSAiaWRlbnRpdHkiOyBJRCA9IFRCRDM7 IFJlZmVyZW5jZSA9IFJGQzU3NTEsIFJGQzUyNzMsIFJGQzcyMzENCi0gYXBwbGljYXRpb24vcGtj czctbWltZTsgc21pbWUtdHlwZT3igJxDTUMtcmVzcG9uc2XigJ07IEVuY29kaW5nID0gImlkZW50 aXR5IjsgSUQgPSBUQkQ0OyBSZWZlcmVuY2UgPSBSRkM1NzUxLCBSRkM1MjczLCBSRkM3MjMxDQot IGFwcGxpY2F0aW9uL3BrY3M4OyBFbmNvZGluZyA9ICJpZGVudGl0eSI7IElEID0gVEJENTsgUmVm ZXJlbmNlID0gUkZDNTk1OCwgUkZDNzIzMQ0KLSBhcHBsaWNhdGlvbi9jc3JhdHRyczsgRW5jb2Rp bmcgPSAiaWRlbnRpdHkiOyBJRCA9IFRCRDY7IFJlZmVyZW5jZSA9IFJGQzcwMzAsIFJGQzcyMzEN Ci0gYXBwbGljYXRpb24vcGtjczEwOyBFbmNvZGluZyA9ICJpZGVudGl0eSI7IElEID0gVEJENzsg UmVmZXJlbmNlID0gUkZDNTk2NywgUkZDNzIzMQ0KDQpLbGF1cyBIYXJ0a2Ugc2NocmVlZiBvcCAy MDE4LTA1LTI1IDExOjIyOg0KPiBXaGF0IGFib3V0IOKAnENNQy1SZXNwb25zZeKAnT8NCg0KdGhh bmtzLCBJIG1pc3NlZCB0aGF0IG9uZS4NCg0KPiANCj4gVGhlcmXigJlzIGEgcmVnaXN0cnkgZm9y IOKAnHNtaW1lLXR5cGXigJ0gdmFsdWVzIGF0IA0KPiBodHRwczovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9tZWRpYS10eXBlLXN1Yi1wYXJhbWV0ZXJzL21lZGlhLXR5cGUtDQo+IHN1Yi1wYXJh bWV0ZXJzLnhodG1sI3NtaW1lIFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gc2ltcGx5IGFsbG9jYXRl IGEgDQo+IENvbnRlbnQtRm9ybWF0IElEIHRvIGVhY2ggb2YgdGhlbT8NCkkgcHJlZmVyIHRvIG9u bHkgc3BlY2lmeSB0aG9zZSB1c2VkIGluIFJGQzcwMzANCj4gDQo+IFRoZSBtZWRpYSB0eXBlIGFu ZCB0aGUgY29udGVudCBjb2RpbmcgYXJlIG9ydGhvZ29uYWwuIEhvd2V2ZXIsIA0KPiDigJxiaW5h cnnigJ0gaXMgbm90IGEgdmFsaWQgY29udGVudCBjb2RpbmcuIChJdOKAmXMgcmVhbGx5IGNvbmZ1 c2luZyB0aGF0IA0KPiB0aGUgY29sdW1uIGlzIGxhYmVsZWQg4oCcRW5jb2RpbmfigJ07IGNvbnRl bnQgY29kaW5nIGlzIHdoYXQgaXMNCj4gbWVhbnQuKSBQb3NzaWJsZSBjb250ZW50IGNvZGluZ3Mg YXJlIGxpc3RlZCBpbiANCj4gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaHR0cC1w YXJhbWV0ZXJzL2h0dHAtcGFyYW1ldGVycy54aHRtbA0KPiAjY29udGVudC1jb2RpbmcgWW91IHBy b2JhYmx5IHdhbnQgdGhlIOKAnGlkZW50aXR54oCcIGNvbnRlbnQgY29kaW5nLg0KDQpZb3UgYXJl IHJpZ2h0LiBsb29rcyBtb3N0IHByb2JhYmxlIG9uZS4NCj4gDQo+IOKAnGFwcGxpY2F0aW9uL3Br Y3M44oCdIGFuZCB0aGUgb3RoZXIgdHdvIG1lZGlhIHR5cGVzIGRvbuKAmXQgaGF2ZSB0aGUgDQo+ IOKAnHNtaW1lLXR5cGXigJ0gcGFyYW1ldGVyIGRlZmluZWQsIHNvIGp1c3QgcmVtb3ZlIHRoYXQg Yml0Lg0KPiANCj4gT3RoZXJ3aXNlIHRoZSB0YWJsZSBsb29rcyBnb29kIHRvIG1lLg0KPiANCj4g S2xhdXMNCj4gDQo+IE9uIEZyaSAyNS4gTWF5IDIwMTggYXQgMTA6NTgsIHBldGVyIHZhbiBkZXIg U3RvayA8c3Rva2NvbnNAeHM0YWxsLm5sPg0KPiB3cm90ZToNCj4gDQo+PiBISSBLbGF1cywNCj4+ IA0KPj4gVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVhY3Rpb24sIGFuZCB0aGFua3MgZm9yIHBvaW50 aW5nIG91dCBzb21lIA0KPj4gZXhpc3Rpbmcgb3RoZXIgc21pbWUgdHlwZXMuDQo+PiBJIGRpZCBh IHNlYXJjaCBpbiBSRkMgNzAzMCwgYW5kIGNhbWUgdXAgd2l0aCBvdGhlciBuZWNlc3Nhcnkgc21p bWUgDQo+PiB0eXBlcy4NCj4+IA0KPj4gQmVsb3cgdGhlIHRhYmxlIGFzIHJlcXVpcmVkIGZvciBl c3QtY29hcCBkcmFmdDogKEkgd2lsbCBjaGFuZ2UgdGhlIA0KPj4gZHJhZnQNCj4+IGFjY29yZGlu Z2x5KQ0KPj4gDQo+PiAtIGFwcGxpY2F0aW9uL3BrY3M3LW1pbWU7IHNtaW1lLXR5cGU94oCcc2Vy dmVyLWdlbmVyYXRlZC1rZXnigJ07DQo+PiBFbmNvZGluZyA9DQo+PiAiYmluYXJ5IjsgSUQgPSBU QkQxOyBSZWZlcmVuY2UgPSBSRkM1NzUxLCBSRkM3MDMwDQo+PiAtIGFwcGxpY2F0aW9uL3BrY3M3 LW1pbWU7IHNtaW1lLXR5cGU94oCcY2VydHMtb25seeKAnTsgRW5jb2RpbmcgPSANCj4+ICJiaW5h cnkiOyBJRCA9IFRCRDI7IFJlZmVyZW5jZSA9IFJGQzU3NTENCj4+IC0gYXBwbGljYXRpb24vcGtj czctbWltZTsgc21pbWUtdHlwZT3igJxDTUMtcmVxdWVzdOKAnTsgRW5jb2RpbmcgPSANCj4+ICJi aW5hcnkiOyBJRCA9IFRCRDM7IFJlZmVyZW5jZSA9IFJGQzU3NTEsIFJGQzUyNzMNCj4+IC0gYXBw bGljYXRpb24vcGtjczg7IHNtaW1lLXR5cGUgPSAtLS07IEVuY29kaW5nID0gImJpbmFyeSI7IElE ID0gDQo+PiBUQkQ0OyBSZWZlcmVuY2UgPSBSRkM1OTU4DQo+PiAtIGFwcGxpY2F0aW9uL2NzcmF0 dHJzOyBzbWltZS10eXBlID0gLS0tOyBFbmNvZGluZyA9ICJiaW5hcnkiOyBJRCA9IA0KPj4gVEJE NTsgUmVmZXJlbmNlID0gUkZDNzAzMA0KPj4gLSBhcHBsaWNhdGlvbi9wa2NzMTA7IHNtaW1lLXR5 cGUgPSAtLS07IEVuY29kaW5nID0gImJpbmFyeSI7IElEID0gDQo+PiBUQkQ2OyBSZWZlcmVuY2Ug PSBSRkM1OTY3DQo+PiANCj4+IEkgZXhwZWN0IHRoZSBFbmNvZGluZyBpcyBvcnRob2dvbmFsIHRv IHRoZSBtZWRpYSB0eXBlIGFuZCBzbWltZSB0eXBlDQo+PiANCj4+IHNwZWNpZmljYXRpb24uDQo+ PiANCj4+IE1hbnkgdGhhbmtzLA0KPj4gDQo+PiBwZXRlcg0KPj4gDQo+PiBLbGF1cyBIYXJ0a2Ug c2NocmVlZiBvcCAyMDE4LTA1LTI1IDA5OjQ4Og0KPj4+IEhpIFBldGVyLA0KPj4+IA0KPj4+IEkg c2VlIHlvdeKAmXJlIHJlcXVlc3RpbmcgQ29udGVudC1Gb3JtYXQgSURzIGZvciB0aGUgZm9sbG93 aW5nIA0KPj4+IGV4aXN0aW5nIG1lZGlhIHR5cGVzOg0KPj4+IA0KPj4+IC0gYXBwbGljYXRpb24v cGtjczctbWltZQ0KPj4+IC0gYXBwbGljYXRpb24vcGtjczgNCj4+PiAtIGFwcGxpY2F0aW9uL2Nz cmF0dHJzDQo+Pj4gLSBhcHBsaWNhdGlvbi9wa2NzMTANCj4+PiANCj4+PiBBIENvbnRlbnQtRm9y bWF0IGlzIHRoZSBjb21iaW5hdGlvbiBvZiBhIG1lZGlhIHR5cGUgYW5kIGEgY29udGVudCANCj4+ PiBjb2RpbmcuIFBsZWFzZSBzcGVjaWZ5IHRoZSBjb250ZW50IGNvZGluZyhzKSB5b3Ugd2FudCB0 byB1c2Ugd2l0aA0KPj4gZWFjaA0KPj4+IG1lZGlhIHR5cGUuIFRoZSBwb3NzaWJsZSBzZXQgb2Yg Y29udGVudCBjb2RpbmdzIGNhbiBiZSBmb3VuZCBhdA0KPj4+IA0KPj4gDQo+IGh0dHBzOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2h0dHAtcGFyYW1ldGVycy9odHRwLXBhcmFtZXRlcnMueGh0 bWwNCj4gI2NvbnRlbnQtY29kaW5nDQo+Pj4gDQo+Pj4gUGxlYXNlIGZvcm1hdCB5b3VyIHJlcXVl c3QgYXMgYSB0YWJsZSB0aGF0IGxvb2tzIGxpa2UgVGFibGUgOSBpbg0KPj4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tMTIuMyAob25lIHJvdyBmb3IgZWFjaCAN Cj4+PiBjb21iaW5hdGlvbiBvZiBhIG1lZGlhIHR5cGUgYW5kIGEgY29udGVudCBjb2RpbmcpDQo+ Pj4gDQo+Pj4gSXQgc2VlbXMg4oCcYXBwbGljYXRpb24vcGtjczctbWltZeKAnCBhY3R1YWxseSBk b2VzIGRlZmluZSBhIG1lZGlhIHR5cGUgDQo+Pj4gcGFyYW1ldGVyLCDigJxzbWltZS10eXBlIOKA nS4gUkZDIDU3NTEgc2F5czoNCj4+PiANCj4+PiBCZWNhdXNlIHRoZXJlIGFyZSBzZXZlcmFsIHR5 cGVzIG9mIGFwcGxpY2F0aW9uL3BrY3M3LW1pbWUNCj4+IG9iamVjdHMsDQo+Pj4gYQ0KPj4+IHNl bmRpbmcgYWdlbnQgU0hPVUxEIGRvIGFzIG11Y2ggYXMgcG9zc2libGUgdG8gaGVscCBhIHJlY2Vp dmluZyANCj4+PiBhZ2VudCBrbm93IGFib3V0IHRoZSBjb250ZW50cyBvZiB0aGUgb2JqZWN0IHdp dGhvdXQgZm9yY2luZyB0aGUNCj4+IHJlY2VpdmluZw0KPj4+IGFnZW50IHRvIGRlY29kZSB0aGUg QVNOLjEgZm9yIHRoZSBvYmplY3QuICBUaGUgQ29udGVudC1UeXBlDQo+PiBoZWFkZXINCj4+PiBm aWVsZCBvZiBhbGwgYXBwbGljYXRpb24vcGtjczctbWltZSBvYmplY3RzIFNIT1VMRCBpbmNsdWRl IHRoZSANCj4+PiBvcHRpb25hbCAic21pbWUtdHlwZSIgcGFyYW1ldGVyLCBhcyBkZXNjcmliZWQg aW4gdGhlIGZvbGxvd2luZyANCj4+PiBzZWN0aW9ucy4NCj4+PiANCj4+PiBTbyBpdCBzZWVtcyB0 aGUgcGFyYW1ldGVyIGlzIG1vcmUgb3IgbGVzcyByZXF1aXJlZC4gRG8geW91IHdhbnQgdG8gDQo+ Pj4gcmVnaXN0ZXIgYSBDb250ZW50LUZvcm1hdCBJRCBmb3IgZWFjaCBkZWZpbmVkIHNtaW1lLXR5 cGUgdmFsdWU/DQo+PiBUaGVuDQo+Pj4gdGhlIGxpc3Qgb2YgbWVkaWEgdHlwZXMgKHRoYXQgbmVl ZCB0byBiZSBwYWlyZWQgd2l0aCBhIGNvbnRlbnQNCj4+IGNvZGluZykNCj4+PiBsb29rcyBsaWtl IHRoaXM6DQo+Pj4gDQo+Pj4gLSBhcHBsaWNhdGlvbi9wa2NzNy1taW1lOyBzbWltZS10eXBlPeKA nGVudmVsb3BlZC1kYXRh4oCdDQo+Pj4gLSBhcHBsaWNhdGlvbi9wa2NzNy1taW1lOyBzbWltZS10 eXBlPeKAnHNpZ25lZC1kYXRh4oCdDQo+Pj4gLSBhcHBsaWNhdGlvbi9wa2NzNy1taW1lOyBzbWlt ZS10eXBlPeKAnGNlcnRzLW9ubHnigJ0NCj4+PiAtIGFwcGxpY2F0aW9uL3BrY3M3LW1pbWU7IHNt aW1lLXR5cGU94oCcY29tcHJlc3NlZC1kYXRh4oCdDQo+Pj4gLSBhcHBsaWNhdGlvbi9wa2NzOA0K Pj4+IC0gYXBwbGljYXRpb24vY3NyYXR0cnMNCj4+PiAtIGFwcGxpY2F0aW9uL3BrY3MxMA0KPj4+ IA0KPj4+IEtsYXVzDQo+Pj4gDQo+Pj4gT24gRnJpIDI1LiBNYXkgMjAxOCBhdCAwOToyNywgcGV0 ZXIgdmFuIGRlciBTdG9rDQo+PiA8c3Rva2NvbnNAeHM0YWxsLm5sPg0KPj4+IHdyb3RlOg0KPj4+ IA0KPj4+PiBEZWFyIGNvcmUgcGFyYW1ldGVyIGV4cGVydHMsDQo+Pj4+IA0KPj4+PiBJbiBkcmFm dC1pZXRmLWFjZS1jb2FwLWVzdCB3ZSB3YW50IHRvIGFsbG9jYXRlIGNvbnRlbnQgZm9ybWF0IA0K Pj4+PiBudW1iZXJzIHRvDQo+Pj4+IDQgYWxyZWFkeSBleGlzdGluZyBtZWRpYSBmb3JtYXRzLg0K Pj4+PiBMV00yTSBwZW9wbGUgYXJlIGltcGxlbWVudGluZyB0aGUgZXN0LWNvYXBzIHNwZWNpZmlj YXRpb24gYW5kDQo+PiB3YW50DQo+Pj4+IHRvDQo+Pj4+IGRlcGxveSBpdCBhcyBxdWlja2x5IGFz IHBvc3NpYmxlLg0KPj4+PiBUaGVyZWZvcmUsIHRoZXkgbmVlZCB0byBrbm93IHRoZSBhbGxvY2F0 ZWQgbnVtYmVycyB0byB3cml0ZSBpbnRvIA0KPj4+PiB0aGVpciBjb2RlLg0KPj4+PiBBbiBlYXJs eSBhbGxvY2F0aW9uIGJlZm9yZSBwdWJsaWNhdGlvbiBvZiB0aGUgZHJhZnQgYXMgUkZDIHdpbGwN Cj4+IGJlDQo+Pj4+IGFwcHJlY2lhdGVkLg0KPj4+PiANCj4+Pj4gQmVsb3cgdGhlIElBTkEgdGV4 dCBmcm9tIHRoZSBkcmFmdCwgdXNpbmcgVEJEMSAtIFRCRDQgYXMNCj4+IGFsbG9jYXRlZA0KPj4+ PiBudW1iZXJzLg0KPj4+PiANCj4+Pj4gTWFueSB0aGFua3MsDQo+Pj4+IA0KPj4+PiBwZXRlcg0K Pj4+PiANCj4+Pj4gDQo+Pj4gDQo+PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gDQo+Pj4+IDguMS4gIENvbnRlbnQtRm9ybWF0 IHJlZ2lzdHJ5DQo+Pj4+IA0KPj4+PiBBZGRpdGlvbnMgdG8gdGhlIHN1Yi1yZWdpc3RyeSAiQ29B UCBDb250ZW50LUZvcm1hdHMiLCB3aXRoaW4gdGhlIA0KPj4+PiAiQ29SRSBQYXJhbWV0ZXJzIiBy ZWdpc3RyeSBhcmUgbmVlZGVkIGZvciB0aGUgYmVsb3cgbWVkaWEgdHlwZXMuDQo+Pj4+IFRoZXNl IGNhbiBiZSByZWdpc3RlcmVkIGVpdGhlciBpbiB0aGUgRXhwZXJ0IFJldmlldyByYW5nZQ0KPj4+ PiAoMC0yNTUpIG9yDQo+Pj4+IElFVEYgUmV2aWV3IHJhbmdlICgyNTYtOTk5OSkuDQo+Pj4+IA0K Pj4+PiAxLg0KPj4+PiANCj4+Pj4gKiAgYXBwbGljYXRpb24vcGtjczctbWltZQ0KPj4+PiAqICBU eXBlIG5hbWU6IGFwcGxpY2F0aW9uDQo+Pj4+ICogIFN1YnR5cGUgbmFtZTogcGtjczctbWltZQ0K Pj4+PiAqICBJRDogVEJEMQ0KPj4+PiAqICBSZXF1aXJlZCBwYXJhbWV0ZXJzOiBOb25lDQo+Pj4+ ICogIE9wdGlvbmFsIHBhcmFtZXRlcnM6IE5vbmUNCj4+Pj4gKiAgRW5jb2RpbmcgY29uc2lkZXJh dGlvbnM6IGJpbmFyeQ0KPj4+PiAqICBTZWN1cml0eSBjb25zaWRlcmF0aW9uczogQXMgZGVmaW5l ZCBpbiB0aGlzIHNwZWNpZmljYXRpb24NCj4+Pj4gKiAgUHVibGlzaGVkIHNwZWNpZmljYXRpb246 IFtSRkM1NzUxXQ0KPj4+PiAqICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBtZWRpYSB0eXBl OiBFU1QNCj4+Pj4gDQo+Pj4+IDIuDQo+Pj4+IA0KPj4+PiAqICBhcHBsaWNhdGlvbi9wa2NzOA0K Pj4+PiAqICBUeXBlIG5hbWU6IGFwcGxpY2F0aW9uDQo+Pj4+ICogIFN1YnR5cGUgbmFtZTogcGtj czgNCj4+Pj4gKiAgSUQ6IFRCRDINCj4+Pj4gKiAgUmVxdWlyZWQgcGFyYW1ldGVyczogTm9uZQ0K Pj4+PiAqICBPcHRpb25hbCBwYXJhbWV0ZXJzOiBOb25lDQo+Pj4+ICogIEVuY29kaW5nIGNvbnNp ZGVyYXRpb25zOiBiaW5hcnkNCj4+Pj4gKiAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6IEFzIGRl ZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uDQo+Pj4+ICogIFB1Ymxpc2hlZCBzcGVjaWZpY2F0 aW9uOiBbUkZDNTk1OF0NCj4+Pj4gKiAgQXBwbGljYXRpb25zIHRoYXQgdXNlIHRoaXMgbWVkaWEg dHlwZTogRVNUDQo+Pj4+IA0KPj4+PiAzLg0KPj4+PiANCj4+Pj4gKiAgYXBwbGljYXRpb24vY3Ny YXR0cnMNCj4+Pj4gKiAgVHlwZSBuYW1lOiBhcHBsaWNhdGlvbg0KPj4+PiAqICBTdWJ0eXBlIG5h bWU6IGNzcmF0dHJzDQo+Pj4+ICogIElEOiBUQkQzDQo+Pj4+ICogIFJlcXVpcmVkIHBhcmFtZXRl cnM6IE5vbmUNCj4+Pj4gKiAgT3B0aW9uYWwgcGFyYW1ldGVyczogTm9uZQ0KPj4+PiAqICBFbmNv ZGluZyBjb25zaWRlcmF0aW9uczogYmluYXJ5DQo+Pj4+ICogIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zOiBBcyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbg0KPj4+PiAqICBQdWJsaXNoZWQg c3BlY2lmaWNhdGlvbjogW1JGQzcwMzBdDQo+Pj4+ICogIEFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0 aGlzIG1lZGlhIHR5cGU6IEVTVA0KPj4+PiANCj4+Pj4gNC4NCj4+Pj4gDQo+Pj4+ICogIGFwcGxp Y2F0aW9uL3BrY3MxMA0KPj4+PiAqICBUeXBlIG5hbWU6IGFwcGxpY2F0aW9uDQo+Pj4+ICogIFN1 YnR5cGUgbmFtZTogcGtjczEwDQo+Pj4+ICogIElEOiBUQkQ0DQo+Pj4+ICogIFJlcXVpcmVkIHBh cmFtZXRlcnM6IE5vbmUNCj4+Pj4gKiAgT3B0aW9uYWwgcGFyYW1ldGVyczogTm9uZQ0KPj4+PiAq ICBFbmNvZGluZyBjb25zaWRlcmF0aW9uczogYmluYXINCj4+Pj4gKiAgU2VjdXJpdHkgY29uc2lk ZXJhdGlvbnM6IEFzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uDQo+Pj4+ICogIFB1Ymxp c2hlZCBzcGVjaWZpY2F0aW9uOiBbUkZDNTk2N10NCj4+Pj4gKiAgQXBwbGljYXRpb25zIHRoYXQg dXNlIHRoaXMgbWVkaWEgdHlwZTogRVNUDQo+Pj4+IA0KPj4+PiANCj4+PiANCj4+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IF9fX19fX19fX19fX19fX19fX19fXw0KPj4+PiANCj4+Pj4gLS0NCj4+Pj4g UGV0ZXIgdmFuIGRlciBTdG9rDQo+Pj4+IHZhbmRlcnN0b2sgY29uc3VsdGFuY3kNCj4+Pj4gbWFp bHRvOiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZw0KPj4+PiB3d3c6IHd3dy52YW5kZXJzdG9r Lm9yZyBbMV0gWzFdDQo+Pj4+IHRlbCBOTDogKzMxKDApNDkyNDc0NjczICAgICBGOiArMzMoMCk5 NjYwMTUyNDgNCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IGNvcmUtcGFyYW1ldGVycyBtYWlsaW5nIGxpc3QNCj4+Pj4gY29y ZS1wYXJhbWV0ZXJzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZS1wYXJhbWV0ZXJzDQo+Pj4gDQo+Pj4gDQo+Pj4gTGlua3M6DQo+Pj4gLS0t LS0tDQo+Pj4gWzFdIGh0dHA6Ly93d3cudmFuZGVyc3Rvay5vcmcNCj4gDQo+IA0KPiBMaW5rczoN Cj4gLS0tLS0tDQo+IFsxXSBodHRwOi8vd3d3LnZhbmRlcnN0b2sub3JnDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlLXBhcmFtZXRlcnMgbWFp bGluZyBsaXN0DQpjb3JlLXBhcmFtZXRlcnNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY29yZS1wYXJhbWV0ZXJzDQo=