Issue 2863: Issue: Problem with issue 2801 resolution (interop) Source: (, ) Nature: Uncategorized Issue Severity: Critical Summary: Summary: > > Add the following paragraph to 15.8: > > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > > - a request may not be sent by an endpoint if a reply has been > > sent by that endpoint without a terminating fragment. > > > > - a reply may not be sent by an endpoint if a request has been > > sent by that endpoint without a terminating fragment." > > > > Why is a plain (non-fragmented) request/reply prohibited here? There has > never been and feature interaction between fragmented request/replies and > non-fragmented ones, so why have this restriction. Jishnu Mukerji wrote: > After poking around some it seems to me that the following words address > Martin"s concern and hence the issue of inadvertently disallowing something > that wasn"t broken in the current resolution of 2801. The additional word > "fragmented" in two places is bracekted between "*"s. > > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a *fragmented* request may not be sent by an endpoint if a > *fragemented* reply has been sent by that endpoint without a terminating >fragment. > > - a *fragemented* reply may not be sent by an endpoint if a > *fragmented* request has been sent by that endpoint without a terminating >fragment." Resolution: resolved, see below Revised Text: Resolution: In section 15.8 (Bi-Directional GIOP), replace the para. that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: " Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". This property of unambiguous association of requests and replies must be preserved while permitting each end to generate Request Ids for new requests independently. To ensure this, on a connection that is used bi-directionally in GIOP 1.2, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted. A connection on which this regime of Request ID assignment is not used, shall never be used to transmit bi-directional GIOP 1.2 messages. Actions taken: September 15, 1999: received issue September 28, 1999: closed issue Discussion: End of Annotations:===== X-Sender: andrew@emerald.omg.org Message-Id: Mime-Version: 1.0 Date: Wed, 15 Sep 1999 15:45:39 -0400 To: Juergen Boldt From: Andrew Watson Subject: Issue: Problem with issue 2801 resolution Content-Type: text/plain; charset="us-ascii" X-UIDL: eb6cf8682fd883c6aa54cafef9d96dfc Martin Chapman wrote: > > Add the following paragraph to 15.8: > > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > > - a request may not be sent by an endpoint if a reply has been > > sent by that endpoint without a terminating fragment. > > > > - a reply may not be sent by an endpoint if a request has been > > sent by that endpoint without a terminating fragment." > > > > Why is a plain (non-fragmented) request/reply prohibited here? There > has > never been and feature interaction between fragmented > request/replies and > non-fragmented ones, so why have this restriction. Jishnu Mukerji wrote: > After poking around some it seems to me that the following words address > Martin's concern and hence the issue of inadvertently disallowing something > that wasn't broken in the current resolution of 2801. The additional word > "fragmented" in two places is bracekted between "*"s. > > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a *fragmented* request may not be sent by an endpoint if a > *fragemented* reply has been sent by that endpoint without a terminating >fragment. > > - a *fragemented* reply may not be sent by an endpoint if a > *fragmented* request has been sent by that endpoint without a terminating >fragment." X-Sender: andrew@emerald.omg.org Message-Id: Mime-Version: 1.0 Date: Wed, 15 Sep 1999 17:50:06 -0400 To: interop@omg.org From: Andrew Watson Subject: Once more, with feeling: Issue 2863 classified as urgent Cc: firewall-rtf@omg.org Content-Type: text/plain; charset="us-ascii" X-UIDL: a596298513e42dfa277aef43bb88cbef Good Afternoon, As you may recall, about a month ago we ran an urgent issue resolution process to address Issue 2801 (fragmentation broken with bi-dir giop). The thread of discussion on this issue is archived here: http://www.omg.org/issues/issue2801.txt Unfortunately, it is now generally agreed that the resolution solved the problem, but created a different one. After some discussion, I have taken the points raised by Martin Chapman and Jishnu Mukerji, turned them into a new issue (2863), and am classifying this new issue as urgent, in accordance with procedure described in section 4.4.1.5 of the P&P, so that we can fix the fix. The summary of this new issue, and also the thread of discussion since it was received, can be found here: http://www.omg.org/issues/issue2863.txt The issue will be voted on by the Interoperability RTF: however, I am also informing the Firewall RTF, since bidirectional GIOP is relevant to the firewall specification. The default resolution will be to add the following paragraph to section 15.8 of the CORBA 2.3 specification, replacing the paragraph inserted by the resolution of issue 2801: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a fragmented request may not be sent by an endpoint if a fragemented reply has been sent by that endpoint without a terminating fragment. - a fragemented reply may not be sent by an endpoint if a fragmented request has been sent by that endpoint without a terminating fragment." This default resolution will be applied to CORBA 2.3 if and only if the Interop RTF fails to generate an alternative resolution within 14 days (i.e. by Wed 29th Sep). It is not necessarily the most desirable resolution. I strongly recommend that any proposed resolutions aired on the RTF mailing list include the *EXACT* wording of the proposed amendment, so we can avoid getting into the same mess again. Cheers, Andrew Cc: interop@omg.org, firewall-rtf@omg.org Message-ID: <37E25D19.9AFC5BE6@lucent.com> Date: Fri, 17 Sep 1999 11:24:09 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Watson Original-CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4c42855428d2a2ab9514a404b8b26ad2 Andrew Watson wrote: > > Good Afternoon, > > As you may recall, about a month ago we ran an urgent issue > resolution > process to address Issue 2801 (fragmentation broken with bi-dir > giop). The > thread of discussion on this issue is archived here: > > http://www.omg.org/issues/issue2801.txt > > Unfortunately, it is now generally agreed that the resolution solved > the > problem, but created a different one. After some discussion, I have > taken > the points raised by Martin Chapman and Jishnu Mukerji, turned them > into a > new issue (2863), and am classifying this new issue as urgent, in > accordance with procedure described in section 4.4.1.5 of the P&P, > so that > we can fix the fix. > > The summary of this new issue, and also the thread of discussion > since it > was received, can be found here: > > http://www.omg.org/issues/issue2863.txt > --------- Andrew has assigned Urgent Resolution 2863 to the Interop RTF for > resolution. The Due date for our recommendation is Wed. 29 September, 1999. The default resolution will be to add the following paragraph to section 15.8 of the CORBA 2.3 specification, replacing the paragraph inserted by the resolution of issue 2801: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a fragmented request may not be sent by an endpoint if a fragemented reply has been sent by that endpoint without a terminating fragment. - a fragemented reply may not be sent by an endpoint if a fragmented request has been sent by that endpoint without a terminating fragment." There is another a big problem, in that the proposed resolution to Urgent Issue 2863 does not mention locate request and locate reply, which allow fragmentation in GIOP 1.2. This mail is to get things going on agreement on exact wording of an alternate proposal to send out for Interop RTF Voting early next week. Proposal a) is provided for completeness, however, based on informal discussions at San Jose, I have decided to propose a formal vote early next week on proposal b) the odd/even request Id approach to solve the problem. ---- a) A minimal fix to the proposed resolution (better than what is proposed, but harder to implement than the even/odd fix restated below) would be: Add the following paragraph to 15.8: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a fragmented request or a fragmented locateRequest message may not be sent by an endpoint if either a reply or locateReply message has been sent by that endpoint without a terminating fragment. - a fragmented reply or a fragmented locateReply message may not be sent by an endpoint if either a request or locateRequest message has been sent by that endpointwithout a terminating fragment." -------------------- However, due to the implementation difficulty (an ORB Multiplexer must keep state information regarding the completion status of fragmented message types), this is not the most desirable solution to many orb vendors. Informal discussion at the San Jose meeting hallways led me to believe that the majority of the voting members would vote yes on the Odd/even proposal if it was offered. b) Thus I offer the following for one wordsmithing round, before a formal vote to be sent out early next week (no later than Wednesday). In section 15.8 (Bi-Directional GIOP), replace the para. that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: "Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". With Bi-directional GIOP this guarantee must be preserved while permitting each end to generate Request IDs for new requests. To ensure this, on a connection that is used bi-directionally, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted." Please respond with any alternative wordings of proposal b, which we can discuss on the list before a vote is sent out next week. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA From: Peter Furniss To: "'Andrew Watson'" , "'Tom Rutt'" Cc: "'interop@omg.org'" , "'firewall-rtf@omg.org'" Subject: RE: Once more, with feeling: Issue 2863 classified as urgent Date: Sat, 18 Sep 1999 11:39:46 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id GAA11582 Content-Type: text/plain; charset="us-ascii" X-UIDL: c1b948c9848f95f5df02f9351b968341 Tom Rutt sent : > provided for completeness, however, based on informal discussions at San Jose, I > have decided to propose a formal vote early next week on proposal b) the > odd/even request Id approach to solve the problem. Would high/low be better than odd/even ? - requiring the connection responder to create request id's with the top bit (of the unsigned long) set. This has the virtue that is very unlikely to be used by an existing implementation (if there are any that try to do bi-dir& fragmentation) and thus will allow the backwards interworking. Effectively, odd/even, high/low and the various (rejected) ways of marking the message as reverse-flow in another field are all equivalent - odd/even and high/low just take a bit (last or first) from the request id to use as the direction bit. (I'm only suggesting this now because it came up, but didn't seem to be noticed in the previous discussion. Let this be the last urgent issue on the subject !) PROBABLY A SEPARATE ISSUE: By the way, is there a related problem with fragmenting very early - in the service context, which is sent before the request id. The note in the middle of page 15-43 disallows Cancel before the request id has been sent, but the whole idea of early fragmentation doesn't fit well with 1.2 fragments (and certainly not with interleaving). With the tendency of service context to carry more and more stuff, this looks worrying. Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Sender: jon@floorboard.com Message-ID: <37E3C3C4.AC846515@floorboard.com> Date: Sat, 18 Sep 1999 09:54:28 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Peter Furniss CC: "'Andrew Watson'" , "'Tom Rutt'" , "'interop@omg.org'" , "'firewall-rtf@omg.org'" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <01BF01CA.AD8417C0@B205.ds.ulcc.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0eb5451096937089c473e0115ee50e7c Peter Furniss wrote: > PROBABLY A SEPARATE ISSUE: > By the way, is there a related problem with fragmenting very early - > in the service context, which is sent before the request id. The > note in the middle of page 15-43 disallows Cancel before the request > id has been sent, but the whole idea of early fragmentation doesn't > fit well with 1.2 fragments (and certainly not with > interleaving). With the tendency of service context to carry more > and more stuff, this looks worrying. I think you missed something. GIOP 1.2 moved the service context field to the end of the Request header just to solve this very problem. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 20 Sep 1999 17:36:47 +1000 (EST) From: Michi Henning To: Tom Rutt cc: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent In-Reply-To: <37E25D19.9AFC5BE6@lucent.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: b9ce5dd6091dd0e23c9646edbfa78b12 On Fri, 17 Sep 1999, Tom Rutt wrote: > b) Thus I offer the following for one wordsmithing round, before a formal vote > to be sent out early next week (no later than Wednesday). That is something I can live with. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com AUSTRALIA http://www.ooc.com Date: Mon, 20 Sep 1999 08:47:32 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Peter Furniss CC: "'Andrew Watson'" , "'Tom Rutt'" , "'interop@omg.org'" , "'firewall-rtf@omg.org'" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent X-Priority: 3 (Normal) References: <01BF01CA.AD8417C0@B205.ds.ulcc.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ae700f9df473ae0e4f31a7012750bdc7 Peter Furniss wrote: > > Would high/low be better than odd/even ? - requiring the connection > responder to create request id's with the top bit (of the unsigned > long) set. This has the virtue that is very unlikely to be used by > an > existing implementation (if there are any that try to do bi-dir& > fragmentation) and thus will allow the backwards interworking. > > Effectively, odd/even, high/low and the various (rejected) ways of > marking the message as reverse-flow in another field are all > equivalent > - odd/even and high/low just take a bit (last or first) from the > request id to use as the direction bit. > > (I'm only suggesting this now because it came up, but didn't seem to > be noticed in the previous discussion. Let this be the last urgent > issue on the subject !) It doesn't matter to me much - but I do need to know which immediately. One advantage of even/odd is that it leaves me free to assign my request ids (for both directions) high in the number space, hopefully preventing collision with numbers used by older orbs. Since this is only probablistic error avoidance I think it is best to leave it as a pragmatic choice for implementations rather than mandating it in the spec. From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: terutt@lucent.com cc: interop@omg.org, firewall-rtf@omg.org Message-ID: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> Date: Mon, 20 Sep 1999 13:35:32 -0500 Subject: Re: Once more, with feeling: Issue 2863 classified as urgent Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: c268517d2dc61da63262bc3b8b4ea7e4 The odd/even technique was voted down in the last go-around, presumably because we realized it was not a good long-term solution and we wanted to do something better, particularly for 1.3. The problem with doing odd/even in 1.2 and something better in 1.3 is that we will always have to support odd/even, since we will always have to support all versions of GIOP. So if 1.3 has a better solution, we will have to implement both the better solution AND odd/even. However, assume we implement the restriction set out in Andrew's note for 1.2 (and we think implementing the restriction is simple - see point 1 below), this could potentially be evolved to a better solution without needing any implementation rework or adding further complexity. For example, we could add a "reverse flow fragment" GIOP message, which would not be subject to the restriction. (Note: I am assuming that "fragmented request/reply/etc." as defined in the restriction means a request/reply/etc. sent using a GIOP "fragment" message and not some other GIOP message that might be added in the future.) Other reasons why we would rather not implement odd/even: 1. Tom says the offered solution is more difficult to implement than the odd/even hack. He said, "an ORB Multiplexer must keep state information regarding the completion status of fragmented message types". We don't agree that this is all that difficult. This state information could be nothing more than a counter, incremented when a fragmented message has begun, and decremented when a fragment message is complete. If the counter is non-zero, then the restriction applies; otherwise you can send fragments. The additional complexity seems minimal. 2. (Here's the architectural purist talking) The problem we are trying to solve involves ONLY fragments and bi-dir GIOP. The solution should ONLY affect fragments and bi-dir GIOP. The even/odd hack is visible on every message that takes a request ID. 3. (The purist again) RequestID has a meaning. It is a label for a request/reply sequence. Adding even/odd restrictions overloads that meaning. Overloading meaning is architecturally shaky. Russell Butek butek@us.ibm.com Tom Rutt on 09/17/99 10:24:09 AM Please respond to terutt@lucent.com To: Andrew Watson cc: interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent Andrew Watson wrote: > > Good Afternoon, > > As you may recall, about a month ago we ran an urgent issue resolution > process to address Issue 2801 (fragmentation broken with bi-dir giop). The > thread of discussion on this issue is archived here: > > http://www.omg.org/issues/issue2801.txt > > Unfortunately, it is now generally agreed that the resolution solved the > problem, but created a different one. After some discussion, I have taken > the points raised by Martin Chapman and Jishnu Mukerji, turned them into a > new issue (2863), and am classifying this new issue as urgent, in > accordance with procedure described in section 4.4.1.5 of the P&P, so that > we can fix the fix. > > The summary of this new issue, and also the thread of discussion since it > was received, can be found here: > > http://www.omg.org/issues/issue2863.txt > --------- Andrew has assigned Urgent Resolution 2863 to the Interop RTF for resolution. The Due date for our recommendation is Wed. 29 September, 1999. The default resolution will be to add the following paragraph to section 15.8 of the CORBA 2.3 specification, replacing the paragraph inserted by the resolution of issue 2801: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a fragmented request may not be sent by an endpoint if a fragemented reply has been sent by that endpoint without a terminating fragment. - a fragemented reply may not be sent by an endpoint if a fragmented request has been sent by that endpoint without a terminating fragment." There is another a big problem, in that the proposed resolution to Urgent Issue 2863 does not mention locate request and locate reply, which allow fragmentation in GIOP 1.2. This mail is to get things going on agreement on exact wording of an alternate proposal to send out for Interop RTF Voting early next week. Proposal a) is provided for completeness, however, based on informal discussions at San Jose, I have decided to propose a formal vote early next week on proposal b) the odd/even request Id approach to solve the problem. ---- a) A minimal fix to the proposed resolution (better than what is proposed, but harder to implement than the even/odd fix restated below) would be: Add the following paragraph to 15.8: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a fragmented request or a fragmented locateRequest message may not be sent by an endpoint if either a reply or locateReply message has been sent by that endpoint without a terminating fragment. - a fragmented reply or a fragmented locateReply message may not be sent by an endpoint if either a request or locateRequest message has been sent by that endpointwithout a terminating fragment." -------------------- However, due to the implementation difficulty (an ORB Multiplexer must keep state information regarding the completion status of fragmented message types), this is not the most desirable solution to many orb vendors. Informal discussion at the San Jose meeting hallways led me to believe that the majority of the voting members would vote yes on the Odd/even proposal if it was offered. b) Thus I offer the following for one wordsmithing round, before a formal vote to be sent out early next week (no later than Wednesday). In section 15.8 (Bi-Directional GIOP), replace the para. that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: "Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". With Bi-directional GIOP this guarantee must be preserved while permitting each end to generate Request IDs for new requests. To ensure this, on a connection that is used bi-directionally, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted." Please respond with any alternative wordings of proposal b, which we can discuss on the list before a vote is sent out next week. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Mon, 20 Sep 1999 14:35:34 PDT Sender: Bill Janssen From: Bill Janssen To: terutt@lucent.com, butek@us.ibm.com Subject: Re: Once more, with feeling: Issue 2863 classified as urgent CC: interop@omg.org, firewall-rtf@omg.org In-Reply-To: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> Content-Type: text X-UIDL: c5e0cfc373fde0c818a7af7d4aef0d47 Excerpts from local.omg: 20-Sep-99 Re: Once more, with feeling.. butek@us.ibm.com (7222*) > 3. (The purist again) RequestID has a meaning. It is a label for a > request/reply sequence. Adding even/odd restrictions overloads that meaning. > Overloading meaning is architecturally shaky. Indeed. I would much prefer to use a bit of those 6 reserved bits in the header, instead of a bit from the RequestID. After all, what are we reserving those bits for, anyway? Bill Cc: butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <37E6F791.497CB915@lucent.com> Date: Mon, 20 Sep 1999 23:12:17 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen Original-CC: butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 09aa28079d257c3e65f7addcb1f0c2b8 The extra bits are not an option. This time we have two options, the odd/even or the restriction (with some better precision). I will be sending out the preliminary wording tonigyt of what will go out for vote tomorrow. This is for one final round of wordsmithing what we will vote on. Bill Janssen wrote: > > Excerpts from local.omg: 20-Sep-99 Re: Once more, with feeling.. > butek@us.ibm.com (7222*) > > > 3. (The purist again) RequestID has a meaning. It is a label > for a > > request/reply sequence. Adding even/odd restrictions overloads > that meaning. > > Overloading meaning is architecturally shaky. > > Indeed. I would much prefer to use a bit of those 6 reserved bits > in > the header, instead of a bit from the RequestID. After all, what > are we > reserving those bits for, anyway? > > Bill -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <37E6FEB9.CE63CBE9@lucent.com> Date: Mon, 20 Sep 1999 23:42:49 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen Original-CC: butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 797073c5645cc1d93f9f6d75f919c2cd The purist approach is not in scope because an urgent resolution fix may only constrain implementations of the published standard, it may not widen or add new functions. We have only two choices, the restriction or the odd/even request id. The next revision of GIOP could be more than an year before it is published, and in fact could be longer (i.e., wait for giop 1.2 to fix all the "efficiency" bugs of giop"). Bill Janssen wrote: > > Indeed. I would much prefer to use a bit of those 6 reserved bits in > the header, instead of a bit from the RequestID. After all, what are we > reserving those bits for, anyway? > > Bill -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Tue, 21 Sep 1999 09:18:17 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 95babc0914593cb71b57263bc2614cb6 Tom, Agreed that the purist approach is not in scope for the urgent clarification. However, it is in scope for the next rev of GIOP. Adopting the restriction now (suitably wordsmithed) would allow us to add a cleaner solution in a future rev of GIOP. Going for odd/even now means that's very unlikely to happen. Simon Tom Rutt wrote: > > The purist approach is not in scope because an urgent > resolution fix may only constrain implementations of the published > standard, it may not widen or add new functions. > > We have only two choices, the restriction or the odd/even request > id. > > The next revision of GIOP could be more than an year before it > is published, and in fact could be longer (i.e., wait for giop 1.2 > to fix all the "efficiency" bugs of giop"). > > Bill Janssen wrote: > > > > > Indeed. I would much prefer to use a bit of those 6 reserved bits > in > > the header, instead of a bit from the RequestID. After all, what > are we > > reserving those bits for, anyway? > > > > Bill > > -- > > Tom Rutt email: > terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Peter Furniss To: "'Tom Rutt'" , "interop@omg.org" Cc: "firewall-rtf@omg.org" Subject: RE: Once more, with feeling: Issue 2863 classified as urgent Date: Tue, 21 Sep 1999 10:09:24 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id FAA16703 Content-Type: text/plain; charset="us-ascii" X-UIDL: 5c3eb76fa98b32bd036fdbb047978b30 Doesn't the restriction text need to cover the case where a Cancel is sent ? The restriction text (and the current solution to the problem) assumes that all fragment sequences end with a terminating fragment. The requestor is not expected to send more fragments after sending a Cancel (the text actually says the server should not expect to receive any, but presumably that is equivalent), so there will never be a terminating fragment. With the proposed text, that would disallow fragmenting replies (from requests in the opposite direction) for ever. There seems to no specification of what happens if a Cancel is received while a fragmented reply is being returned. If the Cancel arrives late, it can cross with the complete reply (or be ignored altogether), so there can be no requirement that the reply be stopped. But is the replier at liberty to stop sending, and leave the fragment sequence hanging ? (or have I missed something again) Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Date: Tue, 21 Sep 1999 08:27:14 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Peter Furniss CC: "'Tom Rutt'" , "interop@omg.org" , "firewall-rtf@omg.org" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent X-Priority: 3 (Normal) References: <01BF0419.8F3B87C0@B210.ds.ulcc.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2288225bd0fef1dedd5cba71e746251b Peter brings up some good points. Of course with sufficient wordsmithing we can cover all these cases in the restrictions on when fragmentation can be done. But chances are we still won't get it right in one more iteration. I agree that the even/odd approach isn't modular or elegant. But its advantage is that it is easy both to specify and to implement. It is very unlikely that there will be any troubles over interpretation of it. AND, it is never less efficient than the restriction approach, and in some cases is more efficient. If we adopt even/odd for 1.2 we probably won't need to adopt something else for 1.3. If we adopt the restriction, then there will be reasons to make a change in 1.3. I consider this bad because it will be that much more to implement. I am in the midst of an implementation of 1.2, and the restriction is a considerable complication, and makes verification that the algorithm is correct harder. The even/odd approach would be much simpler for me. Paul Peter Furniss wrote: > > Doesn't the restriction text need to cover the case where a Cancel > is > sent ? The restriction text (and the current solution to the > problem) > assumes that all fragment sequences end with a terminating fragment. > > The requestor is not expected to send more fragments after sending a > Cancel (the text actually says the server should not expect to > receive > any, but presumably that is equivalent), so there will never be a > terminating fragment. With the proposed text, that would disallow > fragmenting replies (from requests in the opposite direction) for > ever. > > There seems to no specification of what happens if a Cancel is > received while a fragmented reply is being returned. If the Cancel > arrives late, it can cross with the complete reply (or be ignored > altogether), so there can be no requirement that the reply be > stopped. > But is the replier at liberty to stop sending, and leave the > fragment > sequence hanging ? > > (or have I missed something again) > > Peter Furniss To: terutt@lucent.com cc: Bill Janssen , butek@us.ibm.com, > interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent Date: Tue, 21 Sep 1999 14:24:08 +0100 From: Craig Ryan Content-Type: text X-UIDL: 74c9290e5ecb7d8c9fe5be1d1a08a731 >I will be sending out the preliminary wording tonigyt of what will >go out >for vote tomorrow. This is for one final round of wordsmithing what >we will vote on. Tom, as Martin pointed out last time around can you please allow suitable time between the sending out of preliminary text and the time at which voting commences? We really have a significant time difference between Dublin, the US and Perth and need time to go over any proposals in reasonable detail. For this to be possible we'd need a bare minimum of at least 2-3 days. thanks, craig. Sender: jis@fpk.hp.com Message-ID: <37E79B49.81B30E58@fpk.hp.com> Date: Tue, 21 Sep 1999 10:50:49 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash CC: terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3967d874d144bcc7bc5b0d19a41d5a0d > Tom, > Agreed that the purist approach is not in scope for the urgent > clarification. > However, it is in scope for the next rev of GIOP. Adopting the > restriction > now (suitably wordsmithed) would allow us to add a cleaner solution > in a future > rev of GIOP. Going for odd/even now means that's very unlikely to > happen. > Why so? Jishnu -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Tue, 21 Sep 1999 21:27:08 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 8b3c65faf3b9017a91d1d5516b754eb7 Jishnu, Hacks always look good to the people doing them, because they fix the immediate problem. We have all done them in dark corners of our code when under pressure. But do we want to expose this hack to the world as part of the GIOP specification? I say not, even if this creates slightly more implementation cost. Simon Jishnu Mukerji wrote: > > Simon Nash wrote: > > > > Jishnu, > > Because the even/odd hack will be "good enough" and no-one will > want to > > revisit this issue again. The following is from Paul's posting > from earlier > > today: > > > > > If we adopt even/odd for 1.2 we probably won't need to adopt > something > > > else for 1.3. If we adopt the restriction, then there will be > reasons to > > > make a change in 1.3. I consider this bad because it will be > that much > > > more to implement. > > Heck, if it is that good then we should just do it and stop worrying > about > it.:-) Are we now trying to say that we should adopt a relatively > more broken > fix for now so that the purists are more likely to get a shot later > at doing a > more pure fix, which functionally will not be sufficiently better > than the less > broken fix that is on the table now to justify doing it? Seems like > a weird > position to take. > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 21 Sep 1999 20:56:04 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 928294620f5fd7958263c7dec85a288b Jishnu, Because the even/odd hack will be "good enough" and no-one will want to revisit this issue again. The following is from Paul's posting from earlier today: > If we adopt even/odd for 1.2 we probably won't need to adopt something > else for 1.3. If we adopt the restriction, then there will be reasons to > make a change in 1.3. I consider this bad because it will be that much > more to implement. Simon Jishnu Mukerji wrote: > > > Tom, > > Agreed that the purist approach is not in scope for the urgent > clarification. > > However, it is in scope for the next rev of GIOP. Adopting the > restriction > > now (suitably wordsmithed) would allow us to add a cleaner > solution in a future > > rev of GIOP. Going for odd/even now means that's very unlikely to > happen. > > > > Why so? > > Jishnu > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Message-ID: <37E7E80C.FC268304@fpk.hp.com> Date: Tue, 21 Sep 1999 16:18:20 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash CC: terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 05046b7d672f15fa2389d81e9fa5b409 Simon Nash wrote: > > Jishnu, > Because the even/odd hack will be "good enough" and no-one will want > to > revisit this issue again. The following is from Paul's posting from > earlier > today: > > > If we adopt even/odd for 1.2 we probably won't need to adopt > something > > else for 1.3. If we adopt the restriction, then there will be > reasons to > > make a change in 1.3. I consider this bad because it will be that > much > > more to implement. Heck, if it is that good then we should just do it and stop worrying about it.:-) Are we now trying to say that we should adopt a relatively more broken fix for now so that the purists are more likely to get a shot later at doing a more pure fix, which functionally will not be sufficiently better than the less broken fix that is on the table now to justify doing it? Seems like a weird position to take. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Tue, 21 Sep 1999 14:15:01 PDT Sender: Bill Janssen From: Bill Janssen To: Simon Nash , Jishnu Mukerji Subject: Re: Once more, with feeling: Issue 2863 classified as urgent CC: terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org In-Reply-To: <37E7F2A8.71795E9F@fpk.hp.com> References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E7F2A8.71795E9F@fpk.hp.com> Content-Type: text X-UIDL: c70c41a883be3cfc2ea03bed6d431c66 Excerpts from direct: 21-Sep-99 Re: Once more, with feeling.. Jishnu Mukerji@fpk.hp.co (1695*) > If the more > elegent fix stands on its own two feet, the so called hack then can > be > restricted to 1.2 and pure elegence can rule supreme in 1.3. Of course, the `more elegant' version will also have to support 1.2, so both the good, the bad (1.0 and 1.1) and the ugly (1.2) will have to in every implementation. Bill Sender: jis@fpk.hp.com Message-ID: <37E7F2A8.71795E9F@fpk.hp.com> Date: Tue, 21 Sep 1999 17:03:36 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash CC: terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b9cc7757efa405ac502a9922726345d8 Simon Nash wrote: > > Jishnu, > Hacks always look good to the people doing them, because they fix > the > immediate problem. We have all done them in dark corners of our > code when > under pressure. But do we want to expose this hack to the world as > part > of the GIOP specification? I say not, even if this creates slightly > more implementation cost. I think that the dilemma facing us is that apparently the even/odd solution fixes the problem more completely in a more easily comprehensible fashion than the other one. To quote from Paul's email message that you like to quote from: > Peter brings up some good points. Of course with sufficient wordsmithing > we can cover all these cases in the restrictions on when fragmentation > can be done. But chances are we still won't get it right in one more > iteration. > > I agree that the even/odd approach isn't modular or elegant. But its > advantage is that it is easy both to specify and to implement. It is > very unlikely that there will be any troubles over interpretation of it. > AND, it is never less efficient than the restriction approach, and in > some cases is more efficient. I can see how it may be quite difficult covering all the nooks and crannies in the other approach. Personally, I think whatever fixes the problem more completely in the most unambiguous fashion should be done now, and any feature/message set extensions to be proposed (can an RTF actually do that?) in a future RTF should stand on their own merit irrespective of what is adopted as a fix now. If the more elegent fix stands on its own two feet, the so called hack then can be restricted to 1.2 and pure elegence can rule supreme in 1.3. Jishnu. Sender: jis@fpk.hp.com Message-ID: <37E7FA5D.D073CB9E@fpk.hp.com> Date: Tue, 21 Sep 1999 17:36:29 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Bill Janssen CC: Simon Nash , terutt@lucent.com, butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E7F2A8.71795E9F@fpk.hp.com> <4rtzJJgB0KGWI3R6Qx@holmes.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: a27f99aa0ab3929b608ca78cf3326b98 Bill Janssen wrote: > > Excerpts from direct: 21-Sep-99 Re: Once more, with feeling.. Jishnu > Mukerji@fpk.hp.co (1695*) > > > If the more > > elegent fix stands on its own two feet, the so called hack then > can be > > restricted to 1.2 and pure elegence can rule supreme in 1.3. > > Of course, the `more elegant' version will also have to support 1.2, > so > both the good, the bad (1.0 and 1.1) and the ugly (1.2) will have to > be in > every implementation. Which would be the case anyway, no matter what is done now - even if nothing is done now.:-) All we are arguing about is the details of the ugliness, and how relatively broken or unbroken the ugliness is. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Peter Furniss To: "'butek@us.ibm.com'" Cc: "interop@omg.org" , "firewall-rtf@omg.org" Subject: RE: Once more, with feeling: Issue 2863 classified as urgent Date: Wed, 22 Sep 1999 00:11:54 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-UIDL: 3b22ef1a5dfebab12e097a1471382150 I would challenge the view that odd/even is a nasty hack. Russell Butek sent : > 2. (Here's the architectural purist talking) The problem we are trying to > solve involves ONLY fragments and bi-dir GIOP. The solution should ONLY affect > fragments and bi-dir GIOP. The even/odd hack is visible on every message that > takes a request ID. > > 3. (The purist again) RequestID has a meaning. It is a label for a > request/reply sequence. Adding even/odd restrictions overloads that meaning. > Overloading meaning is architecturally shaky. The problem is NOT just fragments and bi-dir - that is just the symptom, not the disease. The disease is that RequestID is not correctly performing it role as a label. As a label the RequestId must unambiguously identify the request/reply. Since GIOP is connection-oriented, it need only be unambiguous within the scope of the connection, and since the request/reply has (normally) a well-defined completion they can be reused. But allowing both sides of the connection to choose RequestIds from the same number space is an architectural mistake in itself and sabotages the unambiguity. So far, this has only showed in the bi-dir + fragment problem. One can imagine potential extensions that would cause it to turn up elsewhere (more sophisticated Cancel's, channel-splitting, savemark/resume features). Odd/even is not the only way to address the labelling ambiguity problem, but it is very straightforward. Allowing both sides to choose numbers independently will mean that anything that uses the label when it could be either must use some other field to say whose id it is. (modified from my original reply to Russell which I unintentionally did not send to the list) Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Cc: Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <37E850B7.FE1EC7D5@lucent.com> Date: Tue, 21 Sep 1999 23:44:55 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash Original-CC: Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7c497a534c94a80aa91e1d156611d757 Simon Nash wrote: > > Tom, > Agreed that the purist approach is not in scope for the urgent > clarification. > However, it is in scope for the next rev of GIOP. Adopting the > restriction > now (suitably wordsmithed) would allow us to add a cleaner solution > in a future > rev of GIOP. Going for odd/even now means that's very unlikely to > happen. > > Simon > I do not see the reality in your point. With giop 1.3, there will be message format changes allowed, which would do things like reverse flow indications and other possibilities. With a new protocol version, the odd/even would not have to flow thru to the new fixes to collision avoidance. I think most would prefer to do it better for 1.3. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Wed, 22 Sep 1999 08:15:05 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Simon Nash CC: Jishnu Mukerji , terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent X-Priority: 3 (Normal) References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: c247ba3ce98e3ac73ee85cc2b3fedff4 Simon Nash wrote: > > Jishnu, > Hacks always look good to the people doing them, because they fix > the > immediate problem. We have all done them in dark corners of our > code > when under pressure. But do we want to expose this hack to the > world > as part of the GIOP specification? I say not, even if this creates > slightly more implementation cost. But the choice isn't between hack and no hack. It is between hack (a) and hack (b). I (a) to be much more of a hack than (b) in addition to being harder to implement and less efficient. I agree with Jishnu that you seem to be advocating (a) *because* it is the poorer choice, increasing the chances that it will be revisited. It will be (technically) equally hard to implement a purer technique in giop 1.3, regardless of whether (a) or (b) is adopted now. But if we adopt (a) we make things worse between now and then. To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <37E8CEF3.F9A7F0A3@lucent.com> Date: Wed, 22 Sep 1999 08:43:31 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Urgent Issue 2863 final wordsmith before vote References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f872a4e7c16ace8274a36be170c886e5 Craig Ryan asked me to not start the vote until Wed Evening or Thurs morning. Thus I feel obliged to allow another day of wordsmithing what we will vote on. I also will use this email to report on the output of the informal "pow-wow" of Myself, Michi, Jon Biggar, and Bill Janssen regarding the multiple Giop versions on a connection issue. In short, we all came to the conclusion that it must be allowed to send multiple GIOP versions on the same connection, because there is no exception which allows an orb to indicate to the other orb that it does not want multiple versions on the connection. All the orb can do is abort the connection without giving the other orb the reason for the abort. Although this proposedresolution has not yet been voted by the interop RTF, I do not anticipate objections, since the major opponents to allowing multiple versions on a connection were Michi, Bill, Jon, and myself, who were the same people who showed up to the informal pre-resolution pow-wow. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Peter Furniss cc: "interop@omg.org" , "firewall-rtf@omg.org" Message-ID: <852567F4.00489ED6.00@d54mta08.raleigh.ibm.com> Date: Wed, 22 Sep 1999 08:12:12 -0500 Subject: RE: Once more, with feeling: Issue 2863 classified as urgent Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 5b783c842d46e42e0161466e371db977 You said, "The problem is NOT just fragments and bi-dir - that is just the symptom, not the disease. The disease is that RequestID is not correctly performing it role as a label." RequestID WAS correctly performing its role as a label BEFORE bi-dir GIOP. So it is bi-dir GIOP that caused the problem, not requestID. Let's just say we need a new bit on the reverse-flow messages to indicate that they are reverse flow. That's effectively all that the odd/even requestID is, the bit is on the requestID within the message rather than on the message itself. But since requestID's are not on all messages, that doesn't seem the appropriate place to put the reverse flow indicator. For instance, how does an ORB which is handling reverse and normal flows on the same connection deal with a MessageError? WHICH message was in error? And what about future messages? Put requestID on new messages JUST to indicate reverse-flow? Russell Butek butek@us.ibm.com Peter Furniss on 09/21/99 06:11:54 PM To: Russell Butek/Austin/IBM@IBMUS cc: "interop@omg.org" , "firewall-rtf@omg.org" Subject: RE: Once more, with feeling: Issue 2863 classified as urgent I would challenge the view that odd/even is a nasty hack. Russell Butek sent : > 2. (Here's the architectural purist talking) The problem we are trying to > solve involves ONLY fragments and bi-dir GIOP. The solution should ONLY affect > fragments and bi-dir GIOP. The even/odd hack is visible on every message that > takes a request ID. > > 3. (The purist again) RequestID has a meaning. It is a label for a > request/reply sequence. Adding even/odd restrictions overloads that meaning. > Overloading meaning is architecturally shaky. The problem is NOT just fragments and bi-dir - that is just the symptom, not the disease. The disease is that RequestID is not correctly performing it role as a label. As a label the RequestId must unambiguously identify the request/reply. Since GIOP is connection-oriented, it need only be unambiguous within the scope of the connection, and since the request/reply has (normally) a well-defined completion they can be reused. But allowing both sides of the connection to choose RequestIds from the same number space is an architectural mistake in itself and sabotages the unambiguity. So far, this has only showed in the bi-dir + fragment problem. One can imagine potential extensions that would cause it to turn up elsewhere (more sophisticated Cancel's, channel-splitting, savemark/resume features). Odd/even is not the only way to address the labelling ambiguity problem, but it is very straightforward. Allowing both sides to choose numbers independently will mean that anything that uses the label when it could be either must use some other field to say whose id it is. (modified from my original reply to Russell which I unintentionally did not send to the list) Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk From: Peter Furniss To: Peter Furniss , "'butek@us.ibm.com'" Cc: "interop@omg.org" , "firewall-rtf@omg.org" Subject: RE: Once more, with feeling: Issue 2863 classified as urgent Date: Wed, 22 Sep 1999 15:22:01 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id KAA02797 Content-Type: text/plain; charset="us-ascii" X-UIDL: a94a7a9d33f40587137cedcc876ca7c7 Russell Butek sent : > You said, "The problem is NOT just fragments and bi-dir - that is just the > symptom, not the disease. The disease is that RequestID is not > correctly performing it role as a label." > > RequestID WAS correctly performing its role as a label BEFORE bi-dir GIOP. So > it is bi-dir GIOP that caused the problem, not requestID. There is an analogous problem with proposals to send GIOP on connectionless transports - the request id loses it's unambiguity. A label that was unambiguous in a limited scope will often become ambiguous if used in a wider scope. It is then a question of whether you disambiguate externally to the label (by prefix::, identifying the message it in as reverse flow) or internally (by restricting the namespace it uses). Although the general solution is usually to do this externally (I don't want to be told my C++ member variables must all start with m), in this case there seems no reason not to restrict the number space used by these integers. Or is the requestid already being overloaded with meanings ? > Let's just say we need a new bit on the reverse-flow messages to indicate that > they are reverse flow. That's effectively all that the odd/even requestID is, > the bit is on the requestID within the message rather than on the message > itself. But since requestID's are not on all messages, that doesn't seem the > appropriate place to put the reverse flow indicator. For instance, how does an > ORB which is handling reverse and normal flows on the same connection deal with > a MessageError? WHICH message was in error? And what about future messages? > Put requestID on new messages JUST to indicate reverse-flow? MessageError is a problem with uni-directional as soon as there are overlapping requests, since it does not identify which message caused the trouble. Effectively it is a connection-level message, since the only semantic understandable at the receiver is "there was a bad message on this connection". (BTW, doesn't MessageError interact with the restriction text and non-terminating fragments ?) A reverse-flow message does not (of itself) need to be identified as such, since both parties know which of them initiated the connection and which of them sent the message, so they can work it out for themselves. If it expects a reply, it will need a requestID to identify the reply (unless only one such message can be outstanding in that direction). If it in some way references one flow direction, but is not part of that direction (some sort of extension of CloseConnection perhaps), then it might need to say which direction it is affecting, but that would be particular to that message (and a bit (or two) in the fields of that message. Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Date: Wed, 22 Sep 1999 16:14:19 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul H Kyzivat CC: Jishnu Mukerji , terutt@lucent.com, Bill Janssen , butek@us.ibm.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E8C849.304D5D31@roguewave.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `Qb!!a89e9_\e!!4=*!! Paul, I am certainly not advocating a poorer choice in the hope that this will create pressure for it to be revisited. The choice is between a "fix" and a restriction. The problem that gave rise to this issue was caused by adding two new features whose design was in conflict. The restriction (a) says that these two features may be used separately, but not together. To my mind, this is the least we can do to restore the integrity of our specifications from their current broken state. The alternative (b) is to make a further addition to the protocol (by overloading one particular bit of the request ID field) with the intention of making these mutually incompatible features compatible. The consensus seems to be that this is not the best design for achieving this, and it is being considered only because it happens to fall within the scope of the urgent clarification process. So, either (a) we contain the damage already done as best we can, and then put in place a well-architected solution in the next rev, or (b) we put in a badly architected solution right now. Once there is a badly architected solution in place, it will be very difficult to subsequently add a well-architected solution that more or less duplicates the badly-architected solution. This is partly because of inertia effects (and one should never underestimate this factor) and partly because the overlap of functionality between the two solutions adds complexity and therefore mitigates against the other benefits of the new design, making it less attractive. Simon Paul H Kyzivat wrote: > > Simon Nash wrote: > > > > Jishnu, > > Hacks always look good to the people doing them, because they fix > the > > immediate problem. We have all done them in dark corners of our > code > > when under pressure. But do we want to expose this hack to the > world > > as part of the GIOP specification? I say not, even if this > creates > > slightly more implementation cost. > > But the choice isn't between hack and no hack. It is between hack > (a) > and hack (b). > > I (a) to be much more of a hack than (b) in addition to being harder > to > implement and less efficient. > > I agree with Jishnu that you seem to be advocating (a) *because* it > is > the poorer choice, increasing the chances that it will be revisited. > > It will be (technically) equally hard to implement a purer technique > in > giop 1.3, regardless of whether (a) or (b) is adopted now. But if we > adopt (a) we make things worse between now and then. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Message-ID: <37E8F9C6.EA281796@fpk.hp.com> Date: Wed, 22 Sep 1999 11:46:14 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: butek@us.ibm.com CC: Peter Furniss , "interop@omg.org" , "firewall-rtf@omg.org" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F4.00489ED6.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $mSd9=0@e9P39e9~h_d9 butek@us.ibm.com wrote: [ ... snip, snip ... ] > And what about future messages? > Put requestID on new messages JUST to indicate reverse-flow? Well, seems like there *is* a good reason to do the more complete fix in 1.3 afterall, notwithstanding which hack we put in place now, as I always suspected.:-) Afterall, it is very unlikely that any new messages will materialize before we get to 1.3. It was Simon and Paul who said that there would be no reason to revisit this once the odd/even hack was in place. And it was I who was suggesting that the more complete fix needs to stand on its own two feet irrespective of what hack is used to band-aid the current problem. Thank you for bolstering my argument by providing the feet on which the more complete fix would stand. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: andrew@emerald.omg.org Message-Id: In-Reply-To: <37E8F24B.86767E01@hursley.ibm.com> References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E8C849.304D5D31@roguewave.com> Mime-Version: 1.0 Date: Wed, 22 Sep 1999 11:51:05 -0400 To: interop@omg.org, firewall-rtf@omg.org From: Andrew Watson Subject: Re: Once more, with feeling: Issue 2863 classified as urgent Content-Type: text/plain; charset="us-ascii" X-UIDL: oE1!!]F)e9DpG!!DF Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Furniss CC: "'butek@us.ibm.com'" , "interop@omg.org" , "firewall-rtf@omg.org" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <01BF050E.57BDC9C0@B249.ds.ulcc.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,4pd9QA\!!DJEe9WT-e9 Peter, Peter Furniss wrote: > > Russell Butek sent : > > > You said, "The problem is NOT just fragments and bi-dir - that is > just the > > symptom, not the disease. The disease is that RequestID is not > > correctly performing it role as a label." > > > > RequestID WAS correctly performing its role as a label BEFORE > bi-dir GIOP. So > > it is bi-dir GIOP that caused the problem, not requestID. > > There is an analogous problem with proposals to send GIOP on > connectionless transports - the request id loses it's unambiguity. A > label that was unambiguous in a limited scope will often become > ambiguous if used in a wider scope. It is then a question of whether > you disambiguate externally to the label (by prefix::, identifying > the message it in as reverse flow) or internally (by restricting the > namespace it uses). > > Although the general solution is usually to do this externally (I > don't want to be told my C++ member variables must all start with > m), in this case there seems no reason not to restrict the number > space used by these integers. Or is the requestid already being > overloaded with meanings ? > Actually, I draw the opposite conclusion from your example. If we > disambiguate externally, this approach generalizes to other conflict situations > such as GIOP over connectionless transports. If we "steal a bit" to disambiguate > internally, this approach does not scale and we will very likely end up with a > messy mixture of internal disambiguation and external disambiguation. Better to keep the request ID semantics as they are today (an arbitrary ID assigned by the sender that is unambiguous within a well-defined scope), and find an architecturally correct place to add the various kinds of disambiguation to identify different scopes. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 22 Sep 1999 21:12:37 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Furniss CC: "'Tom Rutt'" , "interop@omg.org" , "firewall-rtf@omg.org" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <01BF0419.8F3B87C0@B210.ds.ulcc.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F:Od9b9&e9"kPe9FTC!! Peter, Peter Furniss wrote: > > Doesn't the restriction text need to cover the case where a Cancel > is sent ? The restriction text (and the current solution to the > problem) assumes that all fragment sequences end with a terminating > fragment. > > The requestor is not expected to send more fragments after sending a > Cancel (the text actually says the server should not expect to > receive any, but presumably that is equivalent), so there will never > be a terminating fragment. With the proposed text, that would > disallow fragmenting replies (from requests in the opposite > direction) for ever. > Good point. This emans that the wording of the second part of the > restriction must be amended. I suggest: - a fragmented reply or a fragmented locateReply message may not be sent by an endpoint if either a request or locateRequest message has been sent by that endpoint without a terminating fragment or a cancelRequest. > There seems to no specification of what happens if a Cancel is received while a fragmented reply is being returned. If the Cancel arrives late, it can cross with the complete reply (or be ignored altogether), so there can be no requirement that the reply be stopped. But is the replier at liberty to stop sending, and leave the fragment sequence hanging ? > If the replier is at liberty to stop sending, then it would be impossible for the replier to ever send fragmented requests again since they could be mistaken for further fragments of the uncompleted reply. Therefore, the endpoint must complete the fragmented reply before it can send any more fragmented requests. This means that Tom's proposed words for this part are correct: - a fragmented request or a fragmented locateRequest message may not be sent by an endpoint if either a reply or locateReply message has been sent by that endpoint without a terminating fragment. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 22 Sep 1999 21:33:46 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: interop@omg.org, firewall-rtf@omg.org, Andrew Watson Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E8C849.304D5D31@roguewave.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2!Qe9=(R!!Yg>!!(e(e9 Tom, Here's my suggested wording for the "restriction" option: Add the following paragraph to 15.8: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a fragmented request or a fragmented locateRequest message may not be sent by an endpoint if either a reply or locateReply message has been sent by that endpoint without a terminating fragment. - a fragmented reply or a fragmented locateReply message may not be sent by an endpoint if either a request or locateRequest message has been sent by that endpoint without a terminating fragment or cancelRequest." Simon Andrew Watson wrote: > > Hi, > > I'm happy to see all the discussion on this thread, but could I > suggest > that people start to back up their posted opinions with suggested > wordings > for the amendment? We got into a mess last time because the > word-crafting > was left until too late. Please let's not fall into that trap again. > > Cheers, > > Andrew -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Message-ID: <37E95543.24188813@fpk.hp.com> Date: Wed, 22 Sep 1999 18:16:35 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash CC: terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org, Andrew Watson Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E8C849.304D5D31@roguewave.com> <37E93D2A.78175DF9@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @a8e9!P'e9C9Vd907""! Simon Nash wrote: > > Tom, > Here's my suggested wording for the "restriction" option: > > Add the following paragraph to 15.8: > > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a fragmented request or a fragmented locateRequest > message may not be sent by an endpoint if either a > reply or locateReply message has been sent by that > endpoint without a terminating fragment. > > - a fragmented reply or a fragmented locateReply > message may not be sent by an endpoint if either > a request or locateRequest message has been sent by that > endpoint without a terminating fragment or cancelRequest." Now I am confused. the original proposed simple resolution was: > "To avoid collisions of requestId in fragment messages > when bi-directional GIOP is in use: > > - a fragmented request may not be sent by an endpoint > if a fragemented reply has been sent by that endpoint > without a terminating fragment. > > - a fragemented reply may not be sent by an endpoint if > a fragmented request has been sent by that endpoint without > a terminating fragment." > Tom modified it to say: > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a fragmented request or a fragmented locateRequest message > may not be sent by an endpoint if either a reply or > locateReply message has been sent by that endpoint without > a terminating fragment. > > - a fragmented reply or a fragmented locateReply message > may not be sent by an endpoint if either a request or > locateRequest message has been sent by that > endpointwithout a terminating fragment." Notice that the word *fragmented* has been silently dropped from the phrase following the "if". Is it because it is assumed that a non-fragmented message could not possibly have a terminating fragment and therefore the phrase following the "if" certainly refers to a fragmented message? The more complete and unambiguous wording, taken from Simon's wording would be: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a fragmented request or a fragmented locateRequest message may not be sent by an endpoint if either a *fragmented* reply or *a fragmented* locateReply message has been sent by that endpoint without a terminating fragment. - a fragmented reply or a fragmented locateReply message may not be sent by an endpoint if either a *fragmented* request or *a fragmented* locateRequest message has been sent by that endpoint without a terminating fragment or cancelRequest." Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Cc: Peter Furniss , "interop@omg.org" , "firewall-rtf@omg.org" Message-ID: <37E96C4D.91E702BC@lucent.com> Date: Wed, 22 Sep 1999 19:54:53 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com Original-CC: Peter Furniss , "interop@omg.org" , "firewall-rtf@omg.org" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F4.00489ED6.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d2md9YWod9,d$e9D)>e9 butek@us.ibm.com wrote: > > Let's just say we need a new bit on the reverse-flow messages to indicate that > they are reverse flow. That's effectively all that the odd/even requestID is, > the bit is on the requestID within the message rather than on the message > itself. But since requestID's are not on all messages, that doesn't seem the > appropriate place to put the reverse flow indicator. For instance, how does an > ORB which is handling reverse and normal flows on the same connection deal with > a MessageError? WHICH message was in error? And what about future messages? > Put requestID on new messages JUST to indicate reverse-flow? > > Russell Butek > butek@us.ibm.com > You keep trying to get reverse flow into the corba 1.2 spec. This is not is scope of an urgent issue resolution on a spec which is published formally, and which is referenced in several published international standards etc. Assume that we must wait for giop 1.3 do change the message syntax. Given that, what do you want for THIS urgent resolution? -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Thu, 23 Sep 1999 10:31:11 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org, Andrew Watson Subject: Re: Once more, with feeling: Issue 2863 classified as urgent References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E8C849.304D5D31@roguewave.com> <37E93D2A.78175DF9@hursley.ibm.com> <37E95543.24188813@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /YE!!?O#"!S,W!!0'O!! Jishnu. I based my wording on what Tom sent out. However, I agree that your change makes the intent of this clearer and I support your wording as the text that should be used for voting on the "restriction" option. Simon Jishnu Mukerji wrote: > > Simon Nash wrote: > > > > Tom, > > Here's my suggested wording for the "restriction" option: > > > > Add the following paragraph to 15.8: > > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > > - a fragmented request or a fragmented locateRequest > > message may not be sent by an endpoint if either a > > reply or locateReply message has been sent by that > > endpoint without a terminating fragment. > > > > - a fragmented reply or a fragmented locateReply > > message may not be sent by an endpoint if either > > a request or locateRequest message has been sent by that > > endpoint without a terminating fragment or cancelRequest." > > Now I am confused. the original proposed simple resolution was: > > > "To avoid collisions of requestId in fragment messages > > when bi-directional GIOP is in use: > > > > - a fragmented request may not be sent by an endpoint > > if a fragemented reply has been sent by that endpoint > > without a terminating fragment. > > > > - a fragemented reply may not be sent by an endpoint if > > a fragmented request has been sent by that endpoint without > > a terminating fragment." > > > > Tom modified it to say: > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > > - a fragmented request or a fragmented locateRequest message > > may not be sent by an endpoint if either a reply or > > locateReply message has been sent by that endpoint without > > a terminating fragment. > > > > - a fragmented reply or a fragmented locateReply message > > may not be sent by an endpoint if either a request or > > locateRequest message has been sent by that > > endpointwithout a terminating fragment." > > Notice that the word *fragmented* has been silently dropped from the > phrase > following the "if". Is it because it is assumed that a > non-fragmented message > could not possibly have a terminating fragment and therefore the > phrase > following the "if" certainly refers to a fragmented message? > > The more complete and unambiguous wording, taken from Simon's > wording would be: > > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a fragmented request or a fragmented locateRequest > message may not be sent by an endpoint if either a > *fragmented* reply or *a fragmented* locateReply message > has been sent by that endpoint without a terminating fragment. > > - a fragmented reply or a fragmented locateReply > message may not be sent by an endpoint if either > a *fragmented* request or *a fragmented* locateRequest > message has been sent by that endpoint without a > terminating fragment or cancelRequest." > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <37EA1830.D2E347F6@lucent.com> Date: Thu, 23 Sep 1999 08:08:16 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =(;e9M!e!!_4k!!_ND!! Tom Rutt wrote: > > IONA provided the following proposal, which added clarification > as to the GIOP version 1.2 applicability to the latest proposal > from Jishnu. > > Voting members of the interop rtf (names in the send to list > in this mail header) need to cast their vote on proposed resolution > a) versus proposed resolution b). > > The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. > I vote for proposed resolution b) odd/even Request Id From: Peter Furniss To: "'Peter Furniss'" , "'Simon Nash'" Cc: "'Tom Rutt'" , "'interop@omg.org'" , "'firewall-rtf@omg.org'" Subject: RE: Once more, with feeling: Issue 2863 classified as urgent Date: Thu, 23 Sep 1999 12:33:36 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id HAA10763 Content-Type: text/plain; charset="us-ascii" X-UIDL: HMY!!FPSd9fL@e9cpi!! Simon Nash sent : > > There seems to no specification of what happens if a Cancel is received while a fragmented reply is being returned. If the Cancel arrives late, it can cross with the complete reply (or be ignored altogether), so there can be no requirement that the reply be stopped. But is the replier at liberty to stop sending, and leave the fragment sequence hanging ? > > > If the replier is at liberty to stop sending, then it would be impossible for > the replier to ever send fragmented requests again since they could be mistaken > for further fragments of the uncompleted reply. It would with 1.1, but not with 1.2, where the fragments carry the RequestId. With 1.2 the problem only arises with the ambiguous bi-dir RequestIds. > Therefore, the endpoint must > complete the fragmented reply before it can send any more fragmented > requests. But can it stop short, sending (say) an empty last fragment (resulting in the receipt of a bad reply at higher level, but presuming the client will ignore it). But this is to do with Cancel:fragmentation interactions and not the present issue. > This means that Tom's proposed words for this part are correct: I agree (with the addition of the "fragmented" as Jishnu suggested. But the odd/even solution would seem a lot easier to state correctly and safely, and I can't believe it isn't trivial to implement (unless some ORBs are already overloading the id with local semantics ?). Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: terutt@lucent.com cc: "interop@omg.org" , "firewall-rtf@omg.org" Message-ID: <852567F5.0046D4EE.00@d54mta08.raleigh.ibm.com> Date: Thu, 23 Sep 1999 07:52:37 -0500 Subject: Re: Once more, with feeling: Issue 2863 classified as urgent Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 41Wd9~dVd93'\d9(`#!! You misunderstand me. I am simply pointing out what is wrong with odd/even. Odd/even is nothing more than the reverse flow bit put in the wrong place. Which means, of course, that I will not vote for the odd/even approach. Russell Butek butek@us.ibm.com Tom Rutt on 09/22/99 06:54:53 PM Please respond to terutt@lucent.com To: Russell Butek/Austin/IBM@IBMUS cc: Peter Furniss , "interop@omg.org" , "firewall-rtf@omg.org" Subject: Re: Once more, with feeling: Issue 2863 classified as urgent butek@us.ibm.com wrote: > > Let's just say we need a new bit on the reverse-flow messages to indicate that > they are reverse flow. That's effectively all that the odd/even requestID is, > the bit is on the requestID within the message rather than on the message > itself. But since requestID's are not on all messages, that doesn't seem the > appropriate place to put the reverse flow indicator. For instance, how does an > ORB which is handling reverse and normal flows on the same connection deal with > a MessageError? WHICH message was in error? And what about future messages? > Put requestID on new messages JUST to indicate reverse-flow? > > Russell Butek > butek@us.ibm.com > You keep trying to get reverse flow into the corba 1.2 spec. This is not is scope of an urgent issue resolution on a spec which is published formally, and which is referenced in several published international standards etc. Assume that we must wait for giop 1.3 do change the message syntax. Given that, what do you want for THIS urgent resolution? -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <37EA1753.4BE67201@lucent.com> Date: Thu, 23 Sep 1999 08:04:35 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _2*e9I0i!!R5)!!YcEe9 IONA provided the following proposal, which added clarification as to the GIOP version 1.2 applicability to the latest proposal from Jishnu. Voting members of the interop rtf (names in the send to list in this mail header) need to cast their vote on proposed resolution a) versus proposed resolution b). The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. -------------------------- Proposed Resolutions for Vote --------------------------------------------------------------------- a) Refined Restriction Add the following to the subclause on BiDirectional Giop To avoid collisions of request IDs in GIOP 1.2 fragment messages when bi-directional GIOP is in use: - A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 LocateRequest message may not be sent by an endpoint if either a fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been sent by that endpoint without a terminating fragment. - A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply message may not be sent by an endpoint if either a fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has been sent by that endpoint without a terminating fragment or CancelRequest message. ------------------------- b) Odd/Even Request Id on Bidirectional Giop Connection In section 15.8 (Bi-Directional GIOP), replace the para. that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: " Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". This property of unambiguous association of requests and replies must be preserved while permitting each end to generate Request Ids for new requests independently. To ensure this, on a connection that is used bi-directionally in GIOP 1.2, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted. A connection on which this regime of Request ID assignment is not used, shall never be used to transmit bi-directional GIOP 1.2 messages. " Date: Thu, 23 Sep 1999 09:32:35 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %;8e9(WIe9'F2!!"?4!! IONA votes for resolution b) (odd/even). -Bob Tom Rutt wrote: > > IONA provided the following proposal, which added clarification > as to the GIOP version 1.2 applicability to the latest proposal > from Jishnu. > > Voting members of the interop rtf (names in the send to list > in this mail header) need to cast their vote on proposed resolution > a) versus proposed resolution b). > > The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. > > -------------------------- > Proposed Resolutions for Vote > > > --------------------------------------------------------------------- > a) Refined Restriction > > Add the following to the subclause on BiDirectional Giop > > To avoid collisions of request IDs in GIOP 1.2 fragment messages > when > bi-directional GIOP is in use: > > - A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 > LocateRequest > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been > sent > by that endpoint without a terminating fragment. > > - A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has > been > sent by that endpoint without a terminating fragment or > CancelRequest message. > > ------------------------- > b) Odd/Even Request Id on Bidirectional Giop Connection > > In section 15.8 (Bi-Directional GIOP), replace the para. that begins > with > > "Bi-directional GIOP connections modify the behavior of Request IDs" > > with the following new paragraph: > " > Bi-directional GIOP connections modify the behavior of Request > IDs. In > the GIOP specification, "Connection Management" on page 15-44, it is > noted that "Request IDs must unambiguously associate replies with > requests within the scope and lifetime of a connection". This > property > of unambiguous association of requests and replies must be preserved > while permitting each end to generate Request Ids for new requests > independently. To ensure this, on a connection that is used > bi-directionally in GIOP 1.2, the connection originator shall assign > only even valued Request IDs and the other side of the connection > shall assign only odd valued Request IDs. This requirement applies > to > the full lifetime of the connection, even before a > BiDirIIOPServiceContext is transmitted. A connection on which this > regime of Request ID assignment is not used, shall never be used to > transmit bi-directional GIOP 1.2 messages. > " Date: Thu, 23 Sep 1999 10:22:14 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Jishnu Mukerji CC: Simon Nash , terutt@lucent.com, > interop@omg.org, firewall-rtf@omg.org, Andrew Watson Subject: Re: Once more, with feeling: Issue 2863 classified as urgent X-Priority: 3 (Normal) References: <852567F2.00663747.00@d54mta08.raleigh.ibm.com> <0rteWasB0KGW83R9ER@holmes.parc.xerox.com> <37E6FEB9.CE63CBE9@lucent.com> <37E73F49.6E45D1A0@hursley.ibm.com> <37E79B49.81B30E58@fpk.hp.com> <37E7E2D4.E52F3675@hursley.ibm.com> <37E7E80C.FC268304@fpk.hp.com> <37E7EA1C.58093B30@hursley.ibm.com> <37E8C849.304D5D31@roguewave.com> <37E93D2A.78175DF9@hursley.ibm.com> <37E95543.24188813@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 8e0e9If&e9eim!!~Iod9 This shows one of the problems with this approach: it cannot be described simply in a way that knowledgeable people can understand. Each iteration of wording has been thought to be an improvement, but the process does not seem to converge. My level of confidence that this wording is sufficient is about the same as was my level of confidence in the first iteration of it. Nobody is arguing about the wording of the even/odd approach because it is dead simple. I rest my case. Paul Jishnu Mukerji wrote: > > Simon Nash wrote: > > > > Tom, > > Here's my suggested wording for the "restriction" option: > > > > Add the following paragraph to 15.8: > > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > > - a fragmented request or a fragmented locateRequest > > message may not be sent by an endpoint if either a > > reply or locateReply message has been sent by that > > endpoint without a terminating fragment. > > > > - a fragmented reply or a fragmented locateReply > > message may not be sent by an endpoint if either > > a request or locateRequest message has been sent by that > > endpoint without a terminating fragment or cancelRequest." > > Now I am confused. the original proposed simple resolution was: > > > "To avoid collisions of requestId in fragment messages > > when bi-directional GIOP is in use: > > > > - a fragmented request may not be sent by an endpoint > > if a fragemented reply has been sent by that endpoint > > without a terminating fragment. > > > > - a fragemented reply may not be sent by an endpoint if > > a fragmented request has been sent by that endpoint without > > a terminating fragment." > > > > Tom modified it to say: > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > > - a fragmented request or a fragmented locateRequest message > > may not be sent by an endpoint if either a reply or > > locateReply message has been sent by that endpoint without > > a terminating fragment. > > > > - a fragmented reply or a fragmented locateReply message > > may not be sent by an endpoint if either a request or > > locateRequest message has been sent by that > > endpointwithout a terminating fragment." > > Notice that the word *fragmented* has been silently dropped from the > phrase > following the "if". Is it because it is assumed that a > non-fragmented > message > could not possibly have a terminating fragment and therefore the > phrase > following the "if" certainly refers to a fragmented message? > > The more complete and unambiguous wording, taken from Simon's > wording > would be: > > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a fragmented request or a fragmented locateRequest > message may not be sent by an endpoint if either a > *fragmented* reply or *a fragmented* locateReply message > has been sent by that endpoint without a terminating fragment. > > - a fragmented reply or a fragmented locateReply > message may not be sent by an endpoint if either > a *fragmented* request or *a fragmented* locateRequest > message has been sent by that endpoint without a > terminating fragment or cancelRequest." > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: terutt@lucent.com cc: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <852567F5.004C3AF2.00@d54mta08.raleigh.ibm.com> Date: Thu, 23 Sep 1999 08:51:27 -0500 Subject: Re: VOTE 1 For Urgent Issue 2863 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: A'o!!b^B!!dYJ!!Qchd9 IBM votes for a) Refined Restriction. Russell Butek butek@us.ibm.com Tom Rutt on 09/23/99 07:04:35 AM Please respond to terutt@lucent.com To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, Russell Butek/Austin/IBM@IBMUS, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org cc: Subject: VOTE 1 For Urgent Issue 2863 IONA provided the following proposal, which added clarification as to the GIOP version 1.2 applicability to the latest proposal from Jishnu. Voting members of the interop rtf (names in the send to list in this mail header) need to cast their vote on proposed resolution a) versus proposed resolution b). The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. -------------------------- Proposed Resolutions for Vote --------------------------------------------------------------------- a) Refined Restriction Add the following to the subclause on BiDirectional Giop To avoid collisions of request IDs in GIOP 1.2 fragment messages when bi-directional GIOP is in use: - A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 LocateRequest message may not be sent by an endpoint if either a fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been sent by that endpoint without a terminating fragment. - A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply message may not be sent by an endpoint if either a fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has been sent by that endpoint without a terminating fragment or CancelRequest message. ------------------------- b) Odd/Even Request Id on Bidirectional Giop Connection In section 15.8 (Bi-Directional GIOP), replace the para. that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: " Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". This property of unambiguous association of requests and replies must be preserved while permitting each end to generate Request Ids for new requests independently. To ensure this, on a connection that is used bi-directionally in GIOP 1.2, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted. A connection on which this regime of Request ID assignment is not used, shall never be used to transmit bi-directional GIOP 1.2 messages. " Date: Thu, 23 Sep 1999 10:31:38 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: terutt@lucent.com CC: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 X-Priority: 3 (Normal) References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: oK-e9:aO!!_LXd9 Message-ID: <37EA4A15.F4F5F191@inprise.com> Date: Thu, 23 Sep 1999 08:41:09 -0700 From: Jeff Mischkinsky Organization: INPRISE Corporation X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _f > IONA provided the following proposal, which added clarification > as to the GIOP version 1.2 applicability to the latest proposal > from Jishnu. > > Voting members of the interop rtf (names in the send to list > in this mail header) need to cast their vote on proposed resolution > a) versus proposed resolution b). > > The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. > > -------------------------- > Proposed Resolutions for Vote > > > --------------------------------------------------------------------- > a) Refined Restriction > > Add the following to the subclause on BiDirectional Giop > > To avoid collisions of request IDs in GIOP 1.2 fragment messages > when > bi-directional GIOP is in use: > > - A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 > LocateRequest > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been > sent > by that endpoint without a terminating fragment. > > - A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has > been > sent by that endpoint without a terminating fragment or > CancelRequest message. > > ------------------------- > b) Odd/Even Request Id on Bidirectional Giop Connection > > In section 15.8 (Bi-Directional GIOP), replace the para. that begins > with > > "Bi-directional GIOP connections modify the behavior of Request IDs" > > with the following new paragraph: > " > Bi-directional GIOP connections modify the behavior of Request > IDs. In > the GIOP specification, "Connection Management" on page 15-44, it is > noted that "Request IDs must unambiguously associate replies with > requests within the scope and lifetime of a connection". This > property > of unambiguous association of requests and replies must be preserved > while permitting each end to generate Request Ids for new requests > independently. To ensure this, on a connection that is used > bi-directionally in GIOP 1.2, the connection originator shall assign > only even valued Request IDs and the other side of the connection > shall assign only odd valued Request IDs. This requirement applies > to > the full lifetime of the connection, even before a > BiDirIIOPServiceContext is transmitted. A connection on which this > regime of Request ID assignment is not used, shall never be used to > transmit bi-directional GIOP 1.2 messages. > " -- Jeff Mischkinsky email: jeffm@inprise.com Senior Software Architect INPRISE Corporation voice: +1(650)358-3049 951 Mariner's Island Blvd. Suite 460 fax: +1(650)358-3095 San Mateo, CA 94404 web: http://www.inprise.com Date: Thu, 23 Sep 1999 15:58:49 +0100 From: "Dave Stringer" Organization: Nortel Networks X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: terutt@lucent.com CC: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, "Dave Stringer" , bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [')!!-l6!!#p a) Refined Restriction > > Add the following to the subclause on BiDirectional Giop > > To avoid collisions of request IDs in GIOP 1.2 fragment messages > when > bi-directional GIOP is in use: > > - A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 > LocateRequest > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been > sent > by that endpoint without a terminating fragment. > > - A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has > been > sent by that endpoint without a terminating fragment or > CancelRequest message. > > ------------------------- Date: Thu, 23 Sep 1999 10:23:53 PDT Sender: Bill Janssen From: Bill Janssen To: Jishnu Mukerji , Bill Janssen > , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org, terutt@lucent.com Subject: Re: VOTE 1 For Urgent Issue 2863 In-Reply-To: <37EA1753.4BE67201@lucent.com> References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Type: text X-UIDL: 7d?e9~'Ge9V>Ie9C(Fe9 Xerox votes for (a). Bill Sender: jis@fpk.hp.com Message-ID: <37EA5C5E.485125AF@fpk.hp.com> Date: Thu, 23 Sep 1999 12:59:10 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: terutt@lucent.com CC: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3Zkd97D;!!JJ7e9eUDe9 > IONA provided the following proposal, which added clarification > as to the GIOP version 1.2 applicability to the latest proposal > from Jishnu. > > Voting members of the interop rtf (names in the send to list > in this mail header) need to cast their vote on proposed resolution > a) versus proposed resolution b). > > The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. Hewlett-Packard votes for (b) odd/even. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Thu, 23 Sep 1999 15:33:07 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: VOTE 1 For Urgent Issue 2863 To: jis@fpk.hp.com, janssen@parc.xerox.com, stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, sugino@rp.open.cs.fujitsu.co.jp, terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Cc: rip-dev@eng.sun.com MIME-Version: 1.0 Content-MD5: 7RNjRCZ1iWTmQ23lEvEmcw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: H]6!!If$!!M%&e9b Date: Thu, 23 Sep 1999 16:11:46 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com CC: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: /g4!!N"od9ka8!!Ge-e9 [I was going to hold off for a while on my vote and see if I couldn't get to be kingmaker on this issue, but it appears that my delusions of power-mongering didn't pan out. :-) However, that won't stop me from making a speech. :-)] I have a lot of sympathy for the people arguing for architectural purity and solution a), but the more I thought about it the more I agreed that it was a headache to implement. The problem is that previously there was no need for interaction between the send and receive side of the protocol with respect to flow control. Proposal a) adds a need for that interaction. Proposal b), however, is stunningly simple to implement. So, my vote, somewhat reluctantly, is for b). -- Jonathan Biggar Floorboard Software jon@floorboard.com jon@biggar.org Tom Rutt wrote: > > IONA provided the following proposal, which added clarification > as to the GIOP version 1.2 applicability to the latest proposal > from Jishnu. > > Voting members of the interop rtf (names in the send to list > in this mail header) need to cast their vote on proposed resolution > a) versus proposed resolution b). > > The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. > > -------------------------- > Proposed Resolutions for Vote > > > --------------------------------------------------------------------- > a) Refined Restriction > > Add the following to the subclause on BiDirectional Giop > > To avoid collisions of request IDs in GIOP 1.2 fragment messages > when > bi-directional GIOP is in use: > > - A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 > LocateRequest > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been > sent > by that endpoint without a terminating fragment. > > - A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has > been > sent by that endpoint without a terminating fragment or > CancelRequest message. > > ------------------------- > b) Odd/Even Request Id on Bidirectional Giop Connection > > In section 15.8 (Bi-Directional GIOP), replace the para. that begins > with > > "Bi-directional GIOP connections modify the behavior of Request IDs" > > with the following new paragraph: > " > Bi-directional GIOP connections modify the behavior of Request > IDs. In > the GIOP specification, "Connection Management" on page 15-44, it is > noted that "Request IDs must unambiguously associate replies with > requests within the scope and lifetime of a connection". This > property > of unambiguous association of requests and replies must be preserved > while permitting each end to generate Request Ids for new requests > independently. To ensure this, on a connection that is used > bi-directionally in GIOP 1.2, the connection originator shall assign > only even valued Request IDs and the other side of the connection > shall assign only odd valued Request IDs. This requirement applies > to > the full lifetime of the connection, even before a > BiDirIIOPServiceContext is transmitted. A connection on which this > regime of Request ID assignment is not used, shall never be used to > transmit bi-directional GIOP 1.2 messages. > " X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 23 Sep 1999 15:54:39 -0700 To: terutt@lucent.com, Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org From: Edward Cobb Subject: Re: VOTE 1 For Urgent Issue 2863 In-Reply-To: <37EA1753.4BE67201@lucent.com> References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ?S_d9SXn!!YaS!!$o/e9 BEA votes for option B (odd/even Request Ids). At 08:04 AM 9/23/99 -0400, Tom Rutt wrote: > >IONA provided the following proposal, which added clarification >as to the GIOP version 1.2 applicability to the latest proposal >from Jishnu. > >Voting members of the interop rtf (names in the send to list >in this mail header) need to cast their vote on proposed resolution >a) versus proposed resolution b). > >The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. > >-------------------------- >Proposed Resolutions for Vote > --------------------------------------------------------------------- >a) Refined Restriction > >Add the following to the subclause on BiDirectional Giop > >To avoid collisions of request IDs in GIOP 1.2 fragment messages when >bi-directional GIOP is in use: > >- A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 LocateRequest > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been sent > by that endpoint without a terminating fragment. > >- A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply > message may not be sent by an endpoint if either a fragmented GIOP > 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has been > sent by that endpoint without a terminating fragment or > CancelRequest message. > >------------------------- >b) Odd/Even Request Id on Bidirectional Giop Connection > >In section 15.8 (Bi-Directional GIOP), replace the para. that begins with > >"Bi-directional GIOP connections modify the behavior of Request IDs" > >with the following new paragraph: >" >Bi-directional GIOP connections modify the behavior of Request IDs. In >the GIOP specification, "Connection Management" on page 15-44, it is >noted that "Request IDs must unambiguously associate replies with >requests within the scope and lifetime of a connection". This property >of unambiguous association of requests and replies must be preserved >while permitting each end to generate Request Ids for new requests >independently. To ensure this, on a connection that is used >bi-directionally in GIOP 1.2, the connection originator shall assign >only even valued Request IDs and the other side of the connection >shall assign only odd valued Request IDs. This requirement applies to >the full lifetime of the connection, even before a >BiDirIIOPServiceContext is transmitted. A connection on which this >regime of Request ID assignment is not used, shall never be used to >transmit bi-directional GIOP 1.2 messages. >" > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Fri, 24 Sep 1999 08:22:14 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Tom Rutt cc: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 In-Reply-To: <37EA1753.4BE67201@lucent.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )!Ud918=!!"Kk!!OJ0e9 On Thu, 23 Sep 1999, Tom Rutt wrote: > The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. OOC votes for b (odd/even). Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <37F0DF85.195C3E5E@lucent.com> Date: Tue, 28 Sep 1999 11:32:21 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Results of VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37EA1753.4BE67201@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d[Ke9a_*e93(B!!-I1e9 Voting members of the interop rtf (names in the send to list in this mail header) have cast their vote on proposed resolution a) versus proposed resolution b). The vote closed 8:00 PM Eastern Time on Monday September 27, 1999. Proposed Resolution b) odd/even has been selected with healthy majority. Proposed Resolution a) had three votes in favor (IBM, Nortel, Xerox) Proposed Resolution b) had ten votes (Lucent, Iona, Roque Wave, Inprise, HP, OOC, SUN, BEA, Floorboard, Fujitsu) Three members did not register their vote ( App Test, Novell, OIS). -------------------------- Proposed Resolutions for Vote --------------------------------------------------------------------- a) Refined Restriction Add the following to the subclause on BiDirectional Giop To avoid collisions of request IDs in GIOP 1.2 fragment messages when bi-directional GIOP is in use: - A fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 LocateRequest message may not be sent by an endpoint if either a fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply message has been sent by that endpoint without a terminating fragment. - A fragmented GIOP 1.2 Reply or a fragmented GIOP 1.2 LocateReply message may not be sent by an endpoint if either a fragmented GIOP 1.2 Request or a fragmented GIOP 1.2 LocateRequest message has been sent by that endpoint without a terminating fragment or CancelRequest message. ------------------------- b) Odd/Even Request Id on Bidirectional Giop Connection In section 15.8 (Bi-Directional GIOP), replace the para. that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: " Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". This property of unambiguous association of requests and replies must be preserved while permitting each end to generate Request Ids for new requests independently. To ensure this, on a connection that is used bi-directionally in GIOP 1.2, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted. A connection on which this regime of Request ID assignment is not used, shall never be used to transmit bi-directional GIOP 1.2 messages. " -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Message-ID: <37FBBD78.D63F81AE@lucent.com> Date: Wed, 06 Oct 1999 17:22:00 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith Original-CC: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , interop@omg.org, firewall-rtf@omg.org Subject: Re: VOTE 1 For Urgent Issue 2863 References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <4.2.0.58.19991006152225.00b20230@gamma> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: RZZd9JFfd9Fkmd9!5B!! Well, you have one strike against you. You did vote on the last vote, so if you miss the next vote (not anticipated to be soon, but you never know with these urgent resolutions) you will loose voting rights. By the way, AppTest has missed Two votes in a row, so they have lost their voting rights by the rules. Novell has missed the last vote, so Bill Cox is in the same status as Bill Beckwith (i.e., they both still have voting rights, but cannot skip the next vote without loosing their voting rights). Bill Beckwith wrote: > > At 08:04 AM 9/23/99 , Tom Rutt wrote: > > >Voting members of the interop rtf (names in the send to list > >in this mail header) need to cast their vote on proposed > resolution > >a) versus proposed resolution b). > > > >The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. > > Sorry I missed this vote. I just got back in town. I did not have > good email access while I was out. > > -- Bill -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA X-Sender: beckwb@gamma X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 06 Oct 1999 15:23:14 -0400 To: terutt@lucent.com From: Bill Beckwith Subject: Re: VOTE 1 For Urgent Issue 2863 Cc: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, paulk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org In-Reply-To: <37EA1753.4BE67201@lucent.com> References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: #"/e9V9""!djHe9?c~e9 At 08:04 AM 9/23/99 , Tom Rutt wrote: >Voting members of the interop rtf (names in the send to list >in this mail header) need to cast their vote on proposed resolution >a) versus proposed resolution b). > >The vote closes 8:00 PM Eastern Time on Monday September 27, 1999. Sorry I missed this vote. I just got back in town. I did not have good email access while I was out. -- Bill Date: Wed, 22 Sep 1999 18:25:34 PDT Sender: Bill Janssen From: Bill Janssen To: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org, terutt@lucent.com Subject: Different GIOP versions on a single TCP connection In-Reply-To: <37E8CEF3.F9A7F0A3@lucent.com> References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> Content-Type: text X-UIDL: @<8!!~R!e9CbOd9K4,!! Excerpts from local.omg: 22-Sep-99 Re: Urgent Issue 2863 final.. Tom Rutt@lucent.com (1175*) > I also will use this email to report on the output of the informal > "pow-wow" of Myself, Michi, Jon Biggar, and Bill Janssen regarding > the multiple Giop versions on a connection issue. In short, we > all came to the conclusion that it must be allowed to send multiple > GIOP versions on the same connection, because there is no exception > which allows an orb to indicate to the other orb that it does not > want multiple versions on the connection. All the orb can do is > abort the connection without giving the other orb the reason for > the abort. Probably my memory, but I don't remember it this way, Tom. First off, the bit about no suitable exception is not relevant. Leaving that aside, I am still of the opinion that (1) GIOP prescribes a connection-oriented protocol semantics, and (2) for IIOP, that semantics is established by the GIOP level of the first message sent from client to server. All subsequent messages sent on that connection should be required to use the same level of GIOP. It is going to be indescribably messy trying to sort out connection state issues if we allow all three flavors of GIOP on a single connection. You're right in saying that if an ORB detects a client attempting to mix GIOP levels in mid-connection, all it can do is abort the connection, because we've never bothered to give GIOP a coherent error-signalling mechanism. Another possible avenue of attack would be to remove the connection-oriented flavor of GIOP, so that each request is independent of any other request. This would mean playing some tricks in assigning request IDs... Bill Sender: jon@floorboard.com Message-ID: <37E98A0A.C4D127A5@floorboard.com> Date: Wed, 22 Sep 1999 19:01:46 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Different GIOP versions on a single TCP connection References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: eThd9;@Sd9ApOe9FSIe9 Bill Janssen wrote: > > I also will use this email to report on the output of the informal > > "pow-wow" of Myself, Michi, Jon Biggar, and Bill Janssen regarding > > the multiple Giop versions on a connection issue. In short, we > > all came to the conclusion that it must be allowed to send > multiple > > GIOP versions on the same connection, because there is no > exception > > which allows an orb to indicate to the other orb that it does not > > want multiple versions on the connection. All the orb can do is > > abort the connection without giving the other orb the reason for > > the abort. > > Probably my memory, but I don't remember it this way, Tom. First > off, > the bit about no suitable exception is not relevant. Leaving that > aside, I am still of the opinion that (1) GIOP prescribes a > connection-oriented protocol semantics, and (2) for IIOP, that > semantics > is established by the GIOP level of the first message sent from > client > to server. All subsequent messages sent on that connection should > be > required to use the same level of GIOP. It is going to be > indescribably > messy trying to sort out connection state issues if we allow all > three > flavors of GIOP on a single connection. You're right in saying that > if > an ORB detects a client attempting to mix GIOP levels in > mid-connection, > all it can do is abort the connection, because we've never bothered > to > give GIOP a coherent error-signalling mechanism. Bill, I recollect that your position was considered the minority one. :-) I believe that the general consensus among those attending was that: a) since the GIOP specification didn't forbid it, and b) since there were already implementations that do it (or might do it), it was too late to forbid the behavior. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 23 Sep 1999 12:49:29 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jonathan Biggar cc: Bill Janssen , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Different GIOP versions on a single TCP connection In-Reply-To: <37E98A0A.C4D127A5@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: F($e9AWP!!?eP!!#CP!! On Wed, 22 Sep 1999, Jonathan Biggar wrote: > Bill, I recollect that your position was considered the minority one. > :-) > I believe that the general consensus among those attending was that: > > a) since the GIOP specification didn't forbid it, > > and > > b) since there were already implementations that do it (or might do it), > > it was too late to forbid the behavior. I agree. I also remember that we were discussing a number of things that simply broke. For example, with bidir IIOP, I can't see how we could prevent interleaving of versions on the same connection. After all, the server may offer IIOP 1.2 to the client, but the client may pass a 1.1 IOR to the server as a callback reference. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com Date: Thu, 23 Sep 1999 10:17:32 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Jonathan Biggar Subject: Re: Different GIOP versions on a single TCP connection CC: Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org In-Reply-To: <37E98A0A.C4D127A5@floorboard.com> References: <379FA224.7502AFDE@lucent.com> <37A73039.9C4D5DB8@lucent.com> <37A755D0.DCF9DD50@lucent.com> <37A75E41.5283D2BA@fpk.hp.com> <37A768DE.40285696@lucent.com> <37E289FA.3A5F3FB2@lucent.com> <37E293CE.71C9F7E6@lucent.com> <37E700AC.D948AA13@lucent.com> <37E8CEF3.F9A7F0A3@lucent.com> <37E98A0A.C4D127A5@floorboard.com> Content-Type: text X-UIDL: P^8!!>K/!!eeZ!!YZ`!! Excerpts from direct: 22-Sep-99 Re: Different GIOP versions.. Jonathan Biggar@floorboa (1831*) > Bill, I recollect that your position was considered the minority one. :-) Yep, just trying to get the record straight. Bill Date: Thu, 23 Sep 1999 10:18:50 PDT Sender: Bill Janssen From: Bill Janssen To: Jonathan Biggar , Michi Henning Subject: Re: Different GIOP versions on a single TCP connection CC: Bill Janssen , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paulk@roguewave.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org In-Reply-To: References: Content-Type: text X-UIDL: C"U!!3KVd9*Hpd9~*Ud9 Excerpts from direct: 22-Sep-99 Re: Different GIOP versions.. Michi Henning@ooc.com.au (986*) > For example, with bidir IIOP, I can't see how we could prevent > interleaving of versions on the same connection. After all, the > server > may offer IIOP 1.2 to the client, but the client may pass a 1.1 IOR > to the > server as a callback reference. Yes. I think the best solution to this is to consider the bi-directional case *two* different connections, logically. Bill Date: Thu, 23 Sep 1999 16:25:35 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Bill Janssen CC: Jonathan Biggar , Michi Henning , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Different GIOP versions on a single TCP connection X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,We!!h&nd9#'0!!-4)e9 Bill Janssen wrote: > > Yes. I think the best solution to this is to consider the > bi-directional case *two* different connections, logically. > Does that mean when I send a disconnect, I am only doing so in my server role, but I might wish to continue using the connection as a client? Sender: jon@floorboard.com Message-ID: <37EA9468.DBE3ECD8@floorboard.com> Date: Thu, 23 Sep 1999 13:58:16 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Paul H Kyzivat CC: Bill Janssen , Michi Henning , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Different GIOP versions on a single TCP connection References: <37EA8CBF.B9F95E0E@roguewave.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]UL!!Oj"e9U^_d9fQS!! Paul H Kyzivat wrote: > > Bill Janssen wrote: > > > > Yes. I think the best solution to this is to consider the > > bi-directional case *two* different connections, logically. > > > > Does that mean when I send a disconnect, I am only doing so > in my server role, but I might wish to continue using the connection > as > a client? Not currently, since Bill's proposal is not the accepted GIOP 1.2 behavior. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 23 Sep 1999 14:11:12 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Paul H Kyzivat Subject: Re: Different GIOP versions on a single TCP connection CC: Jonathan Biggar , Michi Henning , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, butek@us.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org In-Reply-To: <37EA8CBF.B9F95E0E@roguewave.com> References: <37EA8CBF.B9F95E0E@roguewave.com> Content-Type: text X-UIDL: FjU!!JKD!!&M/e9744!! Excerpts from direct: 23-Sep-99 Re: Different GIOP versions.. Paul H Kyzivat@roguewave (293*) > Does that mean when I send a disconnect, I am only doing so > in my server role, but I might wish to continue using the connection > as > a client? Yes. Bill From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Bill Janssen cc: Bill Janssen , Paul H Kyzivat , Jonathan Biggar , Michi Henning , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Message-ID: <852567F6.005CF718.00@d54mta08.raleigh.ibm.com> Date: Fri, 24 Sep 1999 11:54:12 -0500 Subject: Re: Different GIOP versions on a single TCP connection Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: bBPd9Qh5e9$2H!!/E)!! I am assuming that the phrase "send a disconnect" means send a CloseConnection message. Since CloseConnection can be sent by either a client or a server, how do you distinguish the role it is being sent in? And if we make it so you can, does that mean if you truly want the connection to be closed you have to send two CloseConnections? There is a LOT of wording in the spec that would have to be reworked if we wanted to do this, not to mention all the thought behind it. Russell Butek butek@us.ibm.com Bill Janssen on 09/23/99 04:11:12 PM To: Bill Janssen , Paul H Kyzivat cc: Jonathan Biggar , Michi Henning , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, Russell Butek/Austin/IBM@IBMUS, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Different GIOP versions on a single TCP connection Excerpts from direct: 23-Sep-99 Re: Different GIOP versions.. Paul H Kyzivat@roguewave (293*) > Does that mean when I send a disconnect, I am only doing so > in my server role, but I might wish to continue using the connection > as > a client? Yes. Bill Date: Fri, 24 Sep 1999 13:31:49 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: butek@us.ibm.com CC: Bill Janssen , Jonathan Biggar , Michi Henning , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@eng.sun.com, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Different GIOP versions on a single TCP connection X-Priority: 3 (Normal) References: <852567F6.005CF718.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: h*=!!mX>e9QO;e9nB>e9 butek@us.ibm.com wrote: > > I am assuming that the phrase "send a disconnect" means send a > CloseConnection message. Since CloseConnection can be sent by > either a client or a server, how do you distinguish the role it > is being sent in? And if we make it so you can, does that mean > if you truly want the connection to be closed you have to send > two CloseConnections? > > There is a LOT of wording in the spec that would have to be reworked > if we wanted to do this, not to mention all the thought behind it. ... > Bill Janssen on 09/23/99 04:11:12 PM > > Excerpts from direct: 23-Sep-99 Re: Different GIOP versions.. Paul H > Kyzivat@roguewave (293*) > > > Does that mean when I send a disconnect, I am only doing so > > in my server role, but I might wish to continue using the > connection > > as a client? > > Yes. I meant the question as a joke, but forgot to add a smiley. I agree with Russell that the way things stand this can't be viewed as two connections. However I agree with Bill that we could do a lot better job of partitioning functionality. But it will take a GIOP V2 or something like that to do it decently. I know that Bill has already done a lot of relevant work on HTTP-NG that could make a much more robust basis for a new GIOP. I don't know what the procedure might be, but I think it would be a good idea to start drawing up requirements for GIOP V2. This would eventually have to be an RFP, but it seems to me that we are a long way from being able to spell out clearly *why* we need something different, and exactly what characteristics we need for it to have (and not have). Perhaps this should be an RFI? Date: Fri, 24 Sep 1999 10:56:58 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , butek@us.ibm.com Subject: Re: Different GIOP versions on a single TCP connection CC: Bill Janssen , Paul H Kyzivat , Jonathan Biggar , Michi Henning , Jishnu Mukerji , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, kukura@iona.com, jeffm@inprise.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, ken.cavanaugh@Eng.Sun.COM, Yasuaki Sugino , terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org In-Reply-To: <852567F6.005CF718.00@d54mta08.raleigh.ibm.com> References: <852567F6.005CF718.00@d54mta08.raleigh.ibm.com> Content-Type: text X-UIDL: "W2!!C;nd92:$!!Z-E!! Yes, you're right. We'd have to put in thought about how to do this, unless we had a clear way of separating the two mixed-together channels -- like a bit set in the header for the reverse channel. Bill