Issue 4299: GIOP 1.1 Fragment problem (interop) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: There is nothing in the specification that explicitly states whether the data in the body of a GIOP 1.1 Fragment message is marshalled relative to the Fragment header or relative to the unfragmented message as a whole. The restriction in GIOP 1.2 that all fragments but the last must have a multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment header to 16 bytes both strongly suggest that GIOP 1.1 fragments should be marshalled only relative to the fragment header. Proposed Resolution: In section 15.4.9, right after the paragraph that reads: "A primitive data type of 8 bytes or smaller should never be broken across two fragments." add the following paragraph: In GIOP 1.1, the data in a fragment is marshalled with alignment relative to its position in the fragment, not relative to its position in the whole unfragmented message. Resolution: Accept proposal above Revised Text: In section 15.4.9, right after the paragraph that reads: "A primitive data type of 8 bytes or smaller should never be broken across two fragments." add the following paragraph: " In GIOP 1.1, the data in a fragment is marshalled with alignment relative to its position in the fragment, not relative to its position in the whole unfragmented message. " Actions taken: May 11, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from corvette.floorboard.com (64.121.176.53) by hobbit.omg.org asmtp(1.0) id 10036; Fri, 11 May 2001 19:53:17 -0400 (EDT) Received: from floorboard.com ([209.111.74.139]) by corvette.floorboard.com (8.9.3+Sun/8.8.8) with ESMTP id QAA14649; Fri, 11 May 2001 16:48:00 -0700 (PDT) Sender: jon@corvette.floorboard.com Message-ID: <3AFC7A3D.1CD2EE1C@floorboard.com> Date: Fri, 11 May 2001 16:48:13 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org, issues@omg.org Subject: GIOP 1.1 Fragment problem Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F9#e9^[i!!eg'e9Ai>!! There is nothing in the specification that explicitly states whether the data in the body of a GIOP 1.1 Fragment message is marshalled relative to the Fragment header or relative to the unfragmented message as a whole. The restriction in GIOP 1.2 that all fragments but the last must have a multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment header to 16 bytes both strongly suggest that GIOP 1.1 fragments should be marshalled only relative to the fragment header. Proposed Resolution: In section 15.4.9, right after the paragraph that reads: "A primitive data type of 8 bytes or smaller should never be broken across two fragments." add the following paragraph: In GIOP 1.1, the data in a fragment is marshalled with alignment relative to its position in the fragment, not relative to its position in the whole unfragmented message. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 04 Jun 2001 16:13:28 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: interop@omg.org Subject: Re: GIOP 1.1 Fragment problem References: <3AFC7A3D.1CD2EE1C@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6FS!!,?(e9a"H!!"PNe9 Jon, Sorry for the lateness of this response. Doesn't this cause a problem for an implementation of fragmentation that assembles fragments by concatenating them into a single buffer before unmarshalling? And could it cause a problem for a bridge that wants to retransmit a fragmented message using a different fragment size, but without fully unmarshalling the contents of the message? Would there be any problem with specifying that for GIOP 1.1, alignment is relative to the position in the entire message rather than the position in the current fragment? Simon Jonathan Biggar wrote: > > There is nothing in the specification that explicitly states whether the > data in the body of a GIOP 1.1 Fragment message is marshalled relative > to the Fragment header or relative to the unfragmented message as a > whole. > > The restriction in GIOP 1.2 that all fragments but the last must have a > multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment > header to 16 bytes both strongly suggest that GIOP 1.1 fragments should > be marshalled only relative to the fragment header. > > Proposed Resolution: > > In section 15.4.9, right after the paragraph that reads: > > "A primitive data type of 8 bytes or smaller should never be broken > across two > fragments." > > add the following paragraph: > > In GIOP 1.1, the data in a fragment is marshalled with alignment > relative to its position in the fragment, not relative to its position > in the whole unfragmented message. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jon@corvette.floorboard.com Message-ID: <3B1BBCC7.6EA09849@floorboard.com> Date: Mon, 04 Jun 2001 09:52:23 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: interop@omg.org Subject: Re: GIOP 1.1 Fragment problem References: <3AFC7A3D.1CD2EE1C@floorboard.com> <3B1BA598.70E6C6CB@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: iD=!!p1Z!!fH > Jon, > Sorry for the lateness of this response. > > Doesn't this cause a problem for an implementation of fragmentation that > assembles fragments by concatenating them into a single buffer before > unmarshalling? And could it cause a problem for a bridge that wants to > retransmit a fragmented message using a different fragment size, but without > fully unmarshalling the contents of the message? Yes, I thought about that problem. It's likely that we have an incipient interoperability problem, since there appears to be two different ways to implement GIOP 1.1 fragmenting. As for the bridge issue, it can't do that legally now, since without examining the contents of the message it can't guarantee that it doesn't fragment in the middle of a primitive type. > Would there be any problem with specifying that for GIOP 1.1, alignment is > relative to the position in the entire message rather than the position in > the current fragment? I believe that my proposed resolution is the one that is properly implied by the text as written, since your method would have obviated the need for the 8-byte alignment added for GIOP 1.2 padding. However, I'm certainly willing to see what the implementations out there actually do. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 05 Jun 2001 07:01:42 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: interop@omg.org Subject: Re: GIOP 1.1 Fragment problem References: <3AFC7A3D.1CD2EE1C@floorboard.com> <3B1BA598.70E6C6CB@hursley.ibm.com> <3B1BBCC7.6EA09849@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: c^P!!X?Od93OF!!i7p!! Jon, Jonathan Biggar wrote: > > Simon Nash wrote: > > > > Jon, > > Sorry for the lateness of this response. > > > > Doesn't this cause a problem for an implementation of fragmentation that > > assembles fragments by concatenating them into a single buffer before > > unmarshalling? And could it cause a problem for a bridge that wants to > > retransmit a fragmented message using a different fragment size, but without > > fully unmarshalling the contents of the message? > > Yes, I thought about that problem. It's likely that we have an > incipient interoperability problem, since there appears to be two > different ways to implement GIOP 1.1 fragmenting. > IBM has code in one of its products to implement receiving of GIOP 1.1 fragments by assembling them into a buffer. This code is currently disabled, but we will need to re-enable it to solve an interoperabilty problem that has recently been reported. > As for the bridge issue, it can't do that legally now, since without > examining the contents of the message it can't guarantee that it > doesn't > fragment in the middle of a primitive type. > OK, I accept this. > > Would there be any problem with specifying that for GIOP 1.1, alignment is > > relative to the position in the entire message rather than the position in > > the current fragment? > > I believe that my proposed resolution is the one that is properly > implied by the text as written, since your method would have obviated > the need for the 8-byte alignment added for GIOP 1.2 padding. > I don't think this follows. This change to GIOP 1.2 means that both approaches will produce exactly the same effect. I don't see why this implies one interpretation rather than the other. > However, I'm certainly willing to see what the implementations out there > actually do. > THat's a fair comment. If there are GIOP 1.1 implementations that currently send fragments and do alignment relative to each fragment message, then our fragment assembly approach wouldn't interoperate with them. What if some have implemented it one way and some the other? In this case I presume we would take the majority view. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb ] X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from mercury.sun.com (192.9.25.1) by hobbit.omg.org asmtp(1.0) id 3971; Tue, 05 Jun 2001 03:19:04 -0400 (EDT) Received: from taller.eng.sun.com ([129.144.174.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA03270; Tue, 5 Jun 2001 00:14:13 -0700 (PDT) Received: from brk9i (vpn-129-150-4-101.EBay.Sun.COM [129.150.4.101]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id AAA08558; Tue, 5 Jun 2001 00:14:06 -0700 (PDT) From: "Everett Anderson" To: "Simon Nash" , "Jonathan Biggar" Cc: Subject: RE: GIOP 1.1 Fragment problem Date: Tue, 5 Jun 2001 00:21:50 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B1C75C6.F9B910B9@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="us-ascii" X-UIDL: MfW!!]ia!!6@4e9VP_d9 Hi, > IBM has code in one of its products to implement receiving of > GIOP 1.1 fragments > by assembling them into a buffer. This code is currently > disabled, but we will > need to re-enable it to solve an interoperabilty problem that has > recently been > reported. Do you do that by not requiring the "natural" alignment in the individual fragments when writing? If alignment in CORBA is required since some languages may need it for special memory related primitive handling, I don't see any other solution in GIOP 1.1 other than the proposed one to align with respect to the fragment and avoid the assembly solution: Let's say you're at the end of a 1024 byte fragment in GIOP 1.1, and now want to write a long double. You fragment, get a new buffer, marshal in the 12 byte header, and now need to add 4 bytes of alignment. However, if a reader assembles the fragments without the fragment headers, those 4 bytes shouldn't be there. > THat's a fair comment. If there are GIOP 1.1 implementations > that currently send > fragments and do alignment relative to each fragment message, > then our fragment > assembly approach wouldn't interoperate with them. > > What if some have implemented it one way and some the other? In > this case I presume > we would take the majority view. We haven't released ours, yet. Currently, we have GIOP 1.1 fragmentation disabled, but we did develop it thinking that it had to be aligned with respect to the fragment due to the alignment discussion at the beginning of the CDR Primitive Types section, and since the assembly approach wasn't mandated. - Everett Date: Tue, 05 Jun 2001 12:52:38 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson CC: Jonathan Biggar , interop@omg.org Subject: Re: GIOP 1.1 Fragment problem References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: lD4e9ge5e9c9a!!/$\d9 Everett, Everett Anderson wrote: > > Hi, > > > IBM has code in one of its products to implement receiving of > > GIOP 1.1 fragments > > by assembling them into a buffer. This code is currently > > disabled, but we will > > need to re-enable it to solve an interoperabilty problem that has > > recently been > > reported. > > Do you do that by not requiring the "natural" alignment in the individual > fragments when writing? > > If alignment in CORBA is required since some languages may need it for > special memory related primitive handling, I don't see any other solution in > GIOP 1.1 other than the proposed one to align with respect to the fragment > and avoid the assembly solution: > It is my understanding that GIOP alignment was originally introduced for this reason, but no language has ever been able to exploit this because of cases that force the alignment to be unnatural from a language perspective. However we are stuck with alignment for historical reasons. > Let's say you're at the end of a 1024 byte fragment in GIOP 1.1, and now > want to write a long double. You fragment, get a new buffer, marshal in the > 12 byte header, and now need to add 4 bytes of alignment. However, if a > reader assembles the fragments without the fragment headers, those 4 bytes > shouldn't be there. > I would put this slightly differently: if the spec says that alignment is relative to the whole message, then those 4 bytes shouldn't be there. I don't think this approach is any more difficult to implement (even if the assembly approach is not used by the unmarshaller), but in your case it would be more work since you have already implemented it the other way. > > THat's a fair comment. If there are GIOP 1.1 implementations > > that currently send > > fragments and do alignment relative to each fragment message, > > then our fragment > > assembly approach wouldn't interoperate with them. > > > > What if some have implemented it one way and some the other? In > > this case I presume > > we would take the majority view. > > We haven't released ours, yet. Currently, we have GIOP 1.1 > > fragmentation > disabled, but we did develop it thinking that it had to be aligned > > with > respect to the fragment due to the alignment discussion at the > > beginning of > the CDR Primitive Types section, and since the assembly approach > > wasn't > mandated. > As I said above, I believe this rationale is flawed. I agree with Jon > > that the behaviour of currently released implementations of GIOP 1.1 > > fragmentation should be the deciding factor. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Sai-Lai Lo" To: "Simon Nash" , "Everett Anderson" Cc: "Jonathan Biggar" , References: <3B1CC806.DE08E361@hursley.ibm.com> Subject: Re: GIOP 1.1 Fragment problem Date: Fri, 8 Jun 2001 14:20:07 -0000 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: /dgd9";?e90iOd9\`+e9 I am with the same view as Jon that the whole point of the GIOP 1.2 8-byte alignment rule is to ensure that fragments can be combined at bridges easily. The reason why this has to be done is because fragments in GIOP 1.1 do follow the general alignment rule of any GIOP message and so cannot be simply concatenate together. To me, there is always this general rule in the protocol that alignment of a data item should be calculated relative to the beginning of a GIOP message. GIOP fragment is a GIOP message and so should obey this same rule!!! The idea that one goes back to GIOP 1.1 and make the alignment rule for fragment an exception to this general rule is just wrong. There are implementations out there which actually support GIOP 1.1 and fragmentation and they follow this natural alignment rule. We (omniORB) will very soon release a version that support GIOP versions up to 1.2. Please do not change the alignment rule for fragment in GIOP 1.1 just because it is convenient to fix a problem in a particular implementation! > It is my understanding that GIOP alignment was originally introduced for this > reason, but no language has ever been able to exploit this because of cases > that force the alignment to be unnatural from a language perspective. However > we are stuck with alignment for historical reasons. We actually make use of this alignment rule to do something like this v = *((CORBA::Double*)buffer_p) in C++. > As I said above, I believe this rationale is flawed. I agree with Jon that > the behaviour of currently released implementations of GIOP 1.1 fragmentation > should be the deciding factor. I disagree. To say that fragment body should not follow the alignment rule of a GIOP message is unnecessarily introducing an inconsistency into the spec. Please don't. Sai-Lai Lo ----- Original Message ----- From: "Simon Nash" To: "Everett Anderson" Cc: "Jonathan Biggar" ; Sent: Tuesday, June 05, 2001 11:52 AM Subject: Re: GIOP 1.1 Fragment problem > Everett, > > Everett Anderson wrote: > > > > Hi, > > > > > IBM has code in one of its products to implement receiving of > > > GIOP 1.1 fragments > > > by assembling them into a buffer. This code is currently > > > disabled, but we will > > > need to re-enable it to solve an interoperabilty problem that >has > > > recently been > > > reported. > > > > Do you do that by not requiring the "natural" alignment in the individual > > fragments when writing? > > > > If alignment in CORBA is required since some languages may need it >for > > special memory related primitive handling, I don't see any other solution in > > GIOP 1.1 other than the proposed one to align with respect to the fragment > > and avoid the assembly solution: > > > It is my understanding that GIOP alignment was originally introduced >for this > reason, but no language has ever been able to exploit this because >of cases > that force the alignment to be unnatural from a language >perspective. However > we are stuck with alignment for historical reasons. > > > Let's say you're at the end of a 1024 byte fragment in GIOP 1.1, >and now > > want to write a long double. You fragment, get a new buffer, >marshal in the > > 12 byte header, and now need to add 4 bytes of alignment. >However, if a > > reader assembles the fragments without the fragment headers, those >4 bytes > > shouldn't be there. > > > I would put this slightly differently: if the spec says that >alignment is relative > to the whole message, then those 4 bytes shouldn't be there. I >don't think this > approach is any more difficult to implement (even if the assembly >approach is not > used by the unmarshaller), but in your case it would be more work >since you have > already implemented it the other way. > > > > THat's a fair comment. If there are GIOP 1.1 implementations > > > that currently send > > > fragments and do alignment relative to each fragment message, > > > then our fragment > > > assembly approach wouldn't interoperate with them. > > > > > > What if some have implemented it one way and some the other? In > > > this case I presume > > > we would take the majority view. > > > > We haven't released ours, yet. Currently, we have GIOP 1.1 fragmentation > > disabled, but we did develop it thinking that it had to be aligned >with > > respect to the fragment due to the alignment discussion at the >beginning of > > the CDR Primitive Types section, and since the assembly approach >wasn't > > mandated. > > > As I said above, I believe this rationale is flawed. I agree with >Jon that > the behaviour of currently released implementations of GIOP 1.1 fragmentation > should be the deciding factor. > > Simon > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > --- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND Date: Fri, 08 Jun 2001 12:26:41 -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: Juergen Boldt Cc: interop@emerald.omg.org Subject: Re: Interop Dec 2000 RTF vote one posted - Issue 4299 References: <4.3.2.7.2.20010601174603.01c8c430@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: j]`!!T'?e9A\/!!mpmd9 I have a question about the resolution for 4299. After 4299 is applied to GIOP 1.1, which constrains the set of compliant implementations, and possibly excludes certain existing implementations, what GIOP version would this be? 1.1.1? Clearly it could not still be 1.1 could it? Just wondering..... Jishnu. Sender: jon@corvette.floorboard.com Message-ID: <3B2105E3.A560CB99@floorboard.com> Date: Fri, 08 Jun 2001 10:05:39 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: Juergen Boldt , interop@emerald.omg.org Subject: Re: Interop Dec 2000 RTF vote one posted - Issue 4299 References: <4.3.2.7.2.20010601174603.01c8c430@emerald.omg.org> <3B20FCC1.C1F8A5ED@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4Mnd96/F!!#>;!!n6#"! Jishnu Mukerji wrote: > > I have a question about the resolution for 4299. After 4299 is applied > to GIOP 1.1, which constrains the set of compliant implementations, and > possibly excludes certain existing implementations, what GIOP version > would this be? 1.1.1? Clearly it could not still be 1.1 could it? I view this as a clarification of the protocol, not a change, per se, since I believe that the proposed resolution is the original intent of the specification. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 08 Jun 2001 13:38:02 -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: Jonathan Biggar Cc: Juergen Boldt , interop@emerald.omg.org Subject: Re: Interop Dec 2000 RTF vote one posted - Issue 4299 References: <4.3.2.7.2.20010601174603.01c8c430@emerald.omg.org> <3B20FCC1.C1F8A5ED@hp.com> <3B2105E3.A560CB99@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1Bcd9m38!!e3l!!i>~!! Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > I have a question about the resolution for 4299. After 4299 is applied > > to GIOP 1.1, which constrains the set of compliant implementations, and > > possibly excludes certain existing implementations, what GIOP version > > would this be? 1.1.1? Clearly it could not still be 1.1 could it? > > I view this as a clarification of the protocol, not a change, per se, > since I believe that the proposed resolution is the original intent of > the specification. Isn't that always true of any of these clarification changes? That does not increase my level of comfort because the fact still remains that the new interpretation is different from the old, notwithstanding what the intent may or may not have been. However, the reason that I voted YES is that I don't think we have a good way of dealing with this problem, since we do not have the notion of a minor minor version number. Jishnu. Date: Fri, 08 Jun 2001 13:38:02 -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: Jonathan Biggar Cc: Juergen Boldt , interop@emerald.omg.org Subject: Re: Interop Dec 2000 RTF vote one posted - Issue 4299 References: <4.3.2.7.2.20010601174603.01c8c430@emerald.omg.org> <3B20FCC1.C1F8A5ED@hp.com> <3B2105E3.A560CB99@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: K)*!!k>l!!87_!!NQ)!! Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > I have a question about the resolution for 4299. After 4299 is applied > > to GIOP 1.1, which constrains the set of compliant implementations, and > > possibly excludes certain existing implementations, what GIOP version > > would this be? 1.1.1? Clearly it could not still be 1.1 could it? > > I view this as a clarification of the protocol, not a change, per se, > since I believe that the proposed resolution is the original intent of > the specification. Isn't that always true of any of these clarification changes? That does not increase my level of comfort because the fact still remains that the new interpretation is different from the old, notwithstanding what the intent may or may not have been. However, the reason that I voted YES is that I don't think we have a good way of dealing with this problem, since we do not have the notion of a minor minor version number. Jishnu. X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from corvette.floorboard.com (64.121.176.53) by hobbit.omg.org asmtp(1.0) id 16713; Fri, 08 Jun 2001 13:13:34 -0400 (EDT) Received: from floorboard.com (localhost [127.0.0.1]) by corvette.floorboard.com (8.9.3+Sun/8.8.8) with ESMTP id KAA07150; Fri, 8 Jun 2001 10:05:39 -0700 (PDT) Sender: jon@corvette.floorboard.com Message-ID: <3B2105E3.A560CB99@floorboard.com> Date: Fri, 08 Jun 2001 10:05:39 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: Juergen Boldt , interop@emerald.omg.org Subject: Re: Interop Dec 2000 RTF vote one posted - Issue 4299 References: <4.3.2.7.2.20010601174603.01c8c430@emerald.omg.org> <3B20FCC1.C1F8A5ED@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: RG#!!<'>!!BP&"![(!"! Jishnu Mukerji wrote: > > I have a question about the resolution for 4299. After 4299 is applied > to GIOP 1.1, which constrains the set of compliant implementations, and > possibly excludes certain existing implementations, what GIOP version > would this be? 1.1.1? Clearly it could not still be 1.1 could it? I view this as a clarification of the protocol, not a change, per se, since I believe that the proposed resolution is the original intent of the specification. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org