Issue 2588: Section number: 3.5.1.1, item 3 (incorba-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Issue: 5 Section number: 3.5.1.1, item 3 Problem: We have mistakenly associated TcLinkedContext with the operation which has the LINKED keyword rather than the actual linked operation, i.e., the operations appearing following the LINKED keyword Resolution: Revised Text: 3.5.1.1, item 3 Actions taken: April 12, 1999: received issue Discussion: End of Annotations:===== ]Issue: 5 Section number: 3.5.1.1, item 3 Problem: We have mistakenly associated TcLinkedContext with the operation which has the LINKED keyword rather than the actual linked operation, i.e., the operations appearing following the LINKED keyword Proposed solution: Two solutions are offered: - Nilo has proposed some text changea linked member. And drop the TcLinkedContext. Rationale: s to clarify this - Rob From: "Rob Brennan" To: "ftf" Subject: IN/CORBA: Issue 2588 Date: Mon, 6 Dec 1999 14:33:36 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1154 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: [oTd9CUkd9*ZA!!bkF!! Hi All, this one says: "We have mistakenly associated TcLinkedContext with the operation which has the LINKED keyword rather than the actual linked operation, i.e., the operations appearing following the LINKED keyword" This is a part of specification translation that adds context to be used during interaction translation. As we cannot predict which operations will later be used as linked operations by future ASN.1 specifications, I propose that we merge the TcLinkedContext and TcContext structures to just have one struct with all possible context info and make all operations carry this. This results in a simplification of the IDL (1 less struct) and a simplification of the ST algorithm (no longer a special case for operation definitions with the LINKED keyword). The only down side is that we have a member of the struct which has no meaning in most cases. Fortunately this is just an IDL ULong so it shouldn't be a huge overhead. what do people think? rgds rob From: "Rob Brennan" To: "ftf" Cc: "Rutt, T E (Tom)" , "Nils Fischbeck" , "Dave Stringer" , "Stephen Brennan" , "Nilo Mitra (EUS)" , , Subject: IN/CORBA: Issues 2591 and 2588 - VOTE Date: Mon, 20 Dec 1999 15:01:13 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1154 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BF4AFB.0EB5B7A0" X-UIDL: aQ4e9_,9!!>GTd9US@!! Hi All, as people seem to be drifting away for xmas I'll move the usual 1-week deadline for the vote to a 3 week deadline (Jan 8th). Hopefully everyone will get sufficient chance to vote by then. Unfortunately these resolutions require significant text changes and so are quite long. I have attached a text files with the detailed resolution for 2588. Details can also be found at the IN/CORBA page: http://www.teltec.dcu.ie/~brennanr/incorba-ftf/ Please return a vote to me (brennanr@teltec.dcu.ie) by 12 PM GMT JANUARY 8th 2000 ****Please remember that if you consistently fail to vote you lose the power to vote.**** I propose the following resolution for issue 2588: BEGIN PROPOSED RESOLUTION merge the TcLinkedContext and TcContext structures to just have one struct with all possible context info and make all operations carry this. This results in a simplification of the IDL (1 less struct) and a simplification of the ST algorithm (no longer a special case for operation definitions with the LINKED keyword) The precise text of the resolution is attached as 2588Resolution.txt END PROPOSED RESOLUTION I propose the following resolution for issue 2591: BEGIN PROPOSED RESOLUTION p45, paragraph beginning "InvokeId is used ..." ORIGINAL PARAGRAPH InvokeId is used to specify a TC operation invoke ID. Every operation within an association must have a unique InvokeId assigned. A TC-User object may place the value of NO_ID in this field to indicate that no invoke ID is specified. (Note that this is incompatible with support for TC linked operations.) CHANGE TO InvokeId is used to specify a TC operation invoke ID. A TC-User object may place the value of NO_ID in this field to indicate that no invoke ID is specified. (Note that this is incompatible with support for TC linked operations.) Management of Invoke IDs follows that of Q.774 (93). The relevant text (3.2.1.1.2) is quoted here for completeness; "Invoke IDs are assigned by the invoking end at operation invocation time. A TC-user need not wait for one operation to complete before invoking another. At any point in time, a TC-user may have any number of operations in progress at a remote end (although the latter may reject an invoke component for lack of resources). Each invoke ID value is associated with an operation invocation and its corresponding invoke state machine. Management of this invoke ID state machine takes place only at the end which invokes the operation. The other end reflects this invoke ID in its replies to the operation ivocation, and does not manage a state machine for this invoke ID. Note that both ends may invoke operations in a full-duplex manner: each end manages state machines for the operations it has invoked, and is free to allocate invoke IDs independently of the other. An invoke ID value may be reallocated when the corresponding state machine returns to idle. However immediate reallocation could result in difficulties when certain abnormal situations arise. A released ID value (when the state machine returns to idle) should therefor not be reallocated immediately; the way this is done is implementation-dependent, and thus is not described in this Recommendation." END PROPOSED RESOLUTION best regards Rob Brennan, Research Officer, Teltec DCU Phone: + 353 1 704 5853 [] 2588Resolution.txt