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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
