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.
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
> > > < <mailto:thiago.macieira at intel.com> 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 - <http://www.avg.com> www.avg.com
> Version: 2016.0.7497 / Virus Database: 4545/11971 - Release Date:
> 04/06/16
-------------- next part --------------
HTML ?????? ??????????????...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160408/93900023/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 109627 bytes
Desc: ?????? ?? ????????.
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160408/93900023/attachment.png>
