Issue 589:  Fragment improvements (1) (interop)
Source:  (, )
Nature:  Uncategorized
Severity: 
Summary: Summary: Fragment messages should contain fragment header which contains a Request ID to associate the fragment with given request message. Frgamented request could otherwise block connection until sent.

Resolution:  fixed, close issue
Revised Text: 
Actions taken:
June 17, 1997: received issue
April 9, 1998: closed issue
Discussion: 

End of Annotations:=====

Return-Path: <ter@holta.ho.lucent.com>
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 589: Fragment improvements (1) (interop)

Source:	IONA (Mr. Craig	Ryan, cryan@iona.com)
Nature:	Uncategorized
Severity:
Summary: Fragment messages should contain fragment header
which contains a
Request	ID to associate	the fragment with given	request
message. Frgamented
request	could otherwise	block connection until sent.
Resolution: Needs discussion.  If this is important for
interoperability then we could add a new GIOP version 1.2
fragment message type.	GIOP 1.1 has a "fragment" message
type but the fragement message has no fragment header.	 Is
it worth a new minor protocol version.?	 Also, such a GIOP
1.2 fragment header would not be backward compatible with a
GIOP 1.1 fragment (no header), so the negotiation of
versions would required	the requests to	be sent	using the
same or	lesser version of the protocol as used in the
request	(or the	server can reject the request due to
unsupported protocol version).	The GIOP 1.2 server would be
required to support both GIOP 1.0 and 1.1 message formats.
Revised	Text:
Actions	taken: To be discussed in conference call.
June 17, 1997: received	issue