OMG-IETF Cooperation?

Results of a trip report to the

34th Internet Engineering Task Force

Contents

• Executive Summary
• Liaison with IETF
• Conclusions
• Inputs to OMG Internet SIG
• Next Step

Executive Summary

There appear to be several primarily informal ways OMG and IETF can cooperate. Below, we list some considerations in forming a liaison with the IETF community as an input to the OMG Liaison Subcommittee and identify some technical areas of intersection as an input to the OMG Internet SIG and indirectly to other OMG Task Forces. Finally, we provide some background on the way IETF operates that may be of interest to the entire OMG Technical Committee.

Liaison with IETF

One of the purposes of attending the 34th IETF meeting was to determine how and where OMG and IETF could collaborate. A goal of OMG is enterprise interoperation for both real and virtual enterprises. IDL provides a common object specification language for interoperability and CORBA provides a common distributed backplane.. Similarly, the Internet provides pervasive access to information sources and increasingly for networking services. So there is good reason to suppose that the two communities may find points of intersection.

Motivations for exploring potential IETF-OMG collaboration included:

• Future protocols that might be layered on top of OMG's Internet Inter ORB Protocol (IIOP) for providing object services on the Internet
• Potential integration of IIOP with HTTP to provide object services on the WWW.
• Interoperability between evolving OMG and IETF standards on the Internet (e.g., security protocols)
• Joint publication of relevant standards to reach a broad global base
• Technical feedback on OMG Internet protocol specs by IETF personnel

Ways of possible collaboration we considered were:

• OMG member participation in IETF
• joint working group
• joint publication of standards related to OO on the Internet
• publish GIOP/IIOP as an IETF informational RFC

Some issues we considered were:

• Change control of standards
• IETF and OMG standards processes
• Copyright issues
• Relative technical expertise of OMG and IETF

We learned (from talking to several key people) that:

