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

[Yusuke DOI <[e-mail]>]

Hi Bert,

Thanks for your review.

> (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?

This (server-to-client node/resource capability notification) is beyond the scope of this document. In (only) HTTP, I guess no standard way is defined. The client may try to POST rate 32500 anyway to find it is acceptable or not. If an application uses DNS-SD, the TXT RR could be good place to describe server capability. In CoAP, I guess it could be done with the link format. I've heard Kerry is working on the issue (draft-lynn-core-discovery-mapping).

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

Client can send Accept option with appropriate parameteras it sends GET request 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"?

It's index of the option in the CoAP message.
A  CoAP message may have the following options:

CON GET
[0]Uri-Host: "example.org"
[1]Uri-Port: 15683
[2]Uri-Path: "example.exi"
[3]Accept: example-exi (is an imagenary content-type for an example application with schema-informed EXI encoding)
[4]Accept: example+json (same as above, with JSON)
[5]Option-Parameter1: 3,9,"5" (aid=9 means "level")
[6]Option-Parameter1: 4,2,"0.8"  (aid=2 means "version")

In the first Option-Parameter1, its oidx=3. This parameter is for the option with index [3]. This is
  Accept: example-exi;level=5
The second one is
  Accept: example+json;version=0.8

Since this index is fragile to option add/remove, this is not a proxy-safe option.

> (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?

I guess UTF-8 should be 'modern way'. I have no strong opinion on it. It could be RFC2045-style, UTF-8 string, and opaque octets.


(let me change the order of your question)
> (6) To avoid confusion with CoAP options, would it be helpful to rename "Option-Parameter" to "ContentType-Parameter"?

I agree.

At first, I have been thinking the parameter is also usable for other options. But while thinking through your review, I noticed it's confusing to have generic option parameters because the same semantics could be expressed in different manner in CoAP options. For example, content preference among multiple Accept-able content type is described by the order of options. It may be harmful to have "q" parameter (the same semantics in HTTP) to CoAP.

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

This is because I didn't want adding a parameter BEFORE its target.

The oidx of Option-Parameter points another option ('target') by the order in the packet. If I need to put parameter options before the target, I need to wait for the header building process to decide the oidx field.

However, as I agreed on (6), if this option only points to Content-Type and Accept header, a option number larger than Accept option is enough. Or, separate option for parameter of Content-Type and parameter of Accept could be a good idea because Content-Type does not need oidx.

Regards,

// Yusuke DOI <[e-mail]> Corporate R&D Center, TOSHIBA Corp.

(2012-08-23 10:31), Bert Greevenbosch wrote:
> 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: [e-mail]
> telephone: [phone]
>
> 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!
> ******************************************************************************
>
>