Subject: [core] Last call review of draft-ietf-core-multipart-ct-03

From: [email-masked] (Dale R. Worley)
Date: Wed, 01 May 2019 21:30:40 -0400

I'm no expert on this, but looking at section 3.1 of -03, I suspect the
word that I've marked should be "Pending", not "Content".

   When a client registers to observe a resource [RFC7641] for which no
   representation is available yet, the server may send one or more 2.05
   (Content) notifications before sending the first actual 2.05
----^
   (Content) or 2.03 (Valid) notification.  The possible resulting
   sequence of notifications is shown in Figure 1.

         __________       __________       __________
        |          |     |          |     |          |
   ---->|   2.05   |---->|  2.05 /  |---->|  4.xx /  |
        | Pending  |     |   2.03   |     |   5.xx   |
        |__________|     |__________|     |__________|
           ^   \ \          ^    \           ^
            \__/  \          \___/          /
                   \_______________________/

                   Figure 2: Sequence of Notifications:

The final colon on the figure's caption should probably also be removed.

The example usage in 3.1 seems like it has some semantic complexities
that are not being fixed here.  It appears that the "observe" process
returns a sequence of messages, and there is a complexity that arises if
the server process is constrained to return a 2.05 Pending message
before it knows what the resource-type of the observed resource is.  The
solution proposed here is to return an application/multipart-core with 0
components, and then later return an application/multipart-core with 1
component, which is the observed resource.

The problem arises that the semantics of the notification are fixed by
RFC 7641 section 3.2, "The only difference between a notification and a
normal response is the presence of the Observe Option."  I.e., the body
of a 2.05 message must be the representation of the resource, not an
application/multipart-core containing the representation of the
resource.

One possibility is to extend the semantics of RFC 7641 so that if a 2.05
response's body has Content-Format application/multipart-core, then the
"value" being carried is by definition the first part of the multipart
body.  But that risks being non-upward-compatible for clients that have
not implemented this convention.

A better possibility would be to define a new value for the Observe
Option of the GET request, 2, which requests registration but also
specifies that each response will wrap the resource value in an
application/multipart-core.

In either way, there seems to be a need for a normative change to RFC
7641.

Dale

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 May 2019 06:34:06 +0200

Hi Dale,

> On May 2, 2019, at 03:30, Dale R. Worley <[email-masked]> wrote:
> 

The “Content” is the translation of “2.05” into English, as we tend to do when showing response codes.

> The final colon on the figure’s caption should probably also be removed.

Yes.  Done in https://github.com/core-wg/multipart-ct/tree/ietf-lc-fixes now.

> application/multipart-core containing the representation of the

If your resource chooses to provide that as its representation, everything is fine.
(If it doesn’t, well, you aren’t using multipart-core.)

> In either way, there seems to be a need for a normative change to RFC

We designed this so that change is not needed.  An Accept option with multipart-core in it is all the signaling you’d need (if you want to signal at all).

Grüße, Carsten