Issue 74: Type ids in OBJECT_FORWARD return message (interop) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id? Resolution: Closed with revised text Revised Text: Actions taken: August 13, 1996: received issue March 26, 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 ------------------------------ List of issues: Issue 55: IIOP object pointer resetting Issue 74: Type ids in OBJECT_FORWARD return message Issue 77: LOCATION_FORWARD byte alignment Issue 89: Correct IIOP marshalling of union TypeCodes Issue 382: Use of dynamic ports Issue 383: Callbacks in IIOP Issue 460: IORs and identifying Object Keys Issue 465: Transport Level Bridge Issue 488: Problem with GIOP CancelRequest when fragments are used Issue 543: IIOP server-initiated connection closure problem Issue 573: Type Extensions and code set negotiation Issue 574: Type extensions char code set negotiation Issue 589: Fragment improvements (1) Issue 590: Fragment improvements (2) Issue 591: 1.0 backward compat (1) Issue 592: 1.0 backward compat (2) Issue 593: CloseConnection messages Issue 651: Issue with service context Issue xxx: Unknown received system exception Issue 74: Type ids in OBJECT_FORWARD return message (interop) Source: International Business Machines (Mr. Hari H. Madduri, hari@austin.ibm.com) Nature: Uncategorized Severity: Clarification Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id? Resolution: The Corba 2.1 text in two paragraphs of 10.6.2 was supposed to be clarified to state that typeIds could be null. However an editorial error of not deleting the word "only" leaves the text invalid. Also, a clarifying sentence agreed by the IIOP 1.1 RTF regarding CORBA::Object , a phrase indicating that typeId is repository id, and the phrase "that the server wishes to publish (which were accepted in the resolved issues list) were inadvertently not included in the two paragraphs paragraph. With these three clarification changes, the paragraph becomes as shown below, and resolves this issue with an affirmative answer. Revised Text (proposed): The two paragraphs in 10.6.2 should be changed as follows: 1) Add new second sentence "A null TypeID is the only mechanism which can be used to represent the type CORBA::Object." 2) Delete word only from third sentence 3) Add "is a repository ID identifying an interface type, and" to fourth sentence 4) Add "that the server wishes to publish" in first sentence of second paragraph. The modified two paragraphs would then read: Null object references are indicated by an empty set of profiles, and by a "Null" type ID (a string which contains only a single terminating character). A Null TypeID is the only mechanism which can be used to represent the type CORBA::Object.. Type IDs may be "Null" in any message, requiring the client to use existing knowledge or to consult the object, to determine interface types supported. The type ID is a repository ID identifying an interface type, and is provided to allow ORBs to preserve strong typing. This identifier is agreed on within the bridge and, for reasons outside the scope of this interoperability specification, needs to have a much broader scope to address various problems in system evolution and maintenance. Type IDs support detection of type equivalence, and in conjunction with an Interface Repository, allow processes to reason about the relationship of the type of the object referred to and any other type. The type ID, if provided by the server, indicates the most derived type that the server wishes to publish at the time the reference is generated. The object's actual most derived type may later change to a more derived type. Therefore, the type ID in the IOR can only be interpreted by the client as a hint that the object supports at least the indicated interface. The client can succeed in narrowing the reference to the indicated interface, or to one of its base interfaces, based solely on the type ID in the IOR, but must not fail to narrow the reference without consulting the object via the "_is_a" or "_get_interface" pseudo- operations. Actions taken: Proposed closed with revision. August 13, 1996: Received issue