${taskforce.name} Avatar
  1. OMG Task Force

CORBA 3.5 RTF — Open Issues

Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA35-440 Ordering of user exception and return values CORBA 1.2 open
CORBA35-439 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 open
CORBA35-435 Standard ProgramId CORBA 2.0 open
CORBA35-437 VB cannot handle array out-parameters CORBA 2.0 open
CORBA35-434 Section 4.1.12: DICORBA TypeCode::kind CORBA 2.0 open
CORBA35-433 Remove EX_repositoryID readonly property from IForeignException CORBA 2.0 open
CORBA35-431 Return value type of DICORBATypeCode::member_type should be changed CORBA 2.0 open
CORBA35-340 Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation CORBA 2.3 open
CORBA35-420 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 open
CORBA35-214 Correction of CORBA specification (page 18-51) CORBA 2.3.1 open
CORBA35-339 Section number: 3.5.1.1, item 3 CORBA 2.3 open
CORBA35-208 COM/CORBA keywords CORBA 2.2 open
CORBA35-207 Fixed Types in COM CORBA 2.4.2 open
CORBA35-3 COM Sequence changes CORBA 2.0 open
CORBA35-1 Levels of Indirection for passing COM types seem to be missing CORBA 2.0 open
CORBA35-436 What should Automation View accept in bounded sequences? CORBA 2.0 open
CORBA35-430 uuid for DForeignException has an extra 0 CORBA 2.0 open
CORBA35-427 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 open
CORBA35-429 page 2-25 contradicts first sentence of 3rd full para on p 4-106 CORBA 2.0 open
CORBA35-424 boundary violations should cause View to propagate DISP_E_OVERFLOW CORBA 2.0 open
CORBA35-425 page 4-109, section 4.1.5.3: editorial CORBA 2.0 open
CORBA35-423 page 4-129, section 4.1.17.1: retval attribute CORBA 2.0 open
CORBA35-422 page 4-129, section 4.1.17: change term "CORBA proxy" CORBA 2.0 open
CORBA35-421 INSTANCE_Clone does not need an in-parameter CORBA 2.0 open
CORBA35-342 Section number: 3.3.4 and elsewhere CORBA 2.3 open
CORBA35-419 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 open
CORBA35-330 Shouldn't this section really be called TC Service Interface? CORBA 2.3 open
CORBA35-324 Should SIOP version number start with 1.2? CORBA 2.3 open
CORBA35-325 Could SIOP be changed to 7IOP, pronounced "seven-up"? CORBA 2.3 open
CORBA35-300 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 open
CORBA35-323 Section number: 6.2.2 CORBA 2.3 open
CORBA35-298 Missing definition on security tags in the SIOP CORBA 2.3.1 open
CORBA35-299 There is currently no valuetype support in SIOP. CORBA 2.3.1 open
CORBA35-297 Use of PolicyType id CORBA 2.3.1 open
CORBA35-264 Lifecycle Key type definition CORBA 1.2 open
CORBA35-263 Stream contexts and internalization CORBA 1.2 open
CORBA35-262 Start and end of context tags CORBA 1.2 open
CORBA35-261 Definition of stream portability CORBA 1.2 open
CORBA35-260 Multiple objects on a stream CORBA 1.2 open
CORBA35-259 Timeout while locking CORBA 1.2 open
CORBA35-258 Communication failure issue CORBA 1.2 open
CORBA35-257 Getting the thread ID in a non-transactional lock request CORBA 1.2 open
CORBA35-256 Freeing of locks at the end of a transaction CORBA 1.2 open
CORBA35-255 Coordinator remembering LockCoordinator CORBA 1.2 open
CORBA35-254 Input values for "which" arg of non-trans. LockCoordinator CORBA 1.2 open
CORBA35-253 Using local thread identification for concurrency CORBA 1.2 open
CORBA35-252 Common format on stream CORBA 1.2 open
CORBA35-251 CosGraphs::deep CORBA 1.2 open
CORBA35-250 performing a compound copy of relationship CORBA 1.2 open
CORBA35-246 CosCompoundExternalization Service CORBA 1.2 open
CORBA35-245 CosCompoundExternalization Service (2) CORBA 1.2 open
CORBA35-244 CosCompoundExternalization Service (3) CORBA 1.2 open
CORBA35-240 Internalizing roles-IDL optimization CORBA 2.1 open
CORBA35-243 Purpose of related LockSet CORBA 2.0 open
CORBA35-238 QueryCollection::Collection -- membership scoping CORBA 1.2 open
CORBA35-237 QueryCollection::Collection -- Adding multiple elements CORBA 1.2 open
CORBA35-235 QueryCollection::Collection -- finding index CORBA 1.2 open
CORBA35-236 Query Collection::Collection -- Sharing State CORBA 1.2 open
CORBA35-234 QueryCollection::Collection -- Iterator Position Invalid CORBA 1.2 open
CORBA35-233 QueryCollection::Collection -- iterator updating CORBA 1.2 open
CORBA35-231 QueryCollection::Collection -- reset() exceptions CORBA 1.2 open
CORBA35-232 QueryCollection::Collection -- destroy methods CORBA 1.2 open
CORBA35-230 QueryCollection::Collection -- next_n() CORBA 1.2 open
CORBA35-229 QueryCollection::Collection -- keyed collections CORBA 1.2 open
CORBA35-228 Questions on CosQuery::QueryableCollection interfaces CORBA 1.2 open
CORBA35-226 Updating information via query iterators CORBA 1.2 open
CORBA35-227 Use of MD5 on arguments CORBA 1.2 open
CORBA35-225 How do iterators handle changing of the data they are pointing at CORBA 1.2 open
CORBA35-224 Clarification request for section 11.1.5 CORBA 1.2 open
CORBA35-222 retrieve_element CORBA 1.2 open
CORBA35-223 Definition of NULL in datafiles without NULL as a concept CORBA 1.2 open
CORBA35-221 Delegating iterator functionality to the RDBMS CORBA 1.2 open
CORBA35-220 Query language for operations CORBA 1.2 open
CORBA35-219 OQS relation to POS CORBA 1.2 open
CORBA35-217 Malformed PropertyName CORBA 1.2 open
CORBA35-216 WWW Form output CORBA 1.2 open
CORBA35-209 Compiler being able to translate from OMG-IDL into ANSI CORBA 1.2 open
CORBA35-606 The CMM document component-formal-21-02-04 shall be removed from CORBA 3.4 to become a standalone CMM specification. CORBA 3.4 open
CORBA35-446 Add CDR marshaling support for new IDL4 types (e.g. maps, bitset, bitmask) CORBA 3.3 open
CORBA35-438 Section 4.1.18.5 enum should be named CORBA_CompletionStatus CORBA 2.0 open
CORBA35-432 Add CORBATCKind to end of enum list CORBA 2.0 open
CORBA35-416 Section 5.5 Interface repository (02) CORBA 2.2 open
CORBA35-405 Clarify the hash code algorithm CORBA 2.2 open
CORBA35-404 Section 5.6.2 Repository Id CORBA 2.2 open
CORBA35-403 Repository Id (02) CORBA 2.2 open
CORBA35-402 Repository Id (03) CORBA 2.2 open
CORBA35-401 Section 5.6.3 Hashing Algorythm CORBA 2.2 open
CORBA35-400 Semantics of computing the hash code.. CORBA 2.2 open
CORBA35-399 Concrete value class CORBA 2.2 open
CORBA35-395 Java mapping example and C++ mapping example CORBA 2.2 open
CORBA35-393 Why is ValueBase a value and not a native type? CORBA 2.2 open
CORBA35-391 Editorial page 8-107 CORBA 2.2 open
CORBA35-386 Can public modifier be applied to value operations? CORBA 2.2 open
CORBA35-357 No typecodes for abstract interfaces CORBA 2.2 open
CORBA35-338 How can we bound the range of invoke ids in the IDL? CORBA 2.3 open
CORBA35-335 Problem: Why is AssociationId a string? CORBA 2.3 open
CORBA35-334 The current text for DialogFlowCtr is for outgoing only CORBA 2.3 open
CORBA35-333 There is a difference between the responder and initiator interfaces CORBA 2.3 open
CORBA35-332 Section 4.3.2.1 Title and text should be changed CORBA 2.3 open
CORBA35-331 Section 4.7.1: RelativeRoundTripPolicy CORBA 2.3 open
CORBA35-329 Section number: 5.2 and other sub-sections CORBA 2.3 open
CORBA35-328 Section number: 5.4.1 CORBA 2.3 open
CORBA35-327 Shouldn't it be typedef string CORBA::ScopedName? CORBA 2.3 open
CORBA35-326 Section number: Fig. 27 CORBA 2.3 open
CORBA35-322 Problem: There is no way to send dialogue data in a continue confirm. CORBA 2.3 open
CORBA35-321 Section number: 5 CORBA 2.3 open
CORBA35-313 new_callback CORBA 2.3 open
CORBA35-312 How to obtain initial reference to the GIOPProxy object CORBA 2.3.1 open
CORBA35-311 Proxified object references CORBA 2.3.1 open
CORBA35-310 Reusing PASSTHRU CORBA 2.3.1 open
CORBA35-309 Clarification is needed on the passing of credentials CORBA 2.3.1 open
CORBA35-308 Problems with routing and/or traversal of firewalls. CORBA 2.3.1 open
CORBA35-306 Use of InvokeId as the type name for both invoke id and link id. CORBA 2.3.1 open
CORBA35-304 Why one to one association between a TcPduUser and TcPduProvider interface? CORBA 2.3.1 open
CORBA35-303 Specification Translation from ASN to IDL issue CORBA 2.3.1 open
CORBA35-302 TcPdu User and Provider interfaces CORBA 2.3.1 open
CORBA35-301 use of the SSN number in the 1988 TCAP version CORBA 2.3.1 open
CORBA35-174 Issue: CSIv2 Identity Assertion CORBA 2.3.1 open
CORBA35-210 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 open
CORBA35-242 Which model should ConcurrencyControl support? CORBA 2.0 open
CORBA35-336 Section number: 4.2.1 CORBA 2.3 open
CORBA35-314 new_target CORBA 2.3 open
CORBA35-320 Section number: 2.3 CORBA 2.3 open
CORBA35-211 CosConsurrencyControl service bug or not? CORBA 2.3.1 open
CORBA35-239 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 open
CORBA35-241 Who is responsible for releasing locks in transaction? CORBA 2.0 open
CORBA35-215 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 open
CORBA35-4 Duplicate union labels CORBA 2.0 open
CORBA35-5 Changes to ForeignComplexType CORBA 2.0 open
CORBA35-6 Section 13A.5.2: Editorial CORBA 2.0 open
CORBA35-7 Section 13A.2.3: editorial CORBA 2.0 open
CORBA35-8 Capter 13C: Editorial CORBA 2.0 open
CORBA35-9 Incorrect mappings for systems exceptions (part A) CORBA 2.0 open
CORBA35-175 Polymorphic Valuetypes and the DII CORBA 2.3.1 open
CORBA35-176 DynValue & custom valuetypes CORBA 2.3.1 open
CORBA35-177 Custom Value Marshaling Issue CORBA 2.3.1 open
CORBA35-178 Potential deadlock with POA::deactivate_object() CORBA 2.3 open
CORBA35-218 interface QueryEvaluator { CORBA 2.0 open
CORBA35-296 BiDir GIOP Policy Clarification CORBA 2.4.1 open
CORBA35-305 When does a multiassociation TcUse know that it has been finished with? CORBA 2.3.1 open
CORBA35-315 Firewall Traversal algorithm CORBA 2.3 open
CORBA35-316 Firewall POA Policy does not control access CORBA 2.3 open
CORBA35-317 Outgoing local port in Bi-directional IIOP CORBA 2.3 open
CORBA35-318 Bi-Directional GIOP: Masquerade security issue needs to be more explicit CORBA 2.3 open
CORBA35-319 Bi-Directional GIOP: which connections may be used? CORBA 2.3 open
CORBA35-344 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 open
CORBA35-345 issue with TCPfirewallMechanism CORBA 2.2 open
CORBA35-349 Minimum CORBA and POA CORBA 2.3 open
CORBA35-350 ValueHelper Interface issue CORBA 2.2 open
CORBA35-352 Status of hashed repository IDs CORBA 2.2 open
CORBA35-356 TypeCode complexity for value types CORBA 2.2 open
CORBA35-379 Marshaling engine issue CORBA 2.2 open
CORBA35-347 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 open
CORBA35-348 The values of these tags need to be assigned CORBA 2.2 open
CORBA35-353 OBV init CORBA 2.2 open
CORBA35-354 CodeBase interface uses undefined type CORBA 2.2 open
CORBA35-355 Memory Management for Value Factories Unspecified CORBA 2.2 open
CORBA35-360 OBV TypeCode parameters wrong CORBA 2.2 open
CORBA35-361 C++ boxed value member clashes CORBA 2.2 open
CORBA35-362 Custom marshalling support for IDL fixed type CORBA 2.2 open
CORBA35-363 Default constructor for Java values CORBA 2.2 open
CORBA35-364 Boxed values need extension to write_Value call CORBA 2.2 open
CORBA35-365 TypeCodes for values CORBA 2.2 open
CORBA35-366 Forward declaration of value boxes CORBA 2.2 open
CORBA35-367 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 open
CORBA35-368 OBV spec inefficient for dending large number of small objects CORBA 2.2 open
CORBA35-369 OBV C++ problem with "supports" CORBA 2.2 open
CORBA35-370 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 open
CORBA35-371 TypeCodes defined in section 5.8.2 CORBA 2.2 open
CORBA35-372 CDR Streams CORBA 2.2 open
CORBA35-373 OBV "chunking" CORBA 2.2 open
CORBA35-374 Can "public" mofifier be applied to value operations? CORBA 2.2 open
CORBA35-376 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 open
CORBA35-375 Typo on page 8-107 of OBV specification CORBA 2.2 open
CORBA35-390 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 open
CORBA35-392 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 open
CORBA35-394 Section 7.3.10 Value Factories CORBA 2.2 open
CORBA35-396 Section 7 C++ Language mapping CORBA 2.2 open
CORBA35-397 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 open
CORBA35-398 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 open
CORBA35-406 Type code issue CORBA 2.2 open
CORBA35-407 Missing member_kind and member_tc CORBA 2.2 open
CORBA35-408 describe_value() operation issue CORBA 2.2 open
CORBA35-409 Value type ansd Value Box"s single data member name CORBA 2.2 open
CORBA35-410 p.6.68 boxed values of complex types map to same type CORBA 2.2 open
CORBA35-411 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 open
CORBA35-413 Can Value type inherit from Value Box type? CORBA 2.2 open
CORBA35-417 Section 5.5 Interface repository (01) CORBA 2.2 open
CORBA35-428 ODL is erroneous CORBA 2.0 open
CORBA35-192 rules for marshalling ValueBoxes CORBA 3.0.2 open
CORBA35-193 Problem with ServerRequestInterceptor::receive_request and DSI CORBA 3.0.2 open
CORBA35-194 restriction of where a valuetype chunk can end CORBA 3.0.2 open
CORBA35-197 Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 CORBA 3.0 open
CORBA35-198 Spec doesn't make clear what is valid mix of policies and what is invalid CORBA 3.0 open
CORBA35-200 How does DynValue handle derived valuetypes? CORBA 3.0 open
CORBA35-202 CORBA 3.02, page 11-25, section 11.3.6 CORBA 3.0.2 open
CORBA35-203 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 open
CORBA35-204 valuetypes and local interfaces CORBA 3.0.2 open
CORBA35-206 Unclear and possibly harmful consequences of mandatory annotation definitions CORBA 3.1.1 open
CORBA35-212 CosExternaliazation Service (bug?) CORBA 2.4.2 open
CORBA35-213 Inconsisten IDL in the Minimum CORBA chapter CORBA 2.4.2 open
CORBA35-265 when is a connection a "bi-directional connection"? UML 2.0 open
CORBA35-266 use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous CORBA 2.5 open
CORBA35-267 Bi-directional connections considered volatile at connection acceptor side CORBA 2.5 open
CORBA35-268 Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY CORBA 2.5 open
CORBA35-269 How many BI_DIR_GIOP_OFFER service contexts are allowed CORBA 2.5 open
CORBA35-270 connection_complete field of the FirewallPathRespContext is under specified CORBA 2.5 open
CORBA35-271 Expected behavior of a non-conformant implementation CORBA 2.5 open
CORBA35-272 Targets of Export and Offer Policies incompletely specified CORBA 2.5 open
CORBA35-273 Processing of NegotiateSession messages at various stages of connection set CORBA 2.5 open
CORBA35-274 Firewall FTF Issue: No ene-to-end security for firewall traversal CORBA 2.5 open
CORBA35-275 What BiDirIds shall be sent over what bidirectional connections? CORBA 2.5 open
CORBA35-276 Interplay of Contexts allowed in NegotiateSession messages too ill-defined CORBA 2.5 open
CORBA35-277 Firewall Issue: Random BiDirIds can't be used for persistent POAs CORBA 2.5 open
CORBA35-278 Firewall Issue: Connection over which BiDir offers are sent is unspecified CORBA 2.5 open
CORBA35-279 Firewall Issue: Response to failed BiDir challenge is unclear CORBA 2.5 open
CORBA35-280 Firewall issue - Number of BiDirIds in a BiDirOffer CORBA 2.5 open
CORBA35-281 Implications about BiDirIds CORBA 2.5 open
CORBA35-282 paragraph limits use of BiDirOfferContext CORBA 2.5 open
CORBA35-283 Negotiate Session Message Issues CORBA 2.5 open
CORBA35-284 CodeSet issue (05) CORBA 2.5 open
CORBA35-285 CodeSet issue (04) CORBA 2.5 open
CORBA35-286 CodeSet issue (03) CORBA 2.5 open
CORBA35-287 CodeSet issue (02) CORBA 2.5 open
CORBA35-288 CodeSet issue (01) CORBA 2.5 open
CORBA35-289 GIOP version 2.0 issue CORBA 2.5 open
CORBA35-290 Discrepancy in the changes proposed to CSIIOP and CSI modules CORBA 2.5 open
CORBA35-291 Bidirectional Policy insufficient for persistent objects CORBA 2.5 open
CORBA35-292 Server Authentication CORBA 2.5 open
CORBA35-293 Negotiation Session message is unwieldy CORBA 2.5 open
CORBA35-294 Negotiate Session Message Orientation CORBA 2.5 open
CORBA35-295 MAIN_THREAD_MODEL questions CORBA 2.4.1 open
CORBA35-442 The use of Full Services definitions in CORBA/e spec CORBAe 1.0b1 open
CORBA35-441 CORBA section 11 struct PortableGroup::GroupInfo CORBAe 1.0b1 open
CORBA35-139 Invalid IDL ZIOP 1.0 open
CORBA35-138 Invalid IDL (2) ZIOP 1.0 open
CORBA35-137 Missing PolicyValue encoding instructions ZIOP 1.0 open
CORBA35-136 Missing size information for decompress() ZIOP 1.0 open
CORBA35-447 Add support for IDL4 int8/uint8/map/bitset/bitfield/bitmask CORBA 3.4 open
CORBA35-172 Implications of any/valuetype marshalling CORBA 2.4.1 open
CORBA35-69 69.3 AssemblyFactory Interface CORBA 3.0 open
CORBA35-65 [CCM] Interface Repository Metamodel CORBA 3.0 open
CORBA35-61 CCM IDL style inconsistency CORBA 3.0.2 open
CORBA35-60 multiple lifetime policies declaration issue CORBA 3.0.2 open
CORBA35-58 CCM spec: insufficient examples of component attributes CORBA 3.0.2 open
CORBA35-53 CCM Spec: attributes are listed in the ports section? CORBA 3.0.2 open
CORBA35-2 Section 13C.1.3 Editorial CORBA 2.0 open
CORBA35-54 issue on component supporting abstract interfaces CORBA 3.0.2 open
CORBA35-51 portability of CCM descriptors CORBA 3.0.2 open
CORBA35-173 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 open
CORBA35-48 The association of entity component primary key and PSS key is unclear CORBA 3.0.2 open
CORBA35-45 Generic connectivity for Receptacles, Emitters, Publishers CORBA 3.0.3 open
CORBA35-41 "supports" keyword CORBA 3.0.3 open
CORBA35-40 Contradictory sections in the CCM and Lightweight CCM specifications CORBA 3.0.3 open
CORBA35-29 CCMHome should have a get_container method CORBA 3.0.2 open
CORBA35-307 Traversal algorithm not sufficient CORBA 2.3.1 open
CORBA35-337 It should be possible to have negative invoke ids CORBA 2.3 open
CORBA35-341 Section number: 3.3.4 make factory creation operations conform to the IDL CORBA 2.3 open
CORBA35-343 Title does not cover the use of SS7 as signaling transpor CORBA 2.3 open
CORBA35-346 passthrough connection CORBA 2.2 open
CORBA35-351 "Tool" issue for IDL compilers too complex CORBA 2.2 open
CORBA35-359 P 5-44: use of base type CORBA 2.2 open
CORBA35-358 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 open
CORBA35-377 Narrowing from abstract interfaces CORBA 2.2 open
CORBA35-378 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 open
CORBA35-380 No portable way to obtain list of type safe repository IDs CORBA 2.2 open
CORBA35-381 Keyword identifiers (04) CORBA 2.2 open
CORBA35-382 Keyword Identifiers(03) CORBA 2.2 open
CORBA35-383 Keyword identifiers (02) CORBA 2.2 open
CORBA35-384 Keyword identifiers (01) CORBA 2.2 open
CORBA35-385 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 open
CORBA35-387 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 open
CORBA35-388 Editorial: p 5-50 CORBA 2.2 open
CORBA35-389 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 open
CORBA35-412 New lexical type - Keyword Identifie CORBA 2.2 open
CORBA35-414 "Safe" keyword identifier issue CORBA 2.2 open
CORBA35-415 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 open
CORBA35-418 Can value type inherit from Value Box type CORBA 2.2 open
CORBA35-426 page 2-30: There is a label "Examples", but no examples CORBA 2.0 open
CORBA35-449 exception AdapterInactive ZIOP 1.0b1 open
CORBA35-450 Why is the enum ThreadPolicyValue completely zapped from IDL ZIOP 1.0b1 open
CORBA35-37 spec should define how the base class of an executor is generated by the framework ZIOP 1.0b1 open
CORBA35-35 typedef CCMObjectSeq ZIOP 1.0b1 open
CORBA35-34 Event mechanism proposal ZIOP 1.0b1 open
CORBA35-33 ResourceCommitmentManager lacking ZIOP 1.0 open
CORBA35-31 HomeConfiguration::set_configuration_values should document exception ZIOP 1.0 open
CORBA35-32 two not used and document exceptions listed ZIOP 1.0 open
CORBA35-36 The spec mentions InvalidConfiguration as exception but there is no idl in this spec ZIOP 1.0b1 open
CORBA35-38 add a sequence of CCMHome typedef sequence CCMHomes; CORBA 3.1 open
CORBA35-39 The D&C IDL part doesn't match 06-04-02. CORBA 3.0.3 open
CORBA35-110 NVList Section: 7.5 CORBA 3.0.3 open
CORBA35-113 Page: 21-5 CORBA 3.0.3 open
CORBA35-114 Section: Appendix A CORBA 3.0.3 open
CORBA35-115 Section: 21.3.14.11 CORBA 3.0.3 open
CORBA35-116 Section: 4.5.2 CORBA 3.0.3 open
CORBA35-119 Section: 11.3.9.16 CORBA 3.0.3 open
CORBA35-121 Page: 21-43 CORBA 3.0.3 open
CORBA35-122 Section: 22.11.1 CORBA 3.0.3 open
CORBA35-123 Section: 22.16/ CORBA 3.0.3 open
CORBA35-124 Section: 11.3.9 CORBA 3.0.3 open
CORBA35-125 Section: 21.4.3.1 CORBA 3.0.3 open
CORBA35-126 Section: 21.9.1 CORBA 3.0.3 open
CORBA35-127 Section: 21.7 CORBA 3.0.3 open
CORBA35-128 update the spec to not used anonymous types CORBA 3.0.3 open
CORBA35-129 Section: 4.2 (02) CORBA 3.0.3 open
CORBA35-130 Section: 4.2 CORBA 3.0.3 open
CORBA35-131 Section: 13.6.2 CORBA 3.0.3 open
CORBA35-132 Section: 7.4 CORBA 3.0.3 open
CORBA35-141 struct PolicyValue CORBA 3.0.3 open
CORBA35-145 Third line of 23.1.3.4, ACTIVE must be bold CORBA 3.0.3 open
CORBA35-146 Proposal to change PortableInterceptor::AdapterState to a real enum CORBA 3.0.3 open
CORBA35-147 Proposal to change PortableInterceptor::ReplyStatus to a real enum CORBA 3.0.3 open
CORBA35-148 Section: 15.4.2/16.4.1 CORBA 3.0.3 open
CORBA35-150 Section: 21.3.13 CORBA 3.0.3 open
CORBA35-152 16.10 lists register_initial_reference CORBA 3.1 open
CORBA35-153 add interface ORB { Object string_to_object ( in wstring str ); }; CORBA 3.0.3 open
CORBA35-154 add CORBA::ORB::arg_list CORBA 3.0.3 open
CORBA35-155 Section 13.7 ServiceContext CORBA 3.0.3 open
CORBA35-156 Section: 21.7.3 CORBA 3.0.3 open
CORBA35-157 Section: 4.8.1 CORBA 3.0.3 open
CORBA35-158 move struct to IOP module CORBA 3.0.3 open
CORBA35-159 Add create_policy with just the type as argument CORBA 3.1 open
CORBA35-160 context should be local interface CORBA 3.1 open
CORBA35-162 interface ORB should be local CORBA 3.0.3 open
CORBA35-163 Make anonymous types illegal CORBA 3.0.3 open
CORBA35-180 Appendix A CORBA 3.0.3 open
CORBA35-181 Section: 4.3.13 CORBA 3.0.3 open
CORBA35-183 The POA state inactive is not used consistent. CORBA 3.0.3 open
CORBA35-184 argument of the set_servant call has a small typo CORBA 3.0.3 open
CORBA35-185 change in the POAManager CORBA 3.0.3 open
CORBA35-186 Add a typedef for the POAManager id CORBA 3.0.3 open
CORBA35-187 methods on the POA CORBA 3.0.3 open
CORBA35-205 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 open
CORBA35-443 Add CompressorId for zstd CORBA 3.4 open
CORBA35-444 Extend InvalidName exception CORBA 3.4 open
CORBA35-445 Replace Cookie with a string and use IDL map CORBA 3.4 open
CORBA35-448 ConfigValues to a std map CORBA 3.4 open
CORBA35-28 CCMHome should have a get_components method CORBA 3.0.2 open
CORBA35-26 HomeConfigurator should not extend CCMHome CORBA 3.0.2 open
CORBA35-24 Generic port connections CORBA 3.0.2 open
CORBA35-247 $issue.summary CORBA 1.2 open
CORBA35-248 $issue.summary CORBA 1.2 open
CORBA35-249 $issue.summary CORBA 1.2 open
CORBA35-199 messaging router issue CORBA 3.0 open
CORBA35-201 module SendingContext CORBA 3.0.3 open
CORBA35-191 BNF changes CORBA 3.0.2 open
CORBA35-195 Bad text in 22.6 mandates Routing for sendc/sendp CORBA 3.0.2 open
CORBA35-196 What is the RSC when using a PersistentPoller CORBA 3.0.1 open
CORBA35-188 Codec Interface Deficiencies CORBA 3.0.3 open
CORBA35-189 An extension of IOR to protect target objects Nature CORBA 3.0.3 open
CORBA35-190 Mapping from -ORBxxx to Java properties does not work for -ORBInitRef CORBA 3.0.2 open
CORBA35-182 CORBA 3.0.3 ch. 3.4 OMG IDL Grammar CORBA 3.0.3 open
CORBA35-179 Code Set Conversion on Operations CORBA 3.0.3 open
CORBA35-168 ForwardRequest is impossible to detect in clients CORBA 2.6.1 open
CORBA35-171 Avoiding RSC/TSC copy on server side CORBA 2.4.1 open
CORBA35-170 Proposal for extension to CosNaming CORBA 2.6 open
CORBA35-169 New issue: ForwardRequest() CORBA 2.6 open
CORBA35-164 rule (85) is misplaced CORBA 3.1 open
CORBA35-167 processing TaggedComponents within an IOR CORBA 3.0 open
CORBA35-165 Bad quotes and imported dot CORBA 3.1 open
CORBA35-166 missing document title CORBA 3.1 open
CORBA35-161 Redundant bullet CORBA 3.2 open
CORBA35-151 There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle CORBA 3.1 open
CORBA35-142 Section: Part 2, Chapter 11 - MIOP CORBA 3.1 open
CORBA35-144 definition of Invalid Policies changed CORBA 3.1 open
CORBA35-143 mention of (deprecated) function get_implementation removed from text CORBA 3.1 open
CORBA35-149 Section: 13.6.10.1 CORBA 3.0.3 open
CORBA35-140 Two typo's in Annex A.4 CORBA 3.1 open
CORBA35-135 Moving *Seq typedefs into ORB chapter CORBA 3.0.3 open
CORBA35-134 Minor code ambiguity CORBA 3.0.3 open
CORBA35-133 Typo in sections 22.10.1.1 and 22.10.1.2 CORBA 3.0.3 open
CORBA35-120 FullInterfaceDescription and base_interfaces question CORBA 3.0.3 open
CORBA35-117 Allowing mutual recursion for IDL structs - clarification needed CORBA 3.0.3 open
CORBA35-118 CORBA Exceptions CORBA 3.0.3 open
CORBA35-111 Page: 7-7 CORBA 3.0.3 open
CORBA35-112 Page: 9-1 CORBA 3.0.3 open
CORBA35-106 69.8.2.8 The simple Element, page 69-538 CORBA 3.0 open
CORBA35-107 Section: Chapter 9, Chapter 5 CORBA 3.0.3 open
CORBA35-108 Section: Chapter 11 CORBA 3.0.3 open
CORBA35-109 Allowing Mutual Recursion for IDL Structures CORBA 3.0.3 open
CORBA35-99 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 open
CORBA35-100 69.3 Software Package Descriptor CORBA 3.0 open
CORBA35-101 Add the capability to define a component artifact property CORBA 3.0 open
CORBA35-103 69.8.2.9 The sequence Element CORBA 3.0 open
CORBA35-102 Test Property - add a test property definition to the properties DTD CORBA 3.0 open
CORBA35-104 69.8.2.3 The choices Element, page 69-537 CORBA 3.0 open
CORBA35-105 69.8.2.7 The range Element, pages 69-537/538 CORBA 3.0 open
CORBA35-92 Component Artifact Dependency CORBA 3.0 open
CORBA35-91 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 open
CORBA35-96 69.3.2.25 The propertyfile Element, page 69-482 CORBA 3.0 open
CORBA35-93 69.3.2.2 The author Element, page 69-474 CORBA 3.0 open
CORBA35-95 69.3.2.14 The idl Element, page 69-478 CORBA 3.0 open
CORBA35-94 Descriptor CORBA 3.0 open
CORBA35-98 69.8.2.7 The code Element, pages 69-474 CORBA 3.0 open
CORBA35-97 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 open
CORBA35-85 lwCCM issues - abstract storage type CORBA 3.0.3 open
CORBA35-87 lwCCM issues - entity components CORBA 3.0.3 open
CORBA35-88 lwCCM issues - persistence CORBA 3.0.3 open
CORBA35-86 lwCCM issues - section 4.1.2 CORBA 3.0.3 open
CORBA35-90 lwCCM issues - transaction CORBA 3.0.3 open
CORBA35-89 lwCCM issues - security CORBA 3.0.3 open
CORBA35-84 lwCCM issues - abstract storage home CORBA 3.0.3 open
CORBA35-83 lwCCM issues - CIDL CORBA 3.0.3 open
CORBA35-82 lwCCM issues - locator CORBA 3.0.3 open
CORBA35-81 lwCCM issues - segmentation CORBA 3.0.3 open
CORBA35-75 lwCCM issues - home finders and finder operations CORBA 3.0.3 open
CORBA35-76 lwCCM issues - proxy homes CORBA 3.0.3 open
CORBA35-74 lwCCM issues - invalid rows CORBA 3.0.3 open
CORBA35-79 lwCCM issues - primary key CORBA 3.0.3 open
CORBA35-80 lwCCM issues - get_all_facet, ... CORBA 3.0.3 open
CORBA35-78 lwCCM issues - Section 4.1 CORBA 3.0.3 open
CORBA35-77 lwCCM issues - configurators CORBA 3.0.3 open
CORBA35-67 Checking XML DTD elements related to the trader service CORBA 3.0 open
CORBA35-68 Description for the impltype Element? CORBA 3.0 open
CORBA35-70 Uses Relationships CORBA 3.0 open
CORBA35-71 Device Artifact Dependency CORBA 3.0 open
CORBA35-72 Dependency on D+C FTF CORBA 3.0.3 open
CORBA35-73 lwCCM issues - Entity2Context CORBA 3.0.3 open
CORBA35-64 A new exception specification is needed for CCM2Context::req_passivate() CORBA 3.0 open
CORBA35-62 Derived component supported interface restriction (formal/2002-06-65) CORBA 3.0 open
CORBA35-63 Issue on the description of the consumesidentifier element CORBA 3.0 open
CORBA35-66 Using Configurator on CCMHome or any CORBA objects? CORBA 3.0 open
CORBA35-55 Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3 CORBA 3.0.2 open
CORBA35-56 Section 6.4.5.10 (page 6-26) CORBA 3.0.2 open
CORBA35-59 3.2.7 Compositions with Managed Storage CCM 3.0 open
CORBA35-57 Section 6.4.5.52 (page 6-38) CORBA 3.0.2 open
CORBA35-52 'local executor mapping' CORBA 3.0.2 open
CORBA35-50 EnterpriseComponent should have a get_servant method CCM 3.0 open
CORBA35-44 EnterpriseComponent should have a set_persistent_object method CORBA 3.0.3 open
CORBA35-43 HomeExecutorBase should have a set_context method CORBA 3.0.3 open
CORBA35-46 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA35-47 EnterpriseComponent should have a get_servant method CORBA 3.0.2 open
CORBA35-49 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA35-42 add some feature to let an assembly look like a monolithic compoment CORBA 3.0.3 open
CORBA35-30 Incorrect statement that implies that connect_consumer returns a cookie ZIOP 1.0 open
CORBA35-22 Interface Introspection CORBA 3.0.2 open
CORBA35-23 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 open
CORBA35-27 Session2Context interface CORBA 3.0.2 open
CORBA35-25 LwCCM issue - Section 1.6.8 Exclusion CORBA 3.0.2 open
CORBA35-16 page 1-20 and page 1-21 - editorial CORBA 3.0.2 open
CORBA35-20 Change new GIOP Negotiate Session Message to Firewall Specific CORBA 3.0.2 open
CORBA35-19 GIOP Conformance and Interceptors CORBA 3.0.2 open
CORBA35-18 context interface for home implementation CORBA 3.0.2 open
CORBA35-17 page 1-20 the description of the get_connection operation CORBA 3.0.2 open
CORBA35-21 CodeSet and CSIv2 Negotitaion CORBA 3.0.2 open
CORBA35-10 valuetype fragmentation ambiguous CORBA 3.0.2 open
CORBA35-11 Clarification on multi-threaded codeset negotiation CORBA 3.0.2 open
CORBA35-12 15.3.3 - codesets must be "explicitly defined" CORBA 3.0.2 open
CORBA35-13 [Components] Contradiction between IDL and Interface Repository concerning CORBA 3.0.2 open
CORBA35-14 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 open
CORBA35-15 page 1-20 second bullet of the description of the disconnect operation CORBA 3.0.2 open

Issues Descriptions

Ordering of user exception and return values

  • Legacy Issue Number: 16
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The COM/CORBA Part A spec states that user exceptions go after return values in one place, and before return values in another. (3.2.10.3 and 4.1.3.1)

  • Reported: CORBA 1.2 — Fri, 14 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Standard uuid for interfaces (COM/CORBA Part A)

  • Legacy Issue Number: 680
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Standard ProgramId

  • Legacy Issue Number: 684
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There should be a standard ProgramId for the class which exposes D(I)CORBAAny

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

VB cannot handle array out-parameters

  • Legacy Issue Number: 682
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The VB cannt handle array out-parameters. Must use in-outs.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Section 4.1.12: DICORBA TypeCode::kind

  • Legacy Issue Number: 685
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.1.12: DICORBAtypeCode::kind has one parameter of type TCKind. It should be of type CORBATCKind

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Remove EX_repositoryID readonly property from IForeignException

  • Legacy Issue Number: 686
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: This property should be removed because the INSTANCE_repositoryId property in IForeignComplexType provides this functionality

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Return value type of DICORBATypeCode::member_type should be changed

  • Legacy Issue Number: 688
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The return value type should be DICORBATypeCode*, not IDispatch. The return value of member_label should be a DICORBAAny* rather than VARIANT

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation

  • Legacy Issue Number: 2586
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 3.5.1.1, item 4 plus appropriate section of interaction translation

    Problem: How to handle the sending of an empty RESULT and the reception of
    such a component.

    Proposed solution: Obviously no way to change the IDL from void. Need
    something in the TC Repository for use by a gateway in deciding what to do.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Dispatch versions of DCORBAObject and DORBObject

  • Legacy Issue Number: 699
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There should be straight dispatch versions of DCORBAObject and DORBObject

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Correction of CORBA specification (page 18-51)

  • Legacy Issue Number: 3342
  • Status: open  
  • Source: Anonymous
  • Summary:

    >You write on page 18-51:
    >In COM V2.0, interfaces can have single inheritance. However, as opposed to
    >CORBA,
    >there is a standard mechanism by which an object can have multiple interfaces
    >(without
    >an inheritance relationship between those interfaces) and by which clients can
    >query
    >for these at run-time. (It defines no common way to determine if two interface
    >references refer to the same object, or to enumerate all the interfaces
    >supported by an
    >entity.)
    >
    >It's not right, that there's no common way to determine if two interface
    >references refer to the same object. The IUnknown-Pointer of two different
    >interfaces of the same object must be the same (object identity in COM).

  • Reported: CORBA 2.3.1 — Tue, 22 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Section number: 3.5.1.1, item 3

  • Legacy Issue Number: 2588
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue: 5

    Section number: 3.5.1.1, item 3

    Problem: We have mistakenly associated TcLinkedContext with the operation
    which has the LINKED keyword rather than the actual linked operation, i.e., the
    operations appearing following the LINKED keyword

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

COM/CORBA keywords

  • Legacy Issue Number: 2009
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
    deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
    This tool mangles the following identifier (not necessarily a complete list) by
    prepending them with "_":

    "BSTR", "CALLCONV", "coclass", "CY",
    "CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
    "dual", "EXCEPINFO", "guid", "GUID",
    "HRESULT", "importlib", "IDispatch",
    "INTERFACEDATA", "IUnknown", "LCID",
    "METHODDATA", "odl", "oleautomation",
    "PARAMDATA", "properties", "propget", "propput", "retval",
    "SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
    "VARIANT", "VARIANTARG", "VARIANT_BOOL",
    "VARTYPE", "VARENUM"

    As far as I can tell, the output of the "mktyplib" tool makes use
    (directly or indirectly) of the regular C++ bindings, whose identifiers
    are not mangled the same way. This makes it impossible to emit COM bindings
    for IDL files that contain the above keywords.

    The problem that I"m running into is in CosTrading IDL, where the identifier
    "properties" is used.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Fixed Types in COM

  • Legacy Issue Number: 4507
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

  • Reported: CORBA 2.4.2 — Fri, 17 Aug 2001 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

COM Sequence changes

  • Key: CORBA35-3
  • Legacy Issue Number: 703
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Change the layout of both bounded and unbounded sequences to be the same

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Levels of Indirection for passing COM types seem to be missing

  • Key: CORBA35-1
  • Legacy Issue Number: 702
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

What should Automation View accept in bounded sequences?

  • Legacy Issue Number: 683
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When mapping bounded sequences, should the Automation View accept as an in-parameter a Safearray whose upper bound is less than the maximum lenght of the mapped sequence?

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

uuid for DForeignException has an extra 0

  • Legacy Issue Number: 689
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The uuid for DForeignException has an extra 0. It should be E977F907-3B75-11cf-BBFC-444553540000

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Page 2-41, section 2.9.7.2 Add name for Automation View interface

  • Legacy Issue Number: 692
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There should be a standard name for the Automation View interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

page 2-25 contradicts first sentence of 3rd full para on p 4-106

  • Legacy Issue Number: 690
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I suggest that the automation chapter be changed to align with the architecture chapter

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

boundary violations should cause View to propagate DISP_E_OVERFLOW

  • Legacy Issue Number: 695
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When translating a BSTR to a CORBA bounded string, boundary violations should cause the View to propagate DISP_E_OVERFLOW

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

page 4-109, section 4.1.5.3: editorial

  • Legacy Issue Number: 694
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: "..maximum value of an Automation short" should read "..maximum value of a CORBA::UShort

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

page 4-129, section 4.1.17.1: retval attribute

  • Legacy Issue Number: 696
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The "retval" attribute should be removed from the second argument in both methods. MIDL does not have a retval attribute

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

page 4-129, section 4.1.17: change term "CORBA proxy"

  • Legacy Issue Number: 697
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Second to last paragraph of the section contains the term "CORBA proxy" which should be changed to Automation View Interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

INSTANCE_Clone does not need an in-parameter

  • Legacy Issue Number: 698
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: INSTANCE_Clone does not need an in-parameter to specify the instance to be cloned.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Section number: 3.3.4 and elsewhere

  • Legacy Issue Number: 2584
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: There is a general problem on how to specify sending an empty
    Transaction PDU, such as an empty BEGIN, or an empty CONTINUE. "Empty"
    means just the Transaction portion without ROS components. This problem has
    to be addressed for sending an empty Transaction PDU from the CORBA side,
    as well as what to do when such a PDU is received from the legacy domain.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Automation View should generate HRESULT DISP_E_TYPEMISMATCH

  • Legacy Issue Number: 700
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If number of dimensions of an input SAFEARRAY does not match the mapped CORBA type, the Automation View should generate the HRESULT DISP_E_TYPEMISMATCH

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Shouldn't this section really be called TC Service Interface?

  • Legacy Issue Number: 2597
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5

    Problem: Shouldn’t this section really be called TC Service Interface because it
    really provides an IDL version of Q.771? Note that this requires changing the
    names of various interfaces by removing the word Pdu, which should be
    reasonably simple.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Should SIOP version number start with 1.2?

  • Legacy Issue Number: 2603
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6.1

    Problem: Should SIOP version number start with 1.2?

    Proposed solution:

    Rationale: This would allow a quick recognition of the highest GIOP version supported by
    this version of SIOP.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Could SIOP be changed to 7IOP, pronounced "seven-up"?

  • Legacy Issue Number: 2602
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6

    Problem: Could SIOP be changed to 7IOP, pronounced "seven-up"?

    Proposed solution:

    Rationale: The S in SIOP may be mistaken for Security.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Allow GIOP 1.3 messages to be transported.

  • Legacy Issue Number: 3184
  • Status: open  
  • Source: Siemens AG ( Nils Fischbeck)
  • Summary:

    Align SIOP definition with GIOP 1.3 of CORBA2.3.1.

    Problem: SIOP is currently defined to carry GIOP messages with version 1.2
    and lower.

    Proposed Solution: Allow GIOP 1.3 messages to be transported.

  • Reported: CORBA 2.3.1 — Fri, 7 Jan 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Section number: 6.2.2

  • Legacy Issue Number: 2604
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6.2.2

    Problem: sccp_version should be changed to SIOP_version. Also the word
    "agent" should be changed to "server."

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Missing definition on security tags in the SIOP

  • Legacy Issue Number: 3314
  • Status: open  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:

    There are security tags mentioned in the SIOP
    document but no definition of how to use them is ever given.

  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

There is currently no valuetype support in SIOP.

  • Legacy Issue Number: 3313
  • Status: open  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:
  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Use of PolicyType id

  • Legacy Issue Number: 3363
  • Status: open  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a
    curious thing in the Firewall RTF report. It seems that the RTF chose to re-use
    a PolicyType id for a new and different policy while obsoleting a published one.
    The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE
    associated with the structure BiDirPolicy::BidirectionalPolicy

    and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure
    BiDirPolicy::InvokeMode.

    This appears to me to be a dangerous practice, since the fact that the published
    standard may have been implemented by someone using the obsolete definition.

    I would like to suggest that the recommendation of the Firewall RTF be modified
    leaving the published policy type and policy as is with a note stating that it
    is obsolete, and a new policy type id be allocated for
    BIDIRECTIONAL_INVOKE_POLICY.

  • Reported: CORBA 2.3.1 — Fri, 25 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Lifecycle Key type definition

  • Legacy Issue Number: 18
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Several LifeCycle methods take a "key" argument, but do not clarify whether multiple NameComponents are allowed in a key, if ordering matters, etc.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Stream contexts and internalization

  • Legacy Issue Number: 19
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Externalization spec does not state how a stream implementation is to discover that a context exists when internalizing an object.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Start and end of context tags

  • Legacy Issue Number: 20
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The standard stream data format does not define tags to be used to identify the beginning and end of a context.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Definition of stream portability

  • Legacy Issue Number: 21
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The standard stream format should specify that it is portable across different ORBs and hardware, but not across streamable object implementations whch use different semantic content.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Multiple objects on a stream

  • Legacy Issue Number: 22
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What happens when multiple calls are made to Stream::externalize() at the top level? Does the stream contain all those objects, and how does a client discover this?

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Timeout while locking

  • Legacy Issue Number: 47
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If the ORB times out while LockSet::lock() is being called, how does the client know if the lock was granted or not?

  • Reported: CORBA 1.2 — Tue, 2 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Communication failure issue

  • Legacy Issue Number: 56
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If the ORB suffered a communication failure while LockSet::lock() is being called, how does the client know if the lock was granted or not?

  • Reported: CORBA 1.2 — Tue, 23 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Getting the thread ID in a non-transactional lock request

  • Legacy Issue Number: 57
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In a non-transactional lock request, the lock identity is supposedly based on thread ID. How can the server code get the client thread ID when they may be on different machines?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Freeing of locks at the end of a transaction

  • Legacy Issue Number: 58
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear whether CosTransactions::Coordinator is responsible for freeing locks at the end of a transaction.

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Coordinator remembering LockCoordinator

  • Legacy Issue Number: 59
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: CosTransactions Coordinator does not have any IDL method to remember LockCoordinator. How does it know what Lock Coordinators should be informed to drop locks?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Input values for "which" arg of non-trans. LockCoordinator

  • Legacy Issue Number: 60
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: For a non-transactional client who wants to get a LockCoordinator, what input values should one use for the "which argument?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Using local thread identification for concurrency

  • Legacy Issue Number: 61
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It seemed more useful for the concurrency service to be non-IDL, and just based on local thread identification.

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Common format on stream

  • Legacy Issue Number: 466
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When reading a stream, there is no way of telling where context (limited to calls to begin_context and end_context) end and a new one starts.. Resolved problem with new "tag-byte" 0xFF.

  • Reported: CORBA 1.2 — Thu, 19 Dec 1996 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosGraphs::deep

  • Legacy Issue Number: 469
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If CosGraphs::deep propagation value is encountered, is the Node"s related object supposed to get copied, too. What if LifeCycleObject delegates to CosCompoundLifeCycle::Operations?

  • Reported: CORBA 1.2 — Fri, 3 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

performing a compound copy of relationship

  • Legacy Issue Number: 470
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The second pass of operation is to "cause the node and all of its roles" to be copied. How do you get related object of the NEW roles to be the New Node?

  • Reported: CORBA 1.2 — Fri, 3 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosCompoundExternalization Service

  • Legacy Issue Number: 476
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When Node::externalize_node is called, is node responsible for externalizing related object? What happens, if related object isn"t a CosStream::Streamable?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosCompoundExternalization Service (2)

  • Legacy Issue Number: 477
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Role in new node are disconnected It"s role of read_graph to correctly establish new relationships. How is that accomplished?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosCompoundExternalization Service (3)

  • Legacy Issue Number: 478
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When internalizing a relationships, how do the "shallow" nodes and roles get included?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Internalizing roles-IDL optimization

  • Legacy Issue Number: 706
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation

  • Reported: CORBA 2.1 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Purpose of related LockSet

  • Legacy Issue Number: 576
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the specification, "Related lock sets" appears only in "create_related()" and create_transaction_related()" Where do I use these methods

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- membership scoping

  • Legacy Issue Number: 3
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I assume that we are allowed to scope membership in a collection via an interface test (e.g, must be rooted off of Collection) and throw an InvalidElement exception?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- Adding multiple elements

  • Legacy Issue Number: 4
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Using collection factories, can you add multiple elements at once, and/or add new create methods?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- finding index

  • Legacy Issue Number: 6
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: On CollectionObj->remove_element_at(IteratorRef), how does the collection "know" the index?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Query Collection::Collection -- Sharing State

  • Legacy Issue Number: 5
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How do IteratorObjs and CollectionObjs share state?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- Iterator Position Invalid

  • Legacy Issue Number: 7
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What does the IteratorPositionInvalid exception mean? Is it only that the user has cycled through the list elements and that no reset() has been issued?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- iterator updating

  • Legacy Issue Number: 8
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How does the Iterator know to become invalid when the Collection is altered?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- reset() exceptions

  • Legacy Issue Number: 10
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can an iterator "reset()" throw an exception such as IteratorPositionInvalid if it is wrapping a db cursor which has no facility for reset?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- destroy methods

  • Legacy Issue Number: 9
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Where are the destroy methods on the Iterator or on the Collection?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- next_n()

  • Legacy Issue Number: 11
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can an interator have a next_n()? Or is this supposed to be via subtyping the interface?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- keyed collections

  • Legacy Issue Number: 12
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Is it correct to offer the vanilla collection methods and add a new set for keyed access?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Questions on CosQuery::QueryableCollection interfaces

  • Legacy Issue Number: 13
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarifications on interfaces which support QueryableCollection.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Updating information via query iterators

  • Legacy Issue Number: 69
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When using iterator operations like adding, inserting, etc., how are changes reflected back to the datastores?

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Use of MD5 on arguments

  • Legacy Issue Number: 23
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Appendix D states that a challenge structure consists of the MD5 of the arguments, but does not specify how the arguments are laid into a stream of octets for the MD5 algorithm.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

How do iterators handle changing of the data they are pointing at

  • Legacy Issue Number: 78
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Is it not possible that objects in a collection could have changed in between calls to the iterator accessing them?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Clarification request for section 11.1.5

  • Legacy Issue Number: 79
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Several of the bullets in section 11.1.5 are unclear.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

retrieve_element

  • Legacy Issue Number: 81
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How does this operation work?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Definition of NULL in datafiles without NULL as a concept

  • Legacy Issue Number: 80
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 11.4.2 para. 3 says that FieldValues may be NULL. What if my datastore is a flat file without a concept of NULL. Does NULL take on the value of empty string for flat files?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Delegating iterator functionality to the RDBMS

  • Legacy Issue Number: 82
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Is there a way that I can delegate the functionality of the Iterators to the RDBMS itself?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Query language for operations

  • Legacy Issue Number: 83
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Need all operations on the Collection be made using the SQL-92/QOL-93? If so, how is it possible to handle flat file datastores?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

OQS relation to POS

  • Legacy Issue Number: 84
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Need the OQS have any interface with the POS? I don"t see how the two can be interfaced.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Malformed PropertyName

  • Legacy Issue Number: 284
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help

  • Reported: CORBA 1.2 — Sat, 19 Oct 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

WWW Form output

  • Legacy Issue Number: 535
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue regarding implementation of the Query IDL specifications on a Java ORB. Issue involves implementing following idl definition from the CosQueryCollection module

  • Reported: CORBA 1.2 — Thu, 6 Mar 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Compiler being able to translate from OMG-IDL into ANSI

  • Legacy Issue Number: 184
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Existing software based on messages with ASNI format description and a future version based on IDL. Does anybody know something about such a compiler?

  • Reported: CORBA 1.2 — Mon, 14 Oct 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

The CMM document component-formal-21-02-04 shall be removed from CORBA 3.4 to become a standalone CMM specification.

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The component-formal-21-02-04 for CORBA 3.4 part 3 will be moved to its own separate specification.

  • Reported: CORBA 3.4 — Thu, 28 Mar 2024 17:17 GMT
  • Updated: Thu, 28 Mar 2024 17:18 GMT

Add CDR marshaling support for new IDL4 types (e.g. maps, bitset, bitmask)

  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    IDL4 extends the IDL type system with int8/uint8/map/bitset/bitfield/bitmask, these all could be useful at the CORBA layer so to have guaranteed interoperability CORBA should define the CDR marshaling support for these new types

  • Reported: CORBA 3.3 — Tue, 13 Oct 2020 08:20 GMT
  • Updated: Thu, 28 Mar 2024 17:11 GMT

Section 4.1.18.5 enum should be named CORBA_CompletionStatus

  • Legacy Issue Number: 681
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:45 GMT

Add CORBATCKind to end of enum list

  • Legacy Issue Number: 687
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Enum CORBATCKind omits the boolean kind (p.4-123, section 4.1.12) I recommend adding it to the end of list to preserve backward compatibility. Also missing tk_char.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:44 GMT

Section 5.5 Interface repository (02)

  • Legacy Issue Number: 1065
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
    inherited from Contained. A different name should be used, something like
    "value_member_name"

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:43 GMT

Clarify the hash code algorithm

  • Legacy Issue Number: 1262
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarify the hash code algorithm

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:43 GMT

Section 5.6.2 Repository Id

  • Legacy Issue Number: 1263
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear whether the #pragma prefix is still part
    of the repository Id. I think it should be.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:43 GMT

Repository Id (02)

  • Legacy Issue Number: 1264
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Why is the 64 bit hash code at the end of the string and
    not at the beginning ? This can speed up the comparison
    when two repository Ids are different.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:42 GMT

Repository Id (03)

  • Legacy Issue Number: 1265
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
    policy?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:42 GMT

Section 5.6.3 Hashing Algorythm

  • Legacy Issue Number: 1266
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)

    • It is not clear whether the hash value is translated
      into ascii or not.
    • I assume the result is a long long:

    long long hash = sha[1] << 32 + sha[0]

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:41 GMT

