For what its worth, I remember this decision from when it happened. I thought that only supporting ONLY ';' for a separator was foolish, since 99% of the world uses '&' I'd made the decision at the time (I was the active sub-maintainer) to always parse BOTH & and ; but only produce ';'. I figured that it would give us standards compliance without sacrificing compatibility with other tools.
As far as I know, ; and & should be valid inputs, but ; will always be produced. -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ???(Uze Choi) Sent: Sunday, April 10, 2016 7:33 PM To: Macieira, Thiago <thiago.macieira at intel.com>; 'Dave Thaler' <dthaler at microsoft.com>; 'Mitch Kettrick' <cpm at openconnectivity.org>; cftg at openconnectivity.org; iotivity-dev at lists.iotivity.org Subject: Re: [dev] [cftg] Use of ';' as query separator vs CoAP Hi Thiago, I've tested it with following inputs, C++-QueryMap [{attribute1,value1},{attribute2,value2}] C++- QueryString ?attribute1=value1&attribute2=value2 C- QueryString ?attribute1=value1;attribute2=value2 Same air packet from Wireshark, ?attribute1=value1&attribute2=value2 Queryslit happen with OC_QUERY_SEPARATOR which include ; and & together. Everywhere ; & are used together for parsing. I think you are think about it. BR, Uze Choi -----Original Message----- From: cftg at openconnectivity.org [mailto:[email protected]] On Behalf Of Macieira, Thiago Sent: Saturday, April 09, 2016 10:19 AM To: ???(Uze Choi); 'Dave Thaler'; 'Mitch Kettrick'; cftg at openconnectivity.org; iotivity-dev at lists.iotivity.org Subject: RE: [cftg] Use of ';' as query separator vs CoAP Hi Uze Sorry, I don't think you're correct. Have you actually tested this? I admit I haven't, my conclusion is based only on reading the code. I've seen code that splits on both ";" and on "&". It's possible this is dead code and is unused, but it's there. ________________________________ From: ???(Uze Choi) [[email protected]] Sent: Thursday, April 07, 2016 23:22 To: 'Dave Thaler'; Macieira, Thiago; 'Mitch Kettrick'; cftg at openconnectivity.org; iotivity-dev at lists.iotivity.org Subject: RE: [cftg] Use of ';' as query separator vs CoAP Thiago, For your question, IoTivity works as follows, so there is no problem. oic://<deviceID>/switch?filter=state=ON&colour=0;if=oic.if.baseline -> /switch?filter=state=ON&colour=0&if=oic.if.baseline Mitch, Theoretically, no issue in the air so no issue from certification perspective. If something strange happen this is orthogonal from this argument. This diagram is the IoTivity analysis regarding query param. Some small issue from C api perspective. If & is preferred, we can guide to use & instead of ;. I believe specification perspective, & is work because packet in the air only show &. This is purely IoTivity API issue. [cid:image003.png at 01D191AA.872CC0E0] BR, Uze Choi -----Original Message----- From: cftg at openconnectivity.org [mailto:[email protected]] On Behalf Of Dave Thaler Sent: Thursday, April 07, 2016 10:43 PM To: Macieira, Thiago; Mitch Kettrick; cftg at openconnectivity.org Subject: RE: [cftg] Use of ';' as query separator vs CoAP The use of & to separate name/value pairs in the query string is pretty standard and APIs exist on various platforms to make it easy. By oic URIs choosing not to use it according to the normal convention, we're making it much harder for implementations, and more error prone. Given that IoTivity does not implement oic URIs as far as I can tell so there's no back compat issue there, I would much prefer changing oic URIs to use & and use a different separator (or escaped &) within a filter. Dave > -----Original Message----- > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On > Behalf Of Macieira, Thiago > Sent: Thursday, April 7, 2016 1:26 AM > To: Mitch Kettrick <cpm at openconnectivity.org>; > cftg at openconnectivity.org > Subject: RE: [cftg] Use of ';' as query separator vs CoAP > > Hi Mitch > > I'd say so, but it's not a high priority. > ________________________________________ > From: cftg at openconnectivity.org [cftg at openconnectivity.org] on behalf > of Mitch Kettrick [cpm at openconnectivity.org] > Sent: Wednesday, April 06, 2016 18:54 > To: Macieira, Thiago; cftg at openconnectivity.org > Subject: RE: [cftg] Use of ';' as query separator vs CoAP > > Hi, > > FYI, currently we are not testing multiple query parameters in the > same message. We do "if" and "rt" queries separately but we do not > combine them. > Is this something that we should be testing? Keep in mind > > Mitch > > -----Original Message----- > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On > Behalf Of Thiago Macieira > Sent: Wednesday, April 06, 2016 12:15 PM > To: cftg at openconnectivity.org > Subject: Re: [cftg] Use of ';' as query separator vs CoAP > > Hi Ravi > > The encoding or lack of encoding in the "filter" value is out of our > hands, regardless of what separator we used. > > The CoAP protocol specifies that all %-encoded values must be decoded > before being placed in the header. So the payload would include it in > decoded form anyway. > > So the OIC URI > > > oic://<deviceID>/switch?filter=state=ON&colour=0;if=oic.if.baseline > > When transmitted over CoAP, the header would contain the equivalent of: > > /switch?filter=state=ON%26colour=0&if=oic.if.baseline > > Am I understanding it correctly? > > PS: I'm pretty sure IoTivity today will fail to parse the OIC URI with > & in the filter above. > > On quarta-feira, 6 de abril de 2016 11:54:26 PDT Subramaniam, Ravi wrote: > > Hi Thiago, > > > > The answer is yes i.e. map ; to & for CoAP. The intent for ; is so > > as not to require encoding for & in 'filters'. > > > > This should not be an issue because the CoAP message format allows > > separation as you have pointed out. > > > > As u say no change with only clarifications required. > > > > Ravi Subramaniam > > Principal Engineer > > Intel - (408) 765-3566 > > > > > On Apr 6, 2016, at 11:34 AM, Thiago Macieira > > > <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> > > > wrote: > > > > > > I've just noticed on Ravi's presentation on the Developer Day that > > > the OIC > > > > > > URIs use ';' for query separators. Example: > > > oic://<uuid>/a/switch?if=oic.if.baseline;rt=oic.binaryswitch > > > > > > When we encode such a query in CoAP, we're splitting at the ';' in > > > order to > > > > > > send CoAP header "Uri-Query". That is, the above URI is sent as: > > > Uri-Path: a > > > Uri-Path: switch > > > Uri-Query: if=oic.if.baseline > > > Uri-Query: rf=oic.binaryswitch > > > > > > Which, according to section 6 of RFC 7252 (CoAP URIs), implies a > > > CoAP > URI: > > > coap://<host>/a/switch?if=oic.if.baseline&rt=oic.binaryswitch > > > > > > This was not a question and is not in dispute. This was a > > > statement of fact. > > > > > > Question: do we want that interpretation of a CoAP URI? In other > > > words, should we understand that when a OIC URI is converted to > > > CoAP, > the ';' > > > query separators become '&' ? > > > > > > If the answer is "yes", there's no change required in any > implementation. > > > There's simply a change of understanding, possibly with added > > > wording of the OIC-to-CoAP protocol mapping document that this > > > transformation is required. > > > > > > If the answer is "no", then what do we want to change? > > > > > > Option 1: keep ';' in the CoAP URI, which means that OIC devices > > > must > > > change> > > > the wire protocol and send a single Uri-Query header containing: > > > if=oic.if.baseline;rt=oic.binaryswitch > > > > > > This implies changes to the implementations, to the protocol (in a > > > non- backwards compatible mannder) and most likely will increase > > > the processing required in servers. > > > > > > Option 2: change the OIC URI to use '&' as separators. This > > > implies a change in spec, but no change in implementations. > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com<http://www.avg.com> > Version: 2016.0.7497 / Virus Database: 4545/11971 - Release Date: > 04/06/16 _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
