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

From: Klaus Hartke <[email-masked]>
Date: Tue, 30 Oct 2018 16:50:05 +0100

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

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Tue, 30 Oct 2018 17:42:55 +0000

Hi Klaus,

> (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.

> media types" -- Does it have to be several media types or is 2 media

s/several/two or more/ ?

> used in a CoAP message-body?

s/CoAP message-body/message/ ?

> by figure 1? Or is this about assigning further meaning to positions

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.

> same fixed position." -- Ah, I see. Join this paragraph with the

Makes sense.

> part." -- Do we need this?

How do you suggest we deal with optional values?

> where an application would do this? I can't imagine any where I'd

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.

> providing this range for this purpose forever.

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

> has impact on how the format can be evolved in the future.

Isn't that application specific?

> really helpful. What should a reader of the document do with this

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

> -multipart-ct? If not, shouldn't there be an example for the prime use

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

> -multipart-ct as described in this section? If not, better remove the

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
pubsub.

> Promote it to a top-level section.

Agree

> containing the two elements?

Sorry, I don't understand this.

> because of the use of CoAP Content-Format numbers, right?

Yes

> seems to be referenced only in the usage examples section.

Agree

Thank you very much!
Cheers,
-- 
Thomas