Original text:
Remove the authentiction tag for encryption algorithms as a separate item.  1.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", the responsibility of the application to ensure that it will be transported without changes. <del> is either a single signature or an array of signature values. A single signature value can be represented using either data type.  Implementations MUST be able to parse both data types. </del>  The CDDL grammar structure for a signature is: encryption process (i.e. detached content) then the value 'nil' is encoded here. <del> contains the recipient information.  The field can have one of three data types: </del>  An array of COSE_encrypt elements, one for each recipient. <del> A single COSE_encrypt element, encoded as an extension to the containing COSE_encrypt element, for a single recipient.  Single recipients can be encoded either this way or as a single array element. </del> A 'nil' value if there are no recipients. 4.1.

Reviewer comments:
Following discussions on the mailing list. Removing the ability to have flattened encoding for signers and recipients.
Closes issue
JOSE now allows for a single recipient to be encoded at the same level as the content. While COSE does not allow for quite the same way of encoding this it would be possible to do something similar. Current syntax is "recipients : COSEencrypta null;" Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub-encodings in CBOR. This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it. Not really that hard to do from a programmers point of view.
Open for group discussion
Based on the messages, there seems to be no support for combining the two maps together into a single map. I have therefore removed that from my working copy of the draft. There was one request for allowing option b (where a single recipient can be represented as a single map entry rather than as an array of a single map). I have looked at code size, and there does not seem to be a lot of code associated with this option, but as there was no outcry for this option I have not included it. Unless others have opinions that they believe need to be expressed, I am closing this issue.

Revised text:
Remove the authentiction tag for encryption algorithms as a separate item. <ins> Remove the flattened mode of encoding.  Forcing the use of an array of recipients at all times forces the message size to be two bytes larger, but one gets a corresponding decrease in the implementation size that should compenstate for this. </ins> 1.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", the responsibility of the application to ensure that it will be transported without changes.  <ins> is an array of signature items.  Each of these items uses the COSE_signature structure for its representation. </ins> The CDDL grammar structure for a signature is: encryption process (i.e. detached content) then the value 'nil' is encoded here.  <ins> contains the recipient information.  The field can have one of two data types: </ins> An array of COSE_encrypt elements, one for each recipient.  A 'nil' value if there are no recipients. 4.1.