Subject: Re: [core] draft-bormann-coap-misc-08 - Payload-Length options

From: Cullen Jennings <[email-masked]>
Date: Mon, 20 Jun 2011 08:40:16 -0600

ok, but just to check we have the right things in the base draft, if we want to add this later, how does the later draft negotiate such that both sides know it is supported?

On May 10, 2011, at 7:10 PM, Likepeng wrote:

> I agree that it is quite useful for some cases, but I prefer it to be a separate draft. 
> 
> (1) Because it is not needed (or at least optional) if we use UDP as transport, which is the major transport under consideration now. The information will be redundant if we can get the information from the Payload-Length Option and from the UDP layer. And it may cause problem if they are inconsistent.
> 
> (2) I don't think it is good to pack more than one CoAP message into one UDP payload. It will add the complexity and I can't see too much benefit. 
> 
> (3) I remember it was in the base draft before, but it was removed for some reasons.
> 
> FYI, this is the justification from the misc-08 for the Payload-Length:
>   Not all transport mappings may provide an unambiguous length of the
>   CoAP message.  For UDP, it may also be desirable to pack more than
>   one CoAP message into one UDP payload (aggregation); in that case,
>   for all but the last message there needs to be a way to delimit the
>   payload of that message.
> 
> Kind Regards
> Kepeng
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Tuesday, May 10, 2011 10:13 PM
> To: core WG
> Subject: [core] draft-bormann-coap-misc-08 - Payload-Length options
> 
> I'd like to propose that we take the text from section 6 of this draft defining an option to use Payload-Length options and move it to CoAP. The main reasons I think it needs to be in the base draft is it is hard to add later and easy to implement. Having this makes it much easier for us to be future proof for use on non datagram transports or have aggregation of multiple CoAP messages into a single IP datagram. 
> 
> It also makes it easy to figure out to use CoAP in a situation where you have a serial line between the host and proxy that is IP connected. 
> 
> Cullen <in my individual contributor role>
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Jun 2011 17:58:02 +0200

On Jun 20, 2011, at 16:40, Cullen Jennings wrote:

> if we want to add this later, how does the later draft negotiate such that both sides know it is supported?

If we add this now, how does the client know the server supports it?
Right now, we have no option at all that is actually mandatory (although payloads don't make much sense without the content-type option).

(I'm all for putting Payload-Length in, but the extensibility story may not be the right reason.)

Gruesse, Carsten

---

From: Likepeng <[email-masked]>
Date: Tue, 21 Jun 2011 02:02:23 +0000

> How does the client know the server supports it?

Some time ago, I proposed to add one option, to indicate the supported options. Before sending the request, the client can check what options the server can support. 

The current situation is, the client sends request with the Payload-Length option (or the other elective options), if the server does not support it, it just ignores it. The client will have no idea if that option makes effect or not. The next time, the client will send the option again. 

If the option is critical, it is fine. The server will reject the message with a 4.02 (bad option) response or a reset message. For the non-confirmable request, the server will also ignore the option, which is similar to elective option.

Does the group think that the proposed solution adds value for the client?

Kind Regards
Kepeng
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Monday, June 20, 2011 11:58 PM
To: Cullen Jennings
Cc: Likepeng; core WG
Subject: Re: [core] draft-bormann-coap-misc-08 - Payload-Length options

Gruesse, Carsten