Subject: Re: [core] How to correlate request and responses in group communication

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 2 Dec 2013 01:15:04 +0000

Concerning the two option solutions "Location-Host" and re-use of "Uri-Host": do we care that the "Uri-*" options are critical, whereas the "Location-*" options are not? It seems that an elective option might be more appropriate, especially given that non-supporting devices may be interested in sending multicast requests (esp. PUTs and POSTs) without being interested in the responses.

When would such a "?-Host" option be included in the response? Does the responder need to inspect the UDP layer to indicate that the request is a multicast request? Then for this we are also mixing the layers.

Just some thoughts about this...

> -----Original Message-----
> From: core [mailto:[email-masked]] On Behalf Of Dijk, Esko
> Sent: 29 November 2013 17:52
> To: weigengyu; Carsten Bormann
> Cc: [email-masked]
> Subject: Re: [core] How to correlate request and responses in group
> communication
> 
> If I understand correctly, the proposed idea is to use the Location-*
> Options in a response to indicate the identity/source of a response. In
> a response to a multicast, the identity/source of a response is not
> visible at the CoAP layer. (Only below it, in the UDP layer.)
> 
> However, there is no "Location-Host" option defined, only the relative
> Location-Path and Location-Query options. So this would not help in
> identifying the source of the response!  Unless we define an option
> like "Location-Host".
> 
> Perhaps a better solution is to allow the existing "Uri-Host" option in
> a response (optionally) to identify the source of the response. This is
> quite close to the current meaning of Uri-Host, but then applied to a
> CoAP response situation. The contents of Uri-Host may be an IP literal
> or a hostname (which I assume to be the most stable identifier). In
> terms of standardization, this looks like an easy thing to add, but
> there could be impact on implementations.
> 
> Any thoughts - do we need server identification as a standardized CoAP
> Option? Are there any transports other than UDP/TCP - that allow
> multicast - but somehow don't provide the source IP address of the
> response in the layer below COAP?
> 
> Esko
> 
> -----Original Message-----
> From: weigengyu [mailto:[email-masked]]
> Sent: Friday, November 29, 2013 05:04
> To: Carsten Bormann
> Cc: Dijk, Esko; [email-masked]
> Subject: Re: [core] How to correlate request and responses in group
> communication
> 
> Hi Carsten,
> 
> Thank you for your explanations.
> > I'm not sure I understand what you are trying to achieve with this
> set
> > of options.
> I would like to use the CoAP already defined mechanisms to resolve
> umbiguity locations.
> Using CoAP-defined mechanisms is better than leaving it to applications.
> 
> The CoAP -18 gives descriptions about Location options are used by POST.
> And in CoAP -18 "5.10.6 ETag" is defined as a request option and a
> response option, and ETag may contain Location Options.
> In "5.10.6.1. ETag as a Response Option,
>     If one or more Location-* options are present and thus a location
> URI is indicated (Section 5.10.7), the tagged
>     representation is the representation that would be retrieved by a
> GET request to the location URI.
> In CoAP -18 6. CoAP URIs
>     CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP
> resources and providing a means of locating the resource.
> Based on above texts, I see that the URI from Location options could be
> used "by a GET request to the location URI."
> 
> Current CoAP -18 has not given descriptions whether the GET is
> prohibited from Location options.
> So, GET request could use the URI, or Etag, or Location options.
> Then the responese(s) might use URI, or Etag, or Location options even
> though caches are existed.
> 
> When Location option(s) is in GET, the client can use the standard
> means to see the different responses from multiple locations.
> I believe this CoAP Location facility could be beneficial to a number
> of location-based applicatons.
> 
> 
> Regards,
> 
> Gengyu
> 
> Network Technology Center
> School of Computer
> Beijing University of Posts & Telecommunications
> 
> ________________________________
> 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.
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 4 Dec 2013 11:28:43 +0000

> It seems that an elective option might be more appropriate,
Fully agree, that would be more appropriate. In terms of its semantics though, the Uri-Host Option still is a better fit than Location-Host. So a new type of option similar to Uri-Host would be needed to get the best solution.

> Does the responder need to inspect the UDP layer to indicate that the request is a multicast request?
Yes, it's certainly assumed that the server at CoAP layer is aware of this fact. Hence all the rules about being allowed (or even, advised) to ignore certain multicast requests for security/congestion reasons. "Cross-layer optimization" is at the heart of 6LoWPAN's design and also CoAP's, if you ask me.

Esko

-----Original Message-----
From: Bert Greevenbosch [mailto:[email-masked]]
Sent: Monday, December 02, 2013 02:15
To: Dijk, Esko; weigengyu; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] How to correlate request and responses in group communication

________________________________
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.