Issue 4443: PKI - RepositoryProviderInfo defintion (pki-ftf) Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Summary: The current spec defines RepositoryProviderInfo as an struct. Given that it has approximately 14 state members, I suggest we redefine it as a valuetype simply on the grounds that it is more easily modifiable in the future (using a valuetype will maintain backward compatibility because we can extend it if needed). It also means that implementations could provide supplementary information without breaking interfaces or interoperability. This is the current definition: struct RepositoryProviderInfo { string standardDescription; string standardVersion; string productDescription; string productVersion; string productVendor; PKI::CertificateInfoList supportedCertificates; PKI::CRLInfoList supportedCRLs; PKI::CertificateInfoList supportedCrossCertificates; string user_attribute_name; string ca_attribute_name; string crl_attribute_name; string certificatePair_attribute_name; string deltaCRL_attribute_name; string arl_attribute_name; }; I propose we change this to: valuetype RepositoryProviderInfo { public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; The same case may apply for some of the other info types - but for the moment I'm focussing on the repository interfaces - more question later! Resolution: see above Revised Text: Actions taken: August 2, 2001: received issue July 5, 2002: closed issue Discussion: The current spec defines RepositoryProviderInfo as an struct. Given that it has approximately 14 state members, I suggest we redefine it as a valuetype simply on the grounds that it is more easily modifiable in the future (using a valuetype will maintain backward compatibility because we can extend it if needed). It also means that implementations could provide supplementary information without breaking interfaces or interoperability. This is the current definition: struct RepositoryProviderInfo { string standardDescription; string standardVersion; string productDescription; string productVersion; string productVendor; PKI::CertificateInfoList supportedCertificates; PKI::CRLInfoList supportedCRLs; PKI::CertificateInfoList supportedCrossCertificates; string user_attribute_name; string ca_attribute_name; string crl_attribute_name; string certificatePair_attribute_name; string deltaCRL_attribute_name; string arl_attribute_name; }; Proposed change of struct to 2 separate valuetypes. As follows: valuetype RepositoryProviderInfo { public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; }; and the following with X500 type state members that may be used in the LDAP specific repository. The new module will be making a change adding an extension for an LDAP specific set of interfaces (the original defined interfaces) and a simpler Repository interface to be used instead. This will be described in detail in another issue ie 4444 module PKIExtension { valuetype RepositoryMappingInfo { public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; }; End of Annotations:===== From: "Stephen McConnell" To: Subject: PKI - RepositoryProviderInfo defintion Date: Thu, 2 Aug 2001 06:07:09 +0200 Message-ID: <000001c11b08$99d78050$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: )0E!!GYVd9'U%!!!e&!! The current spec defines RepositoryProviderInfo as an struct. Given that it has approximately 14 state members, I suggest we redefine it as a valuetype simply on the grounds that it is more easily modifiable in the future (using a valuetype will maintain backward compatibility because we can extend it if needed). It also means that implementations could provide supplementary information without breaking interfaces or interoperability. This is the current definition: struct RepositoryProviderInfo { string standardDescription; string standardVersion; string productDescription; string productVersion; string productVendor; PKI::CertificateInfoList supportedCertificates; PKI::CRLInfoList supportedCRLs; PKI::CertificateInfoList supportedCrossCertificates; string user_attribute_name; string ca_attribute_name; string crl_attribute_name; string certificatePair_attribute_name; string deltaCRL_attribute_name; string arl_attribute_name; }; I propose we change this to: valuetype RepositoryProviderInfo { public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; The same case may apply for some of the other info types - but for the moment I'm focussing on the repository interfaces - more question later! Cheers, Steve. Stephen J. McConnell, OSM sarl digital products for a global economy http://www.osm.net mailto:mcconnell@osm.net X-Mailer: exmh version 2.5 07/13/2001 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), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom), IBalabine@iona.com (Igor Balabine) cc: pki-ftf@omg.org Subject: Request vote issue: 4443 Mime-Version: 1.0 Date: Thu, 15 Nov 2001 14:14:58 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: mSOe9L9c!!%[Yd9)ITd9 Issue 4443: PKI - RepositoryProviderInfo defintion (pki-ftf) Click here for this issue's archive. Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Summary: The current spec defines RepositoryProviderInfo as an struct. Given that it has approximately 14 state members, I suggest we redefine it as a valuetype simply on the grounds that it is more easily modifiable in the future (using a valuetype will maintain backward compatibility because we can extend it if needed). It also means that implementations could provide supplementary information without breaking interfaces or interoperability. This is the current definition: struct RepositoryProviderInfo { string standardDescription; string standardVersion; string productDescription; string productVersion; string productVendor; PKI::CertificateInfoList supportedCertificates; PKI::CRLInfoList supportedCRLs; PKI::CertificateInfoList supportedCrossCertificates; string user_attribute_name; string ca_attribute_name; string crl_attribute_name; string certificatePair_attribute_name; string deltaCRL_attribute_name; string arl_attribute_name; }; Proposed change to following valuetype in IDL Section A.3 valuetype RepositoryProviderInfo { public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; ----------------------------- Y/N/Abstain | | --------------------------------------------------------------------------- From: "Stephen McConnell" To: "Simon Gibson" , "Patrick McLaughlin" , "Polar Humenn" , "Gene Garboe" , "Bill Binko" , "Ron Monzillo" , "Simon Gibson" , "Christopher Milsom" , "Igor Balabine" Cc: Subject: RE: Request vote issue: 4443 <--- NO, ISSUE with proposed change !! Date: Thu, 15 Nov 2001 05:53:35 +0100 Message-ID: <008901c16d91$7bba0a80$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200111150415.fAF4Exm22405@thunder.dstc.qut.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: _M=!!jeAe9VSS!!$$8e9 Simon: This issue needs discussion before voting. In fact I would vote NO if forced. There was an issue was raised concerning fields declared in this type that were implementation specific (X500 attribute names). These fields include the following: > string user_attribute_name; > string ca_attribute_name; > string crl_attribute_name; > string certificatePair_attribute_name; > string deltaCRL_attribute_name; > string arl_attribute_name; The proposed/discussed resolution was to define RepositoryProviderInfo as an implementation independent valuetype from which an X500 variant could extend to include the X500 related fields. I suggest that the request to vote on issue 4443 be withdrawn and that a vote be re-issued based on the following IDL (implemented, documented, and working). /** * Aggregated description of a repository, supported standard, supplier, * supported certificate types and encodings, and cross-CA agreements. */ valuetype RepositoryProviderInfo { /** * Description of the standard that the repository is compliant with. */ public string standardDescription; /** * The version of the standard that the repository is compliant with. */ public string standardVersion; /** * Description of the product. */ public string productDescription; /** * Product version identifier. */ public string productVersion; /** * Name of the product vendor. */ public string productVendor; /** * Supported certificate types and encoding. */ public PKI::CertificateInfoList supportedCertificates; /** * Supported cross-certification agreements. */ public PKI::CertificateInfoList supportedCrossCertificates; /** * Supported CRL types and encoding. */ public PKI::CRLInfoList supportedCRLs; }; This is exactly equivalent to the proposal with the single exception that the X500 state members have been removed. It also important to note that the X500 state members are not included in the PKI specification document in its current form (they only appear in the IDL). Cheers, Steve. Stephen J. McConnell, OSM sarl digital products for a global economy http://www.osm.net mailto:mcconnell@osm.net > -----Original Message----- > From: Simon Gibson [mailto:gibson@dstc.qut.edu.au] > Sent: Thursday, 15 November, 2001 05:15 > To: Patrick McLaughlin; Polar Humenn; Gene Garboe; Bill Binko; Stephen > McConnell; Ron Monzillo; Simon Gibson; Christopher Milsom; Igor Balabine > Cc: pki-ftf@omg.org > Subject: Request vote issue: 4443 > > > Issue 4443: PKI - RepositoryProviderInfo defintion (pki-ftf) > > Click here for this issue's archive. > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > Nature: Uncategorized Issue > Severity: > > Summary: The current spec defines RepositoryProviderInfo as an > struct. Given that it has approximately 14 state members, I suggest we > redefine it as a valuetype simply on the grounds that it is more > easily modifiable in the future (using a valuetype will maintain > backward compatibility because we can extend it if needed). It also > means that implementations could provide supplementary information > without breaking interfaces or interoperability. This is the current > definition: > struct RepositoryProviderInfo { > string standardDescription; > string standardVersion; > string productDescription; > string productVersion; > string productVendor; > PKI::CertificateInfoList supportedCertificates; > PKI::CRLInfoList supportedCRLs; > PKI::CertificateInfoList supportedCrossCertificates; > string user_attribute_name; > string ca_attribute_name; > string crl_attribute_name; > string certificatePair_attribute_name; > string deltaCRL_attribute_name; > string arl_attribute_name; > }; > > Proposed change to following valuetype in IDL Section A.3 > > > valuetype RepositoryProviderInfo { > public string standardDescription; > public string standardVersion; > public string productDescription; > public string productVersion; > public string productVendor; > public PKI::CertificateInfoList supportedCertificates; > public PKI::CRLInfoList supportedCRLs; > public PKI::CertificateInfoList supportedCrossCertificates; > public string user_attribute_name; > public string ca_attribute_name; > public string crl_attribute_name; > public string certificatePair_attribute_name; > public string deltaCRL_attribute_name; > public string arl_attribute_name; > }; > ----------------------------- > Y/N/Abstain | | > ------------------------------------------------------------------ > --------- > X-Mailer: exmh version 2.5 07/13/2001 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), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom), IBalabine@iona.com (Igor Balabine) cc: pki-ftf@omg.org Subject: New Request Vote issue: 4443 Mime-Version: 1.0 Date: Thu, 15 Nov 2001 15:50:55 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: mk=e9i*\!!+;>!!MGHe9 Sorry about this please ignore the previous message for this issue. Stephen pointed out something that is important to this issue and also an issue that will follow ie 4444. Issue 4443: PKI - RepositoryProviderInfo defintion (pki-ftf) Click here for this issue's archive. Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Summary: The current spec defines RepositoryProviderInfo as an struct. Given that it has approximately 14 state members, I suggest we redefine it as a valuetype simply on the grounds that it is more easily modifiable in the future (using a valuetype will maintain backward compatibility because we can extend it if needed). It also means that implementations could provide supplementary information without breaking interfaces or interoperability. This is the current definition: struct RepositoryProviderInfo { string standardDescription; string standardVersion; string productDescription; string productVersion; string productVendor; PKI::CertificateInfoList supportedCertificates; PKI::CRLInfoList supportedCRLs; PKI::CertificateInfoList supportedCrossCertificates; string user_attribute_name; string ca_attribute_name; string crl_attribute_name; string certificatePair_attribute_name; string deltaCRL_attribute_name; string arl_attribute_name; }; Proposed change of struct to 2 separate valuetypes. As follows: valuetype RepositoryProviderInfo { public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; }; and the following with X500 type state members that may be used in the LDAP specific repository. The new module will be making a change adding an extension for an LDAP specific set of interfaces (the original defined interfaces) and a simpler Repository interface to be used instead. This will be described in detail in another issue ie 4444 module PKIExtension { valuetype RepositoryMappingInfo { public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; }; Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: <008901c16d91$7bba0a80$0a01a8c0@osm.net> Subject: Re: Request vote issue: 4443 <--- NO, ISSUE with proposed change !! Date: Thu, 15 Nov 2001 22:29:43 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="Windows-1252" X-UIDL: m11!!06Z!!Y[S!!2X'e9 Sent: Wednesday, November 14, 2001 11:53 PM Subject: RE: Request vote issue: 4443 <--- NO, ISSUE with proposed change !! > /** > * Aggregated description of a repository, supported standard, supplier, > * supported certificate types and encodings, and cross-CA agreements. > */ > valuetype RepositoryProviderInfo > { > > /** > * Description of the standard that the repository is compliant with. > */ > public string standardDescription; <<>> This sort of thing worries me greatly unless we define a single, extensible standard to specifying the standard. Personally - since the set possible standards is finite, relatively small, and slow to change - I would prefer to see this as public long standardDescription with a list of constants defined for the set of acceptable standards. This would be both more performant (integers can be compared much more quickly than strings:) and more interoperable - implementors of PKII servers and clients will necessarily have the same set of definitions. It occurs to me that the only downside is that we'll have to ensure that clients can determine the version of the standards definition constants IDL being used by the server. <<>> > > /** > * The version of the standard that the repository is >compliant with. > */ > public string standardVersion; <<>> Well, this takes care of my versioning concern :-) <<>>