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
