Re: [dev] Problem with IPv4 only Discovery

RFC 7668, IPv6 over BLUETOOTH(R) Low Energy http://tools.ietf.org/html/rfc7668

Re: [dev] Problem with IPv4 only Discovery

Thiago Macieira writes: > > Suppose I have an engine that supports OCF messaging and data model, > > but only over TCP/IP. I do not see why that should not be considered > > conformant. > > Certification is a choice. Specifically, we need to choose a combination to > require all > devices to s

Re: [dev] coding conventions: header file naming?

I agree there should be a naming convention. I don't care which one is picked, but picking one is good, and I agree it's good to avoid confusion between C and C++ header files. -Original Message- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.or

Re: [dev] clear distinction of what is below and above the APIs

My opinion: the presence or absence of APIs should not depend on #defines. For example, I would consider any APIs whose presence, absence, or signature is affected by #ifdef __WITH_TLS__ to be a bug that needs to be fixed. -Original Message- From: Mats Wichmann [mailto:m...@wichmann.us]

Re: [dev] clear distinction of what is below and above the APIs

My views, as the iotivity API maintainer, below... -Original Message- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Wouter van der Beek (wovander) Sent: Thursday, February 22, 2018 9:49 AM To: Nash, George ; Mats Wichmann ;

Re: [dev] libcoap version

George’s summary is correct. From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Nash, George Sent: Wednesday, February 7, 2018 10:16 AM To: Raveendranath Kondrakunta ; iotivity-dev@lists.iotivity.org Subject: Re: [dev] libcoap version Rav

Re: [dev] percent encoding IPv6 endpoints

Well if it’s really unfixable then we deprecate the old broken API and add a new API that’s not broken. If this is a recent regression then there may be apps both ways. From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Thursday, January 25, 2018 2:55 PM To: Dave Thaler Cc: kishen.mal...@int

Re: [dev] percent encoding IPv6 endpoints

Ok, after groveling through a bunch of code to refresh my memory, eps->addr should be an IP literal string, not a URL authority component string. So yes it is a bug and the “%25” should be “%” in OCMapZoneIdToLinkLocalEndpoint. The following places in the code confirm that eps->addr is an IP lit

Re: [dev] percent encoding IPv6 endpoints

Ok I read this thread through again and checked the code and now I understand your point. You’re saying that OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, "%25"); should be OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, "%"); in OCMapZoneIdToLinkLocalEndpoint() because eps->addr should be an IP literal

Re: [dev] percent encoding IPv6 endpoints

From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Thursday, January 25, 2018 12:39 PM To: Dave Thaler Cc: iotivity-dev Subject: RE: [dev] percent encoding IPv6 endpoints Further info: This is a literal ipv6 adsress: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 Same embedded *within* a URL:

Re: [dev] percent encoding IPv6 endpoints

From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Thursday, January 25, 2018 12:27 PM To: Dave Thaler Cc: iotivity-dev Subject: RE: [dev] percent encoding IPv6 endpoints Hi Dave, Thanks for taking the time to respond. Comments/questions below. On Jan 22, 2018 3:51 PM, "Dave Thaler" ma

Re: [dev] percent encoding IPv6 endpoints

Below From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds Sent: Monday, January 22, 2018 11:37 AM To: iotivity-dev Subject: [dev] percent encoding IPv6 endpoints OCMapZoneIdToLinkLocalEndpoint (in ocstack.c) percent-encodes

[dev] FW: CoAP over TCP Interop Testing (Feb. 2018)

FYI From: core [mailto:core-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, January 22, 2018 6:46 AM To: c...@ietf.org WG Subject: [core] CoAP over TCP Interop Testing (Feb. 2018) Hi all, Based on the availability of interested folks we are planning to schedule another online in

Re: [dev] Question about discoverable resources

There’s a couple of cases: 1. A resource exists that is not discoverable at all. If you somehow know the full URI, you can use it. 2. A resource exists that is publicly discoverable. Everyone on the network can see its existence, even if you can’t do any operations on it. 3. A resour

Re: [dev] a few more API questions (doc, mainly). long-ish.

My view, as API maintainer... Mats writes: > Question 1. How *do* you determine the official API list? Is it purely > determined by the list of headers? Which is the correct list of headers? Yes, the correct list is the set of .h files copied to the out/ directory by the build. > Is there a

Re: [dev] DoS defences?

Any on-link attacker can already deplete your batteries without using OCF (e.g., via ARP or IPv6 Neighbor Discovery), OCF doesn’t change that. From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds Sent: Saturday, January 6, 20

Re: [dev] Proposed API guidelines

ivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds Sent: Tuesday, January 2, 2018 9:46 PM To: Dave Thaler mailto:dtha...@microsoft.com>> Cc: iotivity-dev mailto:iotivity-dev

Re: [dev] Proposed API guidelines

o: Dave Thaler mailto:dtha...@microsoft.com>> Cc: iotivity-dev mailto:iotivity-dev@lists.iotivity.org>> Subject: Re: [dev] Proposed API guidelines On Aug 18, 2017 10:55 AM, "Dave Thaler via iotivity-dev" mailto:iotivity-dev@lists.iotivity.org>> wrote: As the new API maintainer, he

Re: [dev] Proposed API guidelines

Below From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Tuesday, January 2, 2018 9:46 PM To: Dave Thaler Cc: iotivity-dev Subject: Re: [dev] Proposed API guidelines On Aug 18, 2017 10:55 AM, "Dave Thaler via iotivity-dev" mailto:iotivity-dev@lists.iotivity.org>> wrote

Re: [dev] Proposed API guidelines

Below From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Tuesday, January 2, 2018 9:17 PM To: Dave Thaler Cc: iotivity-dev Subject: Re: [dev] Proposed API guidelines On Jan 2, 2018 7:18 PM, "Dave Thaler via iotivity-dev" mailto:iotivity-dev@lists.iotivity.org>> wrote:

Re: [dev] Proposed API guidelines

[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Friday, August 18, 2017 9:35 AM To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] Proposed API guidelines On 08/18/2017 09:54 AM, Dave Thaler via iotivity-dev wrote: > As the new API maintainer, here's

Re: [dev] which libcoap to use in master branch?

On a non-constrained device, this can be handled by a host firewall, for applications that can't handle it themselves. But it's much more efficient for the app (or iotivity in this case) to be configurable itself rather than relying on a firewall to compensate. For anyone who wants a much deeper

Re: [dev] which libcoap to use in master branch?

dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira Sent: Tuesday, December 5, 2017 1:58 PM To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] which libcoap to use in master branch? On Tuesday, 5 December 2017 11:25:23 PST Dave Thaler via io

