Good to know. Since the draft you mention has turned into a working group draft quite some time already, I would be interested in input what would need to be changed to obtain compatibility.
Gr??e, Carsten Lankswert, Patrick wrote: > Carsten, > > Although the standards folks have taken guidance from > draft-bormann-core-links-json, the link format in JSON for OIC does not > adhere to the draft and not compatible. They have also made it the default > format of OIC. > > Pat > >> -----Original Message----- >> From: iotivity-dev-bounces at 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 - 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 get link-format in JSON, is it written up that an >> appropriate >> Accept Option needs to be present in the request? >> (If it isn't, a server will have to send/ a client will get RFC 6690 >> link-format.) >> >> Gr??e, Carsten >> >> >> ???(June Yong Young) wrote: >>> Thiago, >>> >>> >>> >>> I?d just like to confirm one thing. >>> >>> My understanding from your explanation is if there is someone to wants >>> to use JSON, >>> >>> then it is very easy to add JSON parser and use it based on current >>> IoTivity API implementation. Is this correct? >>> >>> >>> >>> And Dwarka will check if the line in red in Core Spec will be changed >>> in SWG. >>> >>> >>> >>> 10.2 CoAP based Endpoint discovery 12 >>> >>> The following is the description of CoAP based Endpoint discovery: 13 >>> >>> a) All advertising or publishing OIC Devices shall join the ?All CoAP >>> Nodes? multicast group, i.e. 14 224.0.1.187 for IPv4 and FF0X::FD for >>> IPv6 and listen on the port ?5683?. 15 >>> >>> a) The OIC Client that wants to discover resources shall first join >>> the ?All CoAP Nodes? multicast 16 group. 17 >>> >>> b) Then the OIC Client shall send a discovery request (GET request) to >>> the multicast group ?All 18 CoAP Nodes? and port 5683 where the URI in >>> the request shall be /oic/res. 19 >>> >>> c) It shall use the Query mechanism (section 6.2.1) with key ?rt? and >>> the wanted target as value 20 of rt 21 >>> >>> d) When ?rt? Query key is omitted all OIC Devices shall respond to >>> that request 22 >>> >>> e) The considerations for handling multicast requests shall be as >>> described in section 8 of 23 IETF RFC 7252 and section 4.1 in IETF RFC >>> 6690 apply. 24 >>> >>> *f) The OIC Devices that receive this request shall respond in JSON >>> which is in conformance to 25 the JSON schema. In later versions of >>> the specification other formats could be included (e.g., 26 XML/EXI)* >>> >>> >>> >>> >>> >>> June Yong Young >>> >>> OIC Open Sourece WG Project Planning & Requirement TG Chair >>> >>> IoTivity Release Function Lead >>> >>> >>> >>> Samsung Electronics Co.,Ltd. >>> >>> Software R&D Center, IoT Solution Lab. | Web & Convergence Team >>> >>> Principal Engineer >>> >>> >>> >>> T: +82-31-301-6107, M: +82-10-9530-6107 >>> >>> E-mail :juney at samsung.com >>> >>> >>> >>> -----Original Message----- >>> From: Thiago Macieira [mailto:thiago.macieira at intel.com] >>> Sent: Wednesday, July 01, 2015 9:16 AM >>> To: Keane, Erich >>> Cc: uzchoi at samsung.com; Lankswert, Patrick; >>> iotivity-dev at lists.iotivity.org; dwarka.dayama at samsung.com; >>> juney at samsung.com >>> Subject: Re: [oswg] [Pat, Uze] Groups - Action Item "CBOR Comms to SWG" >>> Closed >>> >>> >>> >>> On Tuesday 30 June 2015 16:50:59 Keane, Erich wrote: >>> >>>> The result is a significantly simpler implementation for the >>>> consumers >>>> of the CSDK, since they don't have to worry about parsing the JSON, >>>> just getting said data out of the OCPayload object-model. There are >>>> a >>>> collection of helper methods (see ocpayload.h) to help get the data out. >>> >>> >>> Note that this technically abstracts the representation and could >>> allow, if we wanted to, to have other encodings besides CBOR. >>> >>> >>> >>> There are no plans to add those encodings. >>> >>> -- >>> >>> Thiago Macieira - thiago.macieira (AT) intel.com >>> >>> Software Architect - Intel Open Source Technology Center >>> >>> _______________________________________________ >>> iotivity-dev mailing list >>> iotivity-dev at lists.iotivity.org >>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev >> _______________________________________________ >> iotivity-dev mailing list >> iotivity-dev at lists.iotivity.org >> https://lists.iotivity.org/mailman/listinfo/iotivity-dev > >