Semantics of computing the hash code..

  • Legacy Issue Number: 1267
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:41 GMT

Concrete value class

  • Legacy Issue Number: 1268
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I have an important issue concerning the C++ mapping and the fact
    that application developers need to define/implement the concrete
    value class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:41 GMT

Java mapping example and C++ mapping example

  • Legacy Issue Number: 1272
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the
    generated C++ class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:39 GMT

Why is ValueBase a value and not a native type?

  • Legacy Issue Number: 1274
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What is the rationale for making ValueBase a value and not a native type?
    It seems strange to me that a ValueBase "value" maps to java.io.serializable
    in Java. Isn"t that what native was invented for?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:39 GMT

Editorial page 8-107

  • Legacy Issue Number: 1277
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
    value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:39 GMT

Can public modifier be applied to value operations?

  • Legacy Issue Number: 1284
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Can the "public" modifier be applied to value operations? What is the default?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:38 GMT

No typecodes for abstract interfaces

  • Legacy Issue Number: 1719
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are no typecodes for abstract interfaces. Does this mean
    that abstract interfaces cannot be members of structs, unions,
    or values? If so, I think this is a problem and we should add
    typecodes for abstract interfaces.

  • Reported: CORBA 2.2 — Wed, 22 Jul 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:38 GMT

