Issue 4618: Changing VSCID prefix to 24 bits (interop) Source: (Mr. Andrew Watson, ) Nature: Uncategorized Issue Severity: Summary: In section 13.6.8 of CORBA 2.4.2 (formal/01/02-01), at the top of page 13-29, it says: The high-order 20 bits of service-context ID contain a 20-bit vendor service context codeset ID (VSCID); the low-order 12 bits contain the rest of the service context ID. A vendor (or group of vendors) who wish to define a specific set of system exception minor codes should obtain a unique VSCID from the OMG, and then define a specific set of service context IDs using the VSCID for the high-order bits. The VSCID of zero is reserved for use for OMG-defined standard service context IDs (i.e., service context IDs in the range 0-4095 are reserved as OMG standard service contexts). The VSCID-related text was added by the Interop 1.2 RTF as per RTF report as in document number interop/98-01-04, and revised pages as in document number interop/98-01-03. However, at about the same time OMG staff established a convention that OMG should allocate vendors a 24-bit "service tag", which is in fact the same as a VSCID. Since then, some 47 of these 24 bit service tags have been assigned to various vendors. At the risk of having the tail wag the dog, I propose we resolve this conflict by revising these paragraphs in the CORBA spec as follows: The high-order 24 bits of a service context ID contain a 24-bit vendor service context codeset ID (VSCID); the low-order 8 bits contain the rest of the service context ID. A vendor (or group of vendors) who wishes to define a specific set of system exception minor codes should obtain a unique VSCID from the OMG, and then define a specific set of service context IDs using the VSCID for the high-order bits. The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for use for OMG-defined standard service context IDs (i.e., service context IDs in the range 0-4095 are reserved as OMG standard service contexts). Resolution: see below Revised Text: Change the last two paragraphs of section 13.7 on page 13-30 to read: The high-order 24 bits of a service context ID contain a 24-bit vendor ser-vice context codeset ID (VSCID); the low-order 8 bits contain the rest of the service context ID. A vendor (or group of vendors) who wishes to define a specific set of service context IDs should obtain a unique VSCID from the OMG, and then define a specific set of service context IDs using the VSCID for the high-order bits. The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for use for OMG-defined standard service context IDs (i.e., service con-text IDs in the range 0-4095 are reserved as OMG standard service con-texts). Actions taken: October 12, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== X-Sender: andrew@192.67.184.65 Message-Id: Mime-Version: 1.0 Date: Fri, 12 Oct 2001 18:31:11 +0100 To: issues@omg.org From: Andrew Watson Subject: Changing VSCID prefix to 24 bits Content-Type: text/plain; charset="us-ascii" X-UIDL: U4,e93`F!!"(Yd9>i-!! This is an Interop RTF issue. In section 13.6.8 of CORBA 2.4.2 (formal/01/02-01), at the top of page 13-29, it says: The high-order 20 bits of service-context ID contain a 20-bit vendor service context codeset ID (VSCID); the low-order 12 bits contain the rest of the service context ID. A vendor (or group of vendors) who wish to define a specific set of system exception minor codes should obtain a unique VSCID from the OMG, and then define a specific set of service context IDs using the VSCID for the high-order bits. The VSCID of zero is reserved for use for OMG-defined standard service context IDs (i.e., service context IDs in the range 0-4095 are reserved as OMG standard service contexts). The VSCID-related text was added by the Interop 1.2 RTF as per RTF report as in document number interop/98-01-04, and revised pages as in document number interop/98-01-03. However, at about the same time OMG staff established a convention that OMG should allocate vendors a 24-bit "service tag", which is in fact the same as a VSCID. Since then, some 47 of these 24 bit service tags have been assigned to various vendors. At the risk of having the tail wag the dog, I propose we resolve this conflict by revising these paragraphs in the CORBA spec as follows: The high-order 24 bits of a service context ID contain a 24-bit vendor service context codeset ID (VSCID); the low-order 8 bits contain the rest of the service context ID. A vendor (or group of vendors) who wishes to define a specific set of system exception minor codes should obtain a unique VSCID from the OMG, and then define a specific set of service context IDs using the VSCID for the high-order bits. The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for use for OMG-defined standard service context IDs (i.e., service context IDs in the range 0-4095 are reserved as OMG standard service contexts). From: "Jishnu Mukerji" To: , "Interoperability RTF" References: <3BD991DC.C71A62E5@coastin.com> Subject: Re: Interop vote 1 Date: Fri, 26 Oct 2001 13:11:44 -0400 Organization: Hewlett-Packard MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: j@Xd937a!!UT%!!kbod9 From: "Tom Rutt" > This is not an official Fujitsu response, just my own personal comments > reflecting history. > > > > Issue 4618: Changing VSCID prefix to 24 bits > > > > Change the last two paragraphs of section 13.7 on page 13-30 to > >read: > > > > The high-order 24 bits of a service context ID contain a > >24-bit > > vendor service context codeset ID (VSCID); the low-order 8 > >bits > > contain the rest of the service context ID. A vendor (or > >group > > of vendors) who wishes to define a specific set of service context > > IDs should obtain a unique VSCID from the OMG, and then > >define > > a specific set of service context IDs using the VSCID for > >the > > high-order bits. > > > > The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) > >are > > reserved for use for OMG-defined standard service context > >IDs > > (i.e., service context IDs in the range 0-4095 are > >reserved as > > OMG standard service contexts). > > The existing assigned VSCIDs have values which are in the high order > >20 bits, so > they > have to be reassigned new values (to keep what they are now emitting > >as serviced > contexts to > be valid under the new scheme) > NewVscID = OldVscid * 2**4 > > In addition, if any vendors used more than 256 sevice context values > >with their > existing > vscid? If so they would need to apply for assignment of one or more additional > vcsid(s) to cover their existing > 32 bit values. Andrew claims that all currently assigned VSCIDs cover 24 high order bits and not 20. That is why this issue was raised by him. This is an attempt to bring the standard in line with existing reality, as I understand it. Do you believe that this is a wrong assessment of the sitation? > > > > -- > > > > Issue 4334: Repository ID in nil references > > > > Strike the following sentence at the top of page 15-28: > > > > When a reference to a base Object is encoded, there are two allowed > > encodings for the Repository ID: either "IDL:omg.org/CORBA/Object:1.0" > > or "" may be used. > > > > I think this was put in because some orbs at the time used the first option. > > This issue resolution in the final report needs a rational of why this is being > changed > from the result of a voted rtf change in the past. Tom, I agree with you on this one. This one seems like a gratuitious move to break someone's existing implementation. We could deprecate it in preparation for disallowing it in the future with, but I don't think we should summarily disallow it. That would be grossly backward incompatible change. Also, as a general comment I am tempted to vote against the entire ballot because it does not contain enough information or URL links for me to quickly refer to relevent documents. This ballot is a definite slide in the wrong direction in terms of quality.:-( Jishnu. Date: Fri, 26 Oct 2001 12:39:57 -0400 From: Tom Rutt Reply-To: tom@coastin.com Organization: Coast Enterprises X-Mailer: Mozilla 4.73 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Interoperability RTF Subject: Re: Interop vote 1 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: fEE!!4W^!!GTZ!!@#`d9 This is not an official Fujitsu response, just my own personal comments reflecting history. Michi Henning wrote: > Hi, > > attached are a few issues to vote on. Votes are due by Friday, 2 >November. > > -- > > Issue 4618: Changing VSCID prefix to 24 bits > > Change the last two paragraphs of section 13.7 on page 13-30 to >read: > > The high-order 24 bits of a service context ID contain a >24-bit > vendor service context codeset ID (VSCID); the low-order 8 >bits > contain the rest of the service context ID. A vendor (or >group > of vendors) who wishes to define a specific set of service >context > IDs should obtain a unique VSCID from the OMG, and then >define > a specific set of service context IDs using the VSCID for >the > high-order bits. > > The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) >are > reserved for use for OMG-defined standard service context >IDs > (i.e., service context IDs in the range 0-4095 are reserved >as > OMG standard service contexts). The existing assigned VSCIDs have values which are in the high order 20 bits, so they have to be reassigned new values (to keep what they are now emitting as serviced contexts to be valid under the new scheme) NewVscID = OldVscid * 2**4 In addition, if any vendors used more than 256 sevice context values with their existing vscid? If so they would need to apply for assignment of one or more additional vcsid(s) to cover their existing 32 bit values. > > -- > > Issue 4334: Repository ID in nil references > > Strike the following sentence at the top of page 15-28: > > When a reference to a base Object is encoded, there are two allowed > encodings for the Repository ID: either "IDL:omg.org/CORBA/Object:1.0" > or "" may be used. > I think this was put in because some orbs at the time used the first option. This issue resolution in the final report needs a rational of why this is being changed from the result of a voted rtf change in the past. > -- -- ----------------------------------------------------------- Tom Rutt tel: 732 801 5744 Coast Enterprises LLC fax: 732 774 5133 1313 Fourth Ave, email: tom@coastin.com Asbury Park NJ, 07713 www.coastEnterprises.com Date: Sat, 27 Oct 2001 16:20:13 +0200 (MEST) Message-Id: <200110271420.QAA09814@paros.informatik.hu-berlin.de> X-Authentication-Warning: paros.informatik.hu-berlin.de: loewis set sender to loewis@informatik.hu-berlin.de using -f From: Martin von Loewis To: everett.anderson@Sun.COM CC: interop@omg.org In-reply-to: <3BD9FD39.8A3A488F@sun.com> (message from Everett Anderson on Fri, 26 Oct 2001 17:18:01 -0700) Subject: Re: Interop vote 1 References: <3BD9FD39.8A3A488F@sun.com> User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-UIDL: FnZ!!#~e!!dTD!!nf&e9 Status: RO > 1. Issue 4618 > > Sun's ID is definitely using 24 bits, so I'm inclined to vote yes. > :) However, are we sure that no vendors were allocated 20 bit IDs? > Is there a list/web page somewhere to verify? The OMG tag list is at http://cgi.omg.org/cgi-bin/doc?vendor-tags which currently points to ftp://ftp.omg.org/pub/docs/ptc/01-08-35.txt No vendor holds more than 256 "service tags" (aka one VSCID). In fact, some hold less - I guess the tag list will be updated to give each of them 256 service contexts (i.e. one VCSID). Regards, Martin Date: Mon, 29 Oct 2001 11:04:53 -0500 From: Tom Rutt Reply-To: tom@coastin.com Organization: Coast Enterprises X-Mailer: Mozilla 4.73 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Martin von Loewis CC: everett.anderson@Sun.COM, interop@omg.org Subject: Re: Interop vote 1 References: <3BD9FD39.8A3A488F@sun.com> <200110271420.QAA09814@paros.informatik.hu-berlin.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: k3^!!E;`!!Qo2e9>RAe9 I now understand the problem. The OMG staff already gave out the service context and minor code ids as 24 bit space. However, this issue only addresses service context ids not minor cod ids. what about the minor code IDs, which are now 20 bits in the spec? Tom Rutt Martin von Loewis wrote: > > 1. Issue 4618 > > > > Sun's ID is definitely using 24 bits, so I'm inclined to vote yes. > > :) However, are we sure that no vendors were allocated 20 bit > >IDs? > > Is there a list/web page somewhere to verify? > > The OMG tag list is at > > http://cgi.omg.org/cgi-bin/doc?vendor-tags > > which currently points to > > ftp://ftp.omg.org/pub/docs/ptc/01-08-35.txt > > No vendor holds more than 256 "service tags" (aka one VSCID). In > >fact, > some hold less - I guess the tag list will be updated to give each > >of > them 256 service contexts (i.e. one VCSID). > > Regards, > Martin -- ----------------------------------------------------------- Tom Rutt tel: 732 801 5744 Coast Enterprises LLC fax: 732 774 5133 1313 Fourth Ave, email: tom@coastin.com Asbury Park NJ, 07713 www.coastEnterprises.com Date: Mon, 29 Oct 2001 13:41:54 -0500 From: Tom Rutt Reply-To: tom@coastin.com Organization: Coast Enterprises X-Mailer: Mozilla 4.73 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar , interop@omg.org Subject: Re: Interop vote 1 References: <3BD9FD39.8A3A488F@sun.com> <200110271420.QAA09814@paros.informatik.hu-berlin.de> <3BDD7E25.B72666F4@coastin.com> <3BDD9F59.D65E820B@biggar.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?l8!!%_-!!Cjld9$P1!! I was confused by the following paragraph from: ftp://ftp.omg.org/pub/docs/ptc/01-08-35.txt " The "VMCID" entry stands for three things: Policy IDs (aka VPVIDs), VMCIDs and VSCIDs; they are allocated in separate spaces, but CORBA 2.3 page 4-21 says that implementers automatically get identical tags for VPVIDs and VMCIDs, and as a matter of convenience, OMG staff will do the same for VSCIDs and VMCIDs. " However, if the OMG indeed have only given out 20 bit VMCIDs then there is no problem. Jonathan Biggar wrote: > Tom Rutt wrote: > > > > I now understand the problem. The OMG staff already gave out > > the service context and minor code ids as 24 bit space. However, > > this issue only addresses service context ids not minor cod ids. > > > > what about the minor code IDs, which are now 20 bits in the spec? > > It seems to me that vendors need many more minor code IDs than they do > service context ids, so I don't see a problem. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- ----------------------------------------------------------- Tom Rutt tel: 732 801 5744 Coast Enterprises LLC fax: 732 774 5133 1313 Fourth Ave, email: tom@coastin.com Asbury Park NJ, 07713 www.coastEnterprises.com From: "Jishnu Mukerji" To: , "Jonathan Biggar" , Cc: "Andrew Watson" References: <3BD9FD39.8A3A488F@sun.com> <200110271420.QAA09814@paros.informatik.hu-berlin.de> <3BDD7E25.B72666F4@coastin.com> <3BDD9F59.D65E820B@biggar.org> <3BDDA2F2.50173F1E@coastin.com> Subject: Re: Interop vote 1 Date: Mon, 29 Oct 2001 16:54:41 -0500 Organization: Hewlett-Packard MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: XP)e9*_X!!~,Wd9=NV!! ----- Original Message ----- From: "Tom Rutt" To: "Jonathan Biggar" ; Sent: Monday, October 29, 2001 1:41 PM Subject: Re: Interop vote 1 > I was confused by the following paragraph from: > ftp://ftp.omg.org/pub/docs/ptc/01-08-35.txt > " > The "VMCID" entry stands for three things: Policy IDs (aka VPVIDs), > VMCIDs and VSCIDs; they are allocated in separate spaces, but CORBA > 2.3 > page 4-21 says that implementers automatically get identical tags > for > VPVIDs and VMCIDs, and as a matter of convenience, OMG staff will do > the > same for VSCIDs and VMCIDs. > " > > However, if the OMG indeed have only given out 20 bit VMCIDs then > there is no problem. If wewant to salvage the possibility of using common bit patterns for VMCIDs and VCIDs then the VMCID issuing authority must follow the following rule and then everything might (see caveat below) work out just fine: Any new VMCID that is recorded must not clash with any already allocated VMCID and must not be the same as the highest order 20 bits of any already issued VSCID. This will ensure that the same VMCID can be used as16 VSCIDs by the owner of that VMCID, and it grandfathers in all the existing 24 bit VSCIDs safely. However, if there is already a clash between an allocated VSCID and an allocated VMCID in the high order twenty bits, then we have no choice but to completely separate the allocation schemes of VSCIDs from those for VMCID and VPVID. VMCID and VPVID can continue to be completely aligned while VSCID gets completely decoupled. Jishnu. Date: Tue, 30 Oct 2001 13:07:39 +0100 (MET) Message-Id: <200110301207.NAA23054@paros.informatik.hu-berlin.de> X-Authentication-Warning: paros.informatik.hu-berlin.de: loewis set sender to loewis@informatik.hu-berlin.de using -f From: Martin von Loewis To: jishnu_mukerji@hp.com CC: tom@coastin.com, jon@floorboard.com, interop@omg.org, andrew@omg.org In-reply-to: <022001c160c4$50a60a80$9916490f@fpk.hp.com> (jishnu_mukerji@hp.com) Subject: Re: Interop vote 1 References: <3BD9FD39.8A3A488F@sun.com> <200110271420.QAA09814@paros.informatik.hu-berlin.de> <3BDD7E25.B72666F4@coastin.com> <3BDD9F59.D65E820B@biggar.org> <3BDDA2F2.50173F1E@coastin.com> <022001c160c4$50a60a80$9916490f@fpk.hp.com> User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-UIDL: G$8e90-Ae9c+!!!gPLe9 > However, if there is already a clash between an allocated VSCID and an > allocated VMCID in the high order twenty bits, then we have no choice but to > completely separate the allocation schemes of VSCIDs from those for VMCID > and VPVID. VMCID and VPVID can continue to be completely aligned while VSCID > gets completely decoupled. Currently, no VSCIDs are allocated, so it is hard to say. However: - some vendors have service tags that don't have any VMCID (e.g. HP) - some vendors have service tags, but have a non-matching VMCID (e.g. Sun, Inprise) - there is one instance where the service context ID clashes with a reserved one: ICL has a service context that is in the OMG-reserved range. However, I still don't see the problem in issue 4618. None of the assigned service tags clash in their upper twenty bits (AFAICT). So it would be no problem claiming that OMG has assigned 20-bit VSCIDs in the past, giving each vendor more service tags than they originally asked for. Regards, Martin X-Sender: andrew@192.67.184.65 Message-Id: In-Reply-To: <200110301207.NAA23054@paros.informatik.hu-berlin.de> References: <022001c160c4$50a60a80$9916490f@fpk.hp.com> (jishnu_mukerji@hp.com) <3BD9FD39.8A3A488F@sun.com> <200110271420.QAA09814@paros.informatik.hu-berlin.de> <3BDD7E25.B72666F4@coastin.com> <3BDD9F59.D65E820B@biggar.org> <3BDDA2F2.50173F1E@coastin.com> <022001c160c4$50a60a80$9916490f@fpk.hp.com> Mime-Version: 1.0 Date: Tue, 30 Oct 2001 14:43:46 +0000 To: Martin von Loewis From: Andrew Watson Subject: Re: Interop vote 1 Cc: jishnu_mukerji@hp.com, tom@coastin.com, jon@floorboard.com, interop@omg.org Content-Type: text/plain; charset="us-ascii" X-UIDL: a5P!!Z-!"!KH Currently, no VSCIDs are allocated, so it is hard to say. However: > - some vendors have service tags that don't have any VMCID (e.g. HP) > - some vendors have service tags, but have a non-matching VMCID > (e.g. Sun, Inprise) > - there is one instance where the service context ID clashes with > a reserved one: ICL has a service context that is in the > OMG-reserved range. > > However, I still don't see the problem in issue 4618. None of the > assigned service tags clash in their upper twenty bits (AFAICT). So it > would be no problem claiming that OMG has assigned 20-bit VSCIDs in > the past, giving each vendor more service tags than they originally > asked for. That is essentially what I'm doing at the moment, until 4618 is resolved. However, in the long term I'd prefer to limit vendors to using service tags in blocks of 256, so that I can continue to allocate the upper 24 bits of the service tag as a three-letter mnemonic for the vendor. This is the suggestion I've made for the resolution of 4618. Thanks, Andrew From: "Jishnu Mukerji" To: Cc: , , , "Martin von Loewis" , "Michi Henning" References: <3BD9FD39.8A3A488F@sun.com> <200110271420.QAA09814@paros.informatik.hu-berlin.de> <3BDD7E25.B72666F4@coastin.com> <3BDD9F59.D65E820B@biggar.org> <3BDDA2F2.50173F1E@coastin.com> <022001c160c4$50a60a80$9916490f@fpk.hp.com> <200110301207.NAA23054@paros.informatik.hu-berlin.de> Subject: Re: Interop vote 1 Date: Tue, 30 Oct 2001 11:35:22 -0500 Organization: Hewlett-Packard MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 7hbd9*cG!!Q)`d93EGe9 From: "Martin von Loewis" > > However, if there is already a clash between an allocated VSCID and an > > allocated VMCID in the high order twenty bits, then we have no choice but to > > completely separate the allocation schemes of VSCIDs from those for VMCID > > and VPVID. VMCID and VPVID can continue to be completely aligned while VSCID > > gets completely decoupled. > > Currently, no VSCIDs are allocated, so it is hard to say. However: > - some vendors have service tags that don't have any VMCID (e.g. HP) > - some vendors have service tags, but have a non-matching VMCID > (e.g. Sun, Inprise) > - there is one instance where the service context ID clashes with > a reserved one: ICL has a service context that is in the > OMG-reserved range. > > However, I still don't see the problem in issue 4618. None of the > assigned service tags clash in their upper twenty bits (AFAICT). So it > would be no problem claiming that OMG has assigned 20-bit VSCIDs in > the past, giving each vendor more service tags than they originally > asked for. I am hoping that things would work out this way and we can simply revert back to 20 bit VSCIDs and grant additional space of service ids to those that already have service context ids allocated. However, I have not had the time to check this in detail. My recommendation is to not hastily adopt the change to 24 bit VSCIDs yet, until we have had time to understand the consequences. Please give me a week to take a closer look and make a final recommendation on this matter, and please hold the issue resolution in abeyance until then. Thanks, Jishnu.