[core] Review of draft-ietf-core-multipart-ct-02
Klaus Hartke <hartke@projectcool.de> Tue, 30 October 2018 15:50 UTC
Return-Path: <hartke@projectcool.de>
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 2DE25128CFD for <core@ietfa.amsl.com>; Tue, 30 Oct 2018 08:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aX2R9v7UtYez for <core@ietfa.amsl.com>; Tue, 30 Oct 2018 08:50:48 -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 B619012D4EA for <core@ietf.org>; Tue, 30 Oct 2018 08:50:45 -0700 (PDT)
Received: from mail-qt1-f175.google.com ([209.85.160.175]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gHWHz-0003IX-Da; Tue, 30 Oct 2018 16:50:43 +0100
Received: by mail-qt1-f175.google.com with SMTP id i15-v6so14053737qtr.0 for <core@ietf.org>; Tue, 30 Oct 2018 08:50:43 -0700 (PDT)
X-Gm-Message-State: AGRZ1gJohzsjSufp79KzEArE66dlqRwkNNmWLHKRM5COm5X4AbgdRNFz Oo6sRhWnW21nnMoXpG5bdyeN/dOT7LDTQzHVbhY=
X-Google-Smtp-Source: AJdET5dIemU/Bdr/dBFFM6Y8htbykaFt5jQtKK+NIBbB19ixIqSxl+gZBSdsFlEEIXtH85wIEYz539qAHYINchsPFA4=
X-Received: by 2002:ac8:2ea5:: with SMTP id h34-v6mr2718802qta.18.1540914642297; Tue, 30 Oct 2018 08:50:42 -0700 (PDT)
MIME-Version: 1.0
From: Klaus Hartke <hartke@projectcool.de>
Date: Tue, 30 Oct 2018 16:50:05 +0100
X-Gmail-Original-Message-ID: <CAAzbHvayDZiZg6-4fXYLqda6M0fAFsv_1OZ84mpyPj523W5vYQ@mail.gmail.com>
Message-ID: <CAAzbHvayDZiZg6-4fXYLqda6M0fAFsv_1OZ84mpyPj523W5vYQ@mail.gmail.com>
To: "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1540914645; 08966436;
X-HE-SMSGID: 1gHWHz-0003IX-Da
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/UFSDAJOqzOEAye9DeZnKJSPs0GE>
Subject: [core] Review of draft-ietf-core-multipart-ct-02
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: Tue, 30 Oct 2018 15:50:50 -0000
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?) 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? 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? 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? 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. 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? 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. 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. 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. 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? 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? 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. 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? 4.1 "Fragment identifier considerations: N/A" -- Change to same as CBOR? 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. Klaus
- [core] Review of draft-ietf-core-multipart-ct-02 Klaus Hartke
- Re: [core] Review of draft-ietf-core-multipart-ct… Fossati, Thomas (Nokia - GB/Cambridge)
- Re: [core] Review of draft-ietf-core-multipart-ct… Carsten Bormann
- Re: [core] Review of draft-ietf-core-multipart-ct… Fossati, Thomas (Nokia - GB/Cambridge)
- Re: [core] Review of draft-ietf-core-multipart-ct… Klaus Hartke
- Re: [core] Review of draft-ietf-core-multipart-ct… Fossati, Thomas (Nokia - GB/Cambridge)
- Re: [core] Review of draft-ietf-core-multipart-ct… Jim Schaad