Subject: [core] Question filtering

From: "Berta Carballido" <[email-masked]>
Date: Fri, 17 Aug 2012 17:08:00 +0100

Dear all,

I was reading the main coap draft to find out how to correctly interpret an ampersand in a query and I am still in doubt.

Should the ampersand be treated as AND or OR?

Thanks,
Berta.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yusuke DOI
Sent: 16 August 2012 04:14
To: Bert Greevenbosch
Cc: [email-masked]
Subject: Re: [core] A question on handling of option parameters defined in HTTP

Dear Bart,

Thanks for the comments. I feel anxous again about 'ct number per content-type and any parameter combination' approach.

> I think we need to be careful about bulk assignments though, as it should not be easy to occupy large blocks that afterwards remain unused. So if we go this way, we should consider some IANA guidelines and extra requirements for bulk assignments.

As the space is for content-type parameters and combination of parameters (it may corresponds to anything), it may not be observable how many combinations are actually used.

> Another question is if the client and server can remain oblivious of the distinction between the base content type and the parameters. One of the main usages of the content type is the "accept" option, where the client indicates the acceptable content types to the server. Currently, if the client can accept multiple content types, it will include one option for each content type. But if we allow to split the content type in base and parameters and bulk assignment, do we also need to adjust the semantics of the "accept" option to allow bulk acceptance?

Ouch. I don't think this should happen. Because parameters could be anything, I think it's too difficult to define a general behavior to distinct generic ct and specific ct.

If it's not too late, I'll write up some proposal draft(s) for arbtrary parameter option (by number and by string).

Yusuke

(2012-08-14 09:59), Bert Greevenbosch wrote:
> Hi Yuseke, Carsten, all,
>
> I can see some value of having a larger content type id space, with a suffix mechanism for application specific parameters. I guess extending the value space is easily done by allowing more bytes in the Content-Type option and adjusting the description of the "ct" attribute.
>
> I think we need to be careful about bulk assignments though, as it should not be easy to occupy large blocks that afterwards remain unused. So if we go this way, we should consider some IANA guidelines and extra requirements for bulk assignments.
>
> Another question is if the client and server can remain oblivious of the distinction between the base content type and the parameters. One of the main usages of the content type is the "accept" option, where the client indicates the acceptable content types to the server. Currently, if the client can accept multiple content types, it will include one option for each content type. But if we allow to split the content type in base and parameters and bulk assignment, do we also need to adjust the semantics of the "accept" option to allow bulk acceptance?
>
> B.T.W. in the current version of CoAP, the content type and media type seem to be the same thing. Is there a reason to use two different terms?
>
> Best regards,
> Bert
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of DOI Yusuke
> Sent: 13 August 2012 17:56
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [core] A question on handling of option parameters 
> defined in HTTP
>
> Carsten,
>
> 3 or 4 bytes seems to be enough in this case.  I can agree on your 
> idea to loosen the 16-bit length limit of content type id.
>
> I guess the assignment could be something like IP address prefix 
> assignment.  Then ct registry could be something like this:
>
>     ...
> - application-example.net-exi 0x00f3.1000-0x00f3.1fff
> - application-example.org-exi 0x00f3.2000-0x00f3.2fff
>     ...
> - application-very.large.example.com-exi 0xf000.0000-0xf000.ffff
>
> In terms of fairness and efficiency, I guess block assignment should 
> be done on some larger number (not from 256). My idea is to assign 
> larger block on larger number zone, smaller block on smaller number 
> zone (as shown above). Selfish bulk assign request should pay cost for
> (slightly) larger packet, isn't it?
>
> // Yusuke DOI <[email-masked]>, TOSHIBA R&D Center
>
> From: Carsten Bormann <[email-masked]>
> Subject: Re: [core] A question on handling of option parameters 
> defined in HTTP
> Date: Mon, 13 Aug 2012 08:10:42 +0200
>
>> On Aug 13, 2012, at 07:22, DOI Yusuke <[email-masked]> wrote:
>>
>>> Is 16 bit space enough or not for
>>> parameterized content types?
>>
>> Good question.
>> There is no strong reason to stay within 16 bits, so if we foresee a strong demand we could extend this to, say, 3 bytes.
>> (We also may want to reserve some space to continue the experiment 
>> under http://svn.tools.ietf.org/svn/wg/core/mediatypes.txt if people 
>> find that useful.)
>>
>> There is also a question how well IANA will be able to handle such a large registry.
>> AFAIK, so far the largest registry is http://www.iana.org/assignments/enterprise-numbers with some 40000 entries.
>> But the media type registry would likely be allocated in chunks, so it might be less onerous.
>>
>> Grüße, Carsten
>>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 17 Aug 2012 19:38:00 +0300

Hi Berta,

> Should the ampersand be treated as AND or OR?

If you are referring to filtering .well-known/core, then RFC6690 says
that there must be only one name/value pair in the query string
(section 4.1).

If you are referring to query strings in coap: URIs in general, then
there are no filtering semantics attached to them. The ampersand just
separates the arguments that parametrise the resource. It's up to the
resource what representation is returned for different arguments and
the order in which they appear.

Klaus