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

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2018 13:24:03 +0700

Here are my two cents…

> On Oct 31, 2018, at 00:42, Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]> wrote:
> 
> 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.

Indeed.

>> 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/ ?

“Several” was not intended to exclude 2, 1, or 0.
I see that the dictionary does this.
(It can be 0 or 1 in the case introduced by draft-bormann-core-maybe.)

>> 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/ ?

Well, this is a body, which might even be transmitted in block-wise fashion, so it is not tied to messages.
Maybe “CoAP request or response body” is the best way to fit this.
(There is no implication that it can’t also be used to brush your teeth.)

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

I think Klaus wants us to point out that the application needs to stay in the CDDL.

>> 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?

You could leave them out entirely, but then the application cannot simply use a positional structure.

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

It was meant as an encouragement to define application-specific media types in a way that conforms with the structure of multipart-ct where that makes sense.

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

Right.  We could explicitly say “First Come First Served” instead.

>> 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?

Please see draft-iab-protocol-maintenance

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

If we don’t want to do this, we should remove it.
(I still believe we should do this, now.)

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

Let’s discuss this in the WG today.

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

Klaus points out that there is one more byte, something like 0x81.

>> 4.1 "Fragment identifier considerations: N/A" -- Change to same as
>> CBOR?

Should we also copy the text: “(At
      publication of this document, there is no fragment identification
      syntax defined for “application/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!

Indeed!

Grüße, Carsten

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Tue, 6 Nov 2018 03:20:53 +0000

Hi Carsten,

> (It can be 0 or 1 in the case introduced by draft-bormann-core-maybe.)

It's "[...] used to combine zero or more media types" then?

> Well, this is a body, which might even be transmitted in block-wise
> fashion, so it is not tied to messages.  Maybe “CoAP request or
> response body” is the best way to fit this.

Works for me.

> (There is no implication that it can’t also be used to brush your

:-)

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

The CDDL describes the syntactic constraints but the applications still
need to define the shape and semantics of their multipart blobs.  Using
a programming metaphor, the CDDL says "it's a struct", while the
applications define the fields and associated types inside the struct.

> >> 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?
> >

Optionality by omission doesn't work in all cases (e.g., two adjacent
optional fields of the same type) and I'd rather recommend using the
positional approach which works in all cases and is trivial to
implement.  But yes, we probably shouldn't preclude the ability of the
application designer to optimise for its case.

> >> 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.
>
> It was meant as an encouragement to define application-specific media
> types in a way that conforms with the structure of multipart-ct where
> that makes sense.

Either way I'm OK: I think is a good suggestion but it's not needed for
interop so we could also leave it out.

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

Works for me.

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

Going back to Klaus' comment, which grammar are we talking about?  The
overarching CDDL or the application defined position-type-value?  If the
former I'm more than OK to say "fail hard and early" in this document.
If the latter, I wouldn't know how to deal with these kinds of
inconsistencies in a generally applicable way.  These things should be
left to the applications.

> If we don’t want to do this, we should remove it.  (I still believe we
> should do this, now.)

I think it's safer if we leave any alternative future format to a
separate multipart-ct-2.

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

Apologies I couldn't be there, I had a conflict with TLS :-(
I'll read the minutes.

> >> 3.2 "Implementation hints" -- This doesn't seem like a usage
> >> example.  Promote it to a top-level section.
> >
> > Agree
> >
> >> 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?
> >

OK

> Should we also copy the text: “(At publication of this document, there
> is no fragment identification syntax defined for “application/cbor”.)"
> ?
>
> >>
> >> 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!
>
> Indeed!

and thank you,
cheers, t

________________________________________
From: Carsten Bormann <[email-masked]>
Sent: 05 November 2018 07:24:03
To: Fossati, Thomas (Nokia - GB/Cambridge)
Cc: [email-masked]; [email-masked]
Subject: Re: [core] Review of draft-ietf-core-multipart-ct-02

Here are my two cents…

Indeed.

Indeed!

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 7 Nov 2018 13:26:19 +0100

I think the draft needs to be much clearer on whether a multipart
collection is an unordered multiset of representations (which I had
assumed so far) or an ordered sequence where applications attach
additional out-of-band meaning to the positions.

Speaking of additional out-of-band meaning, I wonder if there should
be identifiers in the collection explicitly describing the semantics
in the interest of self-description. There are also considerations
related to evolving the out-of-band information, such as when an
application wants to change the meaning of a position but continue
using the "application/multipart-core" content format ID.

Klaus

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Wed, 7 Nov 2018 18:57:07 +0000

Hi Klaus,

> additional out-of-band meaning to the positions.

The word multiset got me confused.  In my mind a multiset is a set of
(repeatable) elements of the same type.  What do you mean by "unordered
multiset" exactly?

The way I intend multipart-ct, and I think this is also how it's
described in the current draft, is the latter -- i.e. a sequence of 
fields each with its own type.

> in the interest of self-description.

(see below)

> There are also considerations related to evolving the out-of-band
> information, such as when an application wants to change the meaning
> of a position but continue using the "application/multipart-core"
> content format ID.

Maybe this an example of where the suggestion about freezing a given
multipart-ct into its own content-format comes in handy.  If you want to
change the semantics, you just give it a different c-f.

At this time I wouldn't go down the road of defining a full blown 
container format with all the bells and whistles.  I'd like to see what
we can achieve with this minimalist framework in the first place and
if experience teaches us it's not fit for purpose, we can always make it 
better in a future iteration.

Cheers!

---

From: Jim Schaad <[email-masked]>
Date: Tue, 13 Nov 2018 14:04:32 +0900

Klaus,

I think that I would prefer that the choice between ordered or unordered be
a property of the application that is using the multipart collection rather
than hard coding it in.  I can think of use cases where both are things to
be desired and thus would not like to rule out either one.

Jim

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Klaus Hartke
> Sent: Wednesday, November 7, 2018 9:26 PM
> To: Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>
> Cc: [email-masked] WG <[email-masked]>
collection
> is an unordered multiset of representations (which I had assumed so far)
or
> an ordered sequence where applications attach additional out-of-band
> meaning to the positions.
> 
> Speaking of additional out-of-band meaning, I wonder if there should be
> identifiers in the collection explicitly describing the semantics in the
interest
> of self-description. There are also considerations related to evolving the
out-
> of-band information, such as when an application wants to change the
> meaning of a position but continue using the "application/multipart-core"
> content format ID.
> 
> Klaus
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core