Issue 1857: IIOP 1.2 fragmentation presents an unrecoverable error situation (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation 1.2 IIOP attempted to provide fragment interleaving by defining a 1.2 fragment header containing request id. This does not solve the possibility of receiving multiple first fragments over the same connection which do not contain request id"s. There is no way to associate subsequent fragments with these initial fragments since the initial request id is received after the 1.2 Fragment header specified request_id. Resolution: Revised Text: Actions taken: August 24, 1998: received issue February 17, 1999: closed issue Discussion: End of Annotations:===== Return-Path: To: issues@omg.org, orb_revision@omg.org, interop@omg.org Subject: IIOP 1.2 fragmentation presents an unrecoverable error situation Date: Mon, 24 Aug 1998 21:05:48 +0100 From: Craig Ryan This is based on what I last recall from the proposed 1.2 revision, please correct me if this has already been addressed. regards, Craig Ryan. IIOP 1.2 fragmentation presents an unrecoverable error situation ---------------------------------------------------------------- 1.2 IIOP attempted to provide fragment interleaving by defining a 1.2 fragment header containing request id. This does not solve the possibility of receiving multiple first fragments over the same connection which do not contain request id's. There is no way to associate subsequent fragments with these initial fragments since the initial request id is received after the 1.2 Fragment header specified request_id. Proposed solutions (in order of preference): 1. relocate the request_id in the request header for 1.2 to be the first item in the header (ahead of the service context). A similar issue with Reply messages would also apply. 2. specify that the request id must be contained in the initial 1.2 fragment in all cases, regardless of the service context size. [This potentially causes problems when the service context is large in size] 3. disallow the sender from starting a new request/reply until the fragment containing the request ID for the previous request/reply has been sent. ------------------------------------------------------------------------ Craig Ryan -----------| Principal Software Engineer|-------------------- IONA Technologies PLC | email: cryan@iona.com -----| -- voice extn: 2453 Shelbourne Rd --------| ftp: ftp.iona.com --------| tel: +353-1-6625255 Dublin 4 -------------| WWW: http://www.iona.com/ | fax: +353-1-6625244 Ireland --------------| -- In the USA call: 1-800-orbix4u, 1-800 6724948 Return-Path: Date: Wed, 16 Sep 1998 13:47:52 -0400 From: Bob Kukura Organization: IONA Technologies To: interop@omg.org, orb_revision@omg.org CC: cryan@iona.com, vinoski@iona.com, mchapman@iona.com Subject: Lets fix critical GIOP 1.2 issue (1857) NOW! X-MIME-Autoconverted: from 8bit to quoted-printable by dublin.iona.ie id SAA11897 I think it is worth somehow getting a fix for interop issue 1857 into the final CORBA 2.3 draft, but I'm not sure how this can be done. The current interop RTF doesn't have a report due until March 99, which is too late, but I guess it could issue a ruling in the next week or two for inclusion in the final CORBA 2.3. Or maybe the Core RTF could handle this, since the proposed fix simply requires moving two lines of text. Anyway, GIOP 1.2 attempts to support interleaving of fragments, but an easily fixable detail of the GIOP message formats makes this extremely difficult to implement. It may also lead to implementations that don't interoperate. GIOP 1.2 includes a request_id field in the FragmentHeader_1_2 struct which is intended to allow interleaved fragments to be associated with the proper message. For this to work, the request_id must be present in the initial fragment of the message. The initial fragment of a message uses a RequestHeader_1_2, ReplyHeader_1_2, LocateRequestHeader_1_2, or LocateReplyHeader_1_2 instead of the FragmentHeader_1_2 used in subsequent fragments. The problem is that the request_id field in the RequestHeader_1_2 and ReplyHeader_1_2 structs comes after the service_context field, which can be arbitrarily large and might not fit entirely in the first fragment. This problem could easily be corrected by making the request_id field the first field of the RequestHeader_1_2 and ReplyHeader_1_2 structs, as it already is for the LocateRequestHeader_1_2 and LocateReplyHeader_1_2 structs. The RequestHeader_1_2 and ReplyHeader_1_2 structs are already different than the GIOP 1.1 versions due to the TargetAddress and ReplyStatusType changes, so I don't think changing the order of the fields relative to GIOP 1.1 places any additional burden on the implementor. Specifically, I recommend fixing issue 1857 by moving the service_context field to the end of the offending structs, so that all the fixed length fields, including request_id, preceed the variable length fields. The needed edits are as follows: 15.4.1.2 Request Header At the bottom of page 15-30, change: struct RequestHeader_1_2 { IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; octet reserved[3]; TargetAddress target; string operation; // Principal not in GIOP 1.2 }; to: struct RequestHeader_1_2 { unsigned long request_id; boolean response_expected; octet reserved[3]; TargetAddress target; string operation; IOP::ServiceContextList service_context; // Principal not in GIOP 1.2 }; 15.4.2.1 Reply Header At top of page 15-34, change: struct ReplyHeader_1_2 { IOP:ServiceContextList service_context; unsigned long request_id; ReplyStatusType_1_2 reply_status; }; to: struct ReplyHeader_1_2 { unsigned long request_id; ReplyStatusType_1_2 reply_status; IOP:ServiceContextList service_context; }; With these changes, the request_id will always be first. The request_id can't cross fragment boundaries, so all fragments, initial or subsequent, that contain any data at all, will contain the request_id. Request, Reply, LocateRequest, and LocateReply messages with no data are already illegal, and I'll raise a separate issue to add Fragment to this list. We could then make the following additional edit: 15.4.8 Fragment Message Change note at bottom of page 15-40 from: Note quest message before sending the request ID, may not send a CancelRequest message pertaining to that request ID and may not send another Request message until after the request ID is sent. to: Note uest message before sending the request ID, may not send a CancelRequest message pertaining to that request ID and may not send another Request message until after the request ID is sent. Without these changes, GIOP 1.2 implementations will not be guaranteed to receive the request_id in the initial fragment of a fragmented message. After receiving such an initial fragment, implementations will have to assume that the next fragment that has a request_id that has not already been seen belongs to that message. When sending, if an implementation does not ensure that the request_id is in the first fragment by making that fragment arbitrarily large, it will have to somehow ensure that only one initial fragment without a request_id is outstanding on a connection. This applies to Reply messages, not just Request messages, so the note on page 15-40 would have to be extended to cover Reply messages as well. Fixing the specification now as I've recommended above is much easier, in my opinion. -Bob Return-Path: Sender: "George Scott" Date: Wed, 16 Sep 1998 11:28:33 -0700 From: "George M. Scott" Organization: Inprise Corporation To: Bob Kukura CC: interop@omg.org, orb_revision@omg.org Subject: Re: Lets fix critical GIOP 1.2 issue (1857) NOW! References: <35FFF9C8.C4D4522@iona.com> Bob Kukura wrote: > > Without these changes, GIOP 1.2 implementations will not be > guaranteed > to receive the request_id in the initial fragment of a fragmented > message. After receiving such an initial fragment, implementations > will > have to assume that the next fragment that has a request_id that has > not > already been seen belongs to that message. When sending, if an > implementation does not ensure that the request_id is in the first > fragment by making that fragment arbitrarily large, it will have to > somehow ensure that only one initial fragment without a request_id > is > outstanding on a connection. This applies to Reply messages, not > just > Request messages, so the note on page 15-40 would have to be > extended to > cover Reply messages as well. Fixing the specification now as I've > recommended above is much easier, in my opinion. We agree. Furthermore, these changes allow for efficient implementation of GIOP proxies which often need to change the request_id field. With the request_id field buried after the service context, the proxy must dynamically compute the location of the request_id field in the buffer instead of looking for the request_id at a standard offset. George Return-Path: Date: Fri, 18 Sep 1998 16:44:29 -0400 From: ter@holta.ho.lucent.com (T E Rutt) To: orb_revision@omg.org Subject: proposed resolution to issue 1857 soon To: Interoperability and Core 2.3a RTFs From: Tom Rutt and Jishnu Mukerjii (chairs of above RTFs) In order to allow the urgent resolution of Issue 1857 before publication of corba 2.3 and GIOP 1.2, it has been transferred to the Core 2.3 RTF with resolution with a clarfication to the GIOP text. This proposed resolution will be included with the final Core 2.3a rtf vote to be sent out by Jishnu. If this proposal for resolution does not pass with resolutions acceptable to the CORE 2.3a RTF, then the issue could be processed using the new URGENT ISSUE procedures. ather than waiting for the output of the INterop RTF. ----------------------------- Issue 1857: IIOP 1.2 fragmentation presents an unrecoverable error situation (interop) Click here for this issue's archive. Source: IONA (Mr. Craig Ryan, cryan@iona.com) Nature: Uncategorized Issue Severity: Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation 1.2 IIOP attempted to provide fragment interleaving by defining a 1.2 fragment header containing request id. This does not solve the possibility of receiving multiple first fragments over the same connection which do not contain request id's. There is no way to associate subsequent fragments with these initial fragments since the initial request id is received after the 1.2 Fragment header specified request_id. Resolution: Resolve criticality of issue by simplest solution (do not allow sending next request message on a connection before the original request id is sent in a fragment) , which was the original intent of the GIOP 1.1 introduced note regarding sending Cancel Request message. The note was intended to apply to all uses of the fragmentation message which would result in ambiguity. Any other solutions which would require changing the syntax of the request message should be considered too large to be within the scope of an RTF, when this simple solution can suffice. GIOP Efficiency for fragmentation usage is not enough reason to warrant RTF changes to GIOP 1.2. This should await future RFPs, which would include making improvements to marshalling Type codes , Any values, and encapsulations more efficient. Revised Text: Insert "and may not send another request message" into the note in 13.4.8 The proposal would have the note read as follows: " Note - A GIOP client which fragments the header of a Request message before sending the request ID, may not send a CancelRequest message pertaining to that request ID and may not send another Request message until after the request ID is sent. " Return-Path: Date: Fri, 18 Sep 1998 17:32:31 -0400 From: ter@holta.ho.lucent.com (T E Rutt) To: interop@omg.org Subject: resent of issue 1857 proposl To: Interoperability and Core 2.3a RTFs From: Tom Rutt and Jishnu Mukerjii (chairs of above RTFs) In order to allow the urgent resolution of Issue 1857 before publication of corba 2.3 and GIOP 1.2, it has been transferred to the Core 2.3 RTF with resolution with a clarfication to the GIOP text. This proposed resolution will be included with the final Core 2.3a rtf vote to be sent out by Jishnu. If this proposal for resolution does not pass with resolutions acceptable to the CORE 2.3a RTF, then the issue could be processed using the new URGENT ISSUE procedures. ather than waiting for the output of the INterop RTF. ----------------------------- Issue 1857: IIOP 1.2 fragmentation presents an unrecoverable error situation (interop) Click here for this issue's archive. Source: IONA (Mr. Craig Ryan, cryan@iona.com) Nature: Uncategorized Issue Severity: Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation 1.2 IIOP attempted to provide fragment interleaving by defining a 1.2 fragment header containing request id. This does not solve the possibility of receiving multiple first fragments over the same connection which do not contain request id's. There is no way to associate subsequent fragments with these initial fragments since the initial request id is received after the 1.2 Fragment header specified request_id. Resolution: Resolve criticality of issue by simplest solution (do not allow sending next request message on a connection before the original request id is sent in a fragment) , which was the original intent of the GIOP 1.1 introduced note regarding sending Cancel Request message. The note was intended to apply to all uses of the fragmentation message which would result in ambiguity. Any other solutions which would require changing the syntax of the request message should be considered too large to be within the scope of an RTF, when this simple solution can suffice. GIOP Efficiency for fragmentation usage is not enough reason to warrant RTF changes to GIOP 1.2. This should await future RFPs, which would include making improvements to marshalling Type codes , Any values, and encapsulations more efficient. Revised Text: Insert "and may not send another request message" into the note in 13.4.8 The proposal would have the note read as follows: " Note - A GIOP client which fragments the header of a Request message before sending the request ID, may not send a CancelRequest message pertaining to that request ID and may not send another Request message until after the request ID is sent. " Return-Path: Date: Sat, 19 Sep 1998 23:32:16 -0400 From: Bob Kukura Organization: IONA Technologies To: T E Rutt CC: orb_revision@omg.org, interop@omg.org, cryan@iona.com, mchapman@iona.com, vinoski@iona.com Subject: Re: proposed resolution to issue 1857 soon References: <199809182044.QAA01695@holta.ho.lucent.com> I believe that this is the wrong solution, and urge everyone to vote NO on this proposal if and when it shows up in an ORB 2.3a vote. Please at least consult your company's IIOP implementors before agreeing to Tom's proposed resolution of this issue and rejecting mine. [Note: Please don't take any of this personally, Tom. I assume some conversation must have taken place in Seattle that led to this proposal being forwarded to the ORB 2.3a RTF in place of the one I made.] I had sent out a different proposal for this issue a couple of days ago that received only positive feedback. The proposal I sent out simply moved the service_context field to the end of the RequestHeader and ReplyHeader structs for GIOP 1.2, making the request_id the first field. The request_id field already is first in all other fragmentable messages. With the request_id first, there is no chance that a fragment, initial or subsequent, contains data but doesn't contain a request_id. Having a request_id in every fragment of every fragmentable message has two significant benefits: 1) It allows the sending side GIOP code to send initial and subsequent fragments of a message on a connection when the fragments are ready, regardless of what fragments of other messages might previously have been sent. 2) It makes the receiving side GIOP code that dispatches received fragments to the proper queue or stream or thread or whatever trivial. The fragments are simply dispatched according to their request_ids. Without my proposed change, whether or not Tom's "clarification" is adopted, both the sending and receiving sides of GIOP 1.2 implementations will have to contain significant additional code to deal with the possibility that an initial fragment does not contain a request_id. This additional complexity is described here: The sending side of a GIOP implementation has three choices that I can see: 1) It can make the initial fragment however large is necessary to ensure it contains the request_id. But then it can't use fixed sized buffers for GIOP 1.2. 2) As suggested by Tom's "clarification", it can can perform some sort of connection level locking, where other threads are prevented from sending an initial fragment of a new message until a thread that has sent an initial fragment without a request_id gets around to sending the fragment that does contain the request_id. This seems particularly difficult in any kind of layered protocol implementation, such as one that includes SECIOP and/or is based on message level interceptors. Remember that SECIOP and GIOP message fragments can be interleaved on the same connection. 3) Just don't bother interleaving fragments at all, even though the 1.2 RTF felt this was worth introducing a whole new message header to support. Regardless of which sending side solution is chosen for a GIOP implementation, the receiving side has to be prepared to deal with all three. Dealing with 2) requires extra code that would not be necessary with my proposed resolution, to handle received fragments that don't contain a request_id. The additional complexity required on both the client and server sides is not just an issue for the ORB vendors. Since having a service context be big enough in practice to force the request_id out of the initial fragment of a Request or Reply message is probably a relatively rare occurrence, and because different ORB vendors are likely to choose different solutions on the sending side, this is the kind of situation that is most likely to cause interoperability problems at random times in deployed systems. All of this extra code complexity is easily avoided by simply making the request_id the first field in the RequestHeader_1_2 and ReplyHeader_1_2 structs, as I have proposed. If we don't do this before CORBA 2.3 is published, we will never have the chance again. T E Rutt wrote: > > To: Interoperability and Core 2.3a RTFs > From: Tom Rutt and Jishnu Mukerjii (chairs of above RTFs) > > In order to allow the urgent resolution of Issue 1857 before > publication of corba 2.3 and GIOP 1.2, it has been transferred > to the Core 2.3 RTF with resolution with a clarfication to > the GIOP text. > > This proposed resolution will be included with the final Core 2.3a > rtf vote to be sent out by Jishnu. If this proposal for resolution > does not pass with resolutions acceptable to the CORE 2.3a RTF, then > the issue could be processed using the new URGENT ISSUE procedures. > ather than waiting for the output of the INterop RTF. > > ----------------------------- > Issue 1857: IIOP 1.2 fragmentation presents an > unrecoverable error situation (interop) > > Click here for this issue's archive. > Source: IONA (Mr. Craig Ryan, cryan@iona.com) > Nature: Uncategorized Issue > Severity: > Summary: IIOP 1.2 fragmentation presents an unrecoverable error > situation 1.2 IIOP attempted to provide fragment interleaving by > defining a 1.2 fragment header containing request id. This does > not solve the possibility of receiving multiple first fragments > over the same connection which do not contain request id's. There > is no way to associate subsequent fragments with these initial > fragments since the initial request id is received after the 1.2 > Fragment header specified request_id. > Resolution: > Resolve criticality of issue by simplest solution (do not > allow sending next request message on a connection before the > original request id is sent in a fragment) , which was the > original intent of the GIOP 1.1 introduced note regarding > sending Cancel Request message. The note was intended to apply to > all uses of the fragmentation message which would result in > ambiguity. This may have been the intent of whoever wrote the note, but interleaving of fragments was not a consideration when GIOP 1.1 was specified. There was never any ambiguity as to which message a fragment belonged to, since interleaving was not allowed. There was the possibility of ambiguity as to which message a CancelRequest applied, and dealing with this for GIOP 1.1 was my understanding of the intent of the note. I agree that adding this additional complexity to both sending and receiving sides of GIOP implementations will avoid the problem that Craig identified. But I disagree that this is the simplest solution when the big picture is considered. Also, if the note is intended to apply to fragmented Reply messages, which have the same issue, it will need to be reworded, since it only refers to Request and CancelRequest messages right now. I recommend adopting my proposed changes to RequestHeader_1_2 and ReplyHeader_1_2 instead, and simply clarifying that the note only applies to GIOP 1.1, where it is needed, and where it does not need to apply to Reply messages. > > Any other solutions which would require changing the syntax of the > request message should be considered too large to be within the > scope of an RTF, when this simple solution can suffice. This is utter nonsense. All IIOP RTFs have made much more significant changes to GIOP messages than my proposed change, including the IIOP 1.2 RTF. If changes to message syntax weren't allowed in RTFs, then I guess we'd have to completely remove the support for interleaving of fragments that was added in the GIOP 1.2, by the RTF, not by any RFP, since this added a whole new message. Maybe the IIOP 1.1 RTF should not have added fragmentation. We'd also have to put back the Principal field in the request header, which the 1.2 RTF removed. I cannot believe that anyone would sincerely claim that such a trivial change as moving a field in a message syntax is beyond the scope of an RTF. Please note that I am not proposing any change to the GIOP 1.0 or 1.1 messages, nor any change to the content of the GIOP 1.2 messages. Also, the GIOP 1.2 message format is already significantly different than the GIOP 1.1 message format. This is a new issue introduced by allowing fragments to be interleaved. GIOP 1.0 does not support fragmentation at all, and GIOP 1.1 does not allow fragments of different messages to be interleaved. Only by enabling interleaving of fragments does the original placement of the request_id relative to the service_context become a serious problem. But its a problem that is much easier to fix as I proposed than it is to work around as Tom proposed. > > GIOP Efficiency for fragmentation usage is not enough reason to > warrant RTF changes to GIOP 1.2. This should await future RFPs, > which would include making improvements to marshalling Type codes > , Any values, and encapsulations more efficient. This is not an efficiency issue. Its an implementability issue, and probably an interoperability issue. The specification with Tom's resolution of this issue would require significant additional implementation effort over the specification with my proposal, for absolutely no gain. This is not anything remotely related to the more significant changes that should await future RFPs. > > Revised Text: Insert "and may not send another request message" > into the note in 13.4.8 > > The proposal would have the note read as follows: > " > Note - A GIOP client which fragments the header of a Request > message before sending the request ID, may not send a > CancelRequest message pertaining to that request ID and may not > send another Request message until after the request ID is sent. > " Again, with Tom's proposal, the note would have to be modified to apply to Reply messages as well as Request messages. My proposal would instead change this note to read "A GIOP 1.1 client ...", keeping its original intent as a clarification of GIOP 1.1. -Bob Return-Path: From: "Ken Fleming" To: "George Scott" , "Bob Kukura" Cc: , Subject: RE: Lets fix critical GIOP 1.2 issue (1857) NOW! Date: Sun, 20 Sep 1998 15:09:30 -0700 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 We also agree. > -----Original Message----- > From: George Scott [mailto:gscott@inprise.com] > Sent: Wednesday, September 16, 1998 11:29 AM > To: Bob Kukura > Cc: interop@omg.org; orb_revision@omg.org > Subject: Re: Lets fix critical GIOP 1.2 issue (1857) NOW! > > > Bob Kukura wrote: > > > > Without these changes, GIOP 1.2 implementations will not be > guaranteed > > to receive the request_id in the initial fragment of a fragmented > > message. After receiving such an initial fragment, > implementations will > > have to assume that the next fragment that has a request_id that > has not > > already been seen belongs to that message. When sending, if an > > implementation does not ensure that the request_id is in the first > > fragment by making that fragment arbitrarily large, it will have > to > > somehow ensure that only one initial fragment without a request_id > is > > outstanding on a connection. This applies to Reply messages, not > just > > Request messages, so the note on page 15-40 would have to be > extended to > > cover Reply messages as well. Fixing the specification now as > I've > > recommended above is much easier, in my opinion. > > We agree. Furthermore, these changes allow for efficient > implementation > of GIOP proxies which often need to change the request_id field. > With > the request_id field buried after the service context, the proxy > must > dynamically compute the location of the request_id field in the > buffer > instead of looking for the request_id at a standard offset. > > George > Return-Path: Date: Mon, 21 Sep 1998 15:54:50 PDT Sender: Bill Janssen From: Bill Janssen To: interop@omg.org, orb_revision@omg.org, Bob Kukura Subject: Re: Lets fix critical GIOP 1.2 issue (1857) NOW! CC: cryan@iona.com, vinoski@iona.com, mchapman@iona.com References: <35FFF9C8.C4D4522@iona.com> You'd have to bump the GIOP major version # if you did this... Bill Return-Path: Date: Mon, 21 Sep 1998 16:18:47 PDT Sender: Bill Janssen From: Bill Janssen To: T E Rutt , Bob Kukura Subject: Re: proposed resolution to issue 1857 soon CC: orb_revision@omg.org, interop@omg.org, cryan@iona.com, mchapman@iona.com, vinoski@iona.com References: <199809182044.QAA01695@holta.ho.lucent.com> <36047740.912B0174@iona.com> Excerpts from local.omg: 19-Sep-98 Re: proposed resolution to .. Bob Kukura@iona.com (9703*) > I had sent out a different proposal for this issue a couple of days ago > that received only positive feedback. The proposal I sent out simply > moved the service_context field to the end of the RequestHeader and > ReplyHeader structs for GIOP 1.2, making the request_id the first > field. Let me provide some negative feedback for you, then, Bob. First, look at the issue of backwards compatibility. Moving the service context will break every ORB's IIOP implementation, including that in firewalls and proxies. I can't agree to that. In addition, it will introduce special-case handling for Request and Reply messages -- the service context will come earlier in the other message headers, such as CancelRequest and LocateRequest. Adding more special-casing to a protocol already foundering under it seems like a bad design idea to me. I'd suggest that we simply, for now, say that the request-id must be in the first fragment marshalled, without moving the service contexts. I understand the less-than-optimality of that design, too -- especially for ORBs that might marshal long service contexts, such as Transaction contexts. But I still believe it's a better solution for the short term. Bill Return-Path: Sender: jon@floorboard.com Date: Mon, 21 Sep 1998 16:52:01 -0700 From: Jonathan Biggar To: Bill Janssen CC: T E Rutt , Bob Kukura , orb_revision@omg.org, interop@omg.org, cryan@iona.com, mchapman@iona.com, vinoski@iona.com Subject: Re: proposed resolution to issue 1857 soon References: <199809182044.QAA01695@holta.ho.lucent.com> <36047740.912B0174@iona.com> <8q1hvLEB0KGWMJdXZx@holmes.parc.xerox.com> Bill Janssen wrote: > > Excerpts from local.omg: 19-Sep-98 Re: proposed resolution to .. Bob > Kukura@iona.com (9703*) > > > I had sent out a different proposal for this issue a couple of > days ago > > that received only positive feedback. The proposal I sent out > simply > > moved the service_context field to the end of the RequestHeader > and > > ReplyHeader structs for GIOP 1.2, making the request_id the first > > field. > > Let me provide some negative feedback for you, then, Bob. > > First, look at the issue of backwards compatibility. Moving the > service > context will break every ORB's IIOP implementation, including that > in > firewalls and proxies. I can't agree to that. > > In addition, it will introduce special-case handling for Request and > Reply messages -- the service context will come earlier in the other > message headers, such as CancelRequest and LocateRequest. Adding > more > special-casing to a protocol already foundering under it seems like > a > bad design idea to me. > > I'd suggest that we simply, for now, say that the request-id must be > in > the first fragment marshalled, without moving the service contexts. > I > understand the less-than-optimality of that design, too -- > especially > for ORBs that might marshal long service contexts, such as > Transaction > contexts. But I still believe it's a better solution for the short > term. I think you have some confusion about the proposal. This proposal is only effective for GIOP 1.2, which is not currently published as a standard. This makes it's definition subject to change until final publication by the OMG. So, there is no backwards compatibility issue here at all, an nobody's implementation is broken. Yes, you will have to add additional code to support GIOP 1.2, but you have to anyway. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 21 Sep 1998 22:16:57 -0400 From: Bob Kukura Organization: IONA Technologies To: Bill Janssen CC: T E Rutt , orb_revision@omg.org, interop@omg.org, cryan@iona.com, mchapman@iona.com, vinoski@iona.com Subject: Re: proposed resolution to issue 1857 soon References: <199809182044.QAA01695@holta.ho.lucent.com> <36047740.912B0174@iona.com> <8q1hvLEB0KGWMJdXZx@holmes.parc.xerox.com> Bill Janssen wrote: > > Excerpts from local.omg: 19-Sep-98 Re: proposed resolution to .. Bob > Kukura@iona.com (9703*) > > > I had sent out a different proposal for this issue a couple of > days ago > > that received only positive feedback. The proposal I sent out > simply > > moved the service_context field to the end of the RequestHeader > and > > ReplyHeader structs for GIOP 1.2, making the request_id the first > > field. > > Let me provide some negative feedback for you, then, Bob. Thanks alot! > > First, look at the issue of backwards compatibility. Moving the > service > context will break every ORB's IIOP implementation, including that > in > firewalls and proxies. I can't agree to that. I certainly wouldn't agree to moving anything in GIOP 1.0 or 1.1 either. But this is a new version, 1.2, which has not been officially published yet. Even without my proposed changes, the 1.2 versions of these messages are not compatable with 1.0 or 1.1, since the object_key has been changed into a union, the principal has been removed, and more reply status values have been added. > > In addition, it will introduce special-case handling for Request and > Reply messages -- the service context will come earlier in the other > message headers, such as CancelRequest and LocateRequest. Adding > more > special-casing to a protocol already foundering under it seems like > a > bad design idea to me. No messages other than Request and Reply have service contexts. My proposed changes will actually make the message format more regular - the request_id will now be first in all the message headers that contain one: Request, Reply, LocateRequest, LocateReply, Fragment, and CancelRequest. > > I'd suggest that we simply, for now, say that the request-id must be > in > the first fragment marshalled, without moving the service contexts. > I > understand the less-than-optimality of that design, too -- > especially > for ORBs that might marshal long service contexts, such as > Transaction > contexts. But I still believe it's a better solution for the short > term. > > Bill -Bob Return-Path: Date: Mon, 21 Sep 1998 19:34:56 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Bob Kukura Subject: Re: proposed resolution to issue 1857 soon CC: T E Rutt , orb_revision@omg.org, interop@omg.org, cryan@iona.com, mchapman@iona.com, vinoski@iona.com References: <199809182044.QAA01695@holta.ho.lucent.com> <36047740.912B0174@iona.com> <8q1hvLEB0KGWMJdXZx@holmes.parc.xerox.com> <36070899.B7FDC01C@iona.com> Actually, considering that I was confused about the occurrence of service context in the protocol, I guess I'd not be too opposed to your proposal, Bob. Mind you, I still think it should be GIOP 2.0. Bill Return-Path: Date: Mon, 21 Sep 1998 22:59:23 -0400 From: Bob Kukura Organization: IONA Technologies To: Bill Janssen CC: T E Rutt , orb_revision@omg.org, interop@omg.org, cryan@iona.com, mchapman@iona.com, vinoski@iona.com Subject: Re: proposed resolution to issue 1857 soon References: <199809182044.QAA01695@holta.ho.lucent.com> <36047740.912B0174@iona.com> <8q1hvLEB0KGWMJdXZx@holmes.parc.xerox.com> <36070899.B7FDC01C@iona.com> <4q1knE4B0KGW0JdhIp@holmes.parc.xerox.com> Bill Janssen wrote: > > Actually, considering that I was confused about the occurrence of > service context in the protocol, I guess I'd not be too opposed to > your > proposal, Bob. Thanks, Bill. Not a ringing endorsement, but I'm glad you don't see any major problems with it. I assume you agree that it does solve the problem. > > Mind you, I still think it should be GIOP 2.0. I'm curious why? To me, valid reasons to increment the major version would be: 1) A new IOR profile structure that could not be validly interpretted by implementations of previous GIOP/IIOP versions. For example, a 1.1 client is expected to be able to use a 1.2 profile, but not a 2.0 profile, to establish a 1.0 or 1.1 connection to the server. 2) A completely different protocol design, such as something using the W3C Mux protocol or a complely different encoding syntax. 3) To finally escape the requirement that ORBs have to implement all previous minor versions. For example, if we get to GIOP 1.5, supporting 1.0, 1.1, 1.2, 1.3, and 1.4 might just be too much baggage to carry around. I just don't see moving the fields around a bit to be as significant a change as any of these. Its just a syntax change, that happens to solve one fairly serious fragmentation problem. To me, changing the object_key, or adding support for interleaving itself are more significant, yet haven't seemed to warrant a new major version. I see the decision to bump the major version as a trade-off between 1) and 3). It would be nice to quit supporting all those older protocol versions, but we still generally have to interoperate with some recent older versions, and we don't want to bloat our IORs with another profile. I don't think the protocol in CORBA 2.3 should be 2.0 because I don't think we've really fixed the main problems inherent in the GIOP 1.x design, ala 2). > > Bill -Bob