TDD Thing Model is missing contentType in response objects

[JKRhb]

Experimenting with discovery from TDDs, I noticed that a TDD implementation that adheres to the currently defined Thing Model for the API specification ends up generating a Thing Description that is not valid according to the TD specification. That is because a form like the following does not define a contentType for its response member, causing an instantiated TD to be invalid if no contentType is explicitly added by the TDD:

{
    "href": "/things/{id}",
    "htv:methodName": "PUT",
    "contentType": "application/td+json",
    "response": {
        "description": "Success response",
        "htv:statusCodeValue": 201
        // No contentType defined!
    },
    "additionalResponses": [
        {
            ...
        }
    ]
}

As also discussed in w3c/wot-thing-description#1776, having no contentType seems reasonable to me here – however, if a discovery validates a TDD's Thing Description, then it is rejected in its current form.

Would it be a possible workaround to add application/octet-stream for cases like these? Or is there maybe a better alternative?

[mmccool]

Can't add an assertion, at most can add an informative statement. Worst case, we mention the above workaround using application/octet-stream.

[farshidtz]

A content type should not be needed when there is no content (no HTTP body). Enforcing that on directories would be really strange.

See also:

• https://stackoverflow.com/questions/29784398/should-content-type-header-be-present-when-the-message-body-is-empty
• https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
• https://stackoverflow.com/questions/22326994/is-there-a-standard-null-mime-type a comment suggests using application/x-empty.

I suggest we wait and hope that contentType becomes optional in an upcoming TD spec patch.

[JKRhb]

I fully agree with you, @farshidtz. I opened w3c/wot-thing-description#1780 in the TD repository in order to discuss a possible solution there.

[mmccool]

It looks like making this optional is not going to happen in the current spec, as it would be a normative change which is not possible in CR. The referenced issue is marked as "Defer to TD 2.0".

So we will have to go with the "strange" option, but as an informative note. Suggest adding an informative comment (not an ed note, just a normal sentence) like the following:

Note that a contentType is required by the WoT TD 1.1 specification for ExpectedResponse, even when the body is empty.
In this case, "application/octet-stream" can be used to ensure that the TD is valid.

@JKRhb will prepare a PR (and decide where a suitable place to insert this would).