Profile requirements

[mlagally]

A set of profile requirements was already collected and discussed in the Architecture TF in 2020.

https://github.com/w3c/wot-usecases/blob/main/REQUIREMENTS/profile-requirements.md

All additional requirements by TF members should be added to this issue to make sure they get addressed.

[benfrancis]

@mlagally Aha, I've been looking for this! Thank you for sharing the link.

I note that there are no "accepted requirements" in that document and some of them only have a single supporter. Was a process ever defined for agreeing on final requirements? I agree with all the use cases and most, but not all, of the proposed requirements (the devil is in the details). As an Invited Expert I'm not sure how best to express support or otherwise for different requirements since the current supporters are all companies and my company is technically not a W3C member. Also, can proposed requirements only be "supported" and not "opposed"?

I also recall that at the time these requirements were originally discussed my contribution was to refer to the set of proposed requirements defined in the Web Thing Protocol Use Cases & Requirements Draft Community Group Report, in particular the proposed requirements for an HTTP sub-protocol. I'm not exactly sure whether or how best to contribute those requirements (or a subset of them) since they are much more detailed and granular than the high level requirements in the document you linked to.

I think we may have identified the root cause for the lack of a shared understanding of the requirements of the WoT Profile specification. It's a bit concerning to still be discussing requirements at this stage of the publication timeline, but I'm happy to contribute in any way that is helpful to resolve that.

[mryuichi]

”profile-requirements.md” was a summery of the early discussion for Profile document, but I think it covers the necessary requirements. There is nothing to add to this at this moment.
As I commented in #152 (comment), I think human readability is important. Fujitsu will also support it.

[k-toumura]

I'm particularly support:

• multiple profiles
• composable profiles
• identification of profiles.

(This does not mean that I do not support other requirements.)

Since it is unlikely that a single "Core" profile can cover all use cases, it is desirable to have a composition of multiple (but not too many) profiles to cover a variety of use cases.

For example, if we have profiles such as:

• HTTP/JSON profile
• CoAP/CBOR profile
• Human readability profile
• Class-0...6 device profile

We can compose them, for example:

• In a very constrained environment, select CoAP/CBOR + Class-0 device profile
• In a cloud environment, select HTTP/JSON + Human readability + Class-6 device profile

Consumer/Thing developer can also clarify which profile each implementation conforms to. This making interoperability easier.

[benfrancis]

For the record...

Interoperability

✔️ Support, with a caveat

I broadly support this requirement as being the primary requirement of the specification.

One slight caveat is "should be able to correctly interact with all affordances of the Thing such a TD describes" may prevent Things from providing Forms using other protocols in addition to those covered by the Profile. I think a Thing should be able to conform with multiple profiles and also expose additional Forms outside of a profile (e.g. provide both both HTTP and CoAP protocol bindings, or provide a WebSocket endpoint in addition to HTTP), as long as the requirements of the profile are also met.

Limit and reduce complexity

✔️ Support, with a caveat

I agree that profiles should in general reduce implementation complexity, but not that all profiles should necessarily have to "Limit storage and bandwidth requirements" and "Use finite (maximum) resources".

Ambiguities

✔️ Support, within limits

I broadly support this requirement, though it is open to a lot of interpretation. For example, I agree with specifying particular HTTP verbs in a protocol binding, but requiring that all profiles follow the same semantic ontologies would be a problem.

Human readability

❌ Oppose

I think this should be addressed through recommendations in the Thing Description specification, not constraints in profiles.

Developer guidance

✔️ Support

Multiple profiles

✔️ Support, within limits

I support this, but with strict limits.

Good reasons for adding an additional profile would be:

1. Existing profiles can't be implemented by some devices due to resource constraints
2. Existing profiles can't be implemented under certain deployment models

Bad reasons for adding additional profiles would be:

1. To add requirements specific to a particular application domain, e.g. smart home, industrial, medical (preventing interoperability between application domains)
2. To define a profile specific to a particular brand, manufacturer or platform

Composable profiles

✔️ Support, with clarifications

