Hi Carsten,
On 3/27/13 8:34 AM, Carsten Bormann wrote:
Hi Shoichi,
On Mar 19, 2013, at 01:55, Shoichi Sakane <sakane@xxxxxxxx> 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