Subject: Re: [core] MULTIPART-CT: A few editorial comments

From: Thomas Fossati <[email-masked]>
Date: Thu, 22 Aug 2019 06:50:07 +0000

HI Christer,

Sorry for missing your comments.

I guess we have two possible paths to get them in:

  1.  If the IESG processing triggers a new review, we will be addressing your comments in the updated draft;
  2.  Otherwise, being purely editorial, these can be fixed by the RFC editor.

(I have filed https://github.com/core-wg/multipart-ct/issues/25 to track them.)

Cheers, thanks!

From: core <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Wednesday, 21 August 2019 at 21:40
To: "[email-masked]" <[email-masked]>
Subject: Re: [core] MULTIPART-CT: A few editorial comments

Hi,

Unless I have missed it, I would appreciate if the issues below could be addressed. They should only be editorial.

Regards,

Christer

Lähettäjä: core <[email-masked]> Puolesta Christer Holmberg
Lähetetty: tiistai 23. heinäkuuta 2019 17.53
Vastaanottaja: [email-masked]
Aihe: [core] MULTIPART-CT: A few editorial comments

Hi,

A few minor editorial comments on draft-ietf-core-multipart-ct-03:

(I haven’t read the IESG review comments, so my apologies if someone has already raised these comments)

---

Q1:

The Introduction says talks about “request or response body’.

However, when looking in RFC 7252, I don’t find ‘body’ anywhere.

I assume that ‘body’ refers to what RFC 7252 calls ‘payload’. If so, I suggest aligning the terminology.

(For some reason section 10.2.3 of RFC 7252 does use ‘message-body’, without any explanation or reference, but I guess that is just an error)

---

Q2:

Related to Q1, the text says:

   “can be used to combine representations of zero or more different media types into a single message”

I assume it means ‘single message payload’? Because, you are not combing other parts (Codes, Tokens etc) of the message, are you?

I think it would be more clear if you said ‘combine multiple representations, each using the same or different media types, into a single message payload’.

---

Q3: The draft uses both ‘media type’ and ‘media-type’. RFC 7252 uses ‘media type’ (there is one instance of ‘media-type’, though), so maybe align with that?

Regards,

Christer

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Aug 2019 06:55:29 +0000

Hi,
 
> (I have filed https://protect2.fireeye.com/url?k=6aecc09b-363fd0f3-6aec8000-8691b328a8b8-b9a95f4e7bf9b641&q=1&u=https://github.com/core-wg/multipart-ct/issues/25 to track them.)

Either new review or RFC editor is fine with me - whatever is more convenient for you :)

However, I'd like people to verify that my understanding in comment Q2 is correct.

Regards,

Christer 

Hi,

Regards,
 
Christer

Hi,

 
---
 
Q1:

 

---
 
Q2:

 

---

Regards,
 
Christer

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 22 Aug 2019 07:01:52 +0000

On 22/08/2019, 07:55, "Christer Holmberg" <[email-masked]> wrote:

It depends on what you mean by "message".  What we really mean here is
"MIME message" rather than "$APPLICATION_PROTOCOL message."

Being explicit would solve the ambiguity that confused you in the first place.

Cheers!

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 07:55:13 +0000

Hi,

To me, "message" would refer to a CoAP request or response :)

Regards.

Christer

On 22/08/2019, 10.02, "Thomas Fossati" <[email-masked]> wrote:

    

    Cheers!

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 23 Aug 2019 10:26:13 +0000

Hi Christer,

>  To me, "message" would refer to a CoAP request or response :)

My two cents:

application/multipart-core is a "normal" MIME media type, and it's not
bound to CoAP by any means (although CoAP is the motivating use case).

In the context of MIME (RFC 2046) "message body" is the established
wording for the MIME message content, irrespective of the transport
protocol (CoAP, SMTP, HTTP).

This is how I interpret it, at least.  And I agree with you that the current
text is ambiguous in this respect.

Cheers, t

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 10:53:40 +0000

Hi,

>    bound to CoAP by any means (although CoAP is the motivating use case).
  
Agree.

>    protocol (CoAP, SMTP, HTTP).
  
Agree. 

>    text is ambiguous in this respect.
  
We need to define how the generic terms above are mapped into CoAP.

For example, if you transport a "message body" in CoAP, what is the part of the CoAP message where the "message body" is conveyed?

Figure 7 of RFC 7252 defines the "Payload" part of a CoAP message. I assume that is the part used to convey a "message body" associated with a MIME media type.

But, MULTIPART-CT does not talk about the Payload part. It talks about "body", which is nowhere defined for CoAP. I need to know what part of a CoAP message the "body" is.

Regards,

Christer

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 23 Aug 2019 11:07:01 +0000

On 23/08/2019, 11:53, "Christer Holmberg" <[email-masked]> wrote:
> For example, if you transport a "message body" in CoAP, what is the
> part of the CoAP message where the "message body" is conveyed?
>
> Figure 7 of RFC 7252 defines the "Payload" part of a CoAP message. I
> assume that is the part used to convey a "message body" associated
> with a MIME media type.

Yes - barring Block which allows fragments of the same "MIME message
body" to be spread across multiple "CoAP payloads".

> But, MULTIPART-CT does not talk about the Payload part. It talks about
> "body", which is nowhere defined for CoAP. I need to know what part of
> a CoAP message the "body" is.

I'm not sure multipart-ct should necessarily talk about that, no more
than any other MIME types should.  The mapping of resource
representations into CoAP frames should be explained by RFC 7252.

Cheers, thanks!

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 11:18:12 +0000

Hi,

   >  body" to be spread across multiple "CoAP payloads".
   
   Sure.

    > representations into CoAP frames should be explained by RFC 7252.
    
    Exactly! That is my point :)

    RFC 7252 should define/reference the generic CoAP terminology, and we should then use that terminology in the CoAP extension document.

    Only MULTIPART-CT specific terminology should be defined in MULTIPART-CT.

Regards,

Christer

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 23 Aug 2019 11:25:16 +0000

Hey Christer,

> Exactly! That is my point :)

Excellent :-)

> RFC 7252 should define/reference the generic CoAP terminology, and we
> should then use that terminology in the CoAP extension document.
>

Could you propose a PR against master [1]?

Cheers, thanks!

[1] https://github.com/core-wg/multipart-ct/blob/master/draft-ietf-core-multipart-ct.md

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 11:30:38 +0000

Hi,

    > Could you propose a PR against master [1]?

    I can give it a try :)

    Do I need contributor rights (my GitHub ID is CDH4U)?

    Regards,

    Christer

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 23 Aug 2019 11:33:02 +0000

>  I can give it a try :)

Super!

> Do I need contributor rights (my GitHub ID is CDH4U)?

No worries, the repo is public.

Cheers, t

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 12:23:51 +0000

Pull request: https://github.com/core-wg/multipart-ct/pull/26

Regards,

Christer

On 23/08/2019, 14.33, "Thomas Fossati" <[email-masked]> wrote:

    Super!

    
    Cheers, t

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 23 Aug 2019 12:35:10 +0000

> Pull request: https://github.com/core-wg/multipart-ct/pull/26

Great!  And thanks again.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 16:50:48 -0400

> Pull request: https://github.com/core-wg/multipart-ct/pull/26

looks good to me too.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-