Correct Structuring of HTTP Header fields in Forms

[egekorkan]

Currently, we put HTTP header-related information in the vocabulary table at https://w3c.github.io/wot-binding-templates/bindings/protocols/http/#http-vocabulary-terms by taking them from https://www.w3.org/TR/HTTP-in-RDF10/ . However, it is not clear how these headers should look like in a TD when we think of content negotiation. With CoAP, we also support content negotiation since we defined our own ontology. If I want to say that the Thing requires a CBOR input but will deliver a response in JSON, it is not clear how we should structure the TD. This is also a case where there are multiple response and request content types possible (e.g. the request and response can be in JSON or CBOR). Below are some examples:

1. What is implied (but not documented) by the current binding template:

{
  "href": "something",
  "contentType": "application/cbor",
  "response":"application/json",
  "op": "readproperty",
  "htv:methodName": "POST",
  "htv:headers": [
    {
      "@type":"htv:RequestHeader",
      "fieldValue": "application/json", // what the Consumer wants. 
      // Same as response field above but this is a directive for the
      // Consumer otherwise the Thing can reply with another content type
      "fieldName": "Accept"
    },
    // the two below are implied by the values above
    {
      "@type":"htv:ResponseHeader",
      "fieldValue": "application/json", // what the Thing is going to send, same as response field above.
      "fieldName": "Content-Type"
    },{
      "@type":"htv:RequestHeader",
      "fieldValue": "application/cbor", // what the Consumer should send, same as contentType field above.
      "fieldName": "Content-Type"
    }
  ]
}

2. What would be nicer:
   The array structure is quite annoying to parse so here are some alternatives:

{
  "href": "something",
  "contentType": "application/cbor",
  "response":"application/json",
  "op": "readproperty",
  "htv:methodName": "POST",
  "htv:RequestHeaders":{
      "Accept":"application/json",
      "Content-Type":"application/cbor", // again not really needed
      "@type":"htv:RequestHeader" // this is not mandatory?
  },
  "htv:ResponseHeaders":{
    "Content-Type": "application/json" // again not really needed
  }
}

The issue I see (probably the design behind HTTP in RDF) is that when we list possible headers as keys and if we are strict about it, then we will need to list all the possible headers in HTTP...

@mahdanoura could you provide your opinion based on whether my ideas fit well to the HTTP in RDF document?
@JKRhb since you have designed the CoAP content negotiation, your opinion is also very welcome :)