Issue 4193: The PKIStatus constants are not explained sufficiently. (pki-ftf) Source: DSTC (Mr. Simon Gibson, gibson@dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: The PKIStatus constants are not explained sufficiently. Resolution: see below Revised Text: Here is some proposed text for inclusion in a new SubSection 2.2.1 typedef unsigned long PKIStatus; /** PKISuccess indicates that the current transaction is now * complete without any more invocations required. */ const PKIStatus PKISuccess = 0; /** PKISuccessWithWarning indicates that the client has received * something similar to what was asked for. It is up to the client to * ascertain the differences. This may for example be a certificate * that varies in some way from the request such as the validity * period may be different to that requested. */ const PKIStatus PKISuccessWithWarning = 1; /** PKIContinueNeeded indicates that the current part of the transaction * is complete but the actual end result has not yet been * reached. This means that another invocation is required * most likely requiring some additional information. */ const PKIStatus PKIContinueNeeded = 2; /** PKIFailed indicates that a failure has occurred and the transaction * should be terminated. */ const PKIStatus PKIFailed = 3; /** PKIPending indicates that the transaction is in a transitional * period pending some result. * This state occurs during the period before either * a transaction is complete or a continue is required. */ const PKIStatus PKIPending = 4; /** PKISuccessAfterConfirm indicates that the transaction is complete * but the <code>PKIAuthority</code> requires that a confirmation * message is sent using <code>RequestManager.confirm_content</code> * operation. * For example this might occur in the case where the * CA may revoke the issued certificate if a confirm is not made * as the CA may presume that the client could not decrypt the * message as a way of providing proof of possession (POP) * of the private key. */ const PKIStatus PKISuccessAfterConfirm = 5; Actions taken: February 5, 2001: received issue July 5, 2002: closed issue Discussion: End of Annotations:===== From: webmaster@omg.org Message-Id: <200102060210.f162Ahr18932@emerald.omg.org> Date: 05 Feb 2001 22:11:57 -0500 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: NN-!!>/id9foed9=WGe9 Name: Simon Gibson Company: DSTC mailFrom: gibson@dstc.edu.au Notification: No Specification: Public Key Infrastructure Section: 2.2 FormalNumber: dtc/2001-02-01 Version: 1 RevisionDate: 02/01/2001 Page: 2-1 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.75 [en] (X11; U; SunOS 5.8 sun4u) Description The PKIStatus constants are not explained sufficiently. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pmclaughlin@baltimore.com (Patrick McLaughlin), polar@adiron.com (Polar Humenn), gjarboe@promia.com (Gene Garboe), cwbinko@trcinc.com (Bill Binko), mcconnell@osm.net (Stephen McConnell), dflinn@iona.com (Don Flinn), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom) cc: pki-ftf@emerald.omg.org Subject: PKI FTF issue # 4193 Mime-Version: 1.0 Date: Thu, 15 Feb 2001 08:50:46 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: Mo9e9jOC!!5Q,!!-,;e9 This is issue # 4193 Simon Gibson gibson@dstc.edu.au The PKIStatus constants are not explained sufficiently. ------------------------------------- Proposed Solution Here is some proposed text for inclusion in a new SubSection 2.2.1. This is straight from our IDL file hence the javadoc style comments. typedef unsigned long PKIStatus; /** PKISuccess indicates that the current transaction is now * complete without any more invocations required. */ const PKIStatus PKISuccess = 0; /** PKISuccessWithWarning indicates that the client has received * something similar to what was asked for. It is up to the client to * ascertain the differences. This may for example be a certificate * that varies in some way from the request such as the validity * period may be different to that requested. */ const PKIStatus PKISuccessWithWarning = 1; /** PKIContinueNeeded indicates that the current part of the transaction * is complete but the actual end result has not yet been * reached. This means that another invocation is required * most likely requiring some additional information. */ const PKIStatus PKIContinueNeeded = 2; /** PKIFailed indicates that a failure has occurred and the transaction * should be terminated. */ const PKIStatus PKIFailed = 3; /** PKIPending indicates that the transaction is in a transitional * period pending some result. * This state occurs during the period before either * a transaction is complete or a continue is required. */ const PKIStatus PKIPending = 4; /** PKISuccessAfterConfirm indicates that the transaction is complete * but the PKIAuthority requires that a confirmation * message is sent using RequestManager.confirm_content * operation. * For example this might occur in the case where the * CA may revoke the issued certificate if a confirm is not made * as the CA may presume that the client could not decrypt the * message as a way of providing proof of possession (POP) * of the private key. */ const PKIStatus PKISuccessAfterConfirm = 5; X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Polar Humenn Subject: Re: PKI FTF issue # 4193 In-reply-to: Your message of "Wed, 14 Feb 2001 17:54:05 EST." cc: pki-ftf@emerald.omg.org Mime-Version: 1.0 Date: Thu, 15 Feb 2001 09:15:36 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: MB1!!pYLe9Nf;e9[bld9 Polar, Cheers Polar. I am new to this however there is a published adopted specification document derived from the revised submission document. The section numbers in the issues all relate to the specification document dtc/01-02-01 available from: http://www.omg.org/techprocess/meetings/schedule/Public_Key_Infrastructure_ FTF.html I don't have the frame files for this doc. I will request them and I can do a changebar version and add paragraph numbers. Simon > > Simon, > > You need to produce a document that is derived directly from the > adopted > proposal written as a spec, i.e. with some of the answer to the RFP > requirments explanations and format ripped out. This must be > published so > that we all have something to work off of for resolutions. It would > help > if you number the paragraphs. > > Then, we must vote resolutions to the issues based on that document, > and > others that you progressively edit along the way. > > Cheers, > -Polar > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pmclaughlin@baltimore.com (Patrick McLaughlin), polar@adiron.com (Polar Humenn), gjarboe@promia.com (Gene Garboe), cwbinko@trcinc.com (Bill Binko), mcconnell@osm.net (Stephen McConnell), dflinn@iona.com (Don Flinn), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom) cc: pki-ftf@emerald.omg.org Subject: PKI FTF Request Vote on Issue #4193 Mime-Version: 1.0 Date: Tue, 26 Jun 2001 09:42:35 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: jSNe9mY#e9O*]!!U))!! This is issue # 4193 Simon Gibson gibson@dstc.edu.au The PKIStatus constants are not explained sufficiently. ------------------------------------- Proposed Solution Here is some proposed text for inclusion in a new SubSection 2.2.1. This is straight from our IDL file hence the javadoc style comments. typedef unsigned long PKIStatus; /** PKISuccess indicates that the current transaction is now * complete without any more invocations required. */ const PKIStatus PKISuccess = 0; /** PKISuccessWithWarning indicates that the client has received * something similar to what was asked for. It is up to the client to * ascertain the differences. This may for example be a certificate * that varies in some way from the request such as the validity * period may be different to that requested. */ const PKIStatus PKISuccessWithWarning = 1; /** PKIContinueNeeded indicates that the current part of the transaction * is complete but the actual end result has not yet been * reached. This means that another invocation is required * most likely requiring some additional information. */ const PKIStatus PKIContinueNeeded = 2; /** PKIFailed indicates that a failure has occurred and the transaction * should be terminated. */ const PKIStatus PKIFailed = 3; /** PKIPending indicates that the transaction is in a transitional * period pending some result. * This state occurs during the period before either * a transaction is complete or a continue is required. */ const PKIStatus PKIPending = 4; /** PKISuccessAfterConfirm indicates that the transaction is complete * but the PKIAuthority requires that a confirmation * message is sent using RequestManager.confirm_content * operation. * For example this might occur in the case where the * CA may revoke the issued certificate if a confirm is not made * as the CA may presume that the client could not decrypt the * message as a way of providing proof of possession (POP) * of the private key. */ const PKIStatus PKISuccessAfterConfirm = 5;