Re: [core-parameters] Core content-format number allocation

Esko Dijk <esko.dijk@signify.com> Fri, 25 May 2018 13:12 UTC

Return-Path: <esko.dijk@signify.com>
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 <esko.dijk@signify.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Klaus Hartke <hartke@projectcool.de>
CC: "draft-ietf-ace-coap-est@ietf.org" <draft-ietf-ace-coap-est@ietf.org>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "core-parameters@ietf.org" <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: <VI1P121MB0014E82187F26AFF68460B78E0690@VI1P121MB0014.EURP121.PROD.OUTLOOK.COM>
References: <636715d9568fb16b0dc779773fc99f89@xs4all.nl> <CAAzbHvZ4CGgG6L5ZkaBF_JPN7d=o=XuWCETLF8-k7BP7KtYb=A@mail.gmail.com> <24ec93bb245164263df36d81aaf10c43@xs4all.nl> <CAAzbHvZuaFNPf0KNG4UpDzd_fmHC1OZbegvKu7NpEsdax9NUMg@mail.gmail.com> <daeee2305e8c503bf02b03632c60813f@xs4all.nl>
In-Reply-To: <daeee2305e8c503bf02b03632c60813f@xs4all.nl>
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: <VI1P121MB003233AFAA1A5E31389328D7E0690@VI1P121MB0032.EURP121.PROD.OUTLOOK.COM>
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: <https://mailarchive.ietf.org/arch/msg/core-parameters/DOii6f8jHoueP5afNptVTGU1HTw>
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." <core-parameters.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core-parameters/>
List-Post: <mailto:core-parameters@ietf.org>
List-Help: <mailto:core-parameters-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 May 2018 18:08:22 -0000

Hello Peter & all,

Would it be needed to clarify the (binary) transfer encoding more? RFC 5751 states "If no Content-Transfer-Encoding header field is present, the transfer encoding is presumed to be 7BIT".
For the EST over CoAP case and embedded case in general, I would assume that nodes can assume by default 8-bit encoding is used and accepted.
All parties involved in the exchange would know how to handle 8-bit data and there's no need to assume it will only be 7-bit.  So I would expect one more Content-Transfer-Encoding=X attribute is needed for the pkcs7-mime types? With the right value of X (didn't look this up yet).

Best regards
Esko

-----Original Message-----
From: core-parameters <core-parameters-bounces@ietf.org> On Behalf Of peter van der Stok
Sent: Friday, May 25, 2018 11:44
To: Klaus Hartke <hartke@projectcool.de>
Cc: draft-ietf-ace-coap-est@ietf.org; Hannes Tschofenig <hannes.tschofenig@gmx.net>et>; core-parameters@ietf.org; consultancy@vanderstok.org
Subject: Re: [core-parameters] Core content-format number allocation

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 <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=“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
>> <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.  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

_______________________________________________
core-parameters mailing list
core-parameters@ietf.org
https://www.ietf.org/mailman/listinfo/core-parameters