Change:
Some more edits in response to the review. Does not include one item that was proposed for clarification

Discussion:
Elements after this point are dependent on the specific message type. <ins> COSE messages are also built using the concept of using layers to separate different types of cryptographic concepts.  As an example of how this works consider the COSE_Encrypt message (EnvelopedData). This message type is broken into two layers: the content layer and the recipient layer.  In the content layer, the plain text is encrypted and information about the encrypted message are placed.  In the recipient layer, the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient is placed.  A single layer version of the encryption message COSE_Encrypt0 (EnvelopedData0) is provided for cases where the CEK is pre-shared. </ins> Identification of which type of message has been presented is done by the following method:

not going to be included in a cryptographic computation.  This bucket is encoded in the message as a binary object.  This value is obtained by CBOR encoding the protected map and wrapping it in <del> a bstr object.  Senders SHOULD encode an empty protected map as a zero length binary object (i.e., the byte string h'a0').  This encoding is used because it is both shorter and the version used in the serialization structures for cryptographic computation. Recipients MUST accept both a zero length binary value and a zero length map encoded in the binary value.  The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit.  (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.)  This avoids the problem of all parties needing to be able to do a common canonical encoding. </del> <ins> a bstr object.  Senders SHOULD encode an zero length map as a zero length string rather than as a zero length map (encoded as h'a0'). The zero length binary encoding is preferred because it is both shorter and the version used in the serialization structures for cryptographic computation.  After encoding the map the value is wrapped in the binary object.  Recipients MUST accept both a zero length binary value and a zero length map encoded in the binary value.  The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit.  (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding. </ins> Contains parameters about the current layer that are not cryptographically protected.

Integer labels in the range of 0 to 8 SHOULD be omitted. <del> Integer labels in the range -1 to -255 can be omitted as they </del> <ins> Integer labels in the range -1 to -128 can be omitted as they </ins> are algorithm dependent.  If an application can correctly process an algorithm, it can be assumed that it will correctly process all of the common parameters associated with that <del> algorithm.  (The algorithm range is -1 to -65536; the higher end is for more optional algorithm specific items.) </del> <ins> algorithm.  Integer labels in the range -129 to -65536 SHOULD be included as these would be less common parameters that might not be generally supported. </ins> Labels for parameters required for an application MAY be omitted.  Applications should have a statement if the label can

find the correct one.  The internal structure of 'kid' values is not defined and cannot be relied on by applications.  Key identifier values are hints about which key to use.  This is not a <del> security critical field.  For this reason, it SHOULD be placed in the unprotected headers bucket. </del> <ins> security critical field.  For this reason, it can be placed in the unprotected headers bucket. </ins> This parameter holds the Initialization Vector (IV) value.  For some symmetric encryption algorithms this may be referred to as a nonce.  As the IV is authenticated by the encryption process, it <del> SHOULD be placed in the unprotected header bucket. </del> <ins> can be placed in the unprotected header bucket. </ins> This parameter holds a part of the IV value.  When using the COSE_Encrypt0 structure, a portion of the IV can be part of the

as described in header-parameters. <del> contains the encrypted key encoded as a bstr.  If there is not an encrypted key, then this field is encoded as a nil value. </del> <ins> contains the encrypted key encoded as a bstr.  All encoded keys are symetric keys, the binary value of the key is the content.  If there is not an encrypted key, then this field is encoded as a nil value. </ins> contains an array of recipient information structures.  The type for the recipient information structure is a COSE_recipient.  (An