Consider removing section 8.3.1 Protocol Binding based on HTTP in version 1.1

[benfrancis]

Consider removing section 8.3.1 Protocol Binding based on HTTP. See w3c/wot#996 (comment)

[egekorkan]

I guess that instead of removing, you mean that if it is in the exact same way in the core profile, it should be linked to it right?

[benfrancis]

See the discussion in w3c/wot#996 (comment) and w3c/wot-binding-templates#135.

The Core Profile goes way beyond just defining default HTTP verbs and is only suitable for greenfield devices which comply with the whole profile. There may be an argument for keeping a simpler set of defaults for devices which don't conform with the core profile, but the point is currently those defaults are duplicated in three places and easily get out of sync with each other.

I don't think the Thing Description specification should include all the defaults from the Core Profile, but it may link to a set of defaults in the WoT Protocol Binding Templates specification, or vice-versa.

[sebastiankb]

From a historical perspective, we introduced the first http-based binding in the TD specification because the binding document was not stable at that time. (around 2-3 years ago). Since the situation changed we can indeed think about moving parts of the section to the http binding document and remove the rest which is kind of redundant.

[JKRhb]

Similar to #1274, this issue is rather related to the organization of the WoT specifications and not necessarily use-case-related.

[egekorkan]

As identified in #2006 , this is one of the points to address in the refactoring work. I have compared the relevant section in TD (https://w3c.github.io/wot-thing-description/#http-binding-assertions) with the HTTP Binding Template (https://w3c.github.io/wot-binding-templates/bindings/protocols/http/) and identified the following differences:

1. TD mentions the default inclusion of the HTTP vocabulary in the TD Context. We need to discuss if we should continue doing this.
2. TD mentions the default mechanism with an assertion When no method is indicated in a form representing an Protocol Binding based on HTTP, a Default Value MUST be assumed as shown in the following table. This should be moved to HTTP Binding document. I have thought of having a generic assertion about this but we would test each binding on its own and should have a corresponding assertion in each document.
3. TD default values table have methods in the first column with multiple operations on the right cell. The way it is done in the binding makes more sense to me, i.e. mapping an operation to the method.
4. TD has an example that shows default values insertion
5. TD has an assertion (but not RFC!) saying In the case of a forms entry that has multiple op values the usage of the htv:methodName is not permitted. This should be turned to a real assertion in binding and also should be mentioned in a generic way in the binding registry as it applies to all protocols. This also has a corresponding interactive example.
6. Binding has fieldName and fieldValue in the vocabulary term table. This should be kept.
7. Binding has sequence diagram examples. I see some issues with WebSocket examples since an unsubscription is not necessarily disconnecting the connection. Otherwise they are fine.
8. Binding refers to TD1.0 REC instead of 1.1