Re: [core] [Ext] Re: Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT)
Michelle Cotton <michelle.cotton@iana.org> Wed, 29 September 2021 17:49 UTC
Return-Path: <michelle.cotton@iana.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490803A083D; Wed, 29 Sep 2021 10:49:32 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNOaOFCeq8B9; Wed, 29 Sep 2021 10:49:23 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 4B3263A083C; Wed, 29 Sep 2021 10:49:23 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 18THnFnG027517 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Sep 2021 17:49:15 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.13; Wed, 29 Sep 2021 10:49:14 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0922.013; Wed, 29 Sep 2021 10:49:14 -0700
From: Michelle Cotton <michelle.cotton@iana.org>
To: Carsten Bormann <cabo@tzi.org>, Robert Wilton <rwilton@cisco.com>
CC: Jaime Jimenez <jaime@iki.fi>, "draft-ietf-core-senml-data-ct@ietf.org" <draft-ietf-core-senml-data-ct@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, The IESG <iesg@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: [Ext] Re: Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT)
Thread-Index: AQHXtP7KoPb7NqkDpEuMqt7NaQU3q6u7SqOA
Date: Wed, 29 Sep 2021 17:49:14 +0000
Message-ID: <348C1C8F-45F2-421F-B8AF-A473D06D5316@iana.org>
References: <163221352718.31036.11922703653380735485@ietfa.amsl.com> <3AF5E977-6DF0-450B-969B-34D518AC26E3@tzi.org>
In-Reply-To: <3AF5E977-6DF0-450B-969B-34D518AC26E3@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.52.21080801
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3715757353_402579561"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-29_07:2021-09-29, 2021-09-29 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9vAQb9dDjifvoHLeuA52jOHkfDQ>
Subject: Re: [core] [Ext] Re: Robert Wilton's No Objection on draft-ietf-core-senml-data-ct-05: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2021 17:49:33 -0000
Hello Carsten, Just double checking regarding this comment below: Indeed, we actually have an outstanding project to automatically register a Content-Format number for every one of the couple-thousand media-type registration out there (this is mostly stalled on practical issues around how to ensure this is then done for new registrations as well). Does this mean IANA "automatically" registering something? Can you please clarify about this project? Thank you, Michelle ************ Michelle Cotton Protocol Parameters Engagement Sr. Manager IANA Services On 9/28/21, 11:54 PM, "iesg on behalf of Carsten Bormann" <iesg-bounces@ietf.org on behalf of cabo@tzi.org> wrote: Hi Rob, thank you for pointing out this concern. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this document. > > I have to confess that I am less convinced of the need to have two ways to > represent this information, i.e., to also support Content-Format-Strings as > opposed to always requiring a entry in the CoAP Content-Formats registry. The > CoAP Content-Formats registry seems to be of reasonable size and have a lot of > space available for FCFS allocations which would mean that it should be quite > easy to extend if required. However, I'm willing to defer to the authors & > CORE WG expertise here supporting both ways are needed/useful. Indeed, we actually have an outstanding project to automatically register a Content-Format number for every one of the couple-thousand media-type registration out there (this is mostly stalled on practical issues around how to ensure this is then done for new registrations as well). However, a Content-Type is not just a media-type name, but also potentially parameters, and content-codings. Some media-types have a few parameters that can only take a few values, so it would be possible to register content-format numbers for each combination. text/plain; charset=utf-8 (Content-Format number 0) is the first example where this is breaking down a bit: We clearly do not want to register the cross-product of media-type names that happen to have charset parameters with the registered charset names, in particular as UTF-8 is the only reasonable value for an interchange format like SenML that targets long-lived applications. It then gets ugly quickly with actually variable parameters such as sampling rate, source coding parameters etc. The cross-product consideration also applies to content-coding — more so as new content-codings (beyond the widely used, but ageing, deflate) are becoming more widely used. It is also quite likely that a SenML processor wants to add a content-coding that has not been on the original sensor data. So we think there is no way to ensure that content-format numbers are available for all records in a SenML pack, and we need the flexibility to fall back to a content-format-spec. Grüße, Carsten
- [core] Robert Wilton's No Objection on draft-ietf… Robert Wilton via Datatracker
- Re: [core] Robert Wilton's No Objection on draft-… Carsten Bormann
- Re: [core] [Ext] Re: Robert Wilton's No Objection… Michelle Cotton