Hi Detlef, yes, I agree that a promotion of the current draft to CS makes sense. My current list of minors are - move of paragraph 'Multi-Signature Creation' from section 'Verification' up to 'Signing' - minor fix in 6.2.2 '[...] the server returns one of the first _three_ ResultMinor[...]' to '[...] the server returns one of the first _two_ ResultMinor[...]' - 6.2.2: fix of wrong reference to the component of 'Result' @all: Please post other findings! If we agree upon this way forward on Monday's call (and Chet does not reject our view of 'minor changes') I'll setup a ballot for the migration to CS. Proposal of a version DSS-X core 2.1: As I already mentioned the use of RFC 2119 wording in the core is not consistent and hampers the demarcation of assertions. Fixing this would require a manageable effort ut would introduce a big number of editorial changes to the document. But working with Burcin's testing documents I noticed that the error handling seems to be a bit underspecified. There is a list of ResultMinors (Chapter 9.2) provided but the conditions when to return which ResultMinor is lacking. E.g. the value of 'IncorrectSignature' is never referenced or explained anywhere else. Therefore I would propose to assemble the details we learn working with the test infrastructure and reflect it in a version 2.1 of the core. Greetings, Andreas > Hi, > > IMHO we should fix the minors and then move it to CS. > > BR, > dh > > -----UrsprÃngliche Nachricht----- > Von:
dss-x@lists.oasis-open.org <
dss-x@lists.oasis-open.org> Im Auftrag von Andreas Kuehne > Gesendet: Dienstag, 16. April 2019 16:03 > An: dss-x <
dss-x@lists.oasis-open.org> > Betreff: [dss-x] Promotion of DSS-X core 2.0 to CS > > Hi all, > > > I checked back with the TC Handbook regarding the promotion of the current draft of the core to CS. There is another 7 day ballot required and some work to do by the admins (
http://docs.oasis-open.org/TChandbook/Reference/CommitteeSpecs.html ). > > So I guess we are not that far from having the core 2.0 in the 'CS' > state. But I would prefer to review the core regarding the RFC 2119 wording and assertion demarcation (and a few other minors). I presume that the volume of the 'assertion' changes may require another review period. > > We could move the current draft to CS and later on do the process with a core 2.0.1 again. This approach will not produce too much overhead as there are many other documents in the pipeline for the same process (Metadata, X.509, JWS). > > > What's your opinion? > > > Greetings, > > > Andreas > > -- > Andreas KÃhne > > Chair of OASIS DSS-X > > phone: +49 177 293 24 97 > mailto:
kuehne@trustable.de > > Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 > > Director Andreas KÃhne > > Company UK Company No: 5218868 Registered in England and Wales > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Andreas KÃhne Chair of OASIS DSS-X phone: +49 177 293 24 97 mailto:
kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas KÃhne Company UK Company No: 5218868 Registered in England and Wales Attachment: smime.p7s Description: S/MIME Cryptographic Signature