Re: [dev] Questions about json2cbor tool from the security tools folder

On Oct 26, 2017, at 03:40, Thiago Macieira wrote: > > Also note that COSE requires that the protected maps also conform to the > canonical format (RFC 7049 section 3.9), but our map doesn't. Actually, COSE doesn’t require that. The fact that we didn’t want to require canonicalization of the ma

[dev] Should IoTivity Arduino support be dropped?

On 22 Mar 2017, at 17:47, Thiago Moura wrote: > > And Christian, FYI (https://wiki.iotivity.org/hardware). Raspberry > PI(3/zero), and Intel Galileo (not that cheap) are equally cheap and small. Completely different class of devices (these employ general purpose processors running Linux, not m

[dev] Should IoTivity Arduino support be dropped?

On 24 Feb 2017, at 20:19, Dave Thaler via iotivity-dev wrote: > > Arduino support Arduino is a brand, not a platform; there are several, rather different platforms branded Arduino. Some of these have plenty of resources. What Arduino branded platforms was IoTivity addressing? What of these pla

[dev] IoTivity bug in block-wise transfers.

On 4 Jan 2017, at 00:38, Maloor, Kishen wrote: > > IoTivity_simpleclient issues a GET request and the > IoTivity-Constrained_simpleserver sample returns a payload > with the block2 option set. > > However, IoTivity_simpleclient subsequently returns a > confirmable GET request for the next block

[dev] [Question] sending binary data

Hi ???, > But our senario, we don't need keyword such as "data". > Is there any other way to send binary data without CBOR encoding on Iotiviy > service layer ? ?CBOR encoding? binary data is just prefixing it with length information ? not a big thing. Can you tell us why you want to do this d

[dev] [Versioning] Add option number for IoTivity version

> On 9 Dec 2016, at 08:15, Dwarkaprasad Dayama > wrote: > > Hi Carsten & All, > > Think about following cases - > > - old client <-> old server > - old client <-> new server > - new client <-> old server > - new client <-> old server > > Now let's say there was change in server protocol form

[dev] [Versioning] Add option number for IoTivity version

On 9 Dec 2016, at 06:43, ??? (Uze Choi) wrote: > > Presumably, When client with updated protocol want to communicate with > server, server can detect client protocol is new one. How does the behavior of the server change based on this information? What happens if the server does not know about

[dev] [Versioning] Add option number for IoTivity version

On 8 Dec 2016, at 17:27, Ziran Sun wrote: > > versioning Hi Ziran, can you explain what problem you are trying to solve? (Versioning is often introduced in an attempt to solve problems that actually can?t be solved by versioning.) Gr??e, Carsten

[dev] Running json2cbor

Hi Gabriel, If you just need to convert json to cbor, use one of the tools for that: npm install cbor Or gem install cbor-diag The first installs json2cbor, the second json2cbor.rb Gr??e, Carsten -- next part -- An HTML attachment was scrubbed... URL:

[dev] Segmentation fault with json to cbor file conversion

I saw it in branch 1.1-rel Gr??e, Carsten Thiago Macieira wrote: > On ter?a-feira, 10 de maio de 2016 10:18:13 PDT Carsten Bormann wrote: >> There are two tools called json2cbor: >> resource/csdk/security/tool/json2cbor.c >> and >> extlibs/tinycbor/tinycbor/tools/j

[dev] Segmentation fault with json to cbor file conversion

There are two tools called json2cbor: resource/csdk/security/tool/json2cbor.c and extlibs/tinycbor/tinycbor/tools/json2cbor/json2cbor.c (Why?) Gr??e, Carsten Venkayamma Dudipally wrote: > Hi, > > > I tried to create cbor file using json2cbor provided by Iotivity-1.1.0 > release code. But I am g

[dev] Is there anybody who has seen an assertion abort of tinycbor?

I'm not sure this observation is receiving the attention it requires. Thiago is right: A protocol implementation that crashes when it receives malformed data of any kind is unacceptable. Any such bug must be fixed*). Making sure the tests only run with valid protocol data is *not* a fix. The

[dev] CBOR decoding for well-known attribute key has problems

As far as I understand this problem, the CBOR decoding is fine, but the code that makes use of the decoded information is expecting something else. Is my impression correct? Gr??e, Carsten ??? wrote: > Hi. All, > > > > I inform you of a kind of bug when a payload containing well-known > attr

[dev] POST and PUT, creating resource

SANJEEV BA wrote: > How do we distinguish between the two in IoTivity ? CoAP has inherited this ambiguity from HTTP, which also has no way to distinguish the narrower POST-as-create from the wider catch-all POST-as-an-unspecified-action. In the HTTP world, we tend to distinguish collection resour

[dev] notification on resource delete?

> Translated to OIC spec, the retrieve response with observe flag on > (i.e. a resource notification) should be issued to all observers with > the 4.04 response code, and when that is sent, all observers are also > removed? Yes, that is the idea. > I think my original observation still stands, i.

[dev] notification on resource delete?

Hi Zoltan, > I have not found in the Core spec how resource deletion should be > notified to observers. RFC 7641, section 4.2 has a SHOULD for this. (Sent from mobile, would have included link otherwise.) -- next part -- An HTML attachment was scrubbed... URL:

[dev] Fwd: Array data type problem in IoTivity.

Keane, Erich wrote: >> "rep":[ >> "sourceName": "HDMI-CEC", Not JSON. (Arrays don't have keys.) Gr??e, Carsten

[dev] tinycbor needs to be updated to at least 47a78569c0

Thiago Macieira wrote: > On Friday 21 August 2015 23:55:59 Carsten Bormann wrote: >> Thiago Macieira wrote: >>> On Friday 21 August 2015 20:31:05 Carsten Bormann wrote: >>>>> Tinycbor isn't being updated automatically since it's an external >>>

[dev] tinycbor needs to be updated to at least 47a78569c0

Thiago Macieira wrote: > On Friday 21 August 2015 20:31:05 Carsten Bormann wrote: >>> Tinycbor isn't being updated automatically since it's an external >>> library. >>> >>> To update tinycbor, run 'git pull' in 'extlibs/tinycbo

[dev] tinycbor needs to be updated to at least 47a78569c0

> Tinycbor isn't being updated automatically since it's an external > library. > > To update tinycbor, run 'git pull' in 'extlibs/tinycbor/tinycbor'. The top-level makefile should automate just that (giving the actual commit that is desired, of course, so you can do a controlled update). Gr?

[dev] TCP must be optional

Thiago Macieira wrote: > I'm seeing a few changes go about CoAP over TCP and I'm wondering what those > are for. There are two reasons why we are pursuing CoAP over TCP in the IETF: 1) CoAP is sometimes used in the IPv4 world, which means there is an ugly NAT traversal problem. With today's mos

[dev] CBOR conversion for IoTivity

Attached is a CDDL version of what I understand from that. (I?m not sure I fully understand what you mean by ?mapstart?/?mapend" and ?arraystart?/?arrayend?, but maybe this is just {} and [] from CDDL.) For laughs, I have also attached 20 messages automatically generated from this specification

[dev] [oswg] [Pat, Uze] Groups - Action Item "CBOR Comms to SWG" Closed

lists.iotivity.org [mailto:iotivity-dev- >> bounces at lists.iotivity.org] On Behalf Of Carsten Bormann >> Sent: Thursday, July 02, 2015 7:57 AM >> To: "???(June Yong Young)" >> Cc: iotivity-dev at lists.iotivity.org >> Subject: Re: [dev] [oswg] [Pat, Uze] Groups - A

[dev] [oswg] [Pat, Uze] Groups - Action Item "CBOR Comms to SWG" Closed

Maybe I should mention at I'm at this very moment integrating the technical content of draft-li-core-cbor-equivalents-00.txt into draft-ietf-core-links-json -- that should enable the use of CBOR for link-format as well. One other aspect (since I don't have access to the spec): Since you want to ge

[dev] Proposal for IP Adapter and request for feedback

Thiago Macieira wrote: > Indeed. The security team should figure out a way so that discovery can be > secured against eavesdropping. We don't have a standard way to do this (at the CoAP level). Of course, if your network uses encryption, then you already have some protection. > If that is not p

[dev] Proposal for IP Adapter and request for feedback

6LoWPAN UDP header compression also benefits if the port number you use for most of your messages is 0xf0xx (even more so if both ports are 0xf0bx). http://tools.ietf.org/html/rfc6282#section-4.3.3 It is only a byte (or three bytes) saved, but that is an easy byte to save just by choosing a port

[dev] IoTivity Arduino and ESP8266 WiFi module

Actually, even more interesting would be to use the ESP8266 as a target by itself (there is little need to add a much less powerful Arduino to that rather hefty chip). Gr??e, Carsten Wojciech Topolski wrote: > Hi All > > > > Is it possible (with current version of IoTivity for Arduino) to us

[dev] Metadata in JSON

If JSON must be accommodated, I agree with most of this. Exceot: Thiago Macieira wrote: > US-ASCII text strings You never need to transport user-visible text? (While JSON escaping is ugly, it's never needed for non-ASCII characters. You only ever need to escape code points U+ to U+001

[dev] CBOR proposal

Yes, exactly. Sent from my iPad > On 22.04.2015, at 20:16, Thiago Macieira wrote: > >{"0":"/a/light","1":["123":true,"extensionname":"#123456"]} > > Is that what you'd propose?

[dev] CBOR proposal

Just continue doing these with strings? UUIDs of course also work, but may be less useful in debugging as wireshark won't know them for the custom case. Sent from my iPad > On 22.04.2015, at 20:03, Thiago Macieira wrote: > > How would you propose for custom extensions?

[dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence

???(Uze Choi) wrote: > There is already draft for this in Conditional observe in CoAP. > https://tools.ietf.org/html/draft-li-core-conditional-observe-02 > > How about to implement it into the IoTivity. This will enable various > usecases. Hi Uze, several proposals have been made over the past c

[dev] Arduino Uno U3 support of IoTivity 0.9.0

GyeongHwan Hong wrote: > Could IoTivity 0.9.0 be squeezed into Uno's 2KB SRAM and 32KB flash memory? Some subset maybe, but once you add essential components such as security, no longer. When setting expectations here, it may be useful to reference RFC 7228 [1]. This identifies some clusters of

[dev] Timing issue in handling COAP request in HandleCoAPRequests

I didn't do the code dive yet, so I don't understand why there are two sockets (me not understanding doesn't mean it's wrong). If one is for unicast and one for multicast, I'd rather reply to the multicast on the multicast socket. The unicast socket should then simply ignore packets sent to the

[dev] Timing issue in handling COAP request in HandleCoAPRequests

Chandan wrote: > HI ALL > > Can we have below approach for solving this issue? > > If a server does decide to respond to a multicast request, it should >not respond immediately. Instead, it should pick a duration for the >period of time during which it intends to respond. For the purp

[dev] Timing issue in handling COAP request in HandleCoAPRequests

Hi Pat, Lankswert, Patrick wrote: > Where supported IPV6_RECVPKTINFO is a nice alternative where it is supported, Yes, but only where it is supported :-) (In my parts of the woods it's near universal, but I'm not even close to having the widest range of systems available to me). > but the last

[dev] Timing issue in handling COAP request in HandleCoAPRequests

I didn't dive into the code yet, but it looks a lot like a symptom of binding a UDP socket to INADDR_ANY. For receiving unicast packets, this is almost always wrong, for two reasons: -- you won't have a way to reply from the same source address, -- you are receiving multicasts without knowing it.