Re: [core] A question on handling of option parameters defined in HTTP

Hi Yuseke, all,

I have reviewed your "draft-doi-core-parameter-option" document. I realise that this idea still needs to ripen, so I hope the following questions can help getting a clearer view on the proposed mechanism:

(1) In section 2.2, the server can accept any rate, whereas the client chose the rate 32500 and signals it through the content-type. How did the server indicate the acceptable rates to the client?

(2) In the other direction, how can the client indicate acceptable parameters to the server?

(3) What is the rationale behind the "oid" field? I understand that it is for indexing the option-parameters. Does that mean that a content-type "some/content-type;par1=8;par2=9" would have two "Option-Parameter" options, in which the one for par1 has "oidx=0" and par2 "oix=1"?

(4) For the "value" field, I guess you propose to use a text string with the same content as the "value" field from RFC 2045?

(5) Why do you define 3 "Option-Parameter" options? What is the related implementation complexity, and how does having three separate options resolve it?

(6) To avoid confusion with CoAP options, would it be helpful to rename "Option-Parameter" to "ContentType-Parameter"?

I see value in content type parameters, especially as HTTP already supports a similar mechanism. So I look forward to discuss more about how this could be reflected by CoAP.

Best regards,
Bert

---
Bert Greevenbosch M.Sc.
Senior Research and Standardisation Engineer

email: bert.greevenbosch@huawei.com
telephone: +86-755-28978760

HUAWEI TECHNOLOGIES CO.,LTD.
Building F1 / Floor 8
Huawei Industrial Base
Bantian, Longgang District
Shenzhen  518129
P.R. China

*******************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
******************************************************************************

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of DOI Yusuke
Sent: 22 August 2012 12:48
To: hartke@tzi.org
Cc: core@ietf.org
Subject: Re: [core] A question on handling of option parameters defined in HTTP

Hi Klaus, and all,

As a weekend work, I wrote a draft and just submitted as proposal to
solve parameter problem in some use cases.  (including my EXI
content/schema negotiation)

>	Title           : CoAP Option Parameter Option
>	Author(s)       : Yusuke Doi
>	Filename        : draft-doi-core-parameter-option-00.txt
>	Pages           : 7
>	Date            : 2012-08-21

Any comments are appriciated. 

A trick is to make three options with identical functionarity
(Parameter-Option 1, 2, 3). This is because parameter options need
index to another option, and calculation of option index could be
dirty code if the parameter option is before the other option. I think
there was rough agreement to make three partitions of option number in
the last F2F, I made a parameter option per partition.

A concern is to have complex data type (1-octet integer, 2-octet
integer, string). I don't know other options with complex type. Is
there any reason to avoid it?

Regards,

// Yusuke DOI <yusuke.doi@toshiba.co.jp>, TOSHIBA R&D Center

From: Klaus Hartke <hartke@tzi.org>
Subject: Re: [core] A question on handling of option parameters defined in HTTP
Date: Mon, 20 Aug 2012 12:34:11 +0300

> Yusuke DOI wrote:
> > If it's not too late, I'll write up some proposal draft(s) for arbtrary
> > parameter option (by number and by string).
> 
> I think it would be a good idea to explore this a bit. Maybe don't go
> into details yet, just describe the the problem, give a few motivating
> examples, and outline your solution. Doesn't have to be a draft if
> it's not too long.
> 
> 
> Klaus
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core