How can we bound the range of invoke ids in the IDL?

  • Legacy Issue Number: 2589
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: How can we bound the range of invoke ids in the IDL? Q773 requires
    invoke ids in the range -128 to 127. ROS has no limits.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:35 GMT

Problem: Why is AssociationId a string?

  • Legacy Issue Number: 2592
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: Why is AssociationId a string? Should one explore the possibility of
    using a combination of values supplied by both the initator and responder.
    Strings do not seem to be the most scalable solution.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:34 GMT

The current text for DialogFlowCtr is for outgoing only

  • Legacy Issue Number: 2593
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: The current text for DialogFlowCtr is for outgoing only. It should be
    updated to reflect incoming messages from the legacy domain.

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:34 GMT

There is a difference between the responder and initiator interfaces

  • Legacy Issue Number: 2594
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.2

    Problem: There is a difference between the responder and initiator interfaces
    because the initator cannot support the new association operations.

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:33 GMT

Section 4.3.2.1 Title and text should be changed

  • Legacy Issue Number: 2595
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.3.1.2

    Problem: Title and text should be changed to reflect that it is dealing with creating
    an association rather than initiating a dialog.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:33 GMT

Section 4.7.1: RelativeRoundTripPolicy

  • Legacy Issue Number: 2596
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.7.1

    Problem: Is it necessary to indicate that RelativeRoundTripPolicy is not
    propogated to the server? Also does TC interworking require the support of the
    priority policies?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:32 GMT

