Issue 590: Fragment improvements (2) (interop) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: A response_expected setting should be added to a new "Fragment Header"(issue589) so that this setting may be delayed until the final fragment Resolution: issue closed, no change required Revised Text: Actions taken: June 17, 1997: received issue April 9, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Wed, 10 Dec 1997 16:49:32 -0500 From: ter@holta.ho.lucent.com (T E Rutt) To: interop@omg.org Subject: Interop 1.2 RTF Conference call (Proposed revisions and issues) To: Interop 1.2 RTF Subject: Dec 19, Conference Call From: Tom Rutt, RTF Chair I have attached my proposed Resolutions of Issues for ORB Interoperability 1.2 Revision Task Force. There was no meeting of the RTF at the NJ meeting, since everyone is so busy I decided to take a whack at coming up with resolutions for the issues. We need further discussion on some of these issues, as indicated in the actions section of each issue. A conference Call is scheduled for Friday, December 19, at 11:00 EST. I have the bridge reserved for 2 hours. The bridge phone number (16 ports reserved) is: +1 630 224 444 Conference Code 674 369 Let me know if you will participate, so I can ensure 16 is enough ports. Tom Rutt Issue 590: Fragment improvements (2) (interop) Source: IONA (Mr. Craig Ryan, cryan@iona.com) Nature: Uncategorized Severity: Summary: A response_expected setting should be added to a new 'Fragment Header'(issue589) so that this setting may be delayed until the final fragment Resolution: This seems like a major change to the protocol. What would happen to the response expected value in the original fragment of the request? Accepting this revision would change the meaning of the response expected flag in the original request fragment. Revised Text: Actions taken: Proposed no revision, since it changes semantics of original fragment"s response expected flag (boolean). June 17, 1997: received issue