Re: [core] Review of draft-ietf-core-multipart-ct-02

"Fossati, Thomas (Nokia - GB/Cambridge)" <> Tue, 30 October 2018 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8D16130E23 for <>; Tue, 30 Oct 2018 10:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.885
X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vfmaXp87deZC for <>; Tue, 30 Oct 2018 10:42:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54CB1130DD2 for <>; Tue, 30 Oct 2018 10:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qWZ/vRDr9J36s4C9++gHhv+A/Cb/Gx/orEgS8rcNlQI=; b=ONa9G7gsCJpYjImsoQahNXXutq+kFlwiy0lZvey95zNlVOt0zxv4bwf3VAcK+cuoFLqxjRpG3tCXdhVv77vtPAyzH+gVXFVlBlQfZdrsKVvITR+koD5GmeBsCG53+7XdsH/Z6o3/kUROO1Eww9kW/mwj8QbI9uZXUoxRJxivJhA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.16; Tue, 30 Oct 2018 17:42:55 +0000
Received: from ([fe80::f95b:cf9a:b466:21d3]) by ([fe80::f95b:cf9a:b466:21d3%3]) with mapi id 15.20.1294.018; Tue, 30 Oct 2018 17:42:55 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge)" <>
To: "" <>, "" <>
Thread-Topic: [core] Review of draft-ietf-core-multipart-ct-02
Thread-Index: AQHUcHf46zhgh8nfgU+ep4XF1bdRjw==
Date: Tue, 30 Oct 2018 17:42:55 +0000
Message-ID: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
user-agent: Mutt/1.10.1 (2018-07-13)
x-clientproxiedby: LO2P265CA0258.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::30) To (2603:10a6:20b:5e::11)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM6PR07MB5158; 6:XUxoAE84wA1oDTBlpo8iDpNbLqiEPRw4wa1KJoXwKDNbybkirwzbIUA1KXcA+uBkJQGVeSsL+LDN4+OqwPrqkcm5SEE0nhqsRWn9iSwE/rUk8I3lsKkqXgJ3YXbPV9CB5yJ+7/N2pVCF3iD/M7czrC4AymHtsmEVhAPnNL+ZwEDuOQS7Uc7ixaRVsxs2fZ6Uj5sEQQV7xl/r8051DnRQJGDPmT7rpQgPx/5JNYg5sZBu28e/j46RLcd7aHAepPg6EEZlUcQv13YyPytm4HE6+KZrVY76/uuFVxZ4Pg4JGOgi4HXCjx2QJPYfD8xj6SShP8VIoS+BlBtRlXLvkgZ75iifYbgdSliJQUgxYLOjrTXPf9RBhgSo8pfq5HYdXIoIWM/WxWaEQaonxZUFvPnMhG8ZY6OOvTTwbTqmcnKQCJYXvEbSjojIjO+RHSo7qcPQhYI6AOxYRHQPCereR9Y1oQ==; 5:u30stQlRpuZkjaSZlnnha+fN4ExQSqIgbBRqre8fSedsR9SK48EWW2r99F15S4MBWlwSp+wPbk46utb51goAziR9SrqEllA56aurrVurfIGN5YariIpgN4kzdTcneNoIQgoIsWN9Zz0gOADzb27lBgraOJR55e7PcIpr/1OKU1Q=; 7:jLzSbTsUHuIi/YiWVbqCkK2f9EyjKlZU151mGfISqt++/SFos3PDNuXj/J/TQRjRco6fU101EgCZzk8IvxbNV8qlTSy4qF1519Gua/AMS7fxnBvoWxKE4V7PjM44PvmnqilqunzpXQc8jvnfxCv02w==
x-ms-office365-filtering-correlation-id: 11531199-71c2-4e8c-c3bc-08d63e8f1f67
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5158;
x-ms-traffictypediagnostic: AM6PR07MB5158:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278428928389397)(17755550239193)(131327999870524)(190756311086443);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(11241501184)(806099)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB5158; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5158;
x-forefront-prvs: 08417837C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(39860400002)(396003)(376002)(189003)(199004)(57704003)(1076002)(52116002)(107886003)(6246003)(6116002)(3846002)(2900100001)(229853002)(33656002)(71190400001)(5660300001)(86362001)(36756003)(6512007)(68736007)(53936002)(5250100002)(14454004)(99286004)(6436002)(6486002)(2501003)(71200400001)(14444005)(66066001)(26005)(97736004)(256004)(6506007)(386003)(486006)(478600001)(105586002)(106356001)(186003)(102836004)(4326008)(7736002)(58126008)(305945005)(110136005)(2616005)(476003)(8936002)(2906002)(81166006)(81156014)(316002)(25786009)(8676002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5158;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: q6l1Y3LzhYdsKnvrIjy9E+BcGCFt2LkguA+7TsLkwSZS7UVI1Uo8Q9RSNf7BDw508bufEvwH6Hui6JBpeb79P1HQqowbaohb3QnjBUvHNe9vQwuSZUFXdPoaEF1Gxu6np3/TjaItPEmJAl0zzLreZwTAc1ztTWuG1FE/Cam7/xFHc0YhhfkPIsqZZ+Uopcmox2rakS+R9GBxgJOqzdOF8G8D6G4zvHV6JIgev9XUGVunQl38MhZIWuU98qFFmyyeUCaalnyTB64TM2oeFzicoU6bcHpCjkQofIaOlUque1ggd21z3uKiExb4BQYj9l9sRWKdntbnS7scj58QRyvpsGhaUbXQkdpkV3KIEGjyJDE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 11531199-71c2-4e8c-c3bc-08d63e8f1f67
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2018 17:42:55.7955 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5158
Archived-At: <>
Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2018 17:43:14 -0000

Hi Klaus,

> 1. " This memo defines application/multipart-core, an
> application-independent media-type" -- General purpose media-type?
> (Why does it have "core" in the name if it's general-purpose?)

It's got "core" because it specifies the use of CoAP content formats for
constructing the aggregate, but that doesn't invalidate the general
purpose-ness, I think.

> 1. "that can be used to combine representations of several different
> media types" -- Does it have to be several media types or is 2 media
> types enough? 1? 0?

s/several/two or more/ ?

> 1. "into a single CoAP message-body with minimal framing overhead,
> each along with a CoAP Content-Format identifier." -- Can it only be
> used in a CoAP message-body?

s/CoAP message-body/message/ ?

> 1.  "Applications using the application/multipart-core Content-Format
> define the internal structure of the application/multipart-core
> representation." -- Isn't the internal structure of the format defined
> by figure 1? Or is this about assigning further meaning to positions
> in the array?

Yes, it's the fact that the exact position of a type inside the array is
part of the structural definition - in fact, the position is the unique
name of the field inside the aggregate type.

> 1. "For example, one way to structure the sub-types specific to an
> application/multipart-core container is to always include them at the
> same fixed position." -- Ah, I see. Join this paragraph with the
> previous one.

Makes sense.

> 1. "This specification allows to indicate that an optional part is not
> present by substituting a null value for the representation of the
> part." -- Do we need this?

How do you suggest we deal with optional values?

> 1. "Optionally, an application might use the general format defined
> here, but also register a new media type and an associated
> Content-Format identifier -- typically one in the range 10000-64999 --
> instead of using application/multipart-core." -- What's an example
> where an application would do this? I can't imagine any where I'd
> recommend this.

I don't see how that could harm (besides, if someone wants to do it, we
cannot prevent it); that said I'm not opposed to removing text that is
not strictly necessary.

> 1. "typically one in the range 10000-64999" -- Better not to state the
> range explicitly as that locks the Content-Formats registry into
> providing this range for this purpose forever.

If we remove the above, this will go together with that.

> 2. -- There should be a sub-section or paragraph specifying what a
> recipient of a application/multipart-core representation should do if
> it encounters something that doesn't match the grammar. Does the whole
> array become unusable when there is an unexpected element, or can a
> recipient use the array up to the unexpected element? Should a
> recipient try to do error recovery and skip to the next element? This
> has impact on how the format can be evolved in the future.

Isn't that application specific?

> 2. "(Future extensions might want to include additional alternative
> ways of specifying the media type of a representation in such a
> position.)" -- This side note feels a bit out of place and isn't
> really helpful. What should a reader of the document do with this
> information?

