Subject: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ?

From: "core issue tracker" <[email-masked]>
Date: Mon, 08 Jul 2013 11:50:50 -0000

#332: Remove advice for use of blockwise on "/.well-known/core" ?

 Groupcomm: suggest to remove text in section 3.8

 "Alternatively a server can also minimize the payload length of a
 response to a multicast GET (e.g., on "/.well-known/core") using CoAP
 blockwise transfers [I-D.ietf-core-block], returning only aa first block
 of the link format description."

 Reason: a client that does not know core-block can't use the response. It
 seems unwise to assume the client knows core-block on such a key resource
 for discovery. Besides, an alternative solution is available in the form
 of hierarchically structured  link format document.

 Any opinions on this are welcome! Plan is to remove in next version.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  [email-masked]  |  [email-masked]
     Type:  protocol     |     Status:  new
  defect                 |  Milestone:
 Priority:  major        |    Version:
Component:  groupcomm    |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/332>
core <http://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Jul 2013 14:32:29 +0200

Well, there are a number of problems here.

> Reason: a client that does not know core-block can't use the response.

That is not really a problem, because clients that want to make use of /.well-known/core should do core-block (whether they use multicast or not).

> It
> for discovery.

To me, it seems unwise to build a system that wants to make use of link-format resources and doesn't do (the client side of) core-block.
(The implementation of the client side of core-block is really, really small.)

> Besides, an alternative solution is available in the form

That would mean that the link-format document has to be artificially structure to fit into the block size most appropriate for the server.  I'd prefer if these considerations weren't spilling over into the format of resources.
(Note that there is only one /.well-known/core, whether requested by multicast or by unicast.)

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 8 Jul 2013 15:07:51 +0000

> because clients that want to make use of /.well-known/core should do core-block (whether they use multicast or not).
That is a possible solution indeed, but then this requirement has to be recorded somewhere in core-coap isn't it? (Or should that be in RFC 6690? Or core-groupcomm -> but that is informational so does not solve it.)
Otherwise many implementers will do the 'unwise thing'  and interoperability suffers.

And secondly, core-block will have to be updated (I would expect) with a description on how to use it together with IP multicast. That does not have to be defined for all use cases, only for the use case of multicast GET for a resource where some servers decide to return only the first block. Or maybe this explanation can go into core-groupcomm?

regards,
Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Jul 2013 20:02:01 +0200

On Jul 8, 2013, at 17:07, "Dijk, Esko" <[email-masked]> wrote:

> That is a possible solution indeed, but then this requirement has to be recorded somewhere in core-coap isn't it?

Well, it is not a protocol requirement, it is just a real-world requirement.
If it doesn't fit, you have to do something.

core-coap does mention "... move to
      block-wise transfers [I-D.ietf-core-block] when approaching three-
      digit message sizes."

> (Or should that be in RFC 6690?

RFC 6690 is pretty much oblivious to how the information is transported.
(It does actually mention multicast, though.)

> Or core-groupcomm -> but that is informational so does not solve it.)

groupcomm mentioning it is exactly the right thing, I'd say.

> Otherwise many implementers will do the 'unwise thing'  and interoperability suffers.

In interops so far, few implementations have had problems with this (with unicast, though).
(I expect the "culture" of using CoAP to be set in interops as much as by the standard.)

> And secondly, core-block will have to be updated (I would expect) with a description on how to use it together with IP multicast. That does not have to be defined for all use cases, only for the use case of multicast GET for a resource where some servers decide to return only the first block.

Good point.
-block is currently mute about continuing forward using unicast requests from a response to a multicast request.

>  Or maybe this explanation can go into core-groupcomm?

Possibly as well.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 11 Jul 2013 11:19:48 +0000

> ...
In this light, we should add an implementation guidance for this case in groupcomm, then. Something like

   "... For this reason a CoAP client sending a multicast CoAP request to /.well-known/core SHOULD support core-block; with the exception case being networks where it is a-priori (by design) known that no CoAP server would ever respond with blockwise CoAP to a request to /.well-known/core."

We could even detail support of core-block to mean support of Block2 option in a response to a GET request. (In case partial adherence to the core-block spec is allowed!)

thanks
Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Monday, July 08, 2013 20:02
To: Dijk, Esko
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ?

Good point.

Possibly as well.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 11 Jul 2013 13:33:19 -0400

Hi Esko,

My vote would be just to add the first part of your suggestion to Groupcomm I-D.  That is:

"... For this reason a CoAP client sending a multicast CoAP request to /.well-known/core SHOULD support core-block"

The other parts of your text below are exceptions and I don't think we need to be exhaustive in covering these (i.e. I guess there are others as well that people can always think up and we cannot cover them all).

Best Regards,

Akbar

-----Original Message-----
From: Dijk, Esko [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 7:20 AM
To: Carsten Bormann
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ?

thanks
Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Monday, July 08, 2013 20:02
To: Dijk, Esko
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [core] #332: Remove advice for use of blockwise on "/.well-known/core" ?

Good point.

Possibly as well.

Grüße, Carsten

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 15 Jul 2013 07:55:42 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Resolved in groupcomm-11 by the text:
 "CoAP client sending a multicast CoAP request to /.well-known/core SHOULD
 support core-block."

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]  |  [email-masked]
     Type:  protocol     |      Status:  closed
  defect                 |   Milestone:
 Priority:  major        |     Version:
Component:  groupcomm    |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/332#comment:5>
core <http://tools.ietf.org/core/>