Section number: 5.2 and other sub-sections

  • Legacy Issue Number: 2598
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.2 and other sub-sections

    Problem: The encapsulation BerData could potentially hold ASN.1 encoded via
    other rules like PER. So is this name misleading, or too restrictive?

    Proposed solution: One choice is EncodedData.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:32 GMT

Section number: 5.4.1

  • Legacy Issue Number: 2599
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.4.1

    Problem: DialogPortion should be a union rather than a struct. The complete IDL
    is correct.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:32 GMT

Shouldn't it be typedef string CORBA::ScopedName?

  • Legacy Issue Number: 2600
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 7.1, page 108

    Problem: Shouldn’t it be typedef string CORBA::ScopedName?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:31 GMT

Section number: Fig. 27

  • Legacy Issue Number: 2601
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: Fig. 27

    Problem: Shouldn’t GwTcPduHandler be replaced by GwTcPduProvider?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:31 GMT

Problem: There is no way to send dialogue data in a continue confirm.

  • Legacy Issue Number: 2605
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.4.4

    Problem: There is no way to send dialogue data in a continue confirm.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:30 GMT

Section number: 5

  • Legacy Issue Number: 2606
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5

    Problem: There is no way to associate more than one instance of a TcPduUser
    with a GT/AC pair for incoming SS7 messages.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:29 GMT

new_callback

  • Legacy Issue Number: 2651
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16,
    the first paragraph reads

    When the client side object adapter creates the object reference for the
    callback object, it may invoke the
    new_callback operation on the outermost inbound GIOP Proxy on the server
    side and pass the callback object as the argument.

    Say, there are no client-side firewalls and there is only one
    server-side GIOPproxy firewall.

    1. how does the object adapter or the client orb get access to the IOR
    of the GIOPProxy object ???
    2. how does the object adpater know that the object that is being
    created/instantiated will be used as a callback
    object ??

    Does POA provide any m

  • Reported: CORBA 2.3 — Thu, 13 May 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:29 GMT

How to obtain initial reference to the GIOPProxy object

  • Legacy Issue Number: 2864
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    The specification does not outline a specific method by
    which to obtain the initial reference to the GIOPProxy object. We believe
    that an interoperable solution for obtaining this initial reference is
    needed in order to insure that all implementations will be able to be
    correctly configured to contact all other implementations.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:28 GMT

Proxified object references

  • Legacy Issue Number: 2865
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Proxified object references obtained by invoking
    new_target() should not be passed between ORBs. Instead the original IOR
    containing the target and firewall information should be passed. The reason
    for this is that the IOR does not contain enough information to inform the
    second ORB whether or not it is a reference for a NORMAL or PASSTHRU
    connection, or whether it is a proxified reference at all. This issue is
    very tightly related to issue 2, so we will describe how it fails for each
    of the possible solutions to the PASSTHRU establishment problem outlined in
    issue 2.
    One solution for which this is not an issue is the solution
    of using a port per target. However, this is not a viable solution because
    it is restrictive and will fail under moderate load. For solution 1 we
    don"t have a problem because no object reference is returned by
    set_target(), therefore it cannot be passed to other ORBs. For solution 2
    we have a problem because the second ORB won"t know whether it is supposed
    to first invoke start_passthru() or simply start making requests. Therefore
    it may get a connection type that it wasn"t expecting. For solution 3 we
    have a problem because once the original connection has been made, the
    reference is invalid. This occurs because the firewall does not have
    knowledge of how many clients are expected to try to connect to that target,
    and it may attempt to claim that port for reuse before another client has
    connected.

    Proposed Solution:
    The passing of object references obtained by invoking
    new_target() should be expressly prohibited by the specification. One
    example is, "The object reference returned by new_target() may not be passed
    to another client. Instead the original reference that was passed as the
    argument to new_target() must be passed to the second client, and the second
    client will follow the rules of the traversal algorithm to reach the desired
    target."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:28 GMT

Reusing PASSTHRU

  • Legacy Issue Number: 2866
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    Reusing PASSTHRU connections by the firewall should be
    expressly disallowed by the specification. With the current wording of the
    specification, a vendor may attempt to reuse PASSTHRU connections. While
    this will work in some cases, it is not interoperable because there are
    cases when reusing PASSTHRU connections will not work. For example,
    connection reuse when SSL is in use will not work because all of the
    information that distinguishes data streams is contained within the
    encrypted portion of SSL packets. If two SSL connections try to share a
    single connection, there will be an SSL protocol failure because the server
    will not be able to separate the data streams before it processes the SSL
    packet.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:27 GMT

Clarification is needed on the passing of credentials

  • Legacy Issue Number: 2867
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    Clarification is needed on the passing of credentials.
    Section 4.7.3 states that "Since all proxies will have access to the IOR of
    the target object, and the certificate of the client, they can judge whether
    this client may use a pass-through connection or not." Section 4.12 states
    that "When a client establishes a normal connection to a target via a
    trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to
    achieve end-to-end authentication, the proxy will have to forward the
    client"s certificate/identity to the server." Section 4.12 implies that the
    ForwardedIdentity service context will only be used when using a secure
    transport, but section 4.7.3 implies that the client certificate will always
    be available. In fact, the ForwardedIdentity service context should only be
    used in the case of a NORMAL connection using a secure transport because
    those are the only conditions under which there is a notion of trust between
    a requestor and the recipient of that request. This means that the only
    mechanism upon which to base a decision of whether or not to allow a
    PASSTHRU connection is the source host address/port.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:26 GMT

Problems with routing and/or traversal of firewalls.

  • Legacy Issue Number: 2868
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issues 7-9 refer to problems with routing and/or traversal of firewalls.
    These problems arise due to a lack of required information about firewall
    topology in the IOR. Most of these problems could be eliminated if it were
    required that the servers place the entire chain of server-side firewalls
    that must be traversed into the IOR. Specifically, the first paragraph in
    section 4.8 should be modified so that the entire chain of firewalls is
    always required, or those situations in which it should be required should
    be stated. Some of those situations are outlined in the following issues.
    Specifically, it is incorrect to state that "strictly it is only necessary
    to convey information on the outermost inbound firewall."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:25 GMT

Use of InvokeId as the type name for both invoke id and link id.

  • Legacy Issue Number: 2915
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The idl is

    struct TcLinkedContext

    { DialogFlowCtr ctr; InvokeId ivk_id; InvokeId lnk_id; AssociationId a_id; }

    ;

    While it is correct that these are both of the same type, the name of the type
    could be confusing.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:24 GMT

Why one to one association between a TcPduUser and TcPduProvider interface?

  • Legacy Issue Number: 2917
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    There is an assumption in the design that there is a one to one
    association between a TcPduUser and a TcPduProvider
    during a TC Session. This is enforced in the IDL through the
    call

    TcPduProvider::get_dialog_id()

    and the factory call

    TcPduProvider create_tc_pdu_provider(
    in TcPduUser user,
    out DialogId d_id)
    raises(NoMoreDialogs);

    Since the TcPduUser reference (or some sort of reference)
    is not passed over in get_dialog_id(), the only conclusion
    is that the reference has to be the one passed over in the
    create, and therefore that each TcPduProvider is tied to
    one and only one TcPduUser.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:24 GMT

Specification Translation from ASN to IDL issue

  • Legacy Issue Number: 2918
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The Specification Translation from ASN to IDL does not appear to
    require that each OPERATION carries a NoMoreAssociations exception.

    This is necessary if the use of DialogFlowCtr can implicitly create a new
    association during a call on an object that supports multiple associations.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:23 GMT

TcPdu User and Provider interfaces

  • Legacy Issue Number: 2919
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    As the interfaces currently stand, there is a minimum of 5 CORBA calls
    per transaction
    1. either TcPduProvider::get_dialog_id
    or TcPduProviderFactory::create_tc_pdu_provider
    2. TcPduProvider::invoke_req
    3. TcPduProvider::begin_req
    4. TcPduUser::end_ind
    5. TcPduUser::result_l_ind

    Given that a CORBA call is about 1 millisecond on average,
    this makes for a highly inefficient interface from a high-performance
    perspective,
    and renders the distribution of these interfaces undesirable, and the
    use of the TcPduProvider/User interfaces unlikely in a real system.

    Ideally this should be reduced to a minimum of 2 CORBA calls, one for a call
    going out, and one for the reply.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:23 GMT

use of the SSN number in the 1988 TCAP version

  • Legacy Issue Number: 2982
  • Status: open  
  • Source: Anonymous
  • Summary:

    As far as I can see when using the 1988 TCAP version the submission
    does not seems to handle the case where the subsystem number (SSN) is
    used to seperate between several TC-User protcols per GT (typically
    protocols from different vendors). The naming tree proposed for the
    1988 TCAP protocol can only store one TC-User protocol per GT, that is
    only one DefAc per GT can be stored (see section 4.3.1.1 in the
    proposal).

    The use of the SSN number for this purpose is explained in chapter
    4.2.3 in the second paragraph in the ITU Recommendation Q.775.

    It should be easy to fix this as one only have to use the same naming
    tree structure proposed for the 1993 TCAP version in these cases.

  • Reported: CORBA 2.3.1 — Mon, 8 Nov 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:21 GMT

