Issues for Unreliable Multicast FTF

To comment on any of these issues, send email to umcast-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5455: Unreliable Multicast final adopted specification missing
Issue 5456: Disposition of IONA
Issue 5457: very good justification for not using a derived interface needed
Issue 5458: changes to IOP are not stated in section 5.3
Issue 5459: Consolidated IDL issue
Issue 5460: The included files appear to be from CORBA v2.2 or v2.3
Issue 5461: The FTF report should include a machine readable set of IDL files
Issue 5462: A.2 inconsistent with A.1
Issue 5463: Unreliable Multicast editorial issue
Issue 5464: issue with IDL ab/2002-07-02

Issue 5455: Unreliable Multicast final adopted specification missing (umcast-ftf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Clarification
Severity: Significant
Summary:
Whatever happened to the final adopted
specification doc #ptc/01-11-08? Is it meant to be a well kept secret?
It should have superseded ptc/01-10-18?

Resolution: The specification is available and can be downloaded
Revised Text:
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Issue 5456: Disposition of IONA (umcast-ftf)

Click
here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:
What exactly
happened to IONA? ptc/02-06-15 seems to be quite unclear about their
disposition.

Resolution: see above
Revised Text:
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Discussion:
IONA is a member of the team and Eoghan Glynn is their representative as of  November 20, 2002.


Issue 5457: very good justification for not using a derived interface needed (umcast-ftf)

Click
here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Revision
Severity: Critical
Summary:
This is a critical show stopper issue, because without a
clean resolution of this it breaks existing CORBA Core, and has
significant impact on the published Java jar files etc.


It looks like the submission just tosses in a bunch of additional
operations into the POA interface, without bothering to define a derived
interface. And yet it claims that this proposal is an optional
conformance point for CORBA. So after this proposal is merged into Core,
what is the implementer, who is not complying with this proposal
supposed to do about these additional operations that will suddenly
appear in the base POA interface?


I would like to hear a very good justification for not using a derived
interface for adding these operations. it seems like it will be
difficult to state an optional conformance statement for the POA
extension part, unless the interface is structured and packaged
properly.


Recommend that the added new operations be broken out into a separate
interface named something like UMPOA that derives from POA and that
contains only these new operations.


Then the conformance statement can say that the Unreliable Multicast
conformance point includes implementation of UMPOA.

Resolution: The routines have been taken out of the core IDL file.
Revised Text: The four routines, one exception, and one type definition have been moved to the PortableGroup module as stated below: module PortableGroup { … local interface GOA : PortableServer::POA { exception NotAGroupObject {}; typedef sequence <PortableServer::ObjectId> IDs; PortableServer::ObjectId create_id_for_reference (in Object the_ref) raises (NotAGroupObject); IDs reference_to_ids (in Object the_ref) raises (NotAGroupObject); void associate_reference_with_id (in Object ref, in PortableServer::ObjectId oid) raises (NotAGroupObject); void disassociate_reference_with_id (in Object ref, in PortableServer::ObjectId oid) raises (NotAGroupObject); }; };
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Discussion:


Issue 5458: changes to IOP are not stated in section 5.3 (umcast-ftf)

Click
here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
 It appears that due to an oversight the changes to IOP
are not stated
in section 5.3.


Need to provide an updated version of the IOP module. Please get in
touch with me. Also please populate the IOP module changes with actual
assigned values of the Tags. It is kind of hard to compile something
that looks like:


  ProfileId TAG_FOO_BAR = OMG Assigned;   :-)

Resolution: see above
Revised Text: Revised Text: // For Object Groups in module IOP.idl const ProfileId TAG_UIPMC = 3; const ComponentId TAG_GROUP = 39; const ComponentId TAG_GROUP_IIOP = 40; // End object group
Actions taken:
July 23, 2002: received issue
April 28, 2003: closed issue

Discussion:
Resolution:
The changes to the IOP module have been officially submitted to the AB and the Ids for group objects in the IOP module have been assigned


Issue 5459: Consolidated IDL issue (umcast-ftf)

Click
here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
The consolidated IDL explicitly identifies files that
have been
included - CosNaming.idl, IOP.idl, GIOP.idl and CORBA.idl [sic!] 


This business of including CORBA.idl is a long running problem with a
lot of specification that come out of the Realtime group of folks. Seems
like a systemic error that should be easy to fix.:-)



Resolution: see above
Revised Text:
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Discussion:
The include of the idl file CORBA.idl has been removed from the consolidated IDL


Issue 5460: The included files appear to be from CORBA v2.2 or v2.3 (umcast-ftf)

Click
here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
The included files appear to be from CORBA v2.2 or
v2.3. 
Since this standard will be an extension to CORBA v4.2 at least,
and actually of CORBA of an even later vintage, wouldn't it make sense
to try to compile this IDL relative to at least CORBA 2.4?


It is not at all clear from the FTF report which version of CORBA was
used to compile the non-delivered machine readable version of the IDL.
Recommend that this be done at least with CORBA 2.6, and given that this
will take another meeting cycle or two to complete, perhaps even do so
against CORBA 3.0.

Resolution: The consolidated IDL has been updated to reflect the 3.0 standard IDL format
Revised Text: See attached IDL files
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Discussion:
.


Issue 5461: The FTF report should include a machine readable set of IDL files (umcast-ftf)

Click
here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
The FTF report should include a machine readable set of IDL files.

Resolution: The consolidated IDL files have been included with this report
Revised Text:
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Issue 5462: A.2 inconsistent with A.1 (umcast-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Critical
Summary:
 A.2 states that "The
specification 
is a single, optional compliance point within the CORBA Core
specification." This seems inconsistent with A.1 which picks out one
aspect
of MIOP (the Gateway interface) and states: "An interface to an MIOP
gateway
should be considered an optional interface." I read this as saying that
Gateway is optional within MIOP, which overall implies 2 optional
compliance
points should be included in A.2: MIOP-without-Gateway and MIOP+Gateway

Resolution: The section A.1 was worded in a confusing manner
Revised Text: For A1: The statement: "An interface to an MIOP gateway should be considered an optional interface." will be changed to: "An interface to an MIOP gateway should be considered an optional interface within the MIOP specification." For A2: The statement "The specification is a single, optional compliance point within the CORBA Core specification." will be changed to: "The MIOP specification is a single, optional compliance point within the CORBA Core specification."
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Issue 5463: Unreliable Multicast editorial issue (umcast-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
The FTF Report contains chunks of the temmplate meant for the
document
author and not intended to be left in the actual report.

Resolution: Take the template sections out of the final report
Revised Text:
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Issue 5464: issue with IDL ab/2002-07-02 (umcast-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:
Neither spec or FTF report mentions the separate IDL file ab/01-07-02
 - The above IDL file contains a random line at the end "[] orbos -
2001-07-14 - Unreliable Multicast Revised Joint Submission
Presentation.ppt
"
 - The above IDL has 3 sub-files in one text file with no markings as to
how
to split it: better practice would be to use a zip file
 - * The IDL (in spec and separate file) refers in comments to CORBA 2.2
header files as formal/98-03-01 - which actually contains at least 3
syntax
errors for IOP and GIOP meaning it won't compile. And which I found
non-obvious to carve out into separate IOP and GIOP header files as
required
by the Multicast spec.
So following the advice given by the comments in the IDL I was not able
to
get the IDL to parse (the problems I hit were all to do with the
referred-to
header files - I didn't get as far as the MIOP IDL).


Resolution: The IDL for Unreliable Multicast has been resubmitted
Revised Text:
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue