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

Klaus Hartke <hartke@projectcool.de> Fri, 25 May 2018 10:00 UTC

Return-Path: <hartke@projectcool.de>
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> <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>
From: Klaus Hartke <hartke@projectcool.de>
Date: Fri, 25 May 2018 12:00:29 +0200
X-Gmail-Original-Message-ID: <CAAzbHvbWy=d1tjiaepvyHrZn3vm6PHDLQdop-=WufdpZfRS6fQ@mail.gmail.com>
Message-ID: <CAAzbHvbWy=d1tjiaepvyHrZn3vm6PHDLQdop-=WufdpZfRS6fQ@mail.gmail.com>
To: consultancy@vanderstok.org
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, 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: <https://mailarchive.ietf.org/arch/msg/core-parameters/6QxdEfWn5mWbKBkWlA6qRijLHqc>
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 10:00:48 -0000

Thumbs up đź‘Ť



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