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

["Fossati, Thomas (Nokia - GB/Cambridge)" <[e-mail]>]

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

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

Agree

> 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
> CBOR?
>
> 6.1 "[RFC7252]" -- Just to confirm: This is a normative reference
> because of the use of CoAP Content-Format numbers, right?

Yes

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

Agree

Thank you very much!
Cheers,
-- 
Thomas