Issue 4479: PKI AuthorityInfoType - missing documentation (pki-ftf) Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Summary: The following structure and contantns are declared in the PKI IDL but are not defined within the PKI specification: typedef unsigned long AuthorityInfoType; const AuthorityInfoType UnkownMessage = 0; const AuthorityInfoType PKIXCMPGeneralMessage = 1; const AuthorityInfoType CustomMessage = 0x8000; Resolution: see above Revised Text: Actions taken: August 4, 2001: received issue July 5, 2002: closed issue Discussion: Add the following text to Chapter 2 "2.2.X AuthorityInfoType The AuthorityInfoType is used to describe the type of a message that is being sent/received by an authority. An example type for this is a PKIX Certificate Management Protocol (CMP) general message format End of Annotations:===== From: "Stephen McConnell" To: Subject: PKI AuthorityInfoType - missing documentation Date: Sat, 4 Aug 2001 12:06:14 +0200 Message-ID: <000101c11ccd$18489d50$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 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Importance: Normal Content-Type: text/plain; charset="Windows-1252" X-UIDL: 1o`!!Gaod9I"od9]5Zd9 The following structure and contantns are declared in the PKI IDL but are not defined within the PKI specification: typedef unsigned long AuthorityInfoType; const AuthorityInfoType UnkownMessage = 0; const AuthorityInfoType PKIXCMPGeneralMessage = 1; const AuthorityInfoType CustomMessage = 0x8000; 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 #4477, #4479 Mime-Version: 1.0 Date: Tue, 27 Nov 2001 11:44:49 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: !&@e9F;o!!l;O!!"?$e9 Hi There, Here are 2 more straightforward issues that have been raised. I have created 1 more issue to sort out the compliance chapter which should be the last after these 2. Cheers Simon Issue 4477: PKI RegistrationAuthority QUERY (pki-ftf) Click here for this issue's archive. Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Clarification Severity: Summary: The specification of the get_authority_info operation on the RegistrationAuthority interface does seem to has sufficient information describing the expected semantics. I have included the extract of the javadoc description that I have put together based on the spec, however, this isn't a sufficient description to implement against. Secondly, the method and argument names don't seem to be symmetric with the intent of the operation. As far as I understand, the operation "get_authority_info" actually serves as a post-message-get-reply operation, and the arguments "AuthorityInfo" are actually the messages in and out. If that's correct, then both operation and argument types should be renamed to imply this. Any clarification on this would be appreciated. /** * Message exchange between a client entity and authority. For example * this may provide a method for a client to determine the authentication * policy of the authority. * * @param in_authority_info The encoded message input to authority. * @param out_authority_info The encoded returned message from * authority. * @return Status value. * @exception UnsupportedTypeException * @exception UnsupportedEncodingException * @exception MalformedDataException */ public int get_authority_info(AuthorityInfo in_authority_info, AuthorityInfoHolder out_authority_info) throws UnsupportedTypeException, UnsupportedEncodingException, MalformedDataException { return 0; } Resolution: Propose that we change the IDL parameter names to "authority_info_req" and "authority_info_resp" making the intention clearer: public int get_authority_info(AuthorityInfo authority_info_req, AuthorityInfoHolder authority_info_resp) throws UnsupportedTypeException, UnsupportedEncodingException, MalformedDataException { return 0; } Revised Text: Actions taken: August 5, 2001: received issue ----------------------------- Y/N/Abstain | | --------------------------------------------------------------------------- Issue 4479: PKI AuthorityInfoType - missing documentation (pki-ftf) Click here for this issue's archive. Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Summary: The following structure and contantns are declared in the PKI IDL but are not defined within the PKI specification: typedef unsigned long AuthorityInfoType; const AuthorityInfoType UnkownMessage = 0; const AuthorityInfoType PKIXCMPGeneralMessage = 1; const AuthorityInfoType CustomMessage = 0x8000; Resolution: Add the following text to Chapter 2 "2.2.X AuthorityInfoType The AuthorityInfoType is used to describe the type of a message that is being sent/received by an authority. An example type for this is a PKIX Certificate Management Protocol (CMP) general message format." Revised Text: Actions taken: August 4, 2001: received issue ----------------------------- Y/N/Abstain | | --------------------------------------------------------------------------- X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 27 Nov 2001 09:22:48 -0500 (EST) From: Polar Humenn To: Simon Gibson cc: Patrick McLaughlin , Gene Garboe , Bill Binko , Stephen McConnell , Ron Monzillo , Simon Gibson , Christopher Milsom , Igor Balabine , Subject: Re: Request Vote issue #4477, #4479 In-Reply-To: <200111270144.fAR1iom15346@thunder.dstc.qut.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: NO$e9K^/!!5*Ke9Z5i!! Hi Simon, I would suggest in issue 4479, that instead of CustomMessage, you use the VMCID stuff. That is the vendor code. It works pretty well, and is used almost everywhere and we make use of it in CSIv2. This approach will label something as "custom" by having it tagged with a particular vendors's VMCID (a 20 bit integer) followed by a specification number within the scope of that vendor's definition. May I suggest the following text? 2.2.X AuthorityInfoType The AuthorityInfoType is used to describe the type of a message that is being sent/received by an authority. An example type for this is a PKIX Certificate Management Protocol (CMP) general message format." The high order 20-bits of each AuthorityInfoType constant shall contain the Vendor Minor Codeset ID (VMCID) of the organization that defines the type. The low order 12 bits shall contain the organization-scoped type identifier. The higher order 20-bits of each AuthorityInfoType defined in this specification shall be zero. Organizations must register their VMCIDs with the OMG before using them to define an AuthorityInfoType. Cheers, -Polar On Tue, 27 Nov 2001, Simon Gibson wrote: > Hi There, > > Here are 2 more straightforward issues that have been raised. I have > created 1 more issue to sort out the compliance chapter which should >be > the last after these 2. > > Cheers > > Simon > > > Issue 4477: PKI RegistrationAuthority QUERY (pki-ftf) > > Click here for this issue's archive. > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > Nature: Clarification > Severity: > > Summary: The specification of the get_authority_info operation on >the > RegistrationAuthority interface does seem to has sufficient > information describing the expected semantics. I have included the > extract of the javadoc description that I have put together based on > the spec, however, this isn't a sufficient description to implement > against. Secondly, the method and argument names don't seem to be > symmetric with the intent of the operation. As far as I understand, > the operation "get_authority_info" actually serves as a > post-message-get-reply operation, and the arguments "AuthorityInfo" > are actually the messages in and out. If that's correct, then both > operation and argument types should be renamed to imply this. Any > clarification on this would be appreciated. > > /** * Message exchange between a client entity and authority. For >example > * this may provide a method for a client to determine the >authentication > * policy of the authority. > * > * @param in_authority_info The encoded message input to authority. > * @param out_authority_info The encoded returned message from > * authority. * @return Status value. > * @exception UnsupportedTypeException > * @exception UnsupportedEncodingException > * @exception MalformedDataException > */ > public int get_authority_info(AuthorityInfo in_authority_info, > AuthorityInfoHolder >out_authority_info) > throws UnsupportedTypeException, > UnsupportedEncodingException, MalformedDataException > > { return 0; } > > Resolution: > > Propose that we change the IDL parameter names to >"authority_info_req" > and "authority_info_resp" making the intention clearer: > > public int get_authority_info(AuthorityInfo authority_info_req, > AuthorityInfoHolder >authority_info_resp) > throws UnsupportedTypeException, > UnsupportedEncodingException, MalformedDataException > > { return 0; } > > Revised Text: > Actions taken: > August 5, 2001: received issue > ----------------------------- > Y/N/Abstain | | > --------------------------------------------------------------------------- > > > Issue 4479: PKI AuthorityInfoType - missing documentation (pki-ftf) > > Click here for this issue's archive. > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > Nature: Uncategorized Issue > Severity: > > Summary: The following structure and contantns are declared in the >PKI > IDL but are not defined within the PKI specification: > > typedef unsigned long AuthorityInfoType; > const AuthorityInfoType UnkownMessage = 0; > const AuthorityInfoType PKIXCMPGeneralMessage = 1; > const AuthorityInfoType CustomMessage = 0x8000; > > Resolution: > > Add the following text to Chapter 2 > > "2.2.X AuthorityInfoType > > The AuthorityInfoType is used to describe the type of a message that > is being sent/received by an authority. An example type for this is >a > PKIX Certificate Management Protocol (CMP) general message format." > > > Revised Text: > Actions taken: > August 4, 2001: received issue > ----------------------------- > Y/N/Abstain | | > --------------------------------------------------------------------------- > ------------------------------------------------------------------- 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.5 07/13/2001 with nmh-1.0.4 To: Polar Humenn cc: pki-ftf@omg.org Subject: Re: Request Vote issue #4477, #4479 In-Reply-To: Message from Polar Humenn of "Tue, 27 Nov 2001 09:22:48 EST." Mime-Version: 1.0 Date: Wed, 28 Nov 2001 10:32:22 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: fpV!!SJ=e9kmI!!N~'!! Polar, I hadn't been aware of this VMCID stuff. It would seem actually that this should be done in a few places in the specification I expect. However I would rather that this was raised as a separate issue and later on in an RTF if that's OK. I have a hard deadline of the 15th of Dec to sort out current issues and write the report and a modified document. Would it be OK with you to leave the issue resolution as I have it now and then sort out the VMCID stuff properly later on. It can be raised as an issue now but I will have to defer it I think just due to time constraints. Cheers Simon > > Hi Simon, > > I would suggest in issue 4479, that instead of CustomMessage, you > use the > VMCID stuff. That is the vendor code. It works pretty well, and is > used > almost everywhere and we make use of it in CSIv2. This approach will > label > something as "custom" by having it tagged with a particular > vendors's > VMCID (a 20 bit integer) followed by a specification number within > the > scope of that vendor's definition. > > May I suggest the following text? > > 2.2.X AuthorityInfoType > > The AuthorityInfoType is used to describe the type of a message that > is > being sent/received by an authority. An example type for this is a > PKIX > Certificate Management Protocol (CMP) general message format." > > The high order 20-bits of each AuthorityInfoType constant shall > contain > the Vendor Minor Codeset ID (VMCID) of the organization that defines > the > type. The low order 12 bits shall contain the organization-scoped > type > identifier. The higher order 20-bits of each AuthorityInfoType > defined in > this specification shall be zero. > > Organizations must register their VMCIDs with the OMG before using > them to > define an AuthorityInfoType. > > > Cheers, > -Polar > > On Tue, 27 Nov 2001, Simon Gibson wrote: > > > Hi There, > > > > Here are 2 more straightforward issues that have been raised. I > have > > created 1 more issue to sort out the compliance chapter which > should be > > the last after these 2. > > > > Cheers > > > > Simon > > > > > > Issue 4477: PKI RegistrationAuthority QUERY (pki-ftf) > > > > Click here for this issue's archive. > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > Nature: Clarification > > Severity: > > > > Summary: The specification of the get_authority_info operation on > the > > RegistrationAuthority interface does seem to has sufficient > > information describing the expected semantics. I have included the > > extract of the javadoc description that I have put together based > on > > the spec, however, this isn't a sufficient description to > implement > > against. Secondly, the method and argument names don't seem to be > > symmetric with the intent of the operation. As far as I > understand, > > the operation "get_authority_info" actually serves as a > > post-message-get-reply operation, and the arguments > "AuthorityInfo" > > are actually the messages in and out. If that's correct, then both > > operation and argument types should be renamed to imply this. Any > > clarification on this would be appreciated. > > > > /** * Message exchange between a client entity and authority. For > example > > * this may provide a method for a client to determine the > authentication > > * policy of the authority. > > * > > * @param in_authority_info The encoded message input to > authority. > > * @param out_authority_info The encoded returned message from > > * authority. * @return Status value. > > * @exception UnsupportedTypeException > > * @exception UnsupportedEncodingException > > * @exception MalformedDataException > > */ > > public int get_authority_info(AuthorityInfo in_authority_info, > > AuthorityInfoHolder > out_authority_info) > > throws UnsupportedTypeException, > > UnsupportedEncodingException, MalformedDataException > > > > { return 0; } > > > > Resolution: > > > > Propose that we change the IDL parameter names to > "authority_info_req" > > and "authority_info_resp" making the intention clearer: > > > > public int get_authority_info(AuthorityInfo authority_info_req, > > AuthorityInfoHolder > authority_info_resp) > > throws UnsupportedTypeException, > > UnsupportedEncodingException, MalformedDataException > > > > { return 0; } > > > > Revised Text: > > Actions taken: > > August 5, 2001: received issue > > ----------------------------- > > Y/N/Abstain | | > > > --------------------------------------------------------------------------- > > > > > > Issue 4479: PKI AuthorityInfoType - missing documentation > (pki-ftf) > > > > Click here for this issue's archive. > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > Nature: Uncategorized Issue > > Severity: > > > > Summary: The following structure and contantns are declared in the > PKI > > IDL but are not defined within the PKI specification: > > > > typedef unsigned long AuthorityInfoType; > > const AuthorityInfoType UnkownMessage = 0; > > const AuthorityInfoType PKIXCMPGeneralMessage = 1; > > const AuthorityInfoType CustomMessage = 0x8000; > > > > Resolution: > > > > Add the following text to Chapter 2 > > > > "2.2.X AuthorityInfoType > > > > The AuthorityInfoType is used to describe the type of a message > that > > is being sent/received by an authority. An example type for this > is a > > PKIX Certificate Management Protocol (CMP) general message > format." > > > > > > Revised Text: > > Actions taken: > > August 4, 2001: received issue > > ----------------------------- > > Y/N/Abstain | | > > > --------------------------------------------------------------------------- > > > > ------------------------------------------------------------------- > 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-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 28 Nov 2001 11:49:00 -0500 (EST) From: Polar Humenn To: Simon Gibson cc: Subject: Re: Request Vote issue #4477, #4479 In-Reply-To: <200111280032.fAS0WMm19852@thunder.dstc.qut.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: QH3e9VcNd9-+3e9n-nd9 On Wed, 28 Nov 2001, Simon Gibson wrote: > Polar, > > I hadn't been aware of this VMCID stuff. It would seem actually that >this > should be done in a few places in the specification I >expect. However I > would rather that this was raised as a separate issue and later on >in an > RTF if that's OK. I have a hard deadline of the 15th of Dec to sort >out > current issues and write the report and a modified document. Would >it be > OK with you to leave the issue resolution as I have it now and then >sort > out the VMCID stuff properly later on. It can be raised as an issue >now > but I will have to defer it I think just due to time constraints. Okay, but I would suggest removing the constant "CustomMessage". -Polar > > Cheers > > Simon > > > > > Hi Simon, > > > > I would suggest in issue 4479, that instead of CustomMessage, you >use the > > VMCID stuff. That is the vendor code. It works pretty well, and is >used > > almost everywhere and we make use of it in CSIv2. This approach >will label > > something as "custom" by having it tagged with a particular >vendors's > > VMCID (a 20 bit integer) followed by a specification number within >the > > scope of that vendor's definition. > > > > May I suggest the following text? > > > > 2.2.X AuthorityInfoType > > > > The AuthorityInfoType is used to describe the type of a message >that is > > being sent/received by an authority. An example type for this is a >PKIX > > Certificate Management Protocol (CMP) general message format." > > > > The high order 20-bits of each AuthorityInfoType constant shall >contain > > the Vendor Minor Codeset ID (VMCID) of the organization that >defines the > > type. The low order 12 bits shall contain the organization-scoped >type > > identifier. The higher order 20-bits of each AuthorityInfoType >defined in > > this specification shall be zero. > > > > Organizations must register their VMCIDs with the OMG before using >them to > > define an AuthorityInfoType. > > > > > > Cheers, > > -Polar > > > > On Tue, 27 Nov 2001, Simon Gibson wrote: > > > > > Hi There, > > > > > > Here are 2 more straightforward issues that have been raised. I >have > > > created 1 more issue to sort out the compliance chapter which >should be > > > the last after these 2. > > > > > > Cheers > > > > > > Simon > > > > > > > > > Issue 4477: PKI RegistrationAuthority QUERY (pki-ftf) > > > > > > Click here for this issue's archive. > > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > > Nature: Clarification > > > Severity: > > > > > > Summary: The specification of the get_authority_info operation >on the > > > RegistrationAuthority interface does seem to has sufficient > > > information describing the expected semantics. I have included >the > > > extract of the javadoc description that I have put together >based on > > > the spec, however, this isn't a sufficient description to >implement > > > against. Secondly, the method and argument names don't seem to >be > > > symmetric with the intent of the operation. As far as I >understand, > > > the operation "get_authority_info" actually serves as a > > > post-message-get-reply operation, and the arguments >"AuthorityInfo" > > > are actually the messages in and out. If that's correct, then >both > > > operation and argument types should be renamed to imply >this. Any > > > clarification on this would be appreciated. > > > > > > /** * Message exchange between a client entity and >authority. For example > > > * this may provide a method for a client to determine the >authentication > > > * policy of the authority. > > > * > > > * @param in_authority_info The encoded message input to >authority. > > > * @param out_authority_info The encoded returned message from > > > * authority. * @return Status value. > > > * @exception UnsupportedTypeException > > > * @exception UnsupportedEncodingException > > > * @exception MalformedDataException > > > */ > > > public int get_authority_info(AuthorityInfo in_authority_info, > > > AuthorityInfoHolder >out_authority_info) > > > throws UnsupportedTypeException, > > > UnsupportedEncodingException, MalformedDataException > > > > > > { return 0; } > > > > > > Resolution: > > > > > > Propose that we change the IDL parameter names to >"authority_info_req" > > > and "authority_info_resp" making the intention clearer: > > > > > > public int get_authority_info(AuthorityInfo authority_info_req, > > > AuthorityInfoHolder >authority_info_resp) > > > throws UnsupportedTypeException, > > > UnsupportedEncodingException, MalformedDataException > > > > > > { return 0; } > > > > > > Revised Text: > > > Actions taken: > > > August 5, 2001: received issue > > > ----------------------------- > > > Y/N/Abstain | | > > > >--------------------------------------------------------------------------- > > > > > > > > > Issue 4479: PKI AuthorityInfoType - missing documentation >(pki-ftf) > > > > > > Click here for this issue's archive. > > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > > Nature: Uncategorized Issue > > > Severity: > > > > > > Summary: The following structure and contantns are declared in >the PKI > > > IDL but are not defined within the PKI specification: > > > > > > typedef unsigned long AuthorityInfoType; > > > const AuthorityInfoType UnkownMessage = 0; > > > const AuthorityInfoType PKIXCMPGeneralMessage = 1; > > > const AuthorityInfoType CustomMessage = 0x8000; > > > > > > Resolution: > > > > > > Add the following text to Chapter 2 > > > > > > "2.2.X AuthorityInfoType > > > > > > The AuthorityInfoType is used to describe the type of a message >that > > > is being sent/received by an authority. An example type for this >is a > > > PKIX Certificate Management Protocol (CMP) general message >format." > > > > > > > > > Revised Text: > > > Actions taken: > > > August 4, 2001: received issue > > > ----------------------------- > > > Y/N/Abstain | | > > > >--------------------------------------------------------------------------- > > > > > > > >------------------------------------------------------------------- > > 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 > > > > ------------------------------------------------------------------- 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.5 07/13/2001 with nmh-1.0.4 To: Polar Humenn cc: Simon Gibson , pki-ftf@omg.org, gibson@dstc.qut.edu.au Subject: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) In-Reply-To: Message from Polar Humenn of "Wed, 28 Nov 2001 11:49:00 EST." Mime-Version: 1.0 Date: Thu, 29 Nov 2001 09:46:45 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: O6(!!g$Ce9b$f!!:8Pd9 Polar, I could remove the "CustomMessage" in the IDL however there are others of this type throughout the PKL.idl and I would rather fix this consistently. We thought we were doing the right thing adding this at the time, which I think was right then. Really this needs to be sorted properly. What I suggest is: o Leave the issue resolution as I have proposed (ie including the CustomMessge constant). o I will raise an issue to deal with this suggesting the removal of all "Custom*" type constants and review to using VMCID adding appropriate text throughout and modifying IDL as needed. The downside is that I will have to defer the issue to be dealt with in an RTF. Is this acceptable to everybody? I'll change any previously lodged votes if people wish to change their vote. If they are happy with the previous decision then I will leave it as is if I don't hear otherwise. Cheers Simon > On Wed, 28 Nov 2001, Simon Gibson wrote: > > > Polar, > > > > I hadn't been aware of this VMCID stuff. It would seem actually > that this > > should be done in a few places in the specification I > expect. However I > > would rather that this was raised as a separate issue and later on > in an > > RTF if that's OK. I have a hard deadline of the 15th of Dec to > sort out > > current issues and write the report and a modified document. Would > it be > > OK with you to leave the issue resolution as I have it now and > then sort > > out the VMCID stuff properly later on. It can be raised as an > issue now > > but I will have to defer it I think just due to time constraints. > > Okay, but I would suggest removing the constant "CustomMessage". > > -Polar > > > > > Cheers > > > > Simon > > > > > > > > Hi Simon, > > > > > > I would suggest in issue 4479, that instead of CustomMessage, > you use the > > > VMCID stuff. That is the vendor code. It works pretty well, and > is used > > > almost everywhere and we make use of it in CSIv2. This approach > will label > > > something as "custom" by having it tagged with a particular > vendors's > > > VMCID (a 20 bit integer) followed by a specification number > within the > > > scope of that vendor's definition. > > > > > > May I suggest the following text? > > > > > > 2.2.X AuthorityInfoType > > > > > > The AuthorityInfoType is used to describe the type of a message > that is > > > being sent/received by an authority. An example type for this is > a PKIX > > > Certificate Management Protocol (CMP) general message format." > > > > > > The high order 20-bits of each AuthorityInfoType constant shall > contain > > > the Vendor Minor Codeset ID (VMCID) of the organization that > defines the > > > type. The low order 12 bits shall contain the > organization-scoped type > > > identifier. The higher order 20-bits of each AuthorityInfoType > defined in > > > this specification shall be zero. > > > > > > Organizations must register their VMCIDs with the OMG before > using them to > > > define an AuthorityInfoType. > > > > > > > > > Cheers, > > > -Polar > > > > > > On Tue, 27 Nov 2001, Simon Gibson wrote: > > > > > > > Hi There, > > > > > > > > Here are 2 more straightforward issues that have been > raised. I have > > > > created 1 more issue to sort out the compliance chapter which > should be > > > > the last after these 2. > > > > > > > > Cheers > > > > > > > > Simon > > > > > > > > > > > > Issue 4477: PKI RegistrationAuthority QUERY (pki-ftf) > > > > > > > > Click here for this issue's archive. > > > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > > > Nature: Clarification > > > > Severity: > > > > > > > > Summary: The specification of the get_authority_info operation > on the > > > > RegistrationAuthority interface does seem to has sufficient > > > > information describing the expected semantics. I have included > the > > > > extract of the javadoc description that I have put together > based on > > > > the spec, however, this isn't a sufficient description to > implement > > > > against. Secondly, the method and argument names don't seem > to be > > > > symmetric with the intent of the operation. As far as I > understand, > > > > the operation "get_authority_info" actually serves as a > > > > post-message-get-reply operation, and the arguments > "AuthorityInfo" > > > > are actually the messages in and out. If that's correct, then > both > > > > operation and argument types should be renamed to imply > this. Any > > > > clarification on this would be appreciated. > > > > > > > > /** * Message exchange between a client entity and > authority. For example > > > > * this may provide a method for a client to determine the > authentication > > > > * policy of the authority. > > > > * > > > > * @param in_authority_info The encoded message input to > authority. > > > > * @param out_authority_info The encoded returned message from > > > > * authority. * @return Status value. > > > > * @exception UnsupportedTypeException > > > > * @exception UnsupportedEncodingException > > > > * @exception MalformedDataException > > > > */ > > > > public int get_authority_info(AuthorityInfo in_authority_info, > > > > AuthorityInfoHolder > out_authority_info) > > > > throws UnsupportedTypeException, > > > > UnsupportedEncodingException, > MalformedDataException > > > > > > > > { return 0; } > > > > > > > > Resolution: > > > > > > > > Propose that we change the IDL parameter names to > "authority_info_req" > > > > and "authority_info_resp" making the intention clearer: > > > > > > > > public int get_authority_info(AuthorityInfo > authority_info_req, > > > > AuthorityInfoHolder > authority_info_resp) > > > > throws UnsupportedTypeException, > > > > UnsupportedEncodingException, > MalformedDataException > > > > > > > > { return 0; } > > > > > > > > Revised Text: > > > > Actions taken: > > > > August 5, 2001: received issue > > > > ----------------------------- > > > > Y/N/Abstain | | > > > > > --------------------------------------------------------------------------- > > > > > > > > > > > > Issue 4479: PKI AuthorityInfoType - missing documentation > (pki-ftf) > > > > > > > > Click here for this issue's archive. > > > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > > > Nature: Uncategorized Issue > > > > Severity: > > > > > > > > Summary: The following structure and contantns are declared in > the PKI > > > > IDL but are not defined within the PKI specification: > > > > > > > > typedef unsigned long AuthorityInfoType; > > > > const AuthorityInfoType UnkownMessage = 0; > > > > const AuthorityInfoType PKIXCMPGeneralMessage = 1; > > > > const AuthorityInfoType CustomMessage = 0x8000; > > > > > > > > Resolution: > > > > > > > > Add the following text to Chapter 2 > > > > > > > > "2.2.X AuthorityInfoType > > > > > > > > The AuthorityInfoType is used to describe the type of a > message that > > > > is being sent/received by an authority. An example type for > this is a > > > > PKIX Certificate Management Protocol (CMP) general message > format." > > > > > > > > > > > > Revised Text: > > > > Actions taken: > > > > August 4, 2001: received issue > > > > ----------------------------- > > > > Y/N/Abstain | | > > > > > --------------------------------------------------------------------------- > > > > > > > > > > > ------------------------------------------------------------------- > > > 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 > > > > > > > > > ------------------------------------------------------------------- > 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 > Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: <200111282346.fASNkkm26342@thunder.dstc.qut.edu.au> Subject: Re: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) Date: Wed, 28 Nov 2001 19:06:38 -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: @\J!!M'g!!+G"e9% To: "Polar Humenn" Sent: Wednesday, November 28, 2001 6:46 PM Subject: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) > Polar, > > I could remove the "CustomMessage" in the IDL however there are >others of > this type throughout the PKL.idl and I would rather fix this >consistently. > We thought we were doing the right thing adding this at the time, >which I > think was right then. Really this needs to be sorted properly. What >I > suggest is: > > o Leave the issue resolution as I have proposed (ie including the > CustomMessge constant). > > o I will raise an issue to deal with this suggesting the removal of >all > "Custom*" type constants and review to using VMCID adding >appropriate text > throughout and modifying IDL as needed. The downside is that I will >have > to defer the issue to be dealt with in an RTF. > > Is this acceptable to everybody? > > I'll change any previously lodged votes if people wish to change >their > vote. If they are happy with the previous decision then I will leave >it as > is if I don't hear otherwise. > > Cheers > > Simon X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "David Chizmadia" cc: pki-ftf@omg.org, gibson@dstc.qut.edu.au Subject: Re: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) In-Reply-To: Message from "David Chizmadia" of "Wed, 28 Nov 2001 19:06:38 EST." <007601c17869$b97471c0$a000a8c0@chizmadia> Mime-Version: 1.0 Date: Thu, 29 Nov 2001 10:16:07 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: `k=e9`;&e9#V;e9?^bd9 David, It is certainly a good point. Personally I would imagine that these "CustomMessages" would not even be being used. I am not fully aware of all commercial implementations but it would be unlikely to use anything beyond already defined PKI standards which I think we have covered. The Custom* constants were added trying to be complete but not really thinking they would in fact be used. I don't feel that it is a show stopper at all. Simon > Simon, > > I'd like to point out that it looks like this is a change that > would > affect client code. As such, there could be a substantial backward > compatability issue if the RTF that makes the changes extends too > far beyond > the appearance of commercial (or open source) products implementing > the > spec. > > -DMC > Promia, Inc > > ----- Original Message ----- > From: "Simon Gibson" > To: "Polar Humenn" > Sent: Wednesday, November 28, 2001 6:46 PM > Subject: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) > > > > Polar, > > > > I could remove the "CustomMessage" in the IDL however there are > others of > > this type throughout the PKL.idl and I would rather fix this > consistently. > > We thought we were doing the right thing adding this at the time, > which I > > think was right then. Really this needs to be sorted > properly. What I > > suggest is: > > > > o Leave the issue resolution as I have proposed (ie including the > > CustomMessge constant). > > > > o I will raise an issue to deal with this suggesting the removal > of all > > "Custom*" type constants and review to using VMCID adding > appropriate text > > throughout and modifying IDL as needed. The downside is that I > will have > > to defer the issue to be dealt with in an RTF. > > > > Is this acceptable to everybody? > > > > I'll change any previously lodged votes if people wish to change > their > > vote. If they are happy with the previous decision then I will > leave it as > > is if I don't hear otherwise. > > > > Cheers > > > > Simon > > From: "Stephen McConnell" To: "David Chizmadia" Cc: Subject: RE: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) Date: Thu, 29 Nov 2001 08:33:58 +0100 Message-ID: <000d01c178a8$35712190$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <007601c17869$b97471c0$a000a8c0@chizmadia> Content-Type: text/plain; charset="Windows-1252" X-UIDL: =OUd9LXP!!K5*!!)<#"! David: I don't think that a change need break client interfaces. Given that all occurrences of this of information have now been moved to state members within valuetypes, its relatively easy to add an additional state member and deprecate the old with only a minor version change. Cheers, Steve. > -----Original Message----- > From: David Chizmadia [mailto:vze2729k@verizon.net] > Sent: Thursday, 29 November, 2001 01:07 > To: pki-ftf@omg.org > Subject: Re: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) > > > Simon, > > I'd like to point out that it looks like this is a change that would > affect client code. As such, there could be a substantial backward > compatability issue if the RTF that makes the changes extends too > far beyond > the appearance of commercial (or open source) products implementing the > spec. > > -DMC > Promia, Inc > > ----- Original Message ----- > From: "Simon Gibson" > To: "Polar Humenn" > Sent: Wednesday, November 28, 2001 6:46 PM > Subject: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) > > > > Polar, > > > > I could remove the "CustomMessage" in the IDL however there are > others of > > this type throughout the PKL.idl and I would rather fix this > consistently. > > We thought we were doing the right thing adding this at the > time, which I > > think was right then. Really this needs to be sorted properly. What I > > suggest is: > > > > o Leave the issue resolution as I have proposed (ie including the > > CustomMessge constant). > > > > o I will raise an issue to deal with this suggesting the removal of all > > "Custom*" type constants and review to using VMCID adding > appropriate text > > throughout and modifying IDL as needed. The downside is that I will have > > to defer the issue to be dealt with in an RTF. > > > > Is this acceptable to everybody? > > > > I'll change any previously lodged votes if people wish to change their > > vote. If they are happy with the previous decision then I will > leave it as > > is if I don't hear otherwise. > > > > Cheers > > > > Simon > Reply-To: "David Chizmadia" From: "David Chizmadia" To: "Stephen McConnell" Cc: References: <000d01c178a8$35712190$0a01a8c0@osm.net> Subject: Re: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) Date: Thu, 29 Nov 2001 02:45:20 -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: ?6_d9Y^pd9#ghd9KF^!! From: "Stephen McConnell" > > David: > > I don't think that a change need break client interfaces. Given >that all > occurrences of this of information have now been moved to state >members > within valuetypes, its relatively easy to add an additional state >member and > deprecate the old with only a minor version change. My concern is so much breakage as affect on client code. If the client uses the information, then you - as a vendor - will have to support the state variables until you've been able to convince your customers to stop using them. I mainly wanted to point out that a rapid RTF (perhaps running only from Anaheim to Japan) would be warranted to minimize the potential pain. -DMC > Cheers, Steve. From: "Stephen McConnell" To: Subject: RE: Discuss issue 4479 (Re: Request Vote issue #4477, #4479) Date: Thu, 29 Nov 2001 09:03:00 +0100 Message-ID: <000e01c178ac$43859320$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <200111282346.fASNkkm26342@thunder.dstc.qut.edu.au> Content-Type: text/plain; charset="Windows-1252" X-UIDL: c:,e9l I could remove the "CustomMessage" in the IDL however there > are others of this type throughout the PKL.idl and I would > rather fix this consistently. > We thought we were doing the right thing adding this at the > time, which I think was right then. Really this needs to be > sorted properly. What I suggest is: > > o Leave the issue resolution as I have proposed (ie including > the CustomMessge constant). > > o I will raise an issue to deal with this suggesting the > removal of all "Custom*" type constants and review to using > VMCID adding appropriate text throughout and modifying IDL as > needed. The downside is that I will have to defer the issue > to be dealt with in an RTF. > > Is this acceptable to everybody? It's acceptable to me. > I'll change any previously lodged votes if people wish to change > their vote. If they are happy with the previous decision then I > will leave it as is if I don't hear otherwise. Please change my vote on 4479 from ABSTAIN to YES on the basis that a new issue as noted above is raised. Cheers, Steve. > Cheers > > Simon > > > On Wed, 28 Nov 2001, Simon Gibson wrote: > > > > > Polar, > > > > > > I hadn't been aware of this VMCID stuff. It would seem > actually that this > > > should be done in a few places in the specification I expect. > However I > > > would rather that this was raised as a separate issue and > later on in an > > > RTF if that's OK. I have a hard deadline of the 15th of Dec > to sort out > > > current issues and write the report and a modified document. > Would it be > > > OK with you to leave the issue resolution as I have it now > and then sort > > > out the VMCID stuff properly later on. It can be raised as an > issue now > > > but I will have to defer it I think just due to time >constraints. > > > > Okay, but I would suggest removing the constant "CustomMessage". > > > > -Polar > > > > > > > > Cheers > > > > > > Simon > > > > > > > > > > > Hi Simon, > > > > > > > > I would suggest in issue 4479, that instead of > CustomMessage, you use the > > > > VMCID stuff. That is the vendor code. It works pretty well, > and is used > > > > almost everywhere and we make use of it in CSIv2. This > approach will label > > > > something as "custom" by having it tagged with a particular > vendors's > > > > VMCID (a 20 bit integer) followed by a specification number > within the > > > > scope of that vendor's definition. > > > > > > > > May I suggest the following text? > > > > > > > > 2.2.X AuthorityInfoType > > > > > > > > The AuthorityInfoType is used to describe the type of a > message that is > > > > being sent/received by an authority. An example type for > this is a PKIX > > > > Certificate Management Protocol (CMP) general message format." > > > > > > > > The high order 20-bits of each AuthorityInfoType constant > shall contain > > > > the Vendor Minor Codeset ID (VMCID) of the organization > that defines the > > > > type. The low order 12 bits shall contain the > organization-scoped type > > > > identifier. The higher order 20-bits of each > AuthorityInfoType defined in > > > > this specification shall be zero. > > > > > > > > Organizations must register their VMCIDs with the OMG > before using them to > > > > define an AuthorityInfoType. > > > > > > > > > > > > Cheers, > > > > -Polar > > > > > > > > On Tue, 27 Nov 2001, Simon Gibson wrote: > > > > > > > > > Hi There, > > > > > > > > > > Here are 2 more straightforward issues that have been > raised. I have > > > > > created 1 more issue to sort out the compliance chapter > which should be > > > > > the last after these 2. > > > > > > > > > > Cheers > > > > > > > > > > Simon > > > > > > > > > > > > > > > Issue 4477: PKI RegistrationAuthority QUERY (pki-ftf) > > > > > > > > > > Click here for this issue's archive. > > > > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > > > > Nature: Clarification > > > > > Severity: > > > > > > > > > > Summary: The specification of the get_authority_info > operation on the > > > > > RegistrationAuthority interface does seem to has sufficient > > > > > information describing the expected semantics. I have >included the > > > > > extract of the javadoc description that I have put > together based on > > > > > the spec, however, this isn't a sufficient description to > implement > > > > > against. Secondly, the method and argument names don't seem >to be > > > > > symmetric with the intent of the operation. As far as I > understand, > > > > > the operation "get_authority_info" actually serves as a > > > > > post-message-get-reply operation, and the arguments > "AuthorityInfo" > > > > > are actually the messages in and out. If that's correct, >then both > > > > > operation and argument types should be renamed to imply >this. Any > > > > > clarification on this would be appreciated. > > > > > > > > > > /** * Message exchange between a client entity and > authority. For example > > > > > * this may provide a method for a client to determine > the authentication > > > > > * policy of the authority. > > > > > * > > > > > * @param in_authority_info The encoded message input to > authority. > > > > > * @param out_authority_info The encoded returned message >from > > > > > * authority. * @return Status value. > > > > > * @exception UnsupportedTypeException > > > > > * @exception UnsupportedEncodingException > > > > > * @exception MalformedDataException > > > > > */ > > > > > public int get_authority_info(AuthorityInfo >in_authority_info, > > > > > AuthorityInfoHolder > out_authority_info) > > > > > throws UnsupportedTypeException, > > > > > UnsupportedEncodingException, >MalformedDataException > > > > > > > > > > { return 0; } > > > > > > > > > > Resolution: > > > > > > > > > > Propose that we change the IDL parameter names to > "authority_info_req" > > > > > and "authority_info_resp" making the intention clearer: > > > > > > > > > > public int get_authority_info(AuthorityInfo >authority_info_req, > > > > > AuthorityInfoHolder > authority_info_resp) > > > > > throws UnsupportedTypeException, > > > > > UnsupportedEncodingException, >MalformedDataException > > > > > > > > > > { return 0; } > > > > > > > > > > Revised Text: > > > > > Actions taken: > > > > > August 5, 2001: received issue > > > > > ----------------------------- > > > > > Y/N/Abstain | | > > > > > > ------------------------------------------------------------------ > --------- > > > > > > > > > > > > > > > Issue 4479: PKI AuthorityInfoType - missing documentation > (pki-ftf) > > > > > > > > > > Click here for this issue's archive. > > > > > Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) > > > > > Nature: Uncategorized Issue > > > > > Severity: > > > > > > > > > > Summary: The following structure and contantns are > declared in the PKI > > > > > IDL but are not defined within the PKI specification: > > > > > > > > > > typedef unsigned long AuthorityInfoType; > > > > > const AuthorityInfoType UnkownMessage = 0; > > > > > const AuthorityInfoType PKIXCMPGeneralMessage = 1; > > > > > const AuthorityInfoType CustomMessage = 0x8000; > > > > > > > > > > Resolution: > > > > > > > > > > Add the following text to Chapter 2 > > > > > > > > > > "2.2.X AuthorityInfoType > > > > > > > > > > The AuthorityInfoType is used to describe the type of a > message that > > > > > is being sent/received by an authority. An example type > for this is a > > > > > PKIX Certificate Management Protocol (CMP) general > message format." > > > > > > > > > > > > > > > Revised Text: > > > > > Actions taken: > > > > > August 4, 2001: received issue > > > > > ----------------------------- > > > > > Y/N/Abstain | | > > > > > > ------------------------------------------------------------------ > --------- > > > > > > > > > > > > > >------------------------------------------------------------------- > > > > 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 > > > > > > > > > > > > > > >------------------------------------------------------------------- > > 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.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: Further to issue #4479 Mime-Version: 1.0 Date: Wed, 12 Dec 2001 17:26:07 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: ,_H!!fd,e9Zd;e9[a*!! Further to the previous discussions on this issue with regard to removing the "Custom*" identifiers and replacing with VMCID stuff. An issue has been raised to sort this out properly. Cheers Simon