> > >> Some deployed SNMP-like databases do have currently parameters related > to power consumption, at least.
I was more referring to the fact that SNMP doesn't really define a caching model like HTTP does (assuming you think caching is an effective solution for fetching information from sleeping nodes). > > But one point: the main HTTP semantics (unicast GET/POST/PUT) wouldn't > fit a single-multicast request multiple-unicast response semantics, used > for example when querying a set of sensors. I am not sure how you see > it... > I personally see the world as simple unicast request/response (be it GET/POST/etc). To me caching solves much more than just sleeping nodes. Effective resource caching between the 6LoWPAN and outside world can do lots to save bandwidth on the 6LoWPAN, since commonly addressed resources can be served directly from the cache(s). > > Neither the C Library nor the C++ Standard Template Library include http > calls... not sure what you mean. Do you mean Java and family? Very true! C doesn't come much does it. Although I think most people who want to consume smart device information are likely writing in a higher level language like Java, C#, VB, Ruby, Python, etc. > > A URL yes, but an http server on a sensor? > We can't run TCP/HTTP straight to the sensor, so we must use some UDP binary compression which actually runs on the sensor. I think what matters most is that they we leverage key HTTP concepts like URIs for addressing information resources and HTTP semantics for REST, caching, and MIME typing. > >> If there is interest, I would be glad to post a draft to start some >> discussions around the idea of using compressed HTTP over 6LoWPANs. >> > > Let's see let's see, sounds interesting. > > I am a bit of a new comer to the IETF, so I am not really familiar with the process. What is the best way to post a strawman and keep the discussion going?
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
