Issue 4311: Incorrect table in section 15.4 (interop) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators") is in error. For CloseConnection, it shows that only the server can send this message but, in GIOP 1.2, either client or server can send the message, as detailed in 15.5.1 and 15.4.7. Also. in 15.4.7, we have: In GIOP version 1.2 both sides of the connection may send the CloseConnection message. That should be "must", not "may". Resolution: see above Revised Text: Change the existing entries in Table 15-3 below: Message Type Originator Value GIOP Versions Request Client 0 1.0, 1.1, 1.2 Reply Server 1 1.0, 1.1, 1.2 CancelRequest Client 2 1.0, 1.1, 1.2 LocateRequest Client 3 1.0, 1.1, 1.2 LocateReply Server 3 1.0, 1.1, 1.2 CloseConnection Server 5 1.0, 1.1, 1.2 to: Message Type Originator Value GIOP Versions Request Client 0 1.0, 1.1, 1.2 Request Both 0 1.2 with BiDir GIOP in use Reply Server 1 1.0, 1.1, 1.2 Reply Both 1 1.2 with BiDir GIOP in use CancelRequest Client 2 1.0, 1.1, 1.2 CancelRequest Both 2 1.2 with BiDir GIOP in use LocateRequest Client 3 1.0, 1.1, 1.2 LocateRequest Both 3 1.2 with BiDir GIOP in use LocateReply Server 4 1.0, 1.1, 1.2 LocateReply Both 4 1.2 with BiDir GIOP in use CloseConnection Server 5 1.0, 1.1 CloseConnection Both 5 1.2 Actions taken: May 17, 2001: received issue October 3, 2001: closed issue Discussion: Proposed Resolution: To Close with revision. However the wording in 15.4.7 is correct, since the semantics of the closeConnection message state when it is required to send the message. If bidirection GIOP is in use, a similar problem exists in the table for the Request, Reply, CancelRequest, LocateRequest, LocateReply. This needs to be corrected in the table. End of Annotations:===== Date: Thu, 17 May 2001 11:13:50 +1000 (EST) From: Michi Henning Reply-To: Interoperability RTF To: Interoperability RTF cc: issues@omg.org Subject: Incorrect table in section 15.4 Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ^U>e9~MXd9F:Ce9mZ&!! Hi, The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators") is in error. For CloseConnection, it shows that only the server can send this message but, in GIOP 1.2, either client or server can send the message, as detailed in 15.5.1 and 15.4.7. Also. in 15.4.7, we have: In GIOP version 1.2 both sides of the connection may send the CloseConnection message. That should be "must", not "may". Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from relayx2.inprise.com (143.186.11.7) by hobbit.omg.org asmtp(1.0) id 17951; Thu, 17 May 2001 00:41:49 -0400 (EDT) Received: from messaging.inprise.com (messaging.inprise.com [10.186.2.160]) by relayx2.inprise.com (8.9.3+Sun/Pro-8.9.3) with ESMTP id VAA20462; Wed, 16 May 2001 21:37:06 -0700 (PDT) Received: from godzooky.inprise.com ([172.20.20.12]) by messaging.inprise.com (Netscape Messaging Server 3.61) with ESMTP id AAA6479; Wed, 16 May 2001 21:36:14 -0700 Received: from inprise.com ([172.20.80.235]) by godzooky.inprise.com (Netscape Messaging Server 3.6) with ESMTP id AAA6EA9; Wed, 16 May 2001 21:36:13 -0700 Message-ID: <3B03553E.7499A2B8@inprise.com> Date: Wed, 16 May 2001 21:36:14 -0700 From: Vijaykumar Natarajan Organization: Borland Software Corporation X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Interoperability RTF CC: issues@omg.org Subject: Re: Incorrect table in section 15.4 References: Content-Type: multipart/mixed; boundary="------------DFA8649CCEEF1165E79ECC00" X-UIDL: ILN!!lMO!!J;4e9IKDe9 Hi Michi, Michi Henning wrote: > > Hi, > > The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators") > is in error. For CloseConnection, it shows that only the server can > send this message but, in GIOP 1.2, either client or server can send > the message, as detailed in 15.5.1 and 15.4.7. > > Also. in 15.4.7, we have: > > In GIOP version 1.2 both sides of the connection may send > the CloseConnection message. > > That should be "must", not "may". Why should each side be *required* to send the close connection message? Vijay > > Cheers, > > Michi. > -- > Michi Henning +61 7 3324 9633 > Chief CORBA Scientist +61 4 1118 2700 (mobile) > IONA Technologies +61 7 3324 9799 (fax) > Total Business Integration > http://www.ooc.com.au/staff/michi -- ------- Don't forget to vote in JDJ Readers' Choice Awards: http://www2.sys-con.com/java/readerschoice2001 or vote for all Borland's nominations in one go: http://www.borland.com/jdjvote.html This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. [] vnatarajan4.vcf Date: Thu, 17 May 2001 21:17:29 +1000 (EST) From: Michi Henning To: Vijaykumar Natarajan cc: Interoperability RTF Subject: Re: Incorrect table in section 15.4 In-Reply-To: <3B03553E.7499A2B8@inprise.com> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-ID: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: 4>B!!QY)e9UgLe9>b/e9 On Wed, 16 May 2001, Vijaykumar Natarajan wrote: > > Also. in 15.4.7, we have: > > > > In GIOP version 1.2 both sides of the connection may send > > the CloseConnection message. > > > > That should be "must", not "may". > > Why should each side be *required* to send the close connection > > message? The intent of CloseConnection is to allow the other end to distinguish intentional from unintentional connection closure; this permits the other end to raise an exception or transparently rebind. If we leave this at "may" we might as well not bother saying anything because whether an ORB does or does not send a CloseConnection message before closing hte connection is anybody's guess then. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Fri, 08 Jun 2001 12:52:50 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: terutt@lucent.com Cc: Bob Kukura , interop@omg.org, Michi Henning Subject: Re: Urgent Issue Vote 1 Interop Dec2000 References: <3B180462.8B8A1709@lucent.com> <3B20EBD4.E7C516D5@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~^Ud9do[!!ZKPd9$ekd9 Bob Kukura wrote: > 4311 - No - The current specification could easiliy be interpretted that > a 1.2 client is allowed to send CloseConnection regardless of whether > bidirectional GIOP has been negotiated, so this table seems to introduce > an incompatible change. Also, both sides do not necessarily agree at all > times on whether bidirectional GIOP has been negotatiated, so its not > clear when CloseConnection from the client would become legal. Good catch Bob. I missed that one. I would like to change HP's vote on 4311 to NO. So according to my records now HP's votes are as follows: Vote 1 4314 Urgent YES 4113 NO (needs further work) 4198 YES 4213 YES 4242 YES 4273 NO (needs further work) 4289 NO (needs further work) 4294 YES 4299 YES (although a somewhat uncomfortable one, since the modified 1.1 would be different from 1.1, and yet it is still called 1.1) 4309 YES 4311 NO (introduces incompatible change, and thus minimally requires changing minor version) Vote 2 4289 NO (needs further work) Cheers, Jishnu. Sender: jon@corvette.floorboard.com Message-ID: <3B210A3A.816D1BE3@floorboard.com> Date: Fri, 08 Jun 2001 10:24:10 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: terutt@lucent.com, Bob Kukura , interop@omg.org, Michi Henning Subject: Re: Urgent Issue Vote 1 Interop Dec2000 References: <3B180462.8B8A1709@lucent.com> <3B20EBD4.E7C516D5@iona.com> <3B2102E2.E2F5DE62@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `F4e9e3Ae9:23e9f&Q!! Jishnu Mukerji wrote: > > Bob Kukura wrote: > > > 4311 - No - The current specification could easiliy be interpretted that > > a 1.2 client is allowed to send CloseConnection regardless of whether > > bidirectional GIOP has been negotiated, so this table seems to introduce > > an incompatible change. Also, both sides do not necessarily agree at all > > times on whether bidirectional GIOP has been negotatiated, so its not > > clear when CloseConnection from the client would become legal. > > Good catch Bob. I missed that one. > > I would like to change HP's vote on 4311 to NO. Ditto for Floorboard. My reading of section 15.4.7 and 15.5.1.1 is that it is absolutely clear that a CloseConnection *must* be sent by a GIOP 1.2 client for orderly shutdown even without bidirctional GIOP under the current specification. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 08 Jun 2001 15:09:01 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: interop@omg.org Subject: lucent changes vote on 4311 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >5_!!W3Ge9(l3e9H0'e9 Lucent changes the vote on 4311 to NO. The table needs further work, since some have interpreted that close connection does not depend on bidir giop in use. -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com Date: Sun, 10 Jun 2001 07:59:54 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: jishnu_mukerji@hp.com, "Rutt, T E (Tom)" , Bob Kukura , Interoperability RTF Subject: Re: Urgent Issue Vote 1 Interop Dec2000 In-Reply-To: <3B210A3A.816D1BE3@floorboard.com> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Z11e9IUCe9i-ed9#T%e9 Status: RO On Fri, 8 Jun 2001, Jonathan Biggar wrote: > > Good catch Bob. I missed that one. > > > > I would like to change HP's vote on 4311 to NO. > > Ditto for Floorboard. My reading of section 15.4.7 and 15.5.1.1 is > > that > it is absolutely clear that a CloseConnection *must* be sent by a > > GIOP > 1.2 client for orderly shutdown even without bidirctional GIOP under > > the > current specification. That is my reading too, and that was the intent when we resolved the corresponding issue. See http://cgi.omg.org/issues/interop.html#Issue1968. (Strange -- the issue is still marked as open in the issue database, but I distinctly remember voting on this and making the change to the spec. What's up with that?) Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Wed, 13 Jun 2001 15:45:34 +1000 (EST) From: Michi Henning To: Tom Rutt cc: interop@omg.org Subject: Re: [Fwd: Vote 3 for interop 2001 rtf] In-Reply-To: <3B267926.8FFBBBD3@lucent.com> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-ID: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: nb&!!WN+e9;*;!!#?~e9 On Tue, 12 Jun 2001, Tom Rutt wrote: > Attached is the URL from juergen for vote 2, which closes > Friday 5:00 PM EDT June 15, 2001 I'm still not happy with the resolution for 4311. No amount of wordsmithing will get us around the fact that just closing a connection wasn't what was intended in the normal case. Instead, the idea was that a CloseConnection message is always sent before closing a connection, and that failure to send it will be interpreted as something more serious, such as a crash on the other side or network outage. It's important to be able to distinguish between the two. If nothing else, it results in more useful diagnostics. But it's also useful for active connection management, where a client or server uses a connection pool and wants to reclaim connections. In addition, the ability to distinguish orderly from disorderly connection closure allows me to set rebinding policies for disorderly closure, for example, how many times and at what interval to retry before giving up. By making the CloseConnection optional (the use of the work "may" in 15.4.7), we deprive ourselves of all of this. I would suggest to *require* that CloseConnection be sent. For backward compatibility, it's not an issue because, currently, we have implementations that have either behavior. If an implementation neglegts to send CloseConnection, the other side will interpret the behavior as disorderly closure instead of orderly closure, which is mostly benign. But, by making the change, we at least allow ourselves to move towards something more sensible over time. I don't see the value of "may" in the spec at all. In clear text, it says: "We added a CloseConnection message because we thought it might come in handy some day, but we weren't really sure either, so the ORB may or may not send it (and, therefore, what it means if it is sent is anybody's guess)..." That's just no way to write specifications. Next time I see "may" or "can" in the spec, I shall SCREAM! :-( Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi