Issue 4477: PKI RegistrationAuthority QUERY (pki-ftf) 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: see above Revised Text: Actions taken: August 5, 2001: received issue July 5, 2002: closed issue Discussion: 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; } End of Annotations:===== From: "Stephen McConnell" To: "Simon Gibson" Cc: Subject: PKI RegistrationAuthority QUERY Date: Sun, 5 Aug 2001 15:12:47 +0200 Message-ID: <000001c11db0$5283bf20$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: <000001c11d9d$84d0c530$0a01a8c0@osm.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: OSL!!O`:!!1Y]d9m;ld9 Simon (and/or anyone else on the list): 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; } Cheers, Steve. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Stephen McConnell" cc: "Simon Gibson" , pki-ftf@emerald.omg.org, gibson@dstc.qut.edu.au Subject: Re: PKI RegistrationAuthority QUERY In-Reply-To: Message from "Stephen McConnell" of "Sun, 05 Aug 2001 15:12:47 +0200." <000001c11db0$5283bf20$0a01a8c0@osm.net> Mime-Version: 1.0 Date: Mon, 06 Aug 2001 14:17:21 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: aoQ!!jkf!!?2i!!apE!! Stephen, Its good to see some action on the PKI stuff. Sorry its taken me a couple of days but you know how it is. I'm not really sure of the question. You are right in that it is a message going to the CA/RA and then receiving an answer in return, with status as the return type. The messages are of the same type. I guess the rationale comes down to the original rationale of having to deal with existing standards already out there and wrapping these. Its a trade off not reinventing the standards but using CORBA and its dist object environment. I guess I don't clearly see the problem that you have. It is a situation of sending in a message of a certain type and receiving effectively the same type back but with different content containing the answer. The idea is that we wrap a CA/RA that is already in existence that will work with existing standards and expects ASN.1 encoded messages. Simon > > Simon (and/or anyone else on the list): > > 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; > } > > Cheers, Steve. > Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: <200108060417.f764HLm01802@thunder.dstc.qut.edu.au> Subject: Re: PKI RegistrationAuthority QUERY Date: Mon, 6 Aug 2001 00:45:59 -0400 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: ,Fad9O('!!/$od9c,Td9 For what its worth, my interpretation was that Stephen was suggesting that the signature parameter names should be changed to something like: authority_info_req (in_authority_info) authority_info_resp (out_authority_info) to give a more intuitive sense of the intended semantics. -DMC ----- Original Message ----- From: "Simon Gibson" To: "Stephen McConnell" Cc: "Simon Gibson" ; ; Sent: Monday, August 06, 2001 12:17 AM Subject: Re: PKI RegistrationAuthority QUERY > Stephen, > > Its good to see some action on the PKI stuff. Sorry its taken me a >couple > of days but you know how it is. > > I'm not really sure of the question. You are right in that it is a >message > going to the CA/RA and then receiving an answer in return, with >status as > the return type. The messages are of the same type. I guess the >rationale > comes down to the original rationale of having to deal with existing > standards already out there and wrapping these. Its a trade off not > reinventing the standards but using CORBA and its dist object >environment. > I guess I don't clearly see the problem that you have. It is a >situation > of sending in a message of a certain type and receiving effectively >the > same type back but with different content containing the answer. The >idea > is that we wrap a CA/RA that is already in existence that will work >with > existing standards and expects ASN.1 encoded messages. > > Simon > > > > > Simon (and/or anyone else on the list): > > > > 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; > > } > > > > Cheers, Steve. > > > > > From: "Stephen McConnell" To: "Simon Gibson" Cc: Subject: RE: PKI RegistrationAuthority QUERY Date: Tue, 7 Aug 2001 11:53:39 +0200 Message-ID: <000001c11f26$d5d30800$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: <200108060417.f764HLm01802@thunder.dstc.qut.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: fZ"!!%9E!!P%1!!!#Rd9 Simon Gibson wrote: > > > Stephen, > > Its good to see some action on the PKI stuff. Sorry its taken me a couple > of days but you know how it is. > > I'm not really sure of the question. You are right in that it is > a message going to the CA/RA and then receiving an answer in return, > with status as the return type. The messages are of the same type. > I guess the rationale comes down to the original rationale of having > to deal with existing standards already out there and wrapping these. > Its a trade off not reinventing the standards but using CORBA and > its dist object environment. > I guess I don't clearly see the problem that you have. It is a situation > of sending in a message of a certain type and receiving effectively the > same type back but with different content containing the answer. The idea > is that we wrap a CA/RA that is already in existence that will work with > existing standards and expects ASN.1 encoded messages. There are two issues here: (a) the "naming of types and operation" (as David noted - these need to more clearly reflect the implied intent). AuthorityInfoType should be renamed to MessageType and the operation on the CA interface should be renamed from "get_authority_info" to something like "query". (b) the documentation in the spec and IDL should not assume that the developer understands what a PKIXCMPGeneralMessage, implies - as a very minimum we should be including explicit references to the documents defining this - and preferably, text in the spec and IDL that a developer can quickly digest in order to proceed with implementation. This point also applies to the documentation on things like certificate request type constants, encoding constants and so on. Cheers, Steve. > Simon > > > > > Simon (and/or anyone else on the list): > > > > 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; > > } > > > > Cheers, Steve. > > > 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-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