Properties should probably have an accessibility attribute about api

[benfrancis]

Just leaving a note here from our earlier discussion...

Yes, good point, I think the W3C version has this. The reason I haven't included it in the Thing Description yet is that I wasn't sure how much of this should be in the Thing Description vs. the Thing API. Whether a property is writeable may depend on who sent the request (based on authentication/authorisation). The read/write permissions could either be enumerated in the Thing Description and the Thing Description may be different depending on who requests it, or a client could test for available methods with an HTTP OPTIONS request on the property URL. I'm not sure what the convention is for enumerating read/write permissions for properties in REST APIs...

You raise the point here that you may want to know whether a property can be written to, regardless of whether the current "user" has permission to set it. Can you think of use cases for needing to know a property can be set even when the current consumer can't set it?

A read/write property of some kind seems like a potentially sensible addition, I just want to make sure it's actually necessary to enumerate in the Thing Description or whether read/write status should be handled in the API/protocol instead.

[dhylands]

I think that this really all boils down to UI. If a property is read-only, then the UI shouldn't be presenting it a potentially modifiable field. Similarly, if a field is write-only, then there is no way to get the current value and display it.

In ZWave, each value (which seems to map to what we're calling a property) has read-only and write-only attributes.