Issue 4330: How to Partition the AuthorizationElementType regarding vendor extensions (csiv2-ftf) Source: Sun Microsystems (Mr. Ron Monzillo, ronald.monzillo@east.sun.com) Nature: Uncategorized Issue Severity: Summary: We should define how the namespace of AuthorizationElementType identifiers (used in authorization tokens) is to be partitioned so that individual vendors have some identifiers reserved for their use (i.e. the definition of vendor specific type identifiers). Resolution: Close issue with revised text. Revised Text: base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] add the definition of the OMG VMCID constant to section 16.9.3 Module CSI (Note that this change was also proposed as part of the resolution to issue 4268). // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. const unsigned long OMGVMCID = 0x4F4D0; [2] Add two new paragraphs following para 32. The high order 20-bits of each AuthorizationElementType constant shall contain the Vendor Minor Codeset ID (VMCID) of the organization that defined the element type. The low order 12 bits shall contain the organization-scoped element type identifier. The high-order 20 bits of all element types defined by the OMG shall contain the VMCID allocated to the OMG (that is, 0x4F4D0). Organizations must register their VMCIDs with the OMG before using them to define an AuthorizationElementType. [3] Add the following comment in front of the definition of the AuthorizationElementType in section 16.9.3 Module CSI // The high order 20-bits of each AuthorizationElementType constant // shall contain the Vendor Minor Codeset ID (VMCID) of the // organization that defined the element type. The low order 12 bits // shall contain the organization-scoped element type identifier. The // high-order 20 bits of all element types defined by the OMG shall // contain the VMCID allocated to the OMG (that is, 0x4F4D0). [4] change the defintion of the X509AttributeCertChain constant in a. the IDL following para 32 b. in section 16.9.3 Module CSI to: const AuthorizationElementType X509AttributeCertChain = OMGVMCID | 1; [5] remove the definition of the ORGVMCID constant and accompanying comment from: a. the IDL following para 147 (what was the first para following the heading struct SAS_ContextSec) b. section 16.9.4 Module CSIIOP that is, remove the following: // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. const unsigned long OMGVMCID = 0x4F4D0; [6] change the defintion of the ServiceConfigurationSyntax constants in a. the IDL following para 147 (what was the first para following the heading struct SAS_ContextSec) b. in section 16.9.4 Module CSIIOP to: const ServiceConfigurationSyntax SCS_GeneralNames = CSI::OMGVMCID | 0; const ServiceConfigurationSyntax SCS_GSSExportedName = CSI::OMGVMCID | 1; Actions taken: June 1, 2001: received issue October 3, 2001: closed issue Discussion: The resolution to Issue 4268 (How to Partition the ServiceConfiguration syntax space to support vendor specific extensions) should be applied to the AuthorizationElementType identifier. This resolution also corrects an error in the resolution to issue 4268 as described in items 5 and 6. It consists mainly of declaring the OMGVMCID constant in the CSI module instead of in the CSIIOP module as was originally done in the resolution for 4268. End of Annotations:===== Date: Thu, 31 May 2001 20:11:05 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org, issues@omg.org Subject: ISSUE: CSIv2 How to Partition the AuthorizationElementType identifier space to support vendor extensions Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3kX!!K`S!!<%o!!=-X!! base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf Description: We should define how the namespace of AuthorizationElementType identifiers (used in authorization tokens) is to be partitioned so that individual vendors have some identifiers reserved for their use (i.e. the definition of vendor specific type identifiers). Date: Mon, 11 Jun 2001 15:13:59 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: csiv2-ftf@omg.org Subject: Issue 4330: Proposed resolution Content-Type: multipart/mixed; boundary="------------E6F53F563FB36B91741B689D" X-UIDL: &@A!!FHVd9\Kd!!X:Ie9 Jishnu, Please include the following proposed resolution in the vote that you describe in > 3. The next and last vote (barring any unforseen need for a fixup > additional vote) will go out on Monday June 11, and be due back by > Friday June 15. Thanks, Ron Issue 4330: How to Partition the AuthorizationElementType regarding vendor extensions (csiv2-ftf) Click here for this issue's archive Source: Sun Microsystems (Mr. Ron Monzillo, ronald.monzillo@east.sun.com) Nature: Uncategorized Issue Severity: Summary: We should define how the namespace of AuthorizationElementType identifiers (used in authorization tokens) is to be partitioned so that individual vendors have some identifiers reserved for their use (i.e. the definition of vendor specific type identifiers). Discussion: The resolution to Issue 4268 (How to Partition the ServiceConfiguration syntax space to support vendor specific extensions) should be applied to the AuthorizationElementType identifier. Resolution: Close issue with revised text. Revised Text: base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] add the definition of the OMG VMCID constant to section 16.9.3 Module CSI (Note that this change was also proposed as part of the resolution to issue 4268). // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. const unsigned long OMGVMCID = 0x4F4D0; [2] Add two new paragraphs following para 32. The high order 20-bits of each AuthorizationElementType constant shall contain the Vendor Minor Codeset ID (VMCID) of the organization that defined the element type. The low order 12 bits shall contain the organization-scoped element type identifier. The high-order 20 bits of all element types defined by the OMG shall contain the VMCID allocated to the OMG (that is, 0x4F4D0). Organizations must register their VMCIDs with the OMG before using them to define an AuthorizationElementType. [3] add the following comment in front of the definition of the AuthorizationElementType in section 16.9.3 Module CSI // The high order 20-bits of each AuthorizationElementType constant // shall contain the Vendor Minor Codeset ID (VMCID) of the // organization that defined the element type. The low order 12 bits // shall contain the organization-scoped element type identifier. The // high-order 20 bits of all element types defined by the OMG shall // contain the VMCID allocated to the OMG (that is, 0x4F4D0). [4] change the defintion of the X509AttributeCertChain contant in a. the IDL following para 32 b. in section 16.9.3 Module CSI to: const AuthorizationElementType X509AttributeCertChain = OMGVMCID | 1; Actions taken: June 01, 2001: received issue June XX, 2001: closed issue Date: Mon, 11 Jun 2001 15:55:45 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo Cc: csiv2-ftf@omg.org Subject: Re: Issue 4330: Proposed resolution References: <3B251877.DC1539FC@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `UCe9^_=e9l/7e9%/h!! Since this proposal has not been available for the perusal of the FTF until this afternoon, it would be inappropriate to place it on the vote that is going out this afternoon. However, if there are no objections, since the resolutions appears to be pretty inauccuous, I will be happy to run it in a special vote that will go out on Wednesday and be due on Friday. So, if any of you have any objections please make it known ASAP, at least to me. Also please review the proposal and make sure that you get any modifications that you'd like discussed and incorporated before Wednesday. After it goes out for vote on Wednesday (if it does), ifany problems are discovered, then I will be forced to simply cancel the vote since there will be no time to fix the problem and revote. Thanks, Jishnu. > Ron Monzillo wrote: > > Jishnu, > > Please include the following proposed resolution in the > vote that you describe in > > > 3. The next and last vote (barring any unforseen need for a fixup > > additional vote) will go out on Monday June 11, and be due back by > > Friday June 15. > > Thanks, > > Ron > > --------------------------------------------------------------- > > Issue 4330: How to Partition the AuthorizationElementType regarding > vendor extensions (csiv2-ftf) > > Click here for this issue's archive > Source: Sun Microsystems (Mr. Ron Monzillo, > ronald.monzillo@east.sun.com) > Nature: Uncategorized Issue > Severity: > Summary: We should define how the namespace of > AuthorizationElementType identifiers (used in authorization tokens) > is > to > be partitioned so that individual vendors have some identifiers > reserved for their use (i.e. the definition of vendor specific type > identifiers). > > Discussion: > > The resolution to Issue 4268 (How to Partition the > ServiceConfiguration syntax > space to support vendor specific extensions) should be applied to > the > AuthorizationElementType identifier. > > Resolution: > > Close issue with revised text. > > Revised Text: > > base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > [1] add the definition of the OMG VMCID constant to section 16.9.3 > Module CSI (Note that this change was also proposed as part of > the resolution to issue 4268). > > // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. > > const unsigned long OMGVMCID = 0x4F4D0; > > [2] Add two new paragraphs following para 32. > > The high order 20-bits of each AuthorizationElementType constant > shall contain the Vendor Minor Codeset ID (VMCID) of the > organization that defined the element type. The low order 12 bits > shall contain the organization-scoped element type identifier. The > high-order 20 bits of all element types defined by the OMG shall > contain the VMCID allocated to the OMG (that is, 0x4F4D0). > > Organizations must register their VMCIDs with the OMG before > using them to define an AuthorizationElementType. > > [3] add the following comment in front of the definition of the > AuthorizationElementType in section 16.9.3 Module CSI > > // The high order 20-bits of each AuthorizationElementType constant > // shall contain the Vendor Minor Codeset ID (VMCID) of the > // organization that defined the element type. The low order 12 bits > // shall contain the organization-scoped element type > identifier. The > // high-order 20 bits of all element types defined by the OMG shall > // contain the VMCID allocated to the OMG (that is, 0x4F4D0). > > [4] change the defintion of the X509AttributeCertChain contant in > > a. the IDL following para 32 > b. in section 16.9.3 Module CSI > > to: > > const AuthorizationElementType X509AttributeCertChain = OMGVMCID | > 1; > > Actions taken: > June 01, 2001: received issue > June XX, 2001: closed issue -- Jishnu Mukerji Senior Systems Architect EIAL, Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jishnu_mukerji@hp.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 11 Jun 2001 18:44:05 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Subject: Re: Issue 4330: Proposed resolution In-Reply-To: <3B252241.C27239AD@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: gE^!!P)%e9@n2e9jISd9 Hi Jishnu, Question, are VETOs in FTF/RTFs final? Can they be overridden, you know, like in Congress? :) Cheers, -Polar On Mon, 11 Jun 2001, Jishnu Mukerji wrote: > Since this proposal has not been available for the perusal of the FTF > until this afternoon, it would be inappropriate to place it on the vote > that is going out this afternoon. > > However, if there are no objections, since the resolutions appears to be > pretty inauccuous, I will be happy to run it in a special vote that will > go out on Wednesday and be due on Friday. So, if any of you have any > objections please make it known ASAP, at least to me. Also please review > the proposal and make sure that you get any modifications that you'd > like discussed and incorporated before Wednesday. After it goes out for > vote on Wednesday (if it does), ifany problems are discovered, then I > will be forced to simply cancel the vote since there will be no time to > fix the problem and revote. > > Thanks, > > Jishnu. > > > Ron Monzillo wrote: > > > > Jishnu, > > > > Please include the following proposed resolution in the > > vote that you describe in > > > > > 3. The next and last vote (barring any unforseen need for a fixup > > > additional vote) will go out on Monday June 11, and be due back by > > > Friday June 15. > > > > Thanks, > > > > Ron > > > > --------------------------------------------------------------- > > > > Issue 4330: How to Partition the AuthorizationElementType regarding > > vendor extensions (csiv2-ftf) > > > > Click here for this issue's archive > > Source: Sun Microsystems (Mr. Ron Monzillo, > > ronald.monzillo@east.sun.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: We should define how the namespace of > > AuthorizationElementType identifiers (used in authorization tokens) is > > to > > be partitioned so that individual vendors have some identifiers > > reserved for their use (i.e. the definition of vendor specific type > > identifiers). > > > > Discussion: > > > > The resolution to Issue 4268 (How to Partition the > > ServiceConfiguration syntax > > space to support vendor specific extensions) should be applied to the > > AuthorizationElementType identifier. > > > > Resolution: > > > > Close issue with revised text. > > > > Revised Text: > > > > base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > [1] add the definition of the OMG VMCID constant to section 16.9.3 > > Module CSI (Note that this change was also proposed as part of > > the resolution to issue 4268). > > > > // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. > > > > const unsigned long OMGVMCID = 0x4F4D0; > > > > [2] Add two new paragraphs following para 32. > > > > The high order 20-bits of each AuthorizationElementType constant > > shall contain the Vendor Minor Codeset ID (VMCID) of the > > organization that defined the element type. The low order 12 bits > > shall contain the organization-scoped element type identifier. The > > high-order 20 bits of all element types defined by the OMG shall > > contain the VMCID allocated to the OMG (that is, 0x4F4D0). > > > > Organizations must register their VMCIDs with the OMG before > > using them to define an AuthorizationElementType. > > > > [3] add the following comment in front of the definition of the > > AuthorizationElementType in section 16.9.3 Module CSI > > > > // The high order 20-bits of each AuthorizationElementType constant > > // shall contain the Vendor Minor Codeset ID (VMCID) of the > > // organization that defined the element type. The low order 12 bits > > // shall contain the organization-scoped element type identifier. The > > // high-order 20 bits of all element types defined by the OMG shall > > // contain the VMCID allocated to the OMG (that is, 0x4F4D0). > > > > [4] change the defintion of the X509AttributeCertChain contant in > > > > a. the IDL following para 32 > > b. in section 16.9.3 Module CSI > > > > to: > > > > const AuthorizationElementType X509AttributeCertChain = OMGVMCID | 1; > > > > Actions taken: > > June 01, 2001: received issue > > June XX, 2001: closed issue > > -- > Jishnu Mukerji > Senior Systems Architect > EIAL, Hewlett-Packard Company > 300 Campus Drive, MS 2E-62 > Florham Park NJ 07932, USA > +1 973 443 7528 > jishnu_mukerji@hp.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-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 12 Jun 2001 10:33:51 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Subject: Re: Issue 4330: Proposed resolution In-Reply-To: <3B252241.C27239AD@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \>)!!`6jd9$E3!!/XZd9 Greetings, I will formally object to the issue of a special vote on the proposed resolution to issue 4330. As Jishnu stated, there has not been any discussion in the group on this issue. Furthermore, the issue was introduced after the comment deadline, not that the comment deadline really means much. :) Anyway, since this FTF, as it stands, will not be able to resolve several important issues, due to VETOs and other things, there will be several issues left open and unresolved. So, one more issue being left open isn't going to matter much. Furthermore, we might consider an extension to the FTF to get these issues resolved properly and forge a complete and technically good protocol standard. Cheers, -Polar On Mon, 11 Jun 2001, Jishnu Mukerji wrote: > Since this proposal has not been available for the perusal of the FTF > until this afternoon, it would be inappropriate to place it on the vote > that is going out this afternoon. > > However, if there are no objections, since the resolutions appears to be > pretty inauccuous, I will be happy to run it in a special vote that will > go out on Wednesday and be due on Friday. So, if any of you have any > objections please make it known ASAP, at least to me. Also please review > the proposal and make sure that you get any modifications that you'd > like discussed and incorporated before Wednesday. After it goes out for > vote on Wednesday (if it does), ifany problems are discovered, then I > will be forced to simply cancel the vote since there will be no time to > fix the problem and revote. > > Thanks, > > Jishnu. > > > Ron Monzillo wrote: > > > > Jishnu, > > > > Please include the following proposed resolution in the > > vote that you describe in > > > > > 3. The next and last vote (barring any unforseen need for a fixup > > > additional vote) will go out on Monday June 11, and be due back by > > > Friday June 15. > > > > Thanks, > > > > Ron > > > > --------------------------------------------------------------- > > > > Issue 4330: How to Partition the AuthorizationElementType regarding > > vendor extensions (csiv2-ftf) > > > > Click here for this issue's archive > > Source: Sun Microsystems (Mr. Ron Monzillo, > > ronald.monzillo@east.sun.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: We should define how the namespace of > > AuthorizationElementType identifiers (used in authorization tokens) is > > to > > be partitioned so that individual vendors have some identifiers > > reserved for their use (i.e. the definition of vendor specific type > > identifiers). > > > > Discussion: > > > > The resolution to Issue 4268 (How to Partition the > > ServiceConfiguration syntax > > space to support vendor specific extensions) should be applied to the > > AuthorizationElementType identifier. > > > > Resolution: > > > > Close issue with revised text. > > > > Revised Text: > > > > base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > [1] add the definition of the OMG VMCID constant to section 16.9.3 > > Module CSI (Note that this change was also proposed as part of > > the resolution to issue 4268). > > > > // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. > > > > const unsigned long OMGVMCID = 0x4F4D0; > > > > [2] Add two new paragraphs following para 32. > > > > The high order 20-bits of each AuthorizationElementType constant > > shall contain the Vendor Minor Codeset ID (VMCID) of the > > organization that defined the element type. The low order 12 bits > > shall contain the organization-scoped element type identifier. The > > high-order 20 bits of all element types defined by the OMG shall > > contain the VMCID allocated to the OMG (that is, 0x4F4D0). > > > > Organizations must register their VMCIDs with the OMG before > > using them to define an AuthorizationElementType. > > > > [3] add the following comment in front of the definition of the > > AuthorizationElementType in section 16.9.3 Module CSI > > > > // The high order 20-bits of each AuthorizationElementType constant > > // shall contain the Vendor Minor Codeset ID (VMCID) of the > > // organization that defined the element type. The low order 12 bits > > // shall contain the organization-scoped element type identifier. The > > // high-order 20 bits of all element types defined by the OMG shall > > // contain the VMCID allocated to the OMG (that is, 0x4F4D0). > > > > [4] change the defintion of the X509AttributeCertChain contant in > > > > a. the IDL following para 32 > > b. in section 16.9.3 Module CSI > > > > to: > > > > const AuthorizationElementType X509AttributeCertChain = OMGVMCID | 1; > > > > Actions taken: > > June 01, 2001: received issue > > June XX, 2001: closed issue > > -- > Jishnu Mukerji > Senior Systems Architect > EIAL, Hewlett-Packard Company > 300 Campus Drive, MS 2E-62 > Florham Park NJ 07932, USA > +1 973 443 7528 > jishnu_mukerji@hp.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 Date: Tue, 12 Jun 2001 11:17:19 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: csiv2-ftf@omg.org Subject: Re: Issue 4330: Proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: C8Z!!_@E!!#O[d9j%P!! Polar Humenn wrote: > > Hi Jishnu, > > Question, are VETOs in FTF/RTFs final? Can they be overridden, you know, > like in Congress? :) Vetos are final. They cannot be overridden. Implmenters have absolute right to protect their implementation until the end of the veto period. Jishnu. Date: Tue, 12 Jun 2001 11:23:28 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: csiv2-ftf@omg.org Subject: Re: Issue 4330: Proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _\(!!e/!"![kj!!i7H!! Polar Humenn wrote: > > Greetings, > > I will formally object to the issue of a special vote on the proposed > resolution to issue 4330. As Jishnu stated, there has not been any > discussion in the group on this issue. Furthermore, the issue was > introduced after the comment deadline, not that the comment deadline > really means much. :) Actually, the issue has been discussed in the last teleconference. The exact detail of the proposed text change is the only thing that needs review. > Anyway, since this FTF, as it stands, will not be able to resolve several > important issues, due to VETOs and other things, there will be several > issues left open and unresolved. So, one more issue being left open isn't > going to matter much. Vetos absolutely and finally resolve the issues at least until the end of the veto period, or unless the vetoer wants the issue to be reconsidered. > Furthermore, we might consider an extension to the FTF to get these issues > resolved properly and forge a complete and technically good protocol > standard. I meant to ask whether you had any technical objections. How do you exactly plan to resolve issues that have been vetoed in any other way before the end of the veto period beats me. Could you please explain what you had in mind? Thanks, Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 12 Jun 2001 13:22:15 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Subject: Re: Issue 4330: Proposed resolution In-Reply-To: <3B2633F0.30668210@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: W,0e9TNH!!@c8!!%c+e9 On Tue, 12 Jun 2001, Jishnu Mukerji wrote: > > > Polar Humenn wrote: > > > > Greetings, > > > > I will formally object to the issue of a special vote on the >proposed > > resolution to issue 4330. As Jishnu stated, there has not been any > > discussion in the group on this issue. Furthermore, the issue was > > introduced after the comment deadline, not that the comment >deadline > > really means much. :) > > Actually, the issue has been discussed in the last >teleconference. The > exact detail of the proposed text change is the only thing that >needs > review. Hmmm. I didn't realize that there was a teleconference, since it wasn't publicized that it was going to happen and what the agenda was. I guess that must be my fault. :( If I remember correctly, you didn't realize that teleconference was taking place, either? Correct? Also, I heard no one answer your plea to tell us what happened at the teleconference. This is the first I have heard of this issue being discussed. > > Anyway, since this FTF, as it stands, will not be able to resolve several > > important issues, due to VETOs and other things, there will be several > > issues left open and unresolved. So, one more issue being left open isn't > > going to matter much. > > Vetos absolutely and finally resolve the issues at least until the end > of the veto period, or unless the vetoer wants the issue to be > reconsidered. This is strange. Is that an "issue" or a particular "resolution" to an issue. Does this mean we cannot bring up another resolution to an issue without the VETOer's initiative? > > Furthermore, we might consider an extension to the FTF to get these issues > > resolved properly and forge a complete and technically good protocol > > standard. > > I meant to ask whether you had any technical objections. But you didn't. You asked for objections from *anybody*, and I gave you one. > How do you exactly plan to resolve issues that have been vetoed in any > other way before the end of the veto period beats me. Could you please > explain what you had in mind? By extending the FTF to after the VETO period, of course! :^) Not unbelievable, eh? Didn't the Components FTF get extended beyond the VETO period? Cheers, -Polar > Thanks, > > Jishnu. > ------------------------------------------------------------------- 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 Date: Tue, 12 Jun 2001 14:34:03 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: csiv2-ftf@omg.org Subject: Re: Issue 4330: Proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5?~e9o[S!!*49!!XnA!! Polar Humenn wrote: > > On Tue, 12 Jun 2001, Jishnu Mukerji wrote: > > > > > > > Polar Humenn wrote: > > > > > > Greetings, > > > > > > I will formally object to the issue of a special vote on the proposed > > > resolution to issue 4330. As Jishnu stated, there has not been any > > > discussion in the group on this issue. Furthermore, the issue was > > > introduced after the comment deadline, not that the comment deadline > > > really means much. :) > > > > Actually, the issue has been discussed in the last teleconference. The > > exact detail of the proposed text change is the only thing that needs > > review. > > Hmmm. I didn't realize that there was a teleconference, since it wasn't > publicized that it was going to happen and what the agenda was. > > I guess that must be my fault. :( > > If I remember correctly, you didn't realize that teleconference was taking > place, either? Correct? Also, I heard no one answer your plea to tell us > what happened at the teleconference. This is the first I have heard of > this issue being discussed. This was discussed at the teleconference where you were there, since you were the one that wanted to split this one out in a separate issue. > > > Anyway, since this FTF, as it stands, will not be able to resolve several > > > important issues, due to VETOs and other things, there will be several > > > issues left open and unresolved. So, one more issue being left open isn't > > > going to matter much. > > > > Vetos absolutely and finally resolve the issues at least until the end > > of the veto period, or unless the vetoer wants the issue to be > > reconsidered. > > This is strange. Is that an "issue" or a particular "resolution" to an > issue. Does this mean we cannot bring up another resolution to an issue > without the VETOer's initiative? Generally no, if the resolution pretty much tries to achieve the same goal as of the original resolution. > > > Furthermore, we might consider an extension to the FTF to get these issues > > > resolved properly and forge a complete and technically good protocol > > > standard. > > > > I meant to ask whether you had any technical objections. > > But you didn't. You asked for objections from *anybody*, and I gave you > one. Well, now that this matter is clarified, do you have a technical objection? Or are you just indulging in an exercise to make everyone's life miserable because your baby was vetoed?:-) > > How do you exactly plan to resolve issues that have been vetoed in any > > other way before the end of the veto period beats me. Could you please > > explain what you had in mind? > > By extending the FTF to after the VETO period, of course! :^) You really are a spiteful guy, aren't you?:-) Could you explain why it would be a good thing for OMG and its members to delay finalization, thus leading to this technology not being part of J2EE, and even if it is, OMG not getting the credit for having carried out the task? > Not unbelievable, eh? Didn't the Components FTF get extended beyond the > VETO period? That's mainly 'cause there was no implementation in sight. Somewhat different scenario from the current one I think. As son as implementations of bits and pieces became available, the piece parts were finalized pronto. Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 12 Jun 2001 14:36:35 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Subject: Re: Issue 4330: Proposed resolution In-Reply-To: <3B26609B.AEFD7628@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: R;Od9Eh[d9_n;!!*M[!! I just want a technically good, sound, and complete protocol without any holes, and obvious deficiencies, since a lot of this protocol might be securing our critical infrastructure. Unfortunately, there will be important issues that will not be resolved, and they will not be resolved until after the VETO power on CSIv2 is expired. Oh well. :) Cheers, -Polar On Tue, 12 Jun 2001, Jishnu Mukerji wrote: > > > Polar Humenn wrote: > > > > On Tue, 12 Jun 2001, Jishnu Mukerji wrote: > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > Greetings, > > > > > > > > I will formally object to the issue of a special vote on the >proposed > > > > resolution to issue 4330. As Jishnu stated, there has not been >any > > > > discussion in the group on this issue. Furthermore, the issue >was > > > > introduced after the comment deadline, not that the comment >deadline > > > > really means much. :) > > > > > > Actually, the issue has been discussed in the last >teleconference. The > > > exact detail of the proposed text change is the only thing that >needs > > > review. > > > > Hmmm. I didn't realize that there was a teleconference, since it >wasn't > > publicized that it was going to happen and what the agenda was. > > > > I guess that must be my fault. :( > > > > If I remember correctly, you didn't realize that teleconference >was taking > > place, either? Correct? Also, I heard no one answer your plea to >tell us > > what happened at the teleconference. This is the first I have >heard of > > this issue being discussed. > > This was discussed at the teleconference where you were there, since >you > were the one that wanted to split this one out in a separate issue. > > > > > Anyway, since this FTF, as it stands, will not be able to >resolve several > > > > important issues, due to VETOs and other things, there will be >several > > > > issues left open and unresolved. So, one more issue being left >open isn't > > > > going to matter much. > > > > > > Vetos absolutely and finally resolve the issues at least until >the end > > > of the veto period, or unless the vetoer wants the issue to be > > > reconsidered. > > > > This is strange. Is that an "issue" or a particular "resolution" >to an > > issue. Does this mean we cannot bring up another resolution to an >issue > > without the VETOer's initiative? > > Generally no, if the resolution pretty much tries to achieve the >same > goal as of the original resolution. > > > > > Furthermore, we might consider an extension to the FTF to get >these issues > > > > resolved properly and forge a complete and technically good >protocol > > > > standard. > > > > > > I meant to ask whether you had any technical objections. > > > > But you didn't. You asked for objections from *anybody*, and I >gave you > > one. > > Well, now that this matter is clarified, do you have a technical > objection? Or are you just indulging in an exercise to make >everyone's > life miserable because your baby was vetoed?:-) > > > > How do you exactly plan to resolve issues that have been vetoed >in any > > > other way before the end of the veto period beats me. Could you >please > > > explain what you had in mind? > > > > By extending the FTF to after the VETO period, of course! :^) > > You really are a spiteful guy, aren't you?:-) > > Could you explain why it would be a good thing for OMG and its >members > to delay finalization, thus leading to this technology not being >part of > J2EE, and even if it is, OMG not getting the credit for having >carried > out the task? > > > Not unbelievable, eh? Didn't the Components FTF get extended >beyond the > > VETO period? > > That's mainly 'cause there was no implementation in sight. Somewhat > different scenario from the current one I think. As son as > implementations of bits and pieces became available, the piece parts > were finalized pronto. > > Jishnu. > ------------------------------------------------------------------- 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 more waving of the p&p follows...not recorded -Juergen Date: Wed, 13 Jun 2001 15:30:27 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com, csiv2-ftf@omg.org Subject: Proposed resolution to Issue 4330 Content-Type: multipart/mixed; boundary="------------7C7FD2DAE216DF09F8BDE249" X-UIDL: ]0Xd9-Ve!!#07e9QJk!! Jishnu, Please place the attached resolution up for vote. Thanks. Issue 4330: How to Partition the AuthorizationElementType regarding vendor extensions (csiv2-ftf) Click here for this issue's archive Source: Sun Microsystems (Mr. Ron Monzillo, ronald.monzillo@east.sun.com) Nature: Uncategorized Issue Severity: Summary: We should define how the namespace of AuthorizationElementType identifiers (used in authorization tokens) is to be partitioned so that individual vendors have some identifiers reserved for their use (i.e. the definition of vendor specific type identifiers). Discussion: The resolution to Issue 4268 (How to Partition the ServiceConfiguration syntax space to support vendor specific extensions) should be applied to the AuthorizationElementType identifier. The resolution to Issue 4330 has been accepted by vote in the FTF. The resolution to 4330 (this issue) assumes that the resolution to 4268 has already been applied. Resolution: Close issue with revised text. Revised Text: base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf + 4268 resolution [1] add the definition of the OMG VMCID constant to section 16.9.3 Module CSI. // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. const unsigned long OMGVMCID = 0x4F4D0; [2] Add two new paragraphs following para 32. The high order 20-bits of each AuthorizationElementType constant shall contain the Vendor Minor Codeset ID (VMCID) of the organization that defined the element type. The low order 12 bits shall contain the organization-scoped element type identifier. The high-order 20 bits of all element types defined by the OMG shall contain the VMCID allocated to the OMG (that is, 0x4F4D0). Organizations must register their VMCIDs with the OMG before using them to define an AuthorizationElementType. [3] add the following comment in front of the definition of the AuthorizationElementType in section 16.9.3 Module CSI // The high order 20-bits of each AuthorizationElementType constant // shall contain the Vendor Minor Codeset ID (VMCID) of the // organization that defined the element type. The low order 12 bits // shall contain the organization-scoped element type identifier. The // high-order 20 bits of all element types defined by the OMG shall // contain the VMCID allocated to the OMG (that is, 0x4F4D0). [4] change the defintion of the X509AttributeCertChain contant in a. the IDL following para 32 b. in section 16.9.3 Module CSI to: const AuthorizationElementType X509AttributeCertChain = OMGVMCID | 1; [5] remove the definition of the ORGVMCID constant and accompanying comment from: a. the IDL following para 147 (what was the first para following the heading struct SAS_ContextSec) b. section 16.9.4 Module CSIIOP that is, remove the following: // The OMG VMCID; same value as CORBA::OMGVMCID. Do not change ever. const unsigned long OMGVMCID = 0x4F4D0; [6] change the defintion of the ServiceConfigurationSyntax contants in a. the IDL following para 147 (what was the first para following the heading struct SAS_ContextSec) b. in section 16.9.4 Module CSIIOP to: const ServiceConfigurationSyntax SCS_GeneralNames = CSI::OMGVMCID | 0; const ServiceConfigurationSyntax SCS_GSSExportedName = CSI::OMGVMCID | 1; Actions taken: June 01, 2001: received issue June XX, 2001: closed issue