On Oct 12, 2016 3:44 PM, "Thiago Macieira" <thiago.macieira at intel.com> wrote: > > Em quarta-feira, 12 de outubro de 2016, ?s 15:14:34 CEST, Gregg Reynolds > escreveu: > > > I was thinking that if a query was received, communication is possible, > > > and > > > the query parameters match, it must answer. (sometimes, even if the > > > parameters don't match) > > > > > > > > so here's a (possible) use-case: I want to draw a picture of my oic > > > > > (inter-) network. I need to know which nodes are on which network, > > > > > and > > > > > what their roles are. > > > > > > > > Anyway my main point is that it is a mistake to treat every oic node as > > > > ipso facto a member of an internetwork. specifying oic internetworking > > > > is a completely different issue. and please note that the current > > > > proposal is not the only possible one. > > > > > > Why do you think we shouldn't do that? > > > > Principle of Parsimony, mainly. if I'm not doing internetworking, then I > > want zero internetworking overhead. every byte counts. ;) > > I'm going to repeat what I said above: if a device received a multicast query > whose parameters match resources this current device knows about, it should > reply. >
what resources does a gateway "know about"? I think I'm not getting my point across. the internetworking feature is based on an experimental CoAP option, RM. that discombobulates everything if it is not fully specified. e.g. if I am an non-gateway oic server and I receive a request, am I supposed to look for the RM option? if I find it, how should i interpret it? there are at least two options: 1) I'm not a gateway so I'm going to completely ignore this request; and 2) I'm not a gateway so I'm going to ignore the RM option and do my normal discovery thing. same goes for gateways: I'm a gateway, and I received a discovery request w/o an RM option. what to do? the answers may be intuitively obvious to you or me or whomever, but protocol specs should be explicit. for that matter the same goes for other CoAP options. what should I do with proxy options? I'm beginning to think that options should be treated as out-of-bounds data, or metadata. fwiw my gut says the RM option is not necessary, at least for non-gateways. but I haven't figured out an alternative yet. > If the current device is not supposed to reply, then the sender needs to send > query parameters that are stricter and cause a match to fail. > how is the sender to know ahead of time that the "current device" is not supposed to reply? (I may not be understanding your point, I admit. ) g > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161012/59e3d507/attachment.html>
