Re: [core] Last Call: <draft-ietf-core-coap-14.txt> (Constrained Application Protocol (CoAP)) to Proposed Standard

[Shoichi Sakane <[e-mail]>]

Hi Carsten,

On 3/27/13 8:34 AM, Carsten Bormann wrote:
> Hi Shoichi,
>
> On Mar 19, 2013, at 01:55, Shoichi Sakane <[e-mail]> wrote:
>
>> And, the length of URI is likely to be bigger than the MTU.
>>
>> Do you assume a use case in which the total length of options is going
>> to be greater than the MTU ?
>
> CoAP has been designed for constrained devices, and networks built out of these devices (constrained node networks, draft-ietf-lwig-terminology).
>
> In REST, servers can structure their URIs in a way that is appropriate for the intended use.
> We would expect constrained node servers to come up with short URIs.
> Existing designs based on CoAP (such as OMA lightweight M2M) go to great pains to keep their sizes in check.
>
> So, no, I don't expect a realistic use case where the total length of options (which might be dominated by the URI) is greater than the IP MTU, not even the IFMUALTU (draft-bormann-intarea-alfi).

Agreed.

> I should mention that the CoAP approach to slicing a large request/response pair into multiple exchanges is draft-ietf-core-block, which is widely implemented, but the specification text is not yet completed by the WG; if we ever need to address such a use case, we probably should address it there.  (As of today, -block only addresses slicing up the payload.)

That's the point.  I hope that CoAP transport layer itself would have to have an ability of fragment/reassemble of the CoAP REST layer.  Maybe in the future, "option 0" would be responsible to do that.

Shoichi