Yep, I agree this is out of scope and we should remove it.

> 3. -- Is the "Observing Resources" example the prime usage example for
> -multipart-ct? If not, shouldn't there be an example for the prime use
> case?

I don't think there are prime use cases in a "hierarchical" sense.
Anything that fits is good to go :-)

> 3.1. -- I see that draft-ietf-core-coap-pubsub-05 is still proposing a
> new response code (2.07) for this scenario. Will -pubsub switch to
> -multipart-ct as described in this section? If not, better remove the
> example.

This one is for Carsten, but I think the example in 3.1 is not
necessarily pubsub specific, though clearly it applies quite well to

> 3.2 "Implementation hints" -- This doesn't seem like a usage example.
> Promote it to a top-level section.


> 3.2 "In effect, the serialization for a single object is done by
> prefixing the object with information about its content-format (here:
> 0x82 0x00) and its length (here: 0x4b)." -- What about the array
> containing the two elements?

Sorry, I don't understand this.

> 4.1 "Fragment identifier considerations: N/A" -- Change to same as
> 6.1 "[RFC7252]" -- Just to confirm: This is a normative reference
> because of the use of CoAP Content-Format numbers, right?


> 6.1 "[RFC7641]" -- This should be an informative reference, as Observe
> seems to be referenced only in the usage examples section.


Thank you very much!