[COSE] New option going forward for COSE struct

[Jim Schaad <[e-mail]>]

At the virtual IETF meeting where had a long discussion on how the structure
document should progress without getting any type of final conclusions.
Since that time I have come up with a new option which I think should be
added to the discussion.

1.  Have a single document with the new countersignature algorithm added.
This has the advantage that everything is in one place, it is easy to tag
the current countersignature algorithm header parameters as deprecated
because there is a new replacement in the document.

2.  Have two documents (version 1):  Fix the description of the current
countersignature algorithm in the bis document and progress that.  Create a
new document which contains the new countersignature algorithm.  This would
be an odd choice because I am not sure how the current countersignature
algorithm should be tagged.  Not deprecating seems wrong but trying to
deprecate later also seems to be a strange thing to do.

3.  Have two documents (version 2): Pull the current countersignature
algorithm out of the core document and allow it to progress to full standard
without a countersignature algorithm at all.  Create a new document with
both the new and old countersignature algorithms tagging the old one as
deprecated.  This can then be added to the STD number in the future.

4. Have two documents (version 3): Pull the current countersignature
algorithm out of the core document and add the new countersignature
algorithm to it.  Create  new document which contains the old
countersignature algorithm and publish it as historical.  This is cleaner in
many respects as the deprecated version of the countersignature algorithm
would be in a document which is clearly marked as not being what is to be
used.

5. Have three documents:  Pull the current countersignature algorithm out of
the core document and advance it to full standard.  Create two new
documents, one for each of the countersignature algorithms.  The old
countersignature algorithm would be published as historic and the new
document can be cycled as needed until it is ready and then added to the STD
number as a second document.

I suggested the last option to the chairs in a private email mostly as an
option that exists but I was not really serious about it.  However, in
retrospect I am starting to warmup to the way of doing things as it has
several advantages.  The current structure document can progress without any
big problems.  (Yes I still need to deal with Ben's discuss, but it is kind
of meta.)  It also means that the two countersignature algorithms are
separated and clearly marked in the RFCs themselves as to what there
statuses are.  There are no issues with having multiple documents in the
full standard so adding the countersignature v2 document later is not a
problem.

Jim