Original text:
<del> CBOR Encoded Message Syntax </del>  draft-ietf-cose-msg-latest Abstract Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size.  There is a need for the ability to have the basic security services defined for this data <del> format.  This document specifies processing for signatures, message authentication codes, and encryption using CBOR.  This document also specifies a representation for cryptographic keys using CBOR. </del>  Contributing to this document can thus be inferred rather than made explicit.  If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information.  The <del> identity information does not need to be specified and can be left as absent. </del>  This contains a nonce value.  The nonce can either be implicit from the protocol or carried as a value in the unprotected used to carry this value in the message However, the nonce value could be determined by the application and the value determined from elsewhere. <del> This item is optional and can be absent. </del>  This contains other information that is defined by the protocol. <del> This item is optional and can be absent. </del>  This field holds information about party V.  The content of the structure are the same as for the PartyUInfo but for partyV.

Reviewer comments:
We change the title of the document Implement the suggested change from Carsten that we put nils in to unused elements in the ParytInfo structure. I was a bit more complete than the original suggestion but it is probably simpler to get right that way.
It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field. The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later. It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode, modify and re-encode any of the top level information. I don't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one.
Did not correctly read the spec.

Revised text:
 <ins> COSE: A Message Based Security Solution for CBOR </ins> draft-ietf-cose-msg-latest Abstract Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size.  There is a need for the ability to have the basic security services defined for this data  <ins> format.  This document defines the CBOR Object Signing and Encyption (COSE) specification.  This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization.  This specifiction additionally specifies how to representat cryptographic keys using CBOR. </ins> Contributing to this document can thus be inferred rather than made explicit.  If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information.  The  <ins> identity information does not need to be specified and is set to nil in that case. </ins> This contains a nonce value.  The nonce can either be implicit from the protocol or carried as a value in the unprotected used to carry this value in the message However, the nonce value could be determined by the application and the value determined from elsewhere.  <ins> This option does not need to be specified and is set to nil in that case </ins> This contains other information that is defined by the protocol.  <ins> This option does not need to be specified and is set to nil in that case </ins> This field holds information about party V.  The content of the structure are the same as for the PartyUInfo but for partyV.