I support this requirement in the sense that a Thing should be able to conform to multiple profiles. I would caution against "composable" meaning that certain profiles can be composed of other profiles (like with Thing Models), but I don't think that's the intention here. I disagree with the "home" vs. "industrial" examples given here.

Validatible TDs

✔️ Support

Identification of profiles

✔️ Support

Profile should define a finite set of features and capabilities to implement by the consumer.

✔️ Support, with a caveat

Support, with the caveat above about Things being allowed to support other protocols in addition to those required by a Profile.

Limit resource consumption

❌ Oppose, with a caveat

I disagree that all profiles should have to focus on limiting resource consumption, but it's fine for some profiles (e.g. a "constrained profile") to meet this need.

Follow Security and Privacy Best Practices

✔️ Support, with a caveat

Subject to a review of the actual best practices recommended.

Developer Mode

❌ Oppose

I think there are circumstances under which "nosec" is an acceptable security scheme in production too.

---

In summary, whilst this set of high level requirements is a good start

1. I don't agree with all of them
2. There are some which are not as simple as just "support" or "oppose" because I think they need further refinement
3. These high level requirements are open to a lot of interpretation and could be broken down into much more detailed requirements

Something which might help would be to separate the requirements into:

1. Requirements which apply to all profiles or the profiling mechanism itself
2. Requirements which only apply to certain profiles

[relu91]

Providing my support on the requirements list:

Interoperability

🟩 Support

Limit and reduce complexity

🟨 Support, with a caveat

At first, I was thinking of not supporting this requirement because I think it might be used as an argument to introduce an unlimited amount of out-of-band information in the profile spec. If you thinking about it the simplest TD just contains meta-data with no form at all. However, if the scope of the requirement is better defined or limited to the two points on the text:

1. require only JSON processing
2. simplify thing description to have fewer variations (with an explanation of what a variation is )

I would support it. I also rather keep out Limit storage and bandwidth requirements and Use finite (maximum) resources.

Ambiguities

🟨 Support, with a caveat

I agree with @benfrancis this requirement is a little too broad to really actually agree on. Plus it may have overlapped with the interoperability requirement. I think the problem is that it just contains examples but not a definition.

Human readability

🔴 Oppose

As stated on different occasions I think this requirement should be moved to TD as a set of linting rules for Thing Description documents.

Developer guidance

🟩 Support

Multiple profiles

🟨 Support, with a caveat

I support this, but with strict limits.
Good reasons for adding an additional profile would be:

1. Existing profiles can't be implemented by some devices due to resource constraints
2. Existing profiles can't be implemented under certain deployment models

Bad reasons for adding additional profiles would be:

1. To add requirements specific to a particular application domain, e.g. smart home, industrial, medical (preventing interoperability between application domains)
2. To define a profile specific to a particular brand, manufacturer or platform

+1

Composable profiles

🟩 Support

Validatible TDs

🟩 Support

Just one note, this requirement only refers to TD not behavioral assertions of consumers/producers. I would really support
the requirement as is stated right now, testing consumers/producers is a lot more complex.

Identification of profiles

🟩 Support

Profile should define a finite set of features and capabilities to implement by the consumer.

🟩 Support

Limit resource consumption

🟥 Oppose

1. Overlaps with `Limit and reduce complexity
2. it is use-case specific (i.e. using a particular set of low-end devices)

Follow Security and Privacy Best Practices

🟩 Support

Developer Mode

🟨 Support, with a caveat

I am not sure how this can be implemented in the spec. Is it just a recommendation where to use the nosec security scheme?

[benfrancis]

To close out on this, do we have a final set of requirements we can point towards?

Views are captured in https://github.com/w3c/wot-usecases/blob/main/REQUIREMENTS/profile-requirements.md but it still says the group hasn't reached consensus on any of them.

Section 1.2 Summary of Use Cases and Requirements of the specification says that "a set of requirements have been derived", but doesn't say what they are. There's a high level introduction, and a single high level use case (Multi-Vendor System Integration - Out of the box interoperability).

I do think we now have a general consensus, it just hasn't been written down. Maybe we just need to clean up https://github.com/w3c/wot-usecases/blob/main/REQUIREMENTS/profile-requirements.md with the final list.