• The IETF prefers informal (as opposed to formal) liaison relationships.
• The IETF (as represented by the co-chairs of the Application Area) is mainly concerned with wire protocols, not APIs, and sees little value to using objects in protocols (i.e., some IETF personnel think objects have value, but many don't, at least for global interoperability specifications). A comment was, "Every time the IETF has delved into standardizing APIs they've gotten burned."
• The IETF is reluctant to look at modifying procedural issues to facilitate joint publication of standards.
• The IETF encouraged us to publish IIOP as an informational RFC (anyone can publish anything this way). Since OMG originated and owns change control of IIOP, the most OMG can hope for by doing this is constructive comments from interested parties in IETF. There is no way to progress OMG specifications to become IETF standards without giving IETF change control since IETF is organized primarily to work on specifications, not "bless" others' standards.
• The OMG is prepared to discuss relaxing copyright restrictions and allow GIOP/IIOP to be published as an informational RFC and distributed freely by IETF according to their usual practice, provided that OMG's ownership and rights are not affected.

Conclusions

• Joint publication as OMG-IETF standards won't work due to the change control issues.
• The Application Area co-chairs (Klensin and Alvestrand) indicated that if we could find support for a joint working group and identify specific problems that needed to be addressed they'd be glad to review the charter. They advised against forming a Birds-of-a-Feather (BOF). BOFs are (usually) short-lived and are organized to understand if there is interest in the IETF for a working group but are not necessary steps to forming a working group. They felt that OMG and CORBA were well-enough established that we could skip the working-group stage.
• A joint working group seems unlikely, in the view of those we sampled, (unless through the HTTP W3C folks see below) because key IETF members don't see enough value in using objects and API to specify Internet standards. IETF individuals, of course, can still provide technical input directly to the OMG.
• OMG will probably submit GIOP/IIOP as an informational RFC after we get some feedback from a potential W3C-OMG workshop (see below). The informational RFC doesn't need to include IDL, for it can reference IDL as an ISO spec (i.e., IDL will be an ISO draft international standard in about 4 months it is a committee draft now).
• If we can get technical input from IETF personnel regarding IIOP (via the workshop) and publish the GIOP/IIOP as an informational RFC, we meet most of our goals without needing a joint working group or joint change control.

Inputs to OMG Internet SIG

One of the functions of the OMG Internet SIG is to act as an OMG focal point to collect requirements and architectural extensions to existing and future OMG specifications that are motivated by the Internet community, global networking, and Internet applications.

Based on this meeting, we see several points of intersection between OMG and IETF, where OMG members should be aware of IETF ongoing activities. On the other hand, IETF has no IETF specification or proposal for "moving abstract objects around" and is "reluctant to get into this business." They also resist getting into the business of OOPLs and data structures. Here is a partial list of potential areas of intersection of interests:

• asynchronous dispatch needed in CORBA (see OMG middleware discussions ongoing)
• how are ISO Remote Operations related to OMG IDL?
• OMG OID and WWW URL interoperability
• MIME types and OMG strong typing
• OMG externalization on-the-wire formats
• OMG Naming and X.500 naming
• stream objects including audio-video synchronization
• replication and hierarchical caching
• proxy servers
• distributed indexing of directories. IETF is doing indexing of directories. OMG might do content, extending the Object Query Service with support for indices.
• IIOP to access object services over the Internet
• security -- see the many IETF working groups on security
• firewalls and CORBA -- to allow inter-enterprise CORBA communication
• real-time transfer protocol
• scripting languages -- though IETF is not currently working in this area; "Java has no future in IETF until its compiler and specs are released;" and "if IETF does worry about scripting languages, it will be to insure that more than one of them can co-exist."
• transactions and sessions where state is transferred back and forth to client so server remains stateless
• scalability -- including stateless servers, replication of services, caching, ...
• architecture extensions to include multiplicity of federated services and compositions of services.

Along these lines, we had an interesting discussion with Jim Gettys (on loan to W3C from DEC for one year). He indicated that he had not looked at IIOP personally, but had talked to Bill Janssen (Xerox) and had the impression that IIOP as it is will not scale. He said that not scaling is a non-starter as far as the Internet community is concerned. He indicated several flaws with IIOP. Several of these would require modifying the OMA, so we are definitely NOT advocating making these changes -- we're just pointing out where some IETF members have concern:

• the protocol must support asynchronicity (Xerox's ILU does, CORBA doesn't at present)
• clients must be willing to refresh the server
• servers must be stateless (state info should be maintained at the client), for the server may not receive all of the packets or may discard some of them as needed to prevent excessive congestion. Some WWW sites receive in excess of a million hits a day.
• servers must be able to throw away context objects (see Spiro's text referenced on W3C's HTTP Next Generation WWW page).
• must be able to subclass enumerations--need to be able to generate new MIME types
• protocol must minimize bits in the datagrams because bandwidth is scarce. Think of WWW or CORBA applications over mobile PDAs (cellular modem with 600 baud). Minimize round trips. Asynchronous callbacks required.
• need closures or futures (Halstead reference) for asynchronous world with high latency.
• need a portable, modular implementation
• the IIOP interface should support the ability to add additional layers, such as compression, if necessary in the future.

Due to the above deficiencies (especially, no asynchronous support and too inefficient and also OMG specifications that are hard to read), Gettys indicated that he was using Xerox's ILU to integrate object services into the WWW instead of CORBA implementations and indicated that OMG would have to address these deficiencies quickly to enable it to be used on the WWW.

One other viewpoint, held by several people we talked to at IETF, is that OMG must lose its perceived "attitude problem" of being "the one true path" and "self-contained" and more humbly ask for input from the networking community saying, "We are concerned that IIOP may not scale to global Internets (after all, even intra enterprise networks are global). What do we do to IIOP to fix this problem?".

Next Step

OMG and W3C management will jointly host a workshop on Objects on the Web. OMG rules require the workshop to be open probably requiring a position paper. The time frame: April 1996 plus or minus a few months, possibly co-located with Object World Boston in May 1996. Given the pace of both OMG and Internet/WWW, sooner is better. (Of course, the OMG Internet SIG plays a similar role and meets bimonthly.) [The workshop is now schedule - see Joint W3C/OMG Workshop on Distributed Objects and Mobile Code, June 24-25, 1996.]

Written: December 1995 and sent to OMG TC and OMG Internet SIG.