Re: [dev] which libcoap to use in master branch?

That would be great, thanks for volunteering to clean this up! Dave -Original Message- From: Mats Wichmann [mailto:m...@wichmann.us] Sent: Tuesday, December 5, 2017 11:29 AM To: Dave Thaler ; IoTivity Developer List Subject: Re: [dev] which libcoap to use in master branch? On 12/05/20

Re: [dev] which libcoap to use in master branch?

resource/csdk/connectivity/lib/libcoap-4.1.1 this one is obsolete and should have no new features added. It should be deleted as soon as all builds pass with the newer libcoap. That's always been the plan. My fork is the current working version and is what should be used today

Re: [dev] iotivity master branch cleanup?

Yes on Arduino. When I was platform maintainer (which is now Dan Mihai), the decision was to delete it after 1.3, since Arduino support was moved to iotivity-constrained. So that would be good to do now. -Original Message- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-

Re: [dev] Questions about brightness and dimming resource types

If I have a dimmable light, should I expose it with dimming or brightness or both? It sounds like the answer today is "up to you", which means if I'm developing a dimmer switch (app or device with a client app embedded), then I currently need to support both or there's no guarantee of interoper

Re: [dev] Proposed Design Approach for [IOT-1379] Multi-Device Support

BLE GATT implementation. Regarding OCDevAddr, Let think about adding the other info also such as zone id. BR, Uze Choi From: iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Dave Thaler vi

Re: [dev] IPv4 support for multicast discovery in version 1.3.1

> From: iotivity-dev-boun...@lists.iotivity.org > [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Wednesday, November 22, 2017 2:39 PM > To: Max Kholmyansky ; iotivity > > Subject: Re: [dev] IPv4 support for multicast discovery in version 1.3.1 > [...] > >

Re: [dev] FW: [core] Testing CoAP/TCP at the IETF100 Hackathon?

My understanding is that Olaf wanted the huge iotivity patch broken into lots of little patches, which never got done. So the reimplementation of coap-over-tcp by others exposed a slightly different API surface, and got accepted. -Original Message- From: Mats Wichmann [mailto:m...@wichma

Re: [dev] FW: [core] Testing CoAP/TCP at the IETF100 Hackathon?

he IETF100 Hackathon? On 11/09/2017 06:33 AM, Dave Thaler via iotivity-dev wrote: > Attention any COAP-over-TCP implementers: there's a discussion / interop > event on Saturday > where remote participation is allowed. The message below is from Olaf > Bergmann, maintainer >

[dev] FW: [core] Testing CoAP/TCP at the IETF100 Hackathon?

Attention any COAP-over-TCP implementers: there's a discussion / interop event on Saturday where remote participation is allowed. The message below is from Olaf Bergmann, maintainer of libcoap, saying he'll be a remote participant. -Original Message- From: core [mailto:core-boun...@iet

Re: [dev] direct pairing

“should not vendor-specific features go in vendor-specific forks or libs? otherwise we end up with a kitchen sink o' cruft.” Completely agree with that. Vendor-specific features should never be coded (even if #ifdef’ed) into the middle of files in the master branch, in my view.

[dev] Proposed API guidelines

As the new API maintainer, here's a set of proposed API guidelines. Please review so and feedback can be incorporated before making official guidelines. 1 APIs -- There are three types of APIs: 1) Public 2) Experimental 3) Internal 1.1 Public APIs --- Public APIs are

Re: [dev] Multicast Endpoint Discovery vs. Unicast Endpoint Discovery

Sounds like a bug. From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of June Chen Sent: Thursday, July 13, 2017 4:03 AM To: iotivity-dev@lists.iotivity.org Subject: [dev] Multicast Endpoint Discovery vs. Unicast Endpoint Discovery Hi, Endpo