Consumer mutability of attributes and attribute types

Few ways we could deal w/ this: 1) No change. Instance specific mutability or authorization issues are deal with via a round trip and an HTTP error code. 2) Remove consumer mutability of the attribute from the spec 3) Leave the consumer mutability of attributes in the spec, but not define the values in the spec. Let platform impl decide. They may decide to leave it in the type off the platform or make it instance specific. HTTP caches work using the URL, an instance that points to the type will work just fine with HTTP caches. Based on the 2015-10-28 call, option (2) was acceptable. Proposal for option (2) is at https://www.oasis-open.org/committees/document.php?document_id=56855&wg_abbrev=camp Based on 2015-11-04 telcon, updated v2 proposal: https://www.oasis-open.org/committees/document.php?document_id=56859&wg_abbrev=camp Based on 2015-12-02 telcon, updated v3 proposal: https://www.oasis-open.org/committees/document.php?document_id=57080&wg_abbrev=camp On 2015-12-02 telcon the TC agreed to have the following: 1) both mutability and consumer-mutability as metadata 2) this is associated at the instance level not type 3) The spec will not specify whether the values are true or false 4) It is the platform that decides the values and must provide that information to the consumer v4 of the proposal is located at: https://www.oasis-open.org/committees/document.php?document_id=57565&wg_abbrev=camp This proposal is based on agreements at https://www.oasis-open.org/apps/org/workgroup/camp/download.php/57517/mutability_outline-3.txt and the 2016-02-18 telcon.