Issue: CSIv2 Identity Assertion

  • Legacy Issue Number: 3907
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Issue on Document orbos/2000-08-04, CSIv2 Joint Submission

    Document: orbos/2000-08-04, CSIv2 Joint Submission
    Subject: Identity Assertion of X.501 Distinguished Name is not good enough
    Severity: Critical

    Summary:

    The Identity Token union contains a branch that is labled
    X501DistinguishedName. A single DN is insufficient to identify an entity.
    A path of X501Distinguished Names is needed instead. Also, other concerns
    about naming types are raised.

    Discussion:

    An X.501 Distinguished Name is insufficient to identify a single entity.
    The name must be accompanied by the name of its defining authority. In the
    case of public key certificates, the names certificate authority must be
    included.

    The chain of DNs in this manner must be included up to a root authority
    to have any definitive meaning.

    This approach will be consistent with the client sending a X.509
    Certificate Chain. A DN path is actually defined by the certificate chain.

    Furthermore, the DN path should only come from an authority that is
    acceptable to the server, whether it be a DN path, or an X.509
    Certificate Chain.

    The IOR should list the acceptable authorities and their name types.

    It is becoming more an more evident that we must invent GSS_NT_Export_Name
    types for X.509 Certificate Chain and X.501 DN path.

    The SAS_ContextSec structure should list, instead of the naming types,
    the naming authorities!

    We shall assume that the name types of the asserted identities shall be
    the same as the name types of listed naming authorities in the IOR.

    This is the only way this procedure can work Interoperable and without
    the client Guessing what it should do.

    Suggestions:

    An OID for an X.509 Public Key Certificate Chain shall be defined for a
    GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
    certificate with the least significant certificate first.

    An OID for an X.501 Distinguished Name Path shall be defined for a GSS
    Exported Name, and its encoding shall be an ASN1 sequence of an X.501
    Distinguished Name with the least significant name first.

    To avoid having the target put a whole certificate chain in its IOR,
    a new OID shall be allocated in which its GSS Exported Name encoding is a
    X.501 DN path, but stipulates that the client should send a certificate
    chain from that named authority. This GSS Exported Name shall only be
    used in IORs and not for transmission in the Identity Token.

    typedef Security::GSS_NT_ExportedName NamingAuthority;

    struct CompoundSecMech

    { Security::AssociationOptions target_requires; IOP::TaggedComponent transport_mech; sequence<ServiceConfiguration> privilege_authorities; sequence<NamingAuthority> naming_authorities; }

    ;

  • Reported: CORBA 2.3.1 — Wed, 20 Sep 2000 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:20 GMT

ObjectCreationError and Nofactory exceptions in Externilazition

  • Legacy Issue Number: 1293
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a bit of confusion in the specification concerning the
    exceptions that are possible during the internalization process.

    The internalize operation can raise CosLifeCycle::NoFactory and
    StreamDataFormatError exceptions. This operation calls the
    internalize_from_stream operation of the Streamable interface that can
    raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
    ObjectCreationError exceptions.The last paragraph on page 8-20 (August
    1997 release) states that the ObjectCreationError and
    StreamDataFormatError exceptions of the internalize_from_stream
    operation originate from the read_object amd read_<type> operations on
    the StreamIO interface. However, the ObjectCreationError is not raised
    by any of these, according to the IDL in figure 8-6.

  • Reported: CORBA 2.2 — Thu, 30 Apr 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:18 GMT

Which model should ConcurrencyControl support?

  • Legacy Issue Number: 577
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is inconsistency regarding which model ConcurrencyControl needs to support

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:17 GMT

Section number: 4.2.1

  • Legacy Issue Number: 2591
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog.
    The invoke id can be reused as soon as it is no longer active.

    Proposed solution: Put in text following the discussion of management of invoke
    ids in the TC spec.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:13 GMT

new_target

  • Legacy Issue Number: 2648
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.7.4 - description of new_target operation.

    The first para states:

    "The new_target operation informs the firewall that it should prepare itself
    to
    receive requests destined for the specified target. The object returned
    from this
    operation is the destination on the firewall to which a request on the
    target should be
    sent i.e. the object_key in the return object should be used in the GIOP
    request header."

    and the last para says:

    "The object returned by the new_target operation must contain an object key
    which
    allows the proxy to uniquely identify the target. A client is not required
    to open a new
    connection to the proxy server, even when the target object(s) are located
    in different
    servers."

    The last sentence implies that the IOR returned from the new_target has the
    same host/port number as the GIOPProxy. This may not be true. For example if
    a firewall is load balancing across ports and network interfaces, the
    host/ports may be differnt, and in this situation a new connection is
    required.

  • Reported: CORBA 2.3 — Mon, 10 May 1999 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:06 GMT

Section number: 2.3

  • Legacy Issue Number: 2607
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: Use UML to express relationship of interfaces.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:05 GMT

CosConsurrencyControl service bug or not?

  • Legacy Issue Number: 3522
  • Status: open  
  • Source: Anonymous
  • Summary:

    I develop CosConcurrencyControl service for JacORB, but I don't
    understud from specification how client can destroy LockSet.
    When I create Object which allow concurrency access, I create LockSet.
    When I destroy this Object I must destroy LockSet, because it's garbage,
    bu no way for this does not exists.

    As solution of this problem, I add in CosConcurrencyControl.idl next
    changes:
    exception LockExists{};

    and method
    void destroy raises (LockExists);

    in interface LockSet.

    As I undestand this changes is wrong, but have you idea about desigion
    this problem.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Updated: Wed, 20 Mar 2024 19:03 GMT

Circular References in CosStream and CosCompoundExternalization

  • Legacy Issue Number: 1401
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Circular refrences to CosStream and CosCompoundExternalization,
    i have not been able to find an idl compiler that can compile
    these modules.

    as aside, i have foud many syntax errors in the IDL you provide
    as CORBAServices98-03-02.idl, in many of its interfaces, there are
    typos, and it is not correct with the specifications.

  • Reported: CORBA 2.2 — Mon, 1 Jun 1998 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:02 GMT

Who is responsible for releasing locks in transaction?

  • Legacy Issue Number: 578
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In lock duration of Section 7.1 there are two descriptions. The role of the clients is vague to me

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Wed, 20 Mar 2024 19:01 GMT

