Results of a trip report to the
34th Internet Engineering Task Force
Dallas, Texas, 4-8 December 1995
Craig Thompson, Object Services and Consulting, Inc.,
Dennis Finn, Hughes Research Labs, firstname.lastname@example.org
Jon Siegel, OMG, email@example.com
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.
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
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
- 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
- Technical feedback on OMG Internet protocol specs by IETF
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"
- 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.
- 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
- 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
- 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.
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
- 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
- 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?".
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.