Issue 2031: .Passing the interface repository ID of the method in IIOP (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: If we had a repository ID on the wire with every request, such errors could > be caught. In addition, it would make it substantially easier to build > tools such as IIOP packet tracers -- right now, it is next to impossible > to dump the parameter values of IIOP requests because the packet tracer > has no way of figuring out what the type of the target object is. This could be added to IIOP in a reasonably non-invasive way, too. We could add a service context to the request which would carry the repository ID of the interface in which the method was defined Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do Revised Text: Actions taken: October 5, 1998: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== eturn-Path: Date: Fri, 2 Oct 1998 19:37:47 PDT Sender: Bill Janssen From: Bill Janssen To: Michi Henning Subject: passing the interface repository ID of the method in IIOP CC: orb_revision@omg.org, ab@omg.org, interop.PARC@xerox.com References: Excerpts from direct: 2-Oct-98 Re: What does interface sub.. Michi Henning@dstc.edu.a (2117*) > If we had a repository ID on the wire with every request, such errors could > be caught. In addition, it would make it substantially easier to build > tools such as IIOP packet tracers -- right now, it is next to impossible > to dump the parameter values of IIOP requests because the packet tracer > has no way of figuring out what the type of the target object is. This could be added to IIOP in a reasonably non-invasive way, too. We could add a service context to the request which would carry the repository ID of the interface in which the method was defined. Sending this service context would be optional (for now). A client that wished to participate in this scheme would send a repository ID only when it changed -- that is, if two successive requests were methods from the same interface, only the first request would contain a repository ID. Servers that didn't understand the service context would just drop it. (Unfortunately, the 2.2 spec doesn't seem to say much about what servers should do for unrecognized service contexts, and I'm sure there are some out there that will object.) A participating server would then have one of three states when receiving a request: 1) A repository ID is in the request. It should be used to qualify the method name. 2) No repository ID is in the request, but one has been received in some earlier request on the same connection. That earlier repository ID should be used to qualify the method name. 3) No repository ID in the request, and none has been received previously. Apparently the client doesn't know to send the repository ID. In this case, the server should behave as it does now -- but I'd certainly put a switch into ILU which would allow users to optionally reject any requests received in this state, and lobby for such rejection as the default. I think we'd want to eventually change the DII to specify the interface Typecode as a separate parameter to create_request, but it could be done with the current interface by allowing the string which contains the method name to contain the repository ID -- "IDL:Foo:1.0:method1", for instance, instead of just "method1". Bill Return-Path: From: "Mcree, Randy" To: Juergen Boldt Subject: RE: issue 2031 -- Interop issue Date: Mon, 5 Oct 1998 09:44:09 -0700 I object. This issue needs clarification: what errors are being referred to by the phrase "such errors"? Without knowing more context, this issue is not meaningful. Randy McRee NSDOM ORB technical lead Tandem, a COMPAQ company. -----Original Message----- From: Juergen Boldt [SMTP:juergen@omg.org] Sent: Monday, October 05, 1998 8:42 AM To: issues@omg.org; interop@omg.org Subject: issue 2031 -- Interop issue This is issue # 2031 Passing the interface repository ID of the method in IIOP If we had a repository ID on the wire with every request, such errors could > be caught. In addition, it would make it substantially easier to build > tools such as IIOP packet tracers -- right now, it is next to impossible > to dump the parameter values of IIOP requests because the packet tracer > has no way of figuring out what the type of the target object is. This could be added to IIOP in a reasonably non-invasive way, too. We could add a service context to the request which would carry the repository ID of the interface in which the method was defined ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-508-820 4300 ext. 132 Framingham Corporate Center Fax: +1-508-820 4303 492 Old Connecticut Path Email: juergen@omg.org Framingham, MA 01701 ================================================================ To: "Rutt, T E (Tom)" cc: "'interop@Omg.org'" Subject: Re: interop NM RTF vote 6 announcement In-Reply-To: Your message of "Thu, 26 Oct 2000 14:16:39 PDT." From: Bill Janssen Message-Id: <00Oct26.163916pdt."3441"@watson.parc.xerox.com> Date: Thu, 26 Oct 2000 16:39:16 PDT Content-Type: text X-UIDL: @(gd96MZd9;MK!!,did9 Tom, I don't understand the voting on this. It seems there is an unstated issue with the proposed resolution, "Close the following set of issues as out of scope". Or are we supposed to vote individually on each of the "deferred issues"? In any case, I disagree with your characterization of these issues as "deemed out of scope". For example, issue 2031, passing the interface id of the method in the Request packet, seems like a great optional add-on that fixes a couple of problems, hurts noone, and is completely backwards compatible. Is the real problem that noone has yet proposed a full resolution of the issue? Bill