TypedConsumerAdmin interface (4.9.2))

  • Legacy Issue Number: 961
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: in section 4.9.2 last paragraph:

    "Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
    interface I. Any event on the channel that does not correspond to an
    operation defined in interface I is NOT passed on to the consumer. Such a
    ProxyPushSupplier is therefore an event filter based on type".

    My question is: if we have this proxy to block generic calls (push() in this
    case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
    support push() ? Why should the generic calls like push() be blocked anyway
    if (according to 4.7.1) TypedPushConsumer should support both typed and generic
    models ?

    Is there something I am misunderstanding ?

  • Reported: CORBA 2.2 — Thu, 5 Feb 1998 05:00 GMT
  • Updated: Mon, 4 Mar 2024 20:27 GMT

Duplicate union labels

  • Key: CORBA35-4
  • Legacy Issue Number: 704
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: When multiple union labels resolve to the same union member, the property accessor for that union member has an additional (optional) argument

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Mon, 4 Mar 2024 20:19 GMT

Changes to ForeignComplexType

  • Key: CORBA35-5
  • Legacy Issue Number: 701
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: The following methods should be added to DIForeignComplexType, IID should be changed: string type_name(); string scoped_name(); string_repository_id(); more details in corresponding archive file

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Mon, 4 Mar 2024 20:17 GMT

Section 13A.5.2: Editorial

  • Key: CORBA35-6
  • Legacy Issue Number: 708
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Third bullet should read:"...are sorted based upon interface name.." Last bullet should read "..the operations introduced in the current interface are mapped last and ordered.."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Mon, 4 Mar 2024 20:16 GMT

Section 13A.2.3: editorial

  • Key: CORBA35-7
  • Legacy Issue Number: 707
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Example of "on both machines" does nor correspond to the diagrams. Add "on an intermediate machine" to sentence

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Mon, 4 Mar 2024 20:05 GMT

Capter 13C: Editorial

  • Key: CORBA35-8
  • Legacy Issue Number: 709
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: There are a bunch of code samples that use a different font than the rest of the document

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Mon, 4 Mar 2024 20:04 GMT

Incorrect mappings for systems exceptions (part A)

  • Key: CORBA35-9
  • Legacy Issue Number: 679
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Section 4.1.18.6 Table 4-14: A few of these mappings don"t seem to make sense (i.e. the meaning of the different exceptions in each object system is much different

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Mon, 4 Mar 2024 20:03 GMT

Polymorphic Valuetypes and the DII

  • Legacy Issue Number: 3674
  • Status: open  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Using the static invocation interfaces, it is possible to receive a
    valuetype that derives from the one declared in an operation, as long
    as a valuetype factory is known in the receiver (truncation is not the
    issue here).

    The same is not possible at the DII: When creating the request, the
    caller must indicate what type it expects, by forming a named value.
    Conceptually, the typecode in the named value should be the typecode
    of the base of all acceptable value types. However, if the ORB
    receives a derived type, it has no means of unmarshalling it - even if
    the application has knowledge about the derived type.

    What is missing is an interface to make typecodes of value types known
    to the ORB; with those, the ORB could then understand the CDR of the
    valuetype, and create a DynAny when asked to.

  • Reported: CORBA 2.3.1 — Wed, 7 Jun 2000 04:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

DynValue & custom valuetypes

  • Legacy Issue Number: 3459
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 specification does not cover the interaction between the
    DynValue interface and custom valuetypes.

    I frankly don't see any way that the DynValue interface can possibly
    correctly handle a custom valuetype when the ORB does not have a factory
    for the type. It is theoretically possible for DynValue to properly
    work with a known custom type, but the implementation strategy could not
    be based on parsing the marshalled form of the valuetype.

    So, there are two issues that need to be addressed:

    1. Should DynValue handle custom valuetypes at all?

    2. For the set of custom valuetypes that it cannot handle, what
    exceptions should be raised by each operations?

  • Reported: CORBA 2.3.1 — Sat, 25 Mar 2000 05:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

Custom Value Marshaling Issue

  • Legacy Issue Number: 3097
  • Status: open  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    Due to the way that custom values are marshaled it is
    nearly impossible for a bridge (or other process) to
    process/forward GIOP messages which contain custom
    marshaled values (which the bridge has no compile/run-time
    knowledge of).

    The main issue is that the "alignment" of the
    custom marshaled data is unknown, other than the
    data will always start on a four byte boundry due
    to the presence of chunking.

    Should/could the value encoding format be changed to
    enforce eight byte alignment for all custom marshaled
    data (chunks)? This would allow bridges and other
    tools to process->[store]->forward messages containing
    custom values.

  • Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

Potential deadlock with POA::deactivate_object()

  • Legacy Issue Number: 2772
  • Status: open  
  • Source: Anonymous
  • Summary:

    The draft CORBA 2.3 spec (ptc/99-03-07) does not deal with a potential deadlock situation. If an object is explicitly deactivated with POA::deactivate_object(), the object remains in the active object map until all operations pending on the object have completed. Any attempts to reactivate the object (implicitly via a ServantActivator, or explicitly via activate_object_with_id()) must block until the pending invocations have completed. However, if a servant's implementation of an object deactivates the object and then (directly or indirectly through a call to another collocated object) reactivates the object, the invocation will deadlock.

  • Reported: CORBA 2.3 — Mon, 28 Jun 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

interface QueryEvaluator {

  • Legacy Issue Number: 575
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I understand the params to be name value pairs of columns and the values for the
    selection, update, delete, insert criteria
    what is in the query? I would think if this is the whole query why would you
    need the params??

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Mon, 4 Mar 2024 19:52 GMT

BiDir GIOP Policy Clarification

  • Legacy Issue Number: 4115
  • Status: open  
  • Source: Network Associates ( Brian Niebuhr)
  • Summary:

    I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
    specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
    section 15.8 paragraph 5 on page 15-55, the specification states:

    "If the client ORB policy permits bi-directional use
    of a connection, a Request message should contain an IOP::ServiceContext
    structure in its Request header, which indicates that this GIOP connection
    is bi-directional."

    but then in section 15.9 paragraph 4 on page 15-59, the specification
    states:

    "In the absence of a BidirectionalPolicy being passed in the
    PortableServer::POA::create_POA operation, a POA will assume a policy value
    of
    NORMAL."

    but then again in the next sentence the specification states:

    "A client and a server ORB must each have a BidirectionalPolicy with a value
    of
    BOTH for bi-directional communication to take place."

    Could someone clarify for me what the intent for the scope of the policy was
    here, and what the rationale behind that decision was? We are currently
    reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
    and I would like to understand the issues regarding the scope of the BiDir
    policy.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Updated: Mon, 4 Mar 2024 19:16 GMT

When does a multiassociation TcUse know that it has been finished with?

  • Legacy Issue Number: 2916
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The creation of a TcUser interface with multiple associations does not have
    a standardised way for destruction.

    Proposed solutions

    1. Add a destroy() method to TcUser
    2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
    be called once the object is no longer required.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 19:06 GMT

Firewall Traversal algorithm

  • Legacy Issue Number: 2641
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The description of firewall traversal in orbos/98-07-03 4.11 has some
    significant unstated assumptions, and prescribes an algorithm that has
    several flaws.

    In orbos/98-07-03 4.11 it says: "A client will determine if it needs
    to go through a firewall to make a request on the target object. If
    the client is in the same domain a direct invocation can be made. The
    client can determine this be examining the host address information in
    the target IOR." This assumes that the enclave structure maps to host
    addresses in some way known to all clients. This needs to be made more
    explicit.

  • Reported: CORBA 2.3 — Fri, 7 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:57 GMT

Firewall POA Policy does not control access

  • Legacy Issue Number: 2639
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to provide a
    portable means by which the object implementor can decide whether an
    object could be accessible through a firewall. The following POA
    policy is defined for this purpose:" but this policy can at most
    control what components are included in references created by the
    POA. Since the references do not have any mechanism to defend against
    forgery, exclusion of a FirewallMechanism component does not prevent
    access through a firewall. If an attacker obtains some other reference
    with the FirewallMechanism component(s), it can convert a reference
    created under NO_EXPORT into the reference that would have been
    created under EXPORT.

    The description of the policy needs to be changed to make it clear
    that the policy does not imply any access control enforcement. The
    ability of an attacker to forge references, either by combining parts
    of other references, or otherwise, should be explicitly stated as a
    security issue that must be addressed by means outside this
    specification.

  • Reported: CORBA 2.3 — Thu, 6 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:54 GMT

Outgoing local port in Bi-directional IIOP

  • Legacy Issue Number: 2638
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for
    traditional-style callbacks using a listening socket, then the port entry
    in its IOR must be set to the outgoing connection"s local port (as
    retrieved using the getsockname() sockets API call)". At IOR creation time
    there may be no connection, or there may be many, so the mandated local
    port may be non-existent or ambiguous.

    This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but
    was not raised as an issue.

  • Reported: CORBA 2.3 — Thu, 6 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:54 GMT

Bi-Directional GIOP: Masquerade security issue needs to be more explicit

  • Legacy Issue Number: 2634
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The remark about masquerade at the end of ptc/98-10-11 15.8 is not
    explicit enough. This is an important security issue and it needs to
    be made explicit that a malicious client may claim that its connection
    is Bi-Directional for use with any host and port it chooses, in particular
    it may specifiy the host and port of security sensitive objects.

    In general, a server that has accepted an incoming connection has no
    way to discover the identity or verify the integrity of the client
    that initiated the connection.

  • Reported: CORBA 2.3 — Wed, 5 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:54 GMT

Bi-Directional GIOP: which connections may be used?

  • Legacy Issue Number: 2633
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-10-11 15.8 from the end of the fourth paragraph "any
    requests from the server on an objects exported by the client to the
    server via this connection will be sent back to the client on this
    same connection." to the eleventh paragraph "If the client initiates a
    new connection it is not foreseen here that the server can use that
    connection for requests on the object exported previously." it seems
    to be implied that a reference must be passed via a connection if that
    connection is to be used to invoke the referenced object with
    Bi-Directional GIOP.

  • Reported: CORBA 2.3 — Wed, 5 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:53 GMT

Issue for Firewall RTF - HTTP tunnelling.

  • Legacy Issue Number: 2455
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The submission makes no mention of HTTP tunnelling. There are many
    firewalls which filter HTTP, FTP and email related traffic. Is the
    omission based on the assumption that such firewalls will comprise
    a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
    directional GIOP specification suggests not (section 5-1,
    paragraph 2).

    Is tunnelling regarded as an implementation matter? If so there
    will be important issues such as relaxing GIOP/HTTP mapping and
    security which the specification should clarify.

  • Reported: CORBA 2.2 — Wed, 17 Feb 1999 05:00 GMT
  • Updated: Mon, 4 Mar 2024 18:06 GMT

issue with TCPfirewallMechanism

  • Legacy Issue Number: 2304
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The issue comes from the following configuration:

    Client - Tcp Firewall - Giop Proxy Server - Server

    The server"s IOR will contains a FirewallComponent, which includes two
    FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
    comes when the GIOP Proxy has multiple profiles, which may have different
    host/port, and the TcpFirewallMechanism can only have one host/port. Does
    that mean for any host/port specified in one of the GIOP Proxy "s profiles,
    you always to connect to the host/port specified in the
    TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
    provide a one-to-one mapping.

  • Reported: CORBA 2.2 — Wed, 13 Jan 1999 05:00 GMT
  • Updated: Mon, 4 Mar 2024 18:05 GMT

Minimum CORBA and POA

  • Legacy Issue Number: 2676
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Minimum CORBA submission describes exactly what should
    be present in minimum CORBA (basically CORBA 2.2 including
    the POA) in IDL/PIDL.

    However, the Java language mapping in CORBA 2.2
    does not include the POA -> just the APIs for registering
    transient objects.

    One cannot even take recourse to CORBA 2.3 to get the
    language mapping, since much stuff (OBV, Java to IDL etc.)
    was added in the intervening time. There does not seem to be
    any existing document which documents a Java language mapping
    of CORBA 2.2 including POA without lots of other stuff.

  • Reported: CORBA 2.3 — Mon, 31 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:03 GMT

ValueHelper Interface issue

  • Legacy Issue Number: 1934
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
    inconsistent with current OBV terminology.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:02 GMT

Status of hashed repository IDs

  • Legacy Issue Number: 1817
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec orbos/98-01-18 introduces a new repository ID
    mechanism. It says in 5.6.2.1

    >> We don"t recommand the classic id format "IDL:" <scoped name> ":"
    >> <major> "." <minor> because it is not "foolproof" enough. (It is of
    >> course allowable to use this format, since the CORE specification
    >> does not mandate any particular form.)

    The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33
    specifies

    >> A definition is globally identified by an OMG IDL - format
    >> RepositoryId if no ID pragma is encountered for it.

    The issue is whether the OBV specification changes this default for
    values or not

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:01 GMT

TypeCode complexity for value types

  • Legacy Issue Number: 1726
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
    potentially recursive constructed type that involves ValueMembers.
    The "tk_value" TypeCode defines the entire complexity of the types
    within the Value.

    It is our understanding that when the ORB code that handles "Anys" for
    C++ detects a tk_value TypeCode and needs to encode/decode the associated
    Value object – (e.g., for Any::replace(TypeCode, void *) – it will
    need to invoke a method on that object that understands the object
    instance data and the associated state information. Further
    examination of the TypeCode complexity will not be necessary by the
    Any implementation, since this code would not have knowledge of or
    ability to set the state information within the Value object itself.

    The reason why the layout of the state information within a value
    cannot be known by external code is that virtual inheritance of
    abstract values and/or abstract interfaces makes it impossible to
    calculate the offsets of the data members in a compiler
    independent manner.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:00 GMT

Marshaling engine issue

  • Legacy Issue Number: 1353
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Using the IDL defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as its formal parameter. Now suppose we wish to pass a Derived value type. When marshaling the list of repository ids, the marshaling engine has no notion of the formal type of the parameter, thus it does not know how many safe repository ids it needs to marshal.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 17:57 GMT

Issue for Firewall RTF - Chapter 5 needs clarification

  • Legacy Issue Number: 2240
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after
    numerous readings and a discussion with an author. I believe the chapter
    contains all the pertinent information; it just has to be a bit more
    carefully presented.

  • Reported: CORBA 2.2 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 12 Jan 2024 21:37 GMT

The values of these tags need to be assigned

  • Legacy Issue Number: 1996
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The firewall spec defines a number of tag values from OMG managed spaces.
    The values of these tags need to be assigned.

  • Reported: CORBA 2.2 — Thu, 24 Sep 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:37 GMT

OBV init

  • Legacy Issue Number: 1816
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec introduces the concept of initializers, which maps
    cleanly only to languages that support overloaded constructors.

    Other languages, such as C, would typically offer functions to provide
    inialization of values. Since initializers are not named, an intuitive
    mapping is hard to find.

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:35 GMT

CodeBase interface uses undefined type

  • Legacy Issue Number: 1771
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The definition for interface CodeBase in module SendingContext
    has a method
    CORBA::InterfaceRepository get_ir();

    There is no type CORBA::InterfaceRepository. I believe this was
    intended to say
    CORBA::Repository get_ir();

  • Reported: CORBA 2.2 — Tue, 4 Aug 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:34 GMT

Memory Management for Value Factories Unspecified

  • Legacy Issue Number: 1748
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are no rules governing how to free value factories in C++.
    Specifically, the ORB does not know what to do with the value factory at
    shutdown, and applications do not know what to do with the factory
    returned by register_value_factory. Directly deleting the factories may
    be hazardous (e.g. if they are shared across multiple valuetypes or even
    multiple ORBs), and leaving them around may introduce memory leaks.

  • Reported: CORBA 2.2 — Tue, 28 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:33 GMT

OBV TypeCode parameters wrong

  • Legacy Issue Number: 1676
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both
    tk_value and tk_value_box start with a string which is the type"s
    repository ID. Why? For everything except tk_interface, the repository ID
    is not visible as a parameter. I believe these parameter lists should not
    include repository IDs to make them consistent with the others.

    I assume that the

    {member_name, TypeCode}

    pairs in the tk_value parameter
    list should appear in the order of declaration of the members in the
    valuetype. This is not stated anywhere.

    The visibility of each member should be added to the tk_value parameter
    list. Each entry in the list should contain

    {member_name, TypeCode, short}

    where the short refers to the Visibility of the member.

    The parameter list for tk_value should probably have an additional
    parameter which is the TypeCode of the concrete valuetype base, if any.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

C++ boxed value member clashes

  • Legacy Issue Number: 1674
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: For boxed values that are structs, unions, or other constructed types with
    member accessor and modifier functions, their member functions such as
    value(), boxed_in(), boxed_inout(), etc. may potentially clash with the
    names of those accessor and modifier functions.

    Solution: make the names of such special member functions start with an
    underscore, e.g., _value(), _boxed_in().

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Custom marshalling support for IDL fixed type

  • Legacy Issue Number: 1673
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The custom marshalling streams CDRInputStream and CDROutputStream
    don"t support the IDL fixed type. I propose adding the following
    type definition and methods:

    typedef sequence<fixed> FixedSeq;

    abstract value CDROutputStream

    { ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

    abstract value CDRInputStream

    { ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

  • Reported: CORBA 2.2 — Mon, 13 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Default constructor for Java values

  • Legacy Issue Number: 1654
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec is not very clear about whether the Java class
    generated for an IDL value has a default (no-argument) constructor.

    A no-argument constructor is needed so that the Helper class
    can construct a value when demarshalling. However, it should be
    package-private in order to limit its visbility to the Helper
    class and not expose it to client code. This is also true for
    state fields declared as private in the IDL value type (which the
    spec currently states are mapped to private in Java).

  • Reported: CORBA 2.2 — Thu, 9 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Boxed values need extension to write_Value call

  • Legacy Issue Number: 1650
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There"s a problem with the mapping to Java for boxed IDL values
    for non-primitive Java types, for example, a boxed string or a
    boxed sequence. The currently specified write_Value call doesn"t
    allow these to be marshalled correctly.

  • Reported: CORBA 2.2 — Wed, 8 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

TypeCodes for values

  • Legacy Issue Number: 1625
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The spec does not contain a clear definition of how TypeCodes for
    values and value boxes are constructed. There is something about
    this in section 5.6.3, but this seems to describe a variant of the
    algorithm rather than the algorithm itself. Section 5.9.7 needs to
    be expanded to describe this in at least as much detail as the
    description of the encoding of recursive sequence TypeCodes in the
    current CORBA spec.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Forward declaration of value boxes

  • Legacy Issue Number: 1624
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear from the spec whether or not value boxes can be
    forward declared, and used recursively. For example,

    value v;
    struct s

    { long s0; v next; }

    ;
    value v s;

    If value boxes are indeed syntactic sugar, the answer should be yes.
    That brings the next question: Does this mean that one can call
    create_box_value_tc(), supplying NULL for the original_type, and
    then later on fill in the member typecode via fill_in_recursive_tc,
    supplying a ValueMemberSeq of length 1?

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

Some explicit semantics seem to be missing in section5.8.6

  • Legacy Issue Number: 1615
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not
    describe the semantics behind them. Some of the semantics are referred
    to in earlier section and intuitive for an outsider with a little CORBA
    experience. Some of the the explicit semantics seem to be missing
    altogether (e.g. the "" in <end_tag>). It would be useful if the
    descriptions explicitly used the names within the BNF grammar or
    explicit specifications for each name in the grammar was given.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

OBV spec inefficient for dending large number of small objects

  • Legacy Issue Number: 1614
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: One of the common patterns used in IDL specifications is to pass a
    sequence of a data type in order to cut down on network round trips.
    The current OBV spec (orbos/98-01-01) even suggests sending a graph of
    objects and optimizing for the case where the same object occurs
    multiple times in the graph (which I assume will normally be a small
    number of the total objects). The spec seems to be inefficient for
    sending a large number of small objects though. I have looked at the
    errata before and don"t recall any relavent changes but know the RTF are
    considering some now.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

OBV C++ problem with "supports"

  • Legacy Issue Number: 1539
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
    values
    are specified to derive from the POA skeletons generated from those
    interfaces.
    This presents a potentially intractable problem: skeletons are not designed to
    be inherited together with skeletons for other interfaces because servants do
    not support multiple interfaces. (The Multiple Interface RFP isn"t finished
    yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
    explicitly says

  • Reported: CORBA 2.2 — Tue, 23 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

ValueMemberSeq: What is to be done with the RepositoryID parameter?

  • Legacy Issue Number: 1528
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) In addition to the ValueMemberSeq, the input parameters to
    fill_in_recursive_sequence_tc include the target TypeCode
    pointer, and the RepositoryId.

    What is to be done with the RepositoryId parameter ?
    Is the method supposed to update the Id as well ?
    If that is the case, is it an optional/required parameter ?

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:29 GMT

TypeCodes defined in section 5.8.2

  • Legacy Issue Number: 1527
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) The fill_in_recursive_sequence_tc method is intended to act
    upon an existing "tk_value" TypeCode. The signature indicates
    that it should return a TypeCode pointer.

    What TypeCode is supposed to be returned ?
    If the signature is in error, the specification should
    be corrected – if not, the specification requires
    some additional explanation as to which TypeCode
    needs to be returned.

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:29 GMT

CDR Streams

  • Legacy Issue Number: 1523
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for
    custom marshaling. The names of these types should not contain "CDR" since
    there is nothing that prevents them from being implemented to use a data
    representation other than CDR.

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:29 GMT

OBV "chunking"

  • Legacy Issue Number: 1522
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
    anticipated that value types may be rather large, particularly when a graph
    is being transmitted. Hence the encoding supports the breaking up of the
    serialization into an arbitrary number of "chunks" in order to facilitate
    incremental processing." (orbos/98-01-18, page 5-55)

    This "feature" should be removed from the spec, since it is the job of the
    underlying transport to handle this issue. GIOP already provides
    fragmentation, allowing transports to handle large parameters efficiently
    – why should we build yet another fragmentation solution on top of it?

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:28 GMT

Can "public" mofifier be applied to value operations?

  • Legacy Issue Number: 1421
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can the "public" modifier be applied to value operations? What is the default?
    In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the generated
    C++ class.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:28 GMT

"in". "out", and "inout" modifiers on value operation parameters

  • Legacy Issue Number: 1419
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The "in", "out", and "inout" modifiers on value operation parameters are
    effectively comments. This is the case as a value maps to a language
    pointer or reference. When it is passed in a local interface
    there is no way to guarantee "in" or "out" semantics; it is passed by
    reference which essentially has "inout" semantics.

    These semantics should be explicitly stated.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:27 GMT

Typo on page 8-107 of OBV specification

  • Legacy Issue Number: 1420
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from
    Describable and value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:27 GMT

p 5-24, first paragraph of 5.3.1.3

  • Legacy Issue Number: 1279
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p 5-24, first paragraph of 5.3.1.3:
    The implementation of operations may be remote if the value also
    supports CORBA.Object.
    typo p 5-30, last line of 5.3.2.6: may BE defined

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:23 GMT

Can an instance of C be passed by value to an operation that expects an A?

  • Legacy Issue Number: 1275
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Given:

    abstract interface A {};
    interface B : A {};
    value C : supports B {};

    Can an instance of C be passed by value to an operation that expects an A?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:20 GMT

Section 7.3.10 Value Factories

  • Legacy Issue Number: 1273
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Semantic of register_value_factory is not clear
    What do applications should expect if a factory is already
    registered for a given repositoryId?

    The operation returns the previous factory. But it is not
    clear whether it is overriden or not.

    • When should register_factory be called ?
      I assume that this is after the ORB is initialized (since we
      need a pointer to the ORB). This means that initialization
      of "Component Libraries" is not trivial.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:19 GMT

Section 7 C++ Language mapping

  • Legacy Issue Number: 1271
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: According to the object-by-value C++ mapping, the value type that is
    not boxed results in an abstract C++ class. Basically, the reference
    counting methods are not provided (abstract). It is the responsibility of
    application developer to define/implement a concrete class. Althought
    this can be done, there are some issues:

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:16 GMT

Section 7.3.6 Reference Counting Mix-in Classes

  • Legacy Issue Number: 1270
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The default ref-counting classes are said to be "fully concrete".
    Is this really necessary?
    What is the semantic of "_copy_value" for the ref-counting class?
    => suggest that "_copy_value" MUST NOT be implemented
    (It is implemented by "_copy_value" of the real value type)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:13 GMT

Section 7.3.5 ValueBase and Reference Counting

  • Legacy Issue Number: 1269
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: - What is the return type of "_add_ref" and "_remove_ref"
    (defaults to "int", but what is the semantic of the result value)
    => propose to change to "void"

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:13 GMT

Type code issue

  • Legacy Issue Number: 1261
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: TypeCodes:

    • It is not clear whether the IDL compiler has to generate
      a TypeCode object for each Value type.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:58 GMT

Missing member_kind and member_tc

  • Legacy Issue Number: 1260
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Missing member_kind and member_tc

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:57 GMT

describe_value() operation issue

  • Legacy Issue Number: 1258
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef
    which returns a FullValueDescription structure. Is there supposed to be another
    operation which returns the shorter ValueDescription structure?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:57 GMT

Value type ansd Value Box"s single data member name

  • Legacy Issue Number: 1257
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
    the Value Box"s single data member?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:55 GMT

p.6.68 boxed values of complex types map to same type

  • Legacy Issue Number: 1256
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map
    all to the same type (i.e., as for typedefs, the value"s name appears
    only in holder/helper classes), and that each boxed value of "basic" type
    maps to its individual class. Instead, boxed values of basic types
    could map to the corresponding java.lang.* class, e.g.
    java.lang.Integer, java.lang.Short, etc. An issue with this approach
    is that java.lang.Short and java.lang.Byte are not defined in JDK
    1.0.2. I doubt however this JDK is still much in use; for its users,
    short and octet could optionally map to e.g. CORBA.ShortValue and
    CORBA.ByteValue (inspired from CORBA::StringValue).

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:55 GMT

Section 5.3.3: can value inherit from a boxed value?

  • Legacy Issue Number: 1255
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
    boxed value ? If yes, the Java mapping of boxed values of type
    string, sequence and arrays should be changed because String
    and arrays can"t be extended in Java.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:54 GMT

Can Value type inherit from Value Box type?

  • Legacy Issue Number: 1252
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can a Value type inherit from a Value Box type (the Value Box is described
    as been syntactic sugar for a Value type)?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:53 GMT

Section 5.5 Interface repository (01)

  • Legacy Issue Number: 1064
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
    for it is missing.

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Fri, 12 Jan 2024 20:48 GMT

ODL is erroneous

  • Legacy Issue Number: 691
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ODL which shows an extra, optional parameter for exception information on property-get or property-set method is erroneous, since MKTYPLIB doesn"t allow extra parameter on property accessor

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:24 GMT

rules for marshalling ValueBoxes

  • Legacy Issue Number: 5899
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes.

    I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.

  • Reported: CORBA 3.0.2 — Wed, 16 Apr 2003 04:00 GMT
  • Updated: Fri, 12 Jan 2024 19:51 GMT

Problem with ServerRequestInterceptor::receive_request and DSI

  • Legacy Issue Number: 5895
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    21.3.9.2 states:

    "In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."

    The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.

    Any vendors want to comment on what their PI implementation does now?

    Proposed fix:

    First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?

    Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.

  • Reported: CORBA 3.0.2 — Wed, 2 Apr 2003 05:00 GMT
  • Updated: Fri, 12 Jan 2024 19:50 GMT

restriction of where a valuetype chunk can end

  • Legacy Issue Number: 5892
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    There is a small issue with the restriction of where a valuetype chunk can end. The spec says

    "The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk."

    However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.

  • Reported: CORBA 3.0.2 — Wed, 26 Mar 2003 05:00 GMT
  • Updated: Fri, 12 Jan 2024 19:50 GMT

Messaging Routing Protocol is broken for GIOP 1.0 & 1.1

  • Legacy Issue Number: 5662
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is impossible to use the routing protocol to communicate with servers
    that only support GIOP 1.0 or 1.1, because the information contained in
    struct MessageBody does not contain enough information to determine the
    alignment requirements of the contents of body member. The GIOP 1.0 &
    1.1 RequestHeader struct contain an octet sequence for principle as the
    last member, and specify no alignment requirements for the message
    body. Thus, it is impossible for the final router to determine the
    proper alignment for the message body when marshalling a GIOP Request
    message for delivery to the target object.

    The same problem applies to the Response message.

  • Reported: CORBA 3.0 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:43 GMT

Spec doesn't make clear what is valid mix of policies and what is invalid

  • Legacy Issue Number: 5624
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The spec doesn't make it clear what is a valid mix of policies and what
    is invalid. For example, should it be legal to set a
    RequestPriorityPolicy, MaxHopsPolicy or QueueOrderingPolicy value if the
    RoutingPolicy is ROUTE_NONE?

    Also, should setting both RequestEndTimePolicy and
    RelativeRequestTimeoutPolicy be illegal? Or must the client/server pick
    which ever one expires first?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:42 GMT

How does DynValue handle derived valuetypes?

  • Legacy Issue Number: 5467
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I just noticed that the description of DynValue is totally silent on the
    issue of derived valuetypes.

    Here's an example to set things up:

    // IDL

    valuetype A

    { public short s; }

    ;

    valuetype B

    { public long l; }

    ;

    struct S

    { A an_a; }

    ;

    // C++

    DynamicAny::DynFactory df = ...;
    B *b = ...;
    S my_s;
    CORBA::Any my_any;

    s.an_a = b;
    my_any <<= s;

    DynamicAny::DynAny_var da = df->create_dyn_any(my_any);
    DynamicAny::DynStruct_var ds = DynamicAny::DynStruct::_narrow(da);

    ds->seek(0);
    da = ds->current_component();

    DynamicAny::DynValue_var dv = DynamicAny::DynValue::_narrow(da);
    CORBA::TypeCode_var tc = dv->type();

    cout << tc->id() << endl;

    -----------

    Now some questions:

    1. What is printed by the above C++ code? "IDL:A:1.0" or "IDL:B:1.0"?

    2. If the typecode is for valuetype A, what happens to the members
    defined in valuetype B? Seems they must be inaccessable yet still
    recoverable if I convert the DynValue back to an any and extract the
    value, because I can't truncate a B to an A.

    3. If the typecode is for valuetype B, we now have the interesting case
    where:

    tc->equivalent(ds->type()->member_type(0))

    is false. Is this going to confuse programmers or programs? I think it
    will, since it means that if I try to insert dv into another DynStruct
    via assign() or the like, it will fail, since the TypeCodes are no
    longer equivalent.

    4. Do the answers change if B is truncatable and the program can find
    the TypeCode for B (perhaps via SendingContextRunTime)? How about if it
    can't find the TypeCode?

  • Reported: CORBA 3.0 — Tue, 16 Jul 2002 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:41 GMT

CORBA 3.02, page 11-25, section 11.3.6

  • Legacy Issue Number: 6899
  • Status: open  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Fifth bullet near the beginning of this section states:

    Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.

    Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.

  • Reported: CORBA 3.0.2 — Mon, 12 Jan 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:40 GMT

Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy

  • Legacy Issue Number: 6424
  • Status: open  
  • Source: Borland Software Corporation ( Wolfgang Haefelinger)
  • Summary:

    [..] It is used to indicate the relative amount
    of time for which a Request or its corresponding
    Reply may be delivered. After this amount of
    time, the Request is cancelled (if a response
    has not yet been received from the target) or
    the Reply is discarded (if the Request had
    already been delivered and a Reply returned from
    the target) [..]
    ---------------------------------------------------------
    Question:

    • What is the precise meaning of "Request is
      cancelled"?

    Does it mean that client ORB just gives up or
    does it mean that client tries, in kind of best
    effort semantics, to cancel request on server?

    If this cancellation fails, how will client user
    be informed about this? By a minor code in
    thrown Timeout exception?

    Is it possible to clarify this?

  • Reported: CORBA 3.0.2 — Wed, 29 Oct 2003 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:39 GMT

valuetypes and local interfaces

  • Legacy Issue Number: 6318
  • Status: open  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.

    There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.

    Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.

  • Reported: CORBA 3.0.2 — Thu, 16 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:38 GMT

Unclear and possibly harmful consequences of mandatory annotation definitions

  • Legacy Issue Number: 19738
  • Status: open  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).

    As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
    Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.

    Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
    Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.

  • Reported: CORBA 3.1.1 — Tue, 31 Mar 2015 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:38 GMT

CosExternaliazation Service (bug?)

  • Legacy Issue Number: 4188
  • Status: open  
  • Source: Anonymous
  • Summary:

    Page 2-7 of the CosExternalization Service Specification (April 2000)
    defines the following interfaces:
    CosStream::Node
    CosStream::Role
    CosStream::Relationship

    A CosStream::Node inherits from the CosStream::Streamable interface and
    therefore is a streamable object – it has an external_form_id attribute
    that enables a FactoryFinder to recreate the object using the
    create_uninitialized operation.

    Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
    not support the CosStream::Streamable interface and therefore are not
    "streamable;" in particular, there is no standard method to obtain a KEY for
    them when it is time to internalize them.

    Perhaps, I am missing something (it wouldn't be the first time , but
    having them support the Streamable interface would certainly make
    implementation much easier. Might I suggest the following:

    interface Role: CosGraphs::Role, CosStream::Streamable

    { ... }
    interface Relationship: CosGraphs::Relationship, CosStream::Streamable { ... }

    at a minimum this would permit the CosStream::Node internalize_node()
    operation and the CosStream::StreamIO read_graph() operation to use a KEY
    value in the FactoryFinder to instantiate the object, before it is
    internalized.

  • Reported: CORBA 2.4.2 — Mon, 5 Feb 2001 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:36 GMT

Inconsisten IDL in the Minimum CORBA chapter

  • Legacy Issue Number: 4216
  • Status: open  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
    complete IDL for a minimumCORBA implementation. However, the text in
    the chapter and the IDL are inconsistent, for example, section 23.4.2
    reads:

    ------------------------------------------------------------------------
    ---------------
    The is_a operation is omitted so as not to introduce a requirement
    either for holding

    detailed type information in the object reference or for getting type
    information over

    the wire. Instead, minimumCORBA relies on design time resolution of type
    checking

    issues.

    The non_existent operation is omitted, because of the design philosophy
    of making

    more decisions statically at design time.

    The create_request operation is omitted, as the Dynamic Invocation
    Interface is

    omitted.

  • Reported: CORBA 2.4.2 — Sat, 3 Mar 2001 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:35 GMT

when is a connection a "bi-directional connection"?

  • Legacy Issue Number: 7356
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT

use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous

  • Legacy Issue Number: 7353
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    ptc/04-04-06 section 15.9.1 (top of page 15-67) states:
    When the server receives a BI_DIR_GIOP_OFFER context it must send back a
    BI_DIR_GIOP_ACCEPT context in both the strong and weak identification cases.

    What happens if an ACCEPT service context is not returned? Either immediately
    or ever?

    Can a connection initiator, having sent an OFFER SC, send any further GIOP
    messages over that connection prior to receiving the ACCEPT SC?

    Should a connection initiator, having sent an OFFER SC but not having received
    an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection?
    a) for an object whose POA's BiDirId has been offered and accepted?
    b) for an object whose POA's BiDirId has been offered but a corresponding
    ACCEPT has not yet been received?
    c) for an object whose POA's BiDirId has been offered and accepted only over a
    different connection (to that over which the Request arrives)?
    d) for an object whose POA has a BiDirId but it hasn't yet been offered?
    e) for any object (e.g. one whose POA doesn't have a BiDirId)?

    If an OFFER SC is sent on a Request message, can the corresponding ACCEPT
    SC be carried on any GIOP message from the connection acceptor?
    a) the associated Response
    b) a Response not associated with the Request
    c) a NegotiateSession message
    d) a Request message for an object whose POA's BiDirId has already been
    negotiated

    If an OFFER SC is sent on a NegotiateSession message, can the corresponding
    ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or
    must it come over a NegotiateSession message?

    If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately
    in OFFER SCs on separate messages over a given connection, is a subsequently
    received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds?

    Since I assume that a connection is effectively promoted to BiDir once the first
    ACCEPT SC (indicating no error) is received. What is the point of insisting that
    the connection acceptor "must" send additional ACCEPT SC?

    In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request
    message from the connection acceptor would imply that the connection acceptor
    has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is
    completely superfluous.

    Given the ambiguities in the protocol, it seems likely that an implementation may
    find the real-world interactions to have broken its model of the protocol. What should
    a GIOP protocol machine do in such a situation?

    If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong
    should it be required to close the connection?

    As there is no correlation between OFFER SCs and ACCEPT SCs, on a given
    connection, does an ACCEPT (indicating an error) imply that the connection is
    in an indeterminate state and should be closed?

    If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do
    the normal rules regarding outstanding invocations apply? Do they apply for both
    directions?

  • Reported: CORBA 2.5 — Thu, 13 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT

Bi-directional connections considered volatile at connection acceptor side

  • Legacy Issue Number: 7352
  • Status: open  
  • Source: Syracuse University ( C. Joncheng Kuo)
  • Summary:

    This issue was mentioned by Dave Stringer. I now file it as an issue.

    When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.

    This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.

    On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.

    If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT

Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY

  • Legacy Issue Number: 7351
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.

    The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
    connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.

    For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.

    There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.

    On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and effective BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:32 GMT

How many BI_DIR_GIOP_OFFER service contexts are allowed

  • Legacy Issue Number: 7318
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request.

    If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all.

    If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:32 GMT

connection_complete field of the FirewallPathRespContext is under specified

  • Legacy Issue Number: 7317
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The connection_complete field of the FirewallPathRespContext is under specified.

    The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,

    “Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”

    However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.

    Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:32 GMT

Expected behavior of a non-conformant implementation

  • Legacy Issue Number: 7316
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    It is not defined what happens if a non-conformant implementation receives a BiDir offer.

    RECOMMENDATION:
    State that a non-conformant implementation need not do anything - it may simply ignore the offer.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:15 GMT

Targets of Export and Offer Policies incompletely specified

  • Legacy Issue Number: 7315
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.

    RECOMMENDATION:
    Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:14 GMT

Processing of NegotiateSession messages at various stages of connection set

  • Legacy Issue Number: 7314
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.

    RECOMMENDATION:
    Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):

    "...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:14 GMT

Firewall FTF Issue: No ene-to-end security for firewall traversal

  • Legacy Issue Number: 7313
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.

    I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:09 GMT

What BiDirIds shall be sent over what bidirectional connections?

  • Legacy Issue Number: 7312
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).

    The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.

    Proposed resolution:
    1. Extend the choices of the value field of the BidirectionalOfferPolicy:
    ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
    ALLOW_LISTED – a list of POAs being provided in the policy
    DENY – same as it now
    2. Add a field to the policy to allow a sequence of POAs being specified.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Interplay of Contexts allowed in NegotiateSession messages too ill-defined

  • Legacy Issue Number: 7311
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message. However, the interplay among these contexts is undefined. An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup. What can be used in what order is not defined.

    RECOMMENDATION:
    Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP. The contexts are the following:

    · BI_DIR_GIOP_OFFER
    · BI_DIR_GIOP_CHALLENGE
    · BI_DIR_GIOP_RESPONSE
    · BI_DIR_GIOP_ACCEPT
    · FIREWALL_PATH
    · FIREWALL_PATH_RESP

    Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented. This effectively limits the scope of the problem to the bidir protocol and use by the firewall. The order and stage of processing the above contexts is discussed in another Firewall issue.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Firewall Issue: Random BiDirIds can't be used for persistent POAs

  • Legacy Issue Number: 7310
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document specifies that all BiDirIds must be randomly generated. However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.

    RECOMMENDATION:
    A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
    field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
    field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'

    The random generation method is adequately documented. The repeatable method will always generate the same BiDirId for a given POA. This effectively makes the ID a constant, but without the concern for storage. It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.

    The values for the ID type indicate whether the type of BiDirId generated is strong or weak.

    This policy is placed on the client ORB and/or the POA in question.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Firewall Issue: Connection over which BiDir offers are sent is unspecified

  • Legacy Issue Number: 7309
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.

    RECOMMENDATION:
    A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections. If there are none, then a new connection will be established and its bidirectionality initiated.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Firewall Issue: Response to failed BiDir challenge is unclear

  • Legacy Issue Number: 7308
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The actions that result from the failure of a BiDir challenge are unclear.

    RECOMMENDATION:
    The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

Firewall issue - Number of BiDirIds in a BiDirOffer

  • Legacy Issue Number: 7307
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.

    RECOMMENDATION:
    All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

Implications about BiDirIds

  • Legacy Issue Number: 7225
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.

    Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.

    In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.

    obj = ...; // target
    obj.invoke_target(...);

    In order for the above scenario to work, I derive the following implications from the spec.

    1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on all of its POAs that have EXPORT policy ALLOW must be available at the server side.

    This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on each bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.

    2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.

    If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on every bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that allows efficient implementation, though efficiency is not always a concern for everyone.

  • Reported: CORBA 2.5 — Thu, 8 Apr 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

paragraph limits use of BiDirOfferContext

  • Legacy Issue Number: 7224
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:

    "If the client ORB policy permits bi-directional use of a connection, a Request or
    NegotiateSession (see MARS/04-01-01) message can be sent to the server that
    contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
    indicates that this GIOP connection is bi-directional. The BiDirOfferContext
    indicates to the server that the objects with the supplied BiDirIds are available for
    invocation over that connection. To determine whether an ORB may support bidirectional
    GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
    "Bi-directional GIOP policy," on page 65)."

    This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
    for specific object references received by the client ORB." - Section 15-9, page 15-66).

    Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.

    Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").

    RECOMMENDATION:
    Rephrase the paragraph as follows:

    If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).

  • Reported: CORBA 2.5 — Tue, 6 Apr 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

Negotiate Session Message Issues

  • Legacy Issue Number: 7202
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    If a service context negotiation fails by way of the NegotiateSession
    message in either direction. how does the sender (client or servers side)
    get an indication back to the sender?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:04 GMT

CodeSet issue (05)

  • Legacy Issue Number: 7201
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset come before/with/after BiDir negotiation?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:04 GMT

CodeSet issue (04)

  • Legacy Issue Number: 7200
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Can Codeset come before/with Firewall Traversal in Negotiate Session
    meesages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:03 GMT

CodeSet issue (03)

  • Legacy Issue Number: 7199
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    On a connection in which BiDir is negotiated, but no Codeset
    is negotiated, will the reverse direction be able to negotiate
    code set?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:03 GMT

CodeSet issue (02)

  • Legacy Issue Number: 7198
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset get negotiated in only the other direction?
    If so, will that happen in Negotiate Session meesages orRequest Messages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:03 GMT

CodeSet issue (01)

  • Legacy Issue Number: 7197
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does the CodeSet get negotiated in Negotiate Session?
    If so, does Codeset continue to get negotiated in Requests?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:02 GMT

GIOP version 2.0 issue

  • Legacy Issue Number: 7168
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    The following paragraph raises an interesting issue. If we follow this to the letter

    • since it says that the new version of GIOP is not backward compatible with the
      earlier versions of GIOP, it implicitly appears to make this new GIOP version a
      new "major" version of GIOP. Clearly we need to figure out a way to avoid doing
      this, since creating GIOP version 2.0 in this way raises all sorts of other issues.

    From the second paragraph on page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):

    This document supercedes the previously adopted CORBA firewall specification. In
    addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
    adopted specification for bi-directional GIOP. These specifications are not backwards
    compatible with the previous specifications and they are intended to make it possible
    to create a functional protocol for the interoperation of ORBs and firewalls.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:02 GMT

Discrepancy in the changes proposed to CSIIOP and CSI modules

  • Legacy Issue Number: 7167
  • Status: open  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules. The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar

    Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:00 GMT

Bidirectional Policy insufficient for persistent objects

  • Legacy Issue Number: 6313
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The BidirectionalPolicy insufficient for persistent objects.

    The BidirectinoalExport Policy is a POA policy and it only has two values
    of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
    should be placed in the IOR. It is stated that the ORB must generate a
    random identifier when the POA is created. However, that will not work for
    persistent objects in which the BiDirectional Offer must remain constant.

    Also, there is no default specified if this policy is not placed on a POA,
    and no default for the RootPOA.

  • Reported: CORBA 2.5 — Thu, 9 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:59 GMT

Server Authentication

  • Legacy Issue Number: 6312
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    As I understood it, the Firewall Traversal specification was to use new
    CSIv2 Compound Identity types to give the target server the complex
    principal composed of the client and the authenticating firewall traversal
    path. The server was to be authenticated to the client in much the same
    way. This functionality appears to be missing in the specification. It is
    easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
    firewall negotiation, specifying the backwards firewall authentication
    trail from the server to the client.

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:58 GMT

Negotiation Session message is unwieldy

  • Legacy Issue Number: 6311
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The Negotiate Session message is unwieldy in that if it is used to send
    service contexts, there are no general ways to govern its use other than
    by special rules, all of which special cases are not accounted for in the
    specification.

    For example, when do you sent Bidirectional service contexts as ooposed to
    firewall contexts? Can you send transaction contexts? Codesets? Codebase?
    CSIv2? Can you send BiDir service contexts while firewall contexts are
    being processed?

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:52 GMT

Negotiate Session Message Orientation

  • Legacy Issue Number: 6284
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The NegotiateSession message is a single typed GIOP message that is sent
    between both Client and Server to negotiation service contexts, and
    further to initiate and negotiate bidirectional GIOP.

    Having a single message is problematic in that a connection, once
    negotiated bidirectional may have different requirements for such things
    like Codesets, etc. Getting a NegotiateSession message after a
    bidrectional set up, the endpoints will have difficulty discerning the
    orientation of the NegotiateSession message.

    At the very least NegotateSession messages should have an orientation,
    much like the GIOP Request and Reply messages do.

    I'm not so sure they must be correlated with a "request id", but different
    message types would help. I would suggest two messages,
    NegotiateSessionRequest and NegotiateSessionReply to maintain the
    client-server orientation, respectively.

  • Reported: CORBA 2.5 — Thu, 2 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:52 GMT

MAIN_THREAD_MODEL questions

  • Legacy Issue Number: 4155
  • Status: open  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    i have a few questions about the POA ThreadPolicy type
    MAIN_THREAD_MODEL.

    first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states,
    "If called by the main thread, this operation performs an
    implementation-defined unit of work; otherwise it does nothing."

    how is a distinguished main thread supposed to be reliably determined?
    i'm not sure we really need to define this. i'd think what we're trying
    to say is that the thread that calls perform_work() is the thread that
    will be used to do the work, and it is up to the application to make
    sure this happens. in section 4.2.3.3, the spec states,
    "For maximum portability an application should call either run or
    perform_work on its main thread."

    to me it seems the intent is to let the application determine what the
    'main thread' is.

    second, what happens if an application calls both run & perform_work?
    and what happens if the application calls run from multiple threads? it
    isn't really clear what the difference in request handling with regard
    to the thread used is between run() & perform_work().

    right now the spec seems to imply through the use of the message loop
    example in section 4.2.3.2 that perform_work is really intended to be
    used to handle situations where a single thread must be used for all
    application activity. now add to that the note on pg 11-12 about using
    the main thread model:
    "Note - Not all environments have such a special requirement. If
    not, while requests will be processessed sequentially, they may not all
    be processed on the same thread."

    my interpretation is that ORB::run would be used in cases where you
    simply want the POAs to be accessed sequentially, but the application
    doesn't care about which thread the implementation uses, but you would
    need to call perform_work to specifically hand the application defined
    main thread to process requests.

    my suggestion (finally ;^) is that we should state perform_work should
    be called, on whichever thread the application likes, if it wants to
    hand a specific thread to the ORB to do work. otherwise, calling
    ORB::run from any thread simply means the implementation is free to
    handle requests for servants associated with main thread model POAs on
    whatever thread the implementation may choose (including a new one), in
    keeping
    with the requirement that the requests be processed on each POA's
    servants sequentially..

    one more question: does it make sense to state that a callback type of
    architecture won't work when using this threading model?

  • Reported: CORBA 2.4.1 — Wed, 17 Jan 2001 05:00 GMT
  • Updated: Thu, 11 Jan 2024 16:51 GMT

The use of Full Services definitions in CORBA/e spec

  • Legacy Issue Number: 10598
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Problem:

    Since CORBA/e is for embedded constrained systems, one should be using LW Services as a minimal compliant point this would still allow one to offer up a Full Services in its offering but the other way around would not be compliant.

    Suggested Change

    The suggested change is to use LW Services definitions for CORBA/e.

  • Reported: CORBAe 1.0b1 — Fri, 19 Jan 2007 05:00 GMT
  • Updated: Thu, 11 Jan 2024 16:50 GMT

CORBA section 11 struct PortableGroup::GroupInfo

  • Legacy Issue Number: 12512
  • Status: open  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    In chapter 11 'Unreliable Mulicast Inter-ORB Protocol' the struct PortableGroup::GroupInfo is discussed. However in the consolidated IDL and the IDL available from the OMG web site, this struct has been replaced by PortableGroup::TagGroupTaggedComponent. Which is correct?

  • Reported: CORBAe 1.0b1 — Tue, 27 May 2008 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:45 GMT

Invalid IDL

  • Legacy Issue Number: 18150
  • Status: open  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    In the ZIOP 1.0 specification, the IDL in Annex A has:

    typedef unsigned short CompressorId { };

    The braces are invalid and should be removed.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:40 GMT

Invalid IDL (2)

  • Legacy Issue Number: 18151
  • Status: open  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    In the ZIOP 1.0 specification, Annex A has:

    Compressor get_compressor(
    in CompressorId compressor_id,
    in CompressorLevel compression_level)
    raises (UnknownCompressorId);

    CompressorLevel should be CompressionLevel.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:40 GMT

Missing PolicyValue encoding instructions

  • Legacy Issue Number: 18152
  • Status: open  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    Section 17.3.1 of CORBA 3.1 / 3.2 says:

    17.3.1 Structures

    PolicyValue

    This structure contains the value corresponding to a Policy of the
    PolicyType indicated by its ptype. This representation allows the
    compact transmission of QoS policies within IORs and Service
    Contexts. **The format of pvalue for each type is given in the
    specification of that Policy.**

    When the ZIOP 1.0 specification describes the ZIOP policies, it does not
    give the format for pvalue.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:40 GMT

Missing size information for decompress()

  • Legacy Issue Number: 18153
  • Status: open  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    The ZIOP body format contains the original length of the compressed
    data, which is important because it allows the compressor to efficiently
    allocate a buffer to uncompress it. Unfortunately, the
    Compressor::decompress() operation is not given that size, meaning that
    it has to guess how big the uncompressed data will be.

    The original data size should be given to the decompress() operation.
    One way to do that without changing the operation signature would be to
    specify that the inout Buffer target sequence should have its length
    pre-populated to the expected size.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:39 GMT

Add support for IDL4 int8/uint8/map/bitset/bitfield/bitmask

  • Status: open   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    CORBA 3.4 should have support for int8/uint8/map/bitset/bitfield/bitmask/bitvalue for DynamicAny, DynamicSkeleton, Interface Repo, Any/TypeCode and other CORBA APIs related to types

  • Reported: CORBA 3.4 — Mon, 17 Jul 2023 13:56 GMT
  • Updated: Wed, 6 Dec 2023 23:16 GMT

Implications of any/valuetype marshalling

  • Legacy Issue Number: 4137
  • Status: open  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
    The document citation indicates that the integrity of the valuetype –
    that is, the received marshalled state – is to be preserved in an
    ORB-mediated operation, even if that valuetype cannot be unmarshalled,
    either partially (truncated) or at all. If this value is then passed to
    another operation, the original marshalled state is to be transmitted.
    This preserves the transmitted object in its entirety, regardless of
    local implementation concerns. This is obviously necessary for bridges
    or event processing, such as through the notification service.

    So the question arises, what happens if you have a partial (truncated)
    unmarshall and the recipient application changes the local state of the
    valuetype through its attributes or local operations? How can/will you
    even know the state was changed? Do you ignore the changes and send the
    originally received marshalled stream, send only the new valuetype even
    though it is a truncation of the original, or "merge" the new values for
    the unmarshalled part followed by the original appended data for the
    truncated part? Should this third option be possible through an
    explicit ORB call – that is, the application is responsible to identify
    the change in state to the ORB? I assume that the semantics of
    "truncatable" must come to include the understanding that data in the
    truncatable portions may not be contextually dependent on the inherited
    parent of the valuetype.

    As a further question, is there a reason why this semantic
    interpretation should not be extended to be a general requirement rather
    than only with respect to transmission of anys? My experience has found
    that passing anys tends to be expensive and is avoided where it can be.
    A more general interpretation permits transmission of a comprehensive
    data structure among intermediate agents that only use (unmarshall) the
    information they need.

  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:15 GMT

69.3 AssemblyFactory Interface

  • Key: CORBA35-69
  • Legacy Issue Number: 5576
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Suggested changes to the AssemblyFactory interface.

    AssemblyFactory Issues.

    1. Ease of use Issue. After the create operation is performed, one is
    force to call lookup to get the Assembly that just got just created. Why is
    a cookie returned by the create operation instead of an Assembly? Is the
    reason because of security? If the interface were more open this would
    still allow a secure implementation to be implemented.
    Suggested change is to return an Assembly instead of a Cookie. Change
    destroy operation to take in an Assembly parameter instead of Cookie.
    Change lookup operation to take in a name parameter. These changes
    make it consistent with the other CCM interfaces, such as Container,
    KeyLessCCMHome, ComponentServer, and ServerActivator.
    2. Multiple users Issue. For multiple users, how does a client know what
    assemblies are created. Add a get_assemblies operation that returns a list
    of assemblies. These changes make it consistent with other CCM interfaces,
    such as Container, ComponentServer, and ServerActivator.
    3. User-friendly identifier for Assembly Instance issue. Add an input
    name parameter that can be assigned to the Assembly instance that gets
    created. Add a read only name or label attribute to the Assembly interface.

  • Reported: CORBA 3.0 — Thu, 8 Aug 2002 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:14 GMT

[CCM] Interface Repository Metamodel

  • Key: CORBA35-65
  • Legacy Issue Number: 5594
  • Status: open  
  • Source: Anonymous
  • Summary:

    in the BaseIDL there is a class StructDef which has the Attribute members of
    Type Field. How can I model a IDL struct with more than one entry?
    I think there should be a aggregation from StructDef (1<>----->*) to the Field
    class (Page 8-10 of the CCM Spec).

    *) With EnumDef there is the same problem, I guess a assotiation from EnumDef to
    string (1<>----->*) would solve it (Page 8-10 of the CCM Spec).

    *) Also with ExceptionDif and its attribute members (Page 8-11 of the CCM Spec).

  • Reported: CORBA 3.0 — Mon, 26 Aug 2002 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:13 GMT

CCM IDL style inconsistency

  • Key: CORBA35-61
  • Legacy Issue Number: 5858
  • Status: open  
  • Source: Anonymous
  • Summary:
    • document : formal/02-06-65
    • chapter : 1.5.2.4
    • text in question :

    module Components
    {
    valuetype Cookie

    { private CORBA::OctetSeq cookieValue; }

    ;
    };

    • Issues :

    1. Naming style used in this definition violates rules defined in
    "OMG IDL Style Guide" (ab/98-06-03).

    2. Naming style used in this definition is inconsistent with other parts
    of the CCM IDL, for example:

    module Components
    {
    valuetype PortDescription

    { public FeatureName name; public CORBA::RepositoryId type_id; }

    ;

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;
    }

    • suggested resolution : replace `cookieValue' with `cookie_value'
  • Reported: CORBA 3.0.2 — Wed, 12 Feb 2003 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:12 GMT

multiple lifetime policies declaration issue

  • Key: CORBA35-60
  • Legacy Issue Number: 5870
  • Status: open  
  • Source: INRIA ( Nawel Sabri)
  • Summary:

    In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !

    Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :

    <!ELEMENT segment
    ( segmentmember+
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

    becomes:

    <!ELEMENT segment
    ( segmentmember+
    , servant?
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

  • Reported: CORBA 3.0.2 — Tue, 25 Feb 2003 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:11 GMT

CCM spec: insufficient examples of component attributes

  • Key: CORBA35-58
  • Legacy Issue Number: 5898
  • Status: open  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
    is this text:

    "Declarations for facets, receptacles, event sources, event sinks,
    and attributes all map onto operations on the component's equivalent
    interface. These declarations and their meanings are described in
    detail below."

    In the following sections, I see facets, receptacles, event sources,
    and event sinks described, but I see no mention of attributes.
    It would be usefult to have an example of attributes in an appropriate
    place, as outlined by section 1.3.3.

    In section "1.10 Configuration with Attributes", I see that configurators
    are described, but I see no example of using attributes directly
    to configure a component.

    It would be very useful to include a small example to illustrate
    how to configure a component directly by using attributes.

    Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
    C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

    ======================================================

    component Whatever

    { attribute long cacheMaxKb; }

    ;

    home WhateverHome manages Whatever
    {
    };

    // C++
    WhateverHome_var weh = // obtain ref
    Whatever_var we = weh->create();

    we->cacheMaxKb(200);

    we->configuration_complete();

    ======================================================

    I don't suggest that this example be used verbatim,
    but a similar example would be useful to have in the
    CCM spec.

  • Reported: CORBA 3.0.2 — Thu, 10 Apr 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:11 GMT

CCM Spec: attributes are listed in the ports section?

  • Key: CORBA35-53
  • Legacy Issue Number: 5918
  • Status: open  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In section 1.1.2 of the CCM specification:

    1.1.2 Ports
    ===========
    ..... The component model supports four basic kinds of ports:

    • Facets
    • Receptacles
    • Event sources
    • Event sinks
    • Attributes

    Well, that list includes five things, not four.

    So, is an attribute considered a port or not?

    The wording in this section needs to be clarified in the CCM
    specification, because it is not clear if an attribute
    is a port or not.

  • Reported: CORBA 3.0.2 — Mon, 28 Apr 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:11 GMT

Section 13C.1.3 Editorial

  • Key: CORBA35-2
  • Legacy Issue Number: 710
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: On page 9, paragraph beginning with "Within an interface...." should read "..attributes should appear after operations..."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:10 GMT

issue on component supporting abstract interfaces

  • Key: CORBA35-54
  • Legacy Issue Number: 5910
  • Status: open  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    The following information is sent in order for the specification to
    clearly state if components and local interfaces can support abstract
    interfaces (the specification is confusing on this point).

    CORBA 3.0.1 does not explicitely states if a component can support an
    abstract interface, thus it can be considered that it is possible. If so
    a big problem arises as local interfaces inheriting abstract ones is
    confusing in the specification.

    In addition, it is neither explicitely stated that provides and uses
    declarations can or cannot be of types defined through abstract
    interfaces. It does not seem to make sense for a port to be an abstract
    type. Facets will never be used by value, and an operation cannot
    (should not) return the reference of a facet or a valuetype (which would
    be in favor of provides to be defined using abstract interfaces).

      • Problem

    Consider the following definitions which are correct regarding
    formal/02-12-06:

    /* omg idl3 */

    abstract interface I

    { void foo () ; } ;


    component C supports I {
    } ;


    The mapping to OMG IDL2 of these definitions is not correct right now as
    they become:


    /* omg idl2 */


    abstract interface I { void foo () ; }

    ;

    interface C : Components::CCMObject, I { } ;

    local interface CCM_C : I { } ;

    According to formal/02-12-06, the last line may not be correct. Local
    interfaces may not inherit abstract interfaces (section 10.5.28). (I use
    may as it is confusing and can lead to various understanding of the
    spec.)

      • Potential solutions:

    1. State in the CORBA 3.0.1 that components cannot support abstract
    interfaces. In favor: Could ne considered as a minor change. Against: a
    component reference cannot be returned by an operation that can return
    an object by value or by reference. This solution looks cleaner that the
    second one from a software engineering point of view.

    2. Clearly state that components and local interfaces can support
    abstract interfaces. This use may be surprising from a software
    engineering point of view, but may be important for some users. This
    bring back the debate "quality vs powerfulness".

    In any case, I think it should be clearly stated if local interfaces may
    or may not inherit abstract ones.

  • Reported: CORBA 3.0.2 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:10 GMT

portability of CCM descriptors

  • Key: CORBA35-51
  • Legacy Issue Number: 6286
  • Status: open  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Sylvain Leblanc)
  • Summary:

    Identifier (FPI).

    These FPIs are required for the CAD, CSD, CCD and CPF DTDs.

    Proposed resolution:

    Adds the CCM DTDs on the OMG web site and adds the following text in the specification:

    • section 6.3, before subsection 6.3.1 :

    The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" />

    • section 6.4, before subsection 6.4.1 :

    The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.4.4:

    replace

    <!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">

    with

    <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.7, before subsection 6.7.1 :

    The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.7.1:

    replace

    <!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">

    with

    <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.8, before subsection 6.8.1 :

    The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" />

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:10 GMT

How does an ORB implement Object::get_policy for PI defined policies?

  • Legacy Issue Number: 4065
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The description for Object::get_policy (in the Core, section 4.3.7.1)
    states:

    "The get_policy operation returns the policy object of the specified
    type (see Policy Object on page 4-32), which applies to this object. It
    returns the effective Policy for the object reference. The effective
    Policy is the one that would be used if a request were made."

    For a policy defined by PI, I don't see anyway for the ORB to implement
    this operation correctly, since there isn't any way for it to know how
    to properly resolve any client override policies with the policy
    information stored in the IOR.

    When a invocation is actually in process, the ClientRequestInterceptor
    can use the information available in the ClientRequestInfo interface to
    get the client override and the IOR policy data and do the correct
    resolution before continuing with the request. However,
    Object::get_policy() needs to do the same type of thing, but it has no
    invocation context to do it in.

    I think the same problem also applies to the implementation of
    ClientRequestInfo::get_request_policy().

    I think we need a new interception point to do this work. Something
    like:

    local interface PolicyInterceptor

    { any determine_effective_policy(in PolicyInfo pi); }

    ;

    local interface PolicyInfo

    { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }

    ;

    If this turns out to be an acceptable solution, then we should also
    change ClientRequestInfo to:

    local interface ClientRequestInfo : RequestInfo, PolicyInfo

    { ... }

    ;

    and remove the redundant operations.