C Language Mapping Avatar
  1. OMG Specification

C Language Mapping — Closed Issues

  • Acronym: C
  • Issues Count: 2,562
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
COMMONS12-8 Several processes and external projects need definitions for organizations, and related to that, locations MVF 1.0b2 COMMONS 1.2b1 Resolved closed
COMMONS12-13 Clean up a few issues with the Locations ontology Commons 1.1 COMMONS 1.2b1 Resolved closed
COMMONS12-7 The definition of aspect needs refinement Commons 1.1 COMMONS 1.2b1 Resolved closed
COMMONS12-9 Several OMG and external ontology efforts need to be able to talk about registration authorities MVF 1.0b2 COMMONS 1.2b1 Resolved closed
COMMONS12-5 Several properties in the quantities and units ontology are overly constrained MVF 1.0b2 COMMONS 1.2b1 Resolved closed
COMMONS12-3 The quantities and units ontology is missing the concept of a measurement reference MVF 1.0b2 COMMONS 1.2b1 Resolved closed
COMMONS12-1 Need an ontology representing multidimensional arrays COMMONS 1.0b2 COMMONS 1.2b1 Deferred closed
COMMONS12-2 The quantities and units ontology does not allow representation of unitless quantity values Commons 1.1b1 COMMONS 1.2b1 Deferred closed
COMMONS12-10 Several OMG and external processes need concepts for describing regulatory authorities MVF 1.0b2 COMMONS 1.2b1 Resolved closed
COMMONS12-11 Certain OMG processes need additional structured collection definitions MVF 1.0b2 COMMONS 1.2b1 Resolved closed
C2MS11-249 Misc Post-ballot-13 Fixes C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-254 Table Formatting for Value and Description Columns C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-260 Rename Section 6 C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-223 Clear up Text with Product Message ME5 and ME6. C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-222 Align Alarm Text/Colors with other SDTF Specs C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-211 Expand TLM Changes into Related Messages C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-214 Resolve REQUEST-ID in Message Subjects C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-234 Rework some text for Archive Message Retrieval Request C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-219 Inconsistent figure and table names for Replay TLM Messages C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-238 Miscellaneous 1.1 Text Cleanup C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-187 Consolidate all "Additional Information" Table and Model Figure changes into one Issue C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-193 Rework Individual Message Header Tables C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-217 Consolidate APID and AP ID to just APID C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-35 Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-83 Consider forcing a limited subscription C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-178 Normalize the "Additional Information" Tables Showing Fields for Messages C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-169 Clarify Text Associated with Simple Service Req/Resp C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-163 Align TLM Messages against Subject Elements and Fields C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-130 Create an optional Message Envelope to hold Tracking Fields C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-191 Remove XSDs as Normative Documents C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-111 SERV message, add field SERVICE-GROUP C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-110 PROD message, add fields PROD_SUBTYPE C2MS 1.0 C2MS 1.1b1 Closed; No Change closed
C2MS11-143 Header UNIQUE-ID is Type "Header String" C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-25 Make all subjects be buildable from fields in the message C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-139 Update Text Associated with REQUEST-ID as Replacement Issue C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-54 VCID and APID in Message Subject for TLMTDM Frame C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-16 REQUEST-ID field does not support usage as a GUID C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-101 Text for AMVAL REQ references non-existing fields C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-27 Time Type table clarification for the DDD portion C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-114 Remove APID from TLMFRAME C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-115 Remove APID from TLMPROC C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-141 Improve text related to ONESHOT in Mval Request Message C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-56 Clarify Correlation PUBLISH-RATE and SAMPLE-RATE on Mnemonic Value Request Message C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-135 NUM-OF-[ITEMS] Should be Required C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-137 Revisit SAMPLE-RATE C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-136 MNEMONIC CRITERIA Needs alignment with C2MS11-56 C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-39 Add field APID (and VCID) to Telemetry CCSDS Packet Message C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-36 Add DESTINATION-NODE and DESTINATION-FACILITY as fields C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-108 TLM CCSDS FRAME, TLM Processed Frame messages need AP-ID fields C2MS 1.0 C2MS 1.1b1 Closed; No Change closed
C2MS11-90 Real-world STREAM-MODE Issues C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-43 Deprecate Archive Message Retrieval Messages C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-120 Deprecate REQ-STRING in Product Request Message C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-121 Consider Making Fields in UML Public vs Private C2MS 1.0 C2MS 1.1b1 Closed; No Change closed
C2MS11-109 TLMTDM message, add AP-ID and VCID fields C2MS 1.0 C2MS 1.1b1 Closed; No Change closed
C2MS11-41 C2MS specification on page 168 is not clear regarding CMD-FORMAT=MNEMONIC C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-112 Align MESSAGE-CLASS with Usage C2MS 1.0 C2MS 1.1b1 Closed; No Change closed
C2MS11-15 Log message scope too broad, need Alert/Status style message introduced C2MS 1.0b2 C2MS 1.1b1 Closed; No Change closed
C2MS11-106 CFG, CNTL, DEV, HB, RSRC Messages need fields DESTINATION-NODE and DESTINATION-FACILITY C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-107 TLMPKT Message needs field AP-ID C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-14 Specify multiplicity for required and optional fields C2MS 1.0a1 C2MS 1.1b1 Resolved closed
C2MS11-17 Make Fields Table and UML Match the Order of Fields for greater Readabliity C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-30 Clarify the ".... Message Header Notes" tables re: being included in each message C2MS 1.0 C2MS 1.1b1 Closed; No Change closed
C2MS11-49 Consider Renaming "Header String" type to "Subject Token String" C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-55 REQUEST-ID as "Replacement" and related STOP C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-48 Add Message-level Security Constructs C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-87 Missing Echo Request C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-34 In message Archive Message Retrieval Response, fix Header field names C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-75 Move Tracking Fields to a "Message Envelope" C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-29 In Message Header, make NODE and USER-NAME string rather than Header String C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-28 Add DESTINATION_NODE and DESTINATION_FACILITY to Message Header C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-18 All Messages Subclass Message Header C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-31 Clarify the UML diagrams regarding the values for the fields inherited from Message Header C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-32 Add field for USER to Message Header C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-38 In the Control Message, the field CNTL-STRING should be required C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-33 Add security fields that GMSEC API inserts into encrypted messages as Tracking Fields in C2MS C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-37 Remove value for CNTL-STRING from CNTL message C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-46 Using REQ Messages for 'Publish' C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-26 Document that Header String type is to be at least one ASCII character C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-10 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 C2MS 1.1b1 Transfered closed
C2MS11-40 Control Message SPECIAL_INFO Field type should be String C2MS 1.0 C2MS 1.1b1 Closed; No Change closed
C2MS11-12 "Mnemonic" should be called "Parameter" C2MS 1.0b1 C2MS 1.1b1 Closed; No Change closed
C2MS11-22 Message-level Security Credentials C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-21 Larger Data Types C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-9 Pub/Sub subscription status unknown C2MS 1.0b1 C2MS 1.1b1 Transfered closed
C2MS11-2 C2CX Heartbeat comments C2MS 1.0a1 C2MS 1.1b1 Resolved closed
C2MS11-3 Archive Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.1b1 Resolved closed
C2MS11-8 Acknowledge Final Status inconsistency C2MS 1.0b1 C2MS 1.1b1 Deferred closed
C2MS11-1 Lack of a registry concept C2MS 1.0a1 C2MS 1.1b1 Transfered closed
C2MS11-6 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 C2MS 1.1b1 Deferred closed
C2MS11-5 Data Dictionary Messages C2MS 1.0b1 C2MS 1.1b1 Deferred closed
C2MS11-7 XML PSM recommended C2MS 1.0b1 C2MS 1.1b1 Deferred closed
C2MS11-42 C2MS: Optional Transfer Frame/Packet attributes should be described in schema C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-45 C2MS Database Query (DBQUERY) messages C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-11 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 C2MS 1.1b1 Deferred closed
C2MS11-4 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 C2MS 1.1b1 Deferred closed
C2MS11-24 Add a Message Exchange Pattern (MEP) for a component to forward requests/responses C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-44 Consider a mechanism to request archived Commands and Events C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-20 Harmonize Replay TLM and Archive Mnemonic Message Sets C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-19 Larger Data Types C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-140 Replace Unsolicited Echo with a Separate Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-13 Add documentation within the model C2MS 1.0a1 C2MS 1.1b1 Deferred closed
C2MS11-23 In message tables, rework the "value" column to allow for fixed values vs. default values C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-144 STREAM-MODE Issues with Replay Telemetry Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-47 Using REQ Messages for 'Publish' C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-131 Split ME1 in Simple Service Req/Resp C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-88 Create CMD-MNEMONIC Field in Command Request Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-184 Remove Superfluous Fields from Header and Envelope C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-138 Command Echo Not Provided Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-190 Use Semantic Versioning for Version Number of Messages C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-151 Reconsider Oneshot in MVAL Request/Response C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-189 Add a section describing expected use C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-173 Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-192 Remove the Req/Resp/Pub MEP C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-170 Replace simple service REQ/RESP C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-177 At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-176 At Next Major Revision: Order MEs and Fields Consistently C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-182 Deprecate fields duplicated between C2MS Messages and the Message Envelope C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-200 Revisit Tracking Fields C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-199 Consider Deprecating and Later Removing Resource Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-204 Re-evaluate Optional Boolean Fields C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-209 mnemonic.n.sample.m.quality seems to be wrong type C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-208 Non-sensical Description for PROD-MSGS-TO-SEND C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-207 Inconsistent Optional/Required Fields C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-212 Normalize Headers and Text in the new DB Query Messages C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-242 Consolidate Navigation Data Messages C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-221 Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-240 Rework Log Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-225 Lack of Required Fields in Sub-elements C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-210 AMVAL Value Response Doesn't Mirror MVAL Value Response Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-236 Required or Optional for MNEMONIC Status on Data Messages C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-218 Need Review/Documented Explanation of NUM-OF-PROD-SUBTYPE-SUBCATEGORIES C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-250 Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-244 Undo Addition of DB Query Messages in 1.1 C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-251 Improve Example Text for Publish Rate C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-253 Align TLM Terms C2MS 1.0 C2MS 1.1b1 Deferred closed
C2MS11-248 What to do when Priority isn't Specified C2MS 1.0 C2MS 1.1b1 Deferred closed
CSRM11-3 Create examples of use of the profile CSRM 1.0b1 CSRM 1.1b1 Resolved closed
CSRM11-1 Icons for profile CSRM 1.0b1 CSRM 1.1b1 Resolved closed
CSRM11-2 Add constraints to aid in correctness of profile useage CSRM 1.0b1 CSRM 1.1b1 Closed; Out Of Scope closed
CSRM11-4 Recommended Additions CSRM 1.0a1 CSRM 1.1b1 Closed; Out Of Scope closed
CPP1117-8 Incorrect constructor referenced in Fixed description CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-9 Typo CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-13 Missing annotation mapping CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-7 Missing description related to union member modifier CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-11 Change struct VariableExt constructor CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-10 Improve bitmask mapping CPP11 1.6b1 CPP11 1.7 Deferred closed
CPP1117-1 Add standardized annotation to override the IDL map to std::map mapping CPP11 1.7 CPP11 1.7 Deferred closed
CPP1117-2 Typo in example CPP11 1.7 CPP11 1.7 Closed; No Change closed
CPP1117-3 6.7.8 Argument Passing Considerations should refer to "Basic Data Types" not "primitive" CPP11 1.7 CPP11 1.7 Resolved closed
CPP1117-14 bit_bound CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-12 Add bit_bound/underlying_type for enum traits CPP11 1.6b1 CPP11 1.7 Duplicate or Merged closed
COMMONS11-8 Rename the new composites ontology to roles and compositions COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-4 Several OMG and external projects need a pattern for representing compositions COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-3 Need to add start and end time and explicit time period in Commons COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-1 Several OMG task forces have a need for a common ontology for quantities and units COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-5 Several OMG and external projects need a pattern for representing parties, the roles that they play and situations in which they are involved in COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-2 Need an ontology representing multidimensional arrays COMMONS 1.0b2 $issue.fixedSpecification.name Deferred closed
CSRM11-5 xmi profile CSRM 1.0b2 CSRM 1.1b1 Deferred closed
C2INAV12-1 Use @key instead of @Key C2INAV 1.0 C2INAV 1.2 Resolved closed
COMMONS-12 The properties in the collections ontology are confusing to users Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-11 Need to be able to indicate whether or not something can only be classified by a single classifier from a specific scheme Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-3 The format of the tables throughout the specification needs improvement Commons 1.0a1 COMMONS 1.0 Closed; No Change closed
COMMONS-18 There needs to be an additional usage note on Text in the TextDatatype ontology with a stronger warning Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-16 Revise the abbreviation for the AboutCommons "make file Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-19 CodeSet should be a subclass of arrangement Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-14 Revise the version IRI for all of the Commons ontologies to agree for finalization purposes Commons 1.0a1 COMMONS 1.0 Closed; No Change closed
COMMONS-9 The constraint on a classifier that says it must classify something is too restrictive Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-2 The terms and definitions section of the Commons Ontology Library is incomplete Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-1 The use of rdfs:isDefinedBy is inconsistent in the annotation vocabulary Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-26 Revise the definition of designation to better align with the latest version of ISO 1087 Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-4 Some of the diagrams in Clause 8 are difficult to read Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-6 Some of the commons ontologies include double spaces in annotations Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-5 Examples are needed to help explain to Commons users how to use the ontologies Commons 1.0a1 COMMONS 1.0 Resolved closed
CORBA34-451 Ordering of user exception and return values CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-450 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-453 CORBA section 11 struct PortableGroup::GroupInfo CORBAe 1.0b1 CORBA 3.4 Deferred closed
CORBA34-447 What should Automation View accept in bounded sequences? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-445 Section 4.1.12: DICORBA TypeCode::kind CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-446 Standard ProgramId CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-449 Section 4.1.18.5 enum should be named CORBA_CompletionStatus CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-448 VB cannot handle array out-parameters CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-443 Add CORBATCKind to end of enum list CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-442 Return value type of DICORBATypeCode::member_type should be changed CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-440 page 2-25 contradicts first sentence of 3rd full para on p 4-106 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-441 uuid for DForeignException has an extra 0 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-444 Remove EX_repositoryID readonly property from IForeignException CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-435 boundary violations should cause View to propagate DISP_E_OVERFLOW CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-433 page 4-129, section 4.1.17: change term "CORBA proxy" CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-434 page 4-129, section 4.1.17.1: retval attribute CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-432 INSTANCE_Clone does not need an in-parameter CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-439 ODL is erroneous CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-438 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-437 page 2-30: There is a label "Examples", but no examples CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-436 page 4-109, section 4.1.5.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-425 "Safe" keyword identifier issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-426 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-427 Section 5.5 Interface repository (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-424 Can Value type inherit from Value Box type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-429 Can value type inherit from Value Box type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-430 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-428 Section 5.5 Interface repository (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-431 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-419 describe_value() operation issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-418 Missing member_kind and member_tc CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-421 p.6.68 boxed values of complex types map to same type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-423 New lexical type - Keyword Identifie CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-422 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-420 Value type ansd Value Box"s single data member name CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-411 Semantics of computing the hash code.. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-410 Concrete value class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-412 Section 5.6.3 Hashing Algorythm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-414 Repository Id (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-415 Section 5.6.2 Repository Id CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-413 Repository Id (03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-417 Type code issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-416 Clarify the hash code algorithm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-405 Section 7.3.10 Value Factories CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-407 Section 7 C++ Language mapping CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-406 Java mapping example and C++ mapping example CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-404 Why is ValueBase a value and not a native type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-408 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-409 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-398 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-399 Editorial: p 5-50 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-400 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-403 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-401 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-402 Editorial page 8-107 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-395 Keyword identifiers (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-397 Can public modifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-396 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-391 No portable way to obtain list of type safe repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-393 Keyword Identifiers(03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-392 Keyword identifiers (04) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-394 Keyword identifiers (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-384 OBV "chunking" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-387 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-385 Can "public" mofifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-386 Typo on page 8-107 of OBV specification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-388 Narrowing from abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-389 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-390 Marshaling engine issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-379 OBV spec inefficient for dending large number of small objects CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-378 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-377 Forward declaration of value boxes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-376 TypeCodes for values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-380 OBV C++ problem with "supports" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-382 TypeCodes defined in section 5.8.2 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-381 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-383 CDR Streams CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-370 P 5-44: use of base type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-371 OBV TypeCode parameters wrong CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-368 No typecodes for abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-369 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-373 Custom marshalling support for IDL fixed type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-374 Default constructor for Java values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-372 C++ boxed value member clashes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-375 Boxed values need extension to write_Value call CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-363 Status of hashed repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-362 "Tool" issue for IDL compilers too complex CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-361 ValueHelper Interface issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-367 TypeCode complexity for value types CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-366 Memory Management for Value Factories Unspecified CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-364 OBV init CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-365 CodeBase interface uses undefined type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-353 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-351 Section number: 3.3.4 and elsewhere CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-352 Title does not cover the use of SS7 as signaling transpor CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-355 passthrough connection CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-354 issue with TCPfirewallMechanism CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-356 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-357 The values of these tags need to be assigned CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-360 Minimum CORBA and POA CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-345 Section number: 4.2.1 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-349 Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-348 Section number: 3.5.1.1, item 3 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-347 How can we bound the range of invoke ids in the IDL? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-346 It should be possible to have negative invoke ids CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-350 Section number: 3.3.4 make factory creation operations conform to the IDL CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-341 Section 4.3.2.1 Title and text should be changed CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-340 Section 4.7.1: RelativeRoundTripPolicy CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-344 Problem: Why is AssociationId a string? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-342 There is a difference between the responder and initiator interfaces CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-343 The current text for DialogFlowCtr is for outgoing only CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-337 Section number: 5.4.1 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-336 Shouldn’t it be typedef string CORBA::ScopedName? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-335 Section number: Fig. 27 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-339 Shouldn’t this section really be called TC Service Interface? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-338 Section number: 5.2 and other sub-sections CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-328 Bi-Directional GIOP: which connections may be used? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-329 Section number: 2.3 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-333 Should SIOP version number start with 1.2? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-331 Problem: There is no way to send dialogue data in a continue confirm. CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-332 Section number: 6.2.2 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-330 Section number: 5 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-334 Could SIOP be changed to 7IOP, pronounced "seven-up"? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-325 Firewall POA Policy does not control access CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-323 new_target CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-322 new_callback CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-324 Firewall Traversal algorithm CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-327 Bi-Directional GIOP: Masquerade security issue needs to be more explicit CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-326 Outgoing local port in Bi-directional IIOP CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-320 Proxified object references CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-318 Clarification is needed on the passing of credentials CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-319 Reusing PASSTHRU CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-321 How to obtain initial reference to the GIOPProxy object CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-311 TcPdu User and Provider interfaces CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-313 Why one to one association between a TcPduUser and TcPduProvider interface? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-312 Specification Translation from ASN to IDL issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-316 Traversal algorithm not sufficient CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-317 Problems with routing and/or traversal of firewalls. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-314 When does a multiassociation TcUse know that it has been finished with? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-315 Use of InvokeId as the type name for both invoke id and link id. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-305 BiDir GIOP Policy Clarification CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-306 Use of PolicyType id CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-309 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-307 Missing definition on security tags in the SIOP CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-308 There is currently no valuetype support in SIOP. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-310 use of the SSN number in the 1988 TCAP version CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-299 Discrepancy in the changes proposed to CSIIOP and CSI modules CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-298 GIOP version 2.0 issue CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-300 Bidirectional Policy insufficient for persistent objects CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-301 Server Authentication CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-304 MAIN_THREAD_MODEL questions CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-303 Negotiate Session Message Orientation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-302 Negotiation Session message is unwieldy CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-290 Implications about BiDirIds CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-291 paragraph limits use of BiDirOfferContext CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-292 Negotiate Session Message Issues CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-293 CodeSet issue (05) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-296 CodeSet issue (02) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-295 CodeSet issue (03) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-297 CodeSet issue (01) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-294 CodeSet issue (04) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-284 What BiDirIds shall be sent over what bidirectional connections? CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-285 Interplay of Contexts allowed in NegotiateSession messages too ill-defined CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-283 Firewall FTF Issue: No ene-to-end security for firewall traversal CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-286 Firewall Issue: Random BiDirIds can't be used for persistent POAs CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-287 Firewall Issue: Connection over which BiDir offers are sent is unspecified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-288 Firewall Issue: Response to failed BiDir challenge is unclear CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-289 Firewall issue - Number of BiDirIds in a BiDirOffer CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-275 use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-277 Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-276 Bi-directional connections considered volatile at connection acceptor side CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-279 connection_complete field of the FirewallPathRespContext is under specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-278 How many BI_DIR_GIOP_OFFER service contexts are allowed CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-281 Targets of Export and Offer Policies incompletely specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-280 Expected behavior of a non-conformant implementation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-282 Processing of NegotiateSession messages at various stages of connection set CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-269 Multiple objects on a stream CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-270 Definition of stream portability CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-273 Lifecycle Key type definition CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-272 Stream contexts and internalization CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-271 Start and end of context tags CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-274 when is a connection a "bi-directional connection"? UML 2.0 CORBA 3.4 Deferred closed
CORBA34-264 Coordinator remembering LockCoordinator CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-263 Input values for "which" arg of non-trans. LockCoordinator CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-265 Freeing of locks at the end of a transaction CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-266 Getting the thread ID in a non-transactional lock request CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-267 Communication failure issue CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-268 Timeout while locking CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-255 CosCompoundExternalization Service CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-256 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-257 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-260 CosGraphs::deep CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-261 Common format on stream CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-259 performing a compound copy of relationship CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-258 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-262 Using local thread identification for concurrency CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-249 Internalizing roles-IDL optimization CORBA 2.1 CORBA 3.4 Deferred closed
CORBA34-250 Who is responsible for releasing locks in transaction? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-252 Purpose of related LockSet CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-253 CosCompoundExternalization Service (3) CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-251 Which model should ConcurrencyControl support? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-254 CosCompoundExternalization Service (2) CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-244 QueryCollection::Collection -- finding index CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-245 Query Collection::Collection -- Sharing State CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-248 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-247 QueryCollection::Collection -- membership scoping CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-246 QueryCollection::Collection -- Adding multiple elements CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-237 Questions on CosQuery::QueryableCollection interfaces CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-240 QueryCollection::Collection -- reset() exceptions CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-238 QueryCollection::Collection -- keyed collections CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-239 QueryCollection::Collection -- next_n() CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-241 QueryCollection::Collection -- destroy methods CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-243 QueryCollection::Collection -- Iterator Position Invalid CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-242 QueryCollection::Collection -- iterator updating CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-229 Query language for operations CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-232 Definition of NULL in datafiles without NULL as a concept CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-230 Delegating iterator functionality to the RDBMS CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-233 Clarification request for section 11.1.5 CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-231 retrieve_element CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-234 How do iterators handle changing of the data they are pointing at CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-236 Use of MD5 on arguments CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-235 Updating information via query iterators CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-221 Inconsisten IDL in the Minimum CORBA chapter CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-223 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-222 Correction of CORBA specification (page 18-51) CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-224 WWW Form output CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-227 interface QueryEvaluator { CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-225 Malformed PropertyName CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-228 OQS relation to POS CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-215 COM/CORBA keywords CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-220 CosExternaliazation Service (bug?) CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-218 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-219 CosConsurrencyControl service bug or not? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-216 Compiler being able to translate from OMG-IDL into ANSI CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-213 Unclear and possibly harmful consequences of mandatory annotation definitions CORBA 3.1.1 CORBA 3.4 Deferred closed
CORBA34-212 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-214 Fixed Types in COM CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-207 How does DynValue handle derived valuetypes? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-205 Spec doesn't make clear what is valid mix of policies and what is invalid CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-206 messaging router issue CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-211 valuetypes and local interfaces CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-210 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-209 CORBA 3.02, page 11-25, section 11.3.6 CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-208 module SendingContext CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-199 rules for marshalling ValueBoxes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-198 BNF changes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-200 Problem with ServerRequestInterceptor::receive_request and DSI CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-201 restriction of where a valuetype chunk can end CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-202 Bad text in 22.6 mandates Routing for sendc/sendp CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-203 What is the RSC when using a PersistentPoller CORBA 3.0.1 CORBA 3.4 Deferred closed
CORBA34-204 Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-195 Codec Interface Deficiencies CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-194 methods on the POA CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-193 Add a typedef for the POAManager id CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-196 An extension of IOR to protect target objects Nature CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-197 Mapping from -ORBxxx to Java properties does not work for -ORBInitRef CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-189 The POA state inactive is not used consistent. CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-188 CORBA 3.0.3 ch. 3.4 OMG IDL Grammar CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-191 argument of the set_servant call has a small typo CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-187 Section: 4.3.13 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-192 change in the POAManager CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-180 Issue: CSIv2 Identity Assertion CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-181 Polymorphic Valuetypes and the DII CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-182 DynValue & custom valuetypes CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-185 Code Set Conversion on Operations CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-184 Potential deadlock with POA::deactivate_object() CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-183 Custom Value Marshaling Issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-186 Appendix A CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-174 ForwardRequest is impossible to detect in clients CORBA 2.6.1 CORBA 3.4 Deferred closed
CORBA34-177 Avoiding RSC/TSC copy on server side CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-178 Implications of any/valuetype marshalling CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-176 Proposal for extension to CosNaming CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-175 New issue: ForwardRequest() CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-179 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-170 rule (85) is misplaced CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-173 processing TaggedComponents within an IOR CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-171 Bad quotes and imported dot CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-172 missing document title CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-162 Section: 4.8.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-163 move struct to IOP module CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-164 Add create_policy with just the type as argument CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-165 context should be local interface CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-169 Make anonymous types illegal CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-166 Redundant bullet CORBA 3.2 CORBA 3.4 Deferred closed
CORBA34-168 interface ORB should be local CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-156 There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-155 Section: 21.3.13 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-157 16.10 lists register_initial_reference CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-161 Section: 21.7.3 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-159 add CORBA::ORB::arg_list CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-158 add interface ORB { Object string_to_object ( in wstring str ); }; CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-160 Section 13.7 ServiceContext CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-147 Section: Part 2, Chapter 11 - MIOP CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-149 definition of Invalid Policies changed CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-148 mention of (deprecated) function get_implementation removed from text CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-152 Proposal to change PortableInterceptor::ReplyStatus to a real enum CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-151 Proposal to change PortableInterceptor::AdapterState to a real enum CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-153 Section: 15.4.2/16.4.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-150 Third line of 23.1.3.4, ACTIVE must be bold CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-154 Section: 13.6.10.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-142 Missing PolicyValue encoding instructions ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-143 Invalid IDL (2) ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-145 Two typo's in Annex A.4 CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-144 Invalid IDL ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-146 struct PolicyValue CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-137 Section: 7.4 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-140 Moving *Seq typedefs into ORB chapter CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-139 Minor code ambiguity CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-141 Missing size information for decompress() ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-138 Typo in sections 22.10.1.1 and 22.10.1.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-132 Section: 21.7 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-133 update the spec to not used anonymous types CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-131 Section: 21.9.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-130 Section: 21.4.3.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-134 Section: 4.2 (02) CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-135 Section: 4.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-136 Section: 13.6.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-124 FullInterfaceDescription and base_interfaces question CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-121 Allowing mutual recursion for IDL structs - clarification needed CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-122 CORBA Exceptions CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-123 Section: 11.3.9.16 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-129 Section: 11.3.9 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-128 Section: 22.16/ CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-126 Page: 21-43 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-127 Section: 22.11.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-115 Page: 7-7 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-116 Page: 9-1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-117 Page: 21-5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-119 Section: 21.3.14.11 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-120 Section: 4.5.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-118 Section: Appendix A CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-110 69.8.2.8 The simple Element, page 69-538 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-111 Section: Chapter 9, Chapter 5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-112 Section: Chapter 11 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-113 Allowing Mutual Recursion for IDL Structures CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-114 NVList Section: 7.5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-103 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-104 69.3 Software Package Descriptor CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-105 Add the capability to define a component artifact property CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-107 69.8.2.9 The sequence Element CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-106 Test Property - add a test property definition to the properties DTD CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-108 69.8.2.3 The choices Element, page 69-537 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-109 69.8.2.7 The range Element, pages 69-537/538 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-96 Component Artifact Dependency CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-95 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-100 69.3.2.25 The propertyfile Element, page 69-482 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-97 69.3.2.2 The author Element, page 69-474 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-99 69.3.2.14 The idl Element, page 69-478 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-98 Descriptor CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-102 69.8.2.7 The code Element, pages 69-474 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-101 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-89 lwCCM issues - abstract storage type CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-91 lwCCM issues - entity components CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-92 lwCCM issues - persistence CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-90 lwCCM issues - section 4.1.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-94 lwCCM issues - transaction CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-93 lwCCM issues - security CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-88 lwCCM issues - abstract storage home CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-87 lwCCM issues - CIDL CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-86 lwCCM issues - locator CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-85 lwCCM issues - segmentation CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-79 lwCCM issues - home finders and finder operations CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-80 lwCCM issues - proxy homes CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-78 lwCCM issues - invalid rows CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-83 lwCCM issues - primary key CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-84 lwCCM issues - get_all_facet, ... CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-82 lwCCM issues - Section 4.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-81 lwCCM issues - configurators CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-71 Checking XML DTD elements related to the trader service CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-72 Description for the impltype Element? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-74 Uses Relationships CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-73 69.3 AssemblyFactory Interface CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-75 Device Artifact Dependency CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-76 Dependency on D+C FTF CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-77 lwCCM issues - Entity2Context CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-68 A new exception specification is needed for CCM2Context::req_passivate() CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-65 CCM IDL style inconsistency CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-66 Derived component supported interface restriction (formal/2002-06-65) CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-67 Issue on the description of the consumesidentifier element CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-70 Using Configurator on CCMHome or any CORBA objects? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-69 [CCM] Interface Repository Metamodel CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-59 Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3 CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-60 Section 6.4.5.10 (page 6-26) CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-62 CCM spec: insufficient examples of component attributes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-64 multiple lifetime policies declaration issue CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-63 3.2.7 Compositions with Managed Storage CCM 3.0 CORBA 3.4 Deferred closed
CORBA34-61 Section 6.4.5.52 (page 6-38) CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-56 'local executor mapping' CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-55 portability of CCM descriptors CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-54 EnterpriseComponent should have a get_servant method CCM 3.0 CORBA 3.4 Deferred closed
CORBA34-58 issue on component supporting abstract interfaces CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-57 CCM Spec: attributes are listed in the ports section? CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-48 EnterpriseComponent should have a set_persistent_object method CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-47 HomeExecutorBase should have a set_context method CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-49 Generic connectivity for Receptacles, Emitters, Publishers CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-50 HomeExecutorBase should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-51 EnterpriseComponent should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-52 The association of entity component primary key and PSS key is unclear CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-53 HomeExecutorBase should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-44 Contradictory sections in the CCM and Lightweight CCM specifications CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-41 spec should define how the base class of an executor is generated by the framework ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-43 The D&C IDL part doesn't match 06-04-02. CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-42 add a sequence of CCMHome typedef sequence CCMHomes; CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-46 add some feature to let an assembly look like a monolithic compoment CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-45 "supports" keyword CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-36 two not used and document exceptions listed ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-38 Event mechanism proposal ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-39 typedef CCMObjectSeq ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-40 The spec mentions InvalidConfiguration as exception but there is no idl in this spec ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-37 ResourceCommitmentManager lacking ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-31 CCMHome should have a get_components method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-32 CCMHome should have a get_container method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-33 Incorrect statement that implies that connect_consumer returns a cookie ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-34 HomeConfiguration::set_configuration_values should document exception ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-25 Interface Introspection CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-27 Generic port connections CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-26 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-29 HomeConfigurator should not extend CCMHome CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-30 Session2Context interface CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-28 LwCCM issue - Section 1.6.8 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-19 page 1-20 and page 1-21 - editorial CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-23 Change new GIOP Negotiate Session Message to Firewall Specific CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-22 GIOP Conformance and Interceptors CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-21 context interface for home implementation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-20 page 1-20 the description of the get_connection operation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-24 CodeSet and CSIv2 Negotitaion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-13 valuetype fragmentation ambiguous CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-14 Clarification on multi-threaded codeset negotiation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-15 15.3.3 - codesets must be "explicitly defined" CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-16 [Components] Contradiction between IDL and Interface Repository concerning CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-17 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-18 page 1-20 second bullet of the description of the disconnect operation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-7 Duplicate union labels CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-6 COM Sequence changes CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-8 Changes to ForeignComplexType CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-9 Section 13A.5.2: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-10 Section 13A.2.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-11 Capter 13C: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-12 Incorrect mappings for systems exceptions (part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-5 Section 13C.1.3 Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-4 Levels of Indirection for passing COM types CORBA 2.0 CORBA 3.4 Deferred closed
CSRM-14 Additions for convenience methods CSRM 1.0b2 CSRM 1.0 Resolved closed
CSRM-31 Add comments to 7.6.3 ExtRequirement source/Risk elements CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-28 MeasurementSpecification missing documentation CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-26 VerificationActivity missing documentation on verificaionMethod CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-3 Change 7.6 SysML Extentions CSRM 1.0b1 CSRM 1.0 Closed; No Change closed
CSRM-2 Add relationship convenience attribute for Validated and other relationships CSRM 1.0b1 CSRM 1.0 Duplicate or Merged closed
CSRM-41 Modify Paragraph 2 to remove redundant reference to the machine readable file. CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-35 Clarify usage of Group stereotype CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-11 Change names from CubeSat to Satellite CSRM 1.0b2 CSRM 1.0 Closed; No Change closed
CSRM-17 Remove Section 0 (zero) CSRM 1.0b2 CSRM 1.0 Closed; No Change closed
CSRM-8 This issue created by mistake CSRM 1.0b2 CSRM 1.0 Closed; No Change closed
CSRM-12 Recommended Additions CSRM 1.0a1 CSRM 1.0 Deferred closed
CSRM-4 Add constraints to aid in correctness of profile useage CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-9 Change names from CubeSat to Satellite. CSRM 1.0b1 CSRM 1.0 Closed; No Change closed
CSRM-5 Create examples of use of the profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-1 Icons for profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-16 Remove Section 0 from the document CSRM 1.0a1 CSRM 1.0 Closed; No Change closed
CORBARS_-1 Provide a simple sample application CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
CORBARS_-2 Provide example of authentication and security CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
C2INAV11-1 FTF-1 changes to be applied to GraphQL PSM C2INAV 1.0a1 C2INAV 1.1 Resolved closed
C2INAV11-3 Update GraphQL PSM Mapping C2INAV 1.0 C2INAV 1.1 Duplicate or Merged closed
CPP1116-19 Add mapping for @optional CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-20 Impact of @final on union/struct mapping CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-11 Add IDL::traits<>::bit_bound CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-12 Invalid constructor in example code CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-18 Use IDL::traits<>::make_reference instead of CORBA::make_reference CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-15 The page footers of https://www.omg.org/spec/CPP11/1.5/PDF (ptc-20-11-02.pdf) all say v1.4 CPP11 1.5 CPP 1.6 Duplicate or Merged closed
CPP1116-6 Struct inheritance mapping strange CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-5 Incorrect footer CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-7 IDL::traits missing for enum type for bitmask and use a C++11 strong enum CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-10 Remove std namespace from example code CPP11 1.5 CPP 1.6 Duplicate or Merged closed
CPP1116-9 Why not map bitset inheritance to struct inheritance CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-14 Missing override CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-8 Remove std namespace from example code CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-13 Missing override CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-3 Annotation for union discriminator name CPP11 1.5 CPP 1.6 Deferred closed
CPP1116-4 Add mapping for IDL4.2 standardized annotations CPP11 1.4 CPP 1.6 Deferred closed
CPP1116-1 Replace ServantBase with Servant CPP11 1.4 CPP 1.6 Resolved closed
CPP1114-29 Use C++11 using instead of typedef in all C++11 example code CPP11 1.3 CPP11 1.4 Resolved closed
CPP1115-18 IDL4 Extended Data-Types: struct inheritance CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-4 Add support for int8 CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-9 Example V_factory should list deleted assignment/copy CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-7 Copy/move assignment operators should be deleted CPP11 1.4 CPP11 1.5 Duplicate or Merged closed
CPP1115-6 valuebox should be final CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-5 Copy/move assignment operators should be deleted CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-8 Missing deleted assignment/copy operators CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-3 Operations tagged with override shouldn't have virtual CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-2 _default_POA should use override CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-1 Add support for bitset/bitfield/bitmask CPP11 1.4 CPP11 1.5 Resolved closed
C2MS-14 Data Dictionary Messages C2MS 1.0b1 C2MS 1.0 Deferred closed
C2INAV-45 No Depth Accuracy Information Available C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-43 Placement of surge,sway and heave within the spec C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-13 Declaration of keys missing from IDL files C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-12 Circular dependency between modules Reporting and Attitude C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-11 offset_report_type is declared out of order C2INAV 1.0a1 C2INAV 1.0 Closed; No Change closed
C2INAV-10 Missing import statements C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-9 Strings should have a maximum size C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-8 Class version numbers are inappropriate C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-7 All Ext child packages are in the same file C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-6 navigation_report_type: composite_contributors needs a Length tag C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-5 Add notes to the navigation_report_kind_type in the IDL/DDS PSM enum literals C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-18 There are no notes for the report relation of navigation_covariance_type C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-17 Depth Report not a specialisation of navigation_report_type C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-15 Reference from navigation_covariance_type to navigation_report_type needs a length C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-49 FTF-1 changes to be applied to GraphQL PSM C2INAV 1.0a1 C2INAV 1.0 Deferred closed
C2INAV-47 Rotation should be about the centre of rotation not the platform reference point C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-4 implementation defined is miss-spelled C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-3 Accuracy compositions should have notes C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-2 write_rotational_attitude is not correctly entered in the UML model C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-1 navigation_covariance_type should have a max length C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-21 Unclear which OARIS files are required C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-20 Duplicate declaration from overloaded operation names C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-19 navigation_report_kind_sequence_type in unbounded in DDS PSM C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-16 Type mismatch in reference to navigation_report_type C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-14 Only top-level attributes can be declared as keys for DDS topic types C2INAV 1.0a1 C2INAV 1.0 Resolved closed
CORBA34-2 Extract IDL details from CORBA spec CORBA 3.3 CORBA 3.4 Resolved closed
CORBA34-1 Valuetypes should be added to the list of scopes CORBA 3.3 CORBA 3.4 Closed; Out Of Scope closed
C2MS-62 Specify multiplicity for required and optional fields C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-61 Add documentation within the model C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-60 "Mnemonic" should be called "Parameter" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-59 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-44 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-42 Pub/Sub subscription status unknown C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-41 Acknowledge Final Status inconsistency C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-39 XML PSM recommended C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-15 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-13 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-11 Archive Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-9 C2CX Heartbeat comments C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-3 Lack of a registry concept C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-36 Fix C2CX Device message, field NUM-OF_DEVICES C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-84 Merge figures 8-1 and 8-2 C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-83 Add (back) Simple Service request and response messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-82 Change HEADER-VERSION and CONTENT-VERSION default values to 2019 in all Message Diagrams and all Message Contents tables C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-81 Add DESTINATION-COMPONENT field to the header and to the Miscellaneous Elements of REQ, RESP, and MSG messages that are associated with a REQ C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-80 Add field MSG-VERSION to the header C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-79 Add request-id to be one of the Miscellaneous Elements in subjects of MSG type messages that may be in response to a request C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-78 Add another row in the table, for operator entered log messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-57 Figure 7-1, C2MS Message Exchange Patterns Diagram, misspells RESPONSE C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-40 Non-satellite-related messages are not representable C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-25 Change the type info for a field in the C2CX Device message C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-24 Add Command Echo message C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-21 In Heartbeat message: fix typo in the name of the field CONNECTION-ENDPOINT C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-20 space/18-02-05 (C2MS zip file for XML schemas) contains corrupt file C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-19 space/18-02-03 XMI file doesn't 'validate' C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-17 use of color is discouraged C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-16 space/18-02-05 (C2MS zip file for XML schemas) - zip file unreadable C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-12 Product Messages comments C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-10 Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-43 Modifying a subscription is undefined C2MS 1.0b1 C2MS 1.0 Duplicate or Merged closed
C2MS-23 Flatten the message hierarchy re: C2CX, TLM, and NDM messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-22 Make sure CCSDS info is consistent and current C2MS 1.0b1 C2MS 1.0 Closed; No Change closed
C2MS-18 page numbers in early sections are messed up (i, ii, i, iii, etc.) C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-8 Directive Request: strings, UNIQUE-ID and correlation IDs C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-7 Change comments regarding signed types C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-6 Have required attributes in the messages C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-5 Acknowledge Final Status is not deterministic C2MS 1.0a1 C2MS 1.0 Closed; No Change closed
C2MS-4 Subject naming missing the concept of something not being directly tied to a satellite C2MS 1.0a1 C2MS 1.0 Closed; No Change closed
C2MS-2 Should GMSEC API enforce/recommend XML-formatted string constructor usage? C2MS 1.0a1 C2MS 1.0 Closed; Out Of Scope closed
C2MS-1 Expecting that GMSEC will change to use C2MS as its Subject Standard C2MS 1.0a1 C2MS 1.0 Closed; Out Of Scope closed
CPP1114-31 Add Delegation-Based Interface Implementation CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-14 Remove the setter operation for the discriminator of a union CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-12 Bullets before IDL::traits::narrow(ap) lost CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-9 OBV_Example constructor CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-8 Text alignment CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-7 Typo fixes CPP11 1.3b1 CPP11 1.4 Resolved closed
CPP1114-13 Only single argument constructors have to be explicit CPP11 1.3 CPP11 1.4 Closed; No Change closed
CPP1114-4 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-3 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.4 Resolved closed
CPP1114-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-1 In-place construction of structure types CPP11 1.0 CPP11 1.4 Closed; No Change closed
CPP1114-11 Reduce indent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-10 Alignment _is_a and _non_existent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-5 Structure mapping change should be reverted CPP11 1.2 CPP11 1.4 Closed; No Change closed
CPP1114-6 Fixed is now broken CPP11 1.2 CPP11 1.4 Resolved closed
CORBA31-112 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 CORBA 3.1 Deferred closed
CPP1113-11 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.3 Deferred closed
CPP1113-6 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-7 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-5 In-place construction of structure types CPP11 1.0 CPP11 1.3 Deferred closed
CPP1113-10 Example C++ code in mapping for constants should use C++11 uniform initialization CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-1 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.3 Resolved closed
CPP1113-9 Fix assignment operator of ColorValue CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-8 CORBA::make_reference shouldn't explicitly imply perfect forwarding CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-4 Handle possible exception what conflict and improve Exception introduction text CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-3 Trivial grammatic fix in 6.14.1 CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-2 minor accessors of SystemException should use pass by value, minor should be uint32_t CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-13 Only a namespace level swap should be provided CPP11 1.2 CPP11 1.3 Resolved closed
CR-89 Tasks with RepetitionRule: how to restrict the number of task instances (at a given time)? CMMN 1.1 CMMN 1.1 Resolved closed
CR-141 DI Chapter Editorials CMMN 1.0 CMMN 1.1 Resolved closed
CR-140 Change the Notation of the OnPart so it does not conflict with Association CMMN 1.0 CMMN 1.1 Resolved closed
CR-143 Editorial to section 5.1.5 CMMN 1.0 CMMN 1.1 Resolved closed
CR-131 Need for annotations and comments in CMMN CMMN 1.0 CMMN 1.1 Resolved closed
CR-133 Need the ability to have repetition rules in Tasks and Stages without entry criterion CMMN 1.0 CMMN 1.1 Resolved closed
CR-137 Editorial: Update Table 2.1 - Conformance matrix CMMN 1.0 CMMN 1.1 Resolved closed
CR-128 Expressiveness of Task patterns CMMN 1.0 CMMN 1.1 Deferred closed
CR-127 Depicting Inputs and Outputs to Tasks CMMN 1.0 CMMN 1.1 Deferred closed
CR-126 Exit Criterion may be misleading (as a name or concept) CMMN 1.0 CMMN 1.1 Deferred closed
CR-124 Need to add names to contributors CMMN 1.0 CMMN 1.1 Resolved closed
CR-118 Missing constraint to prevent Human Task from being discretionary to itself CMMN 1.0 CMMN 1.1 Resolved closed
CR-98 Create classes to hold entry and exit criterion references CMMN 1.0 CMMN 1.1 Resolved closed
CR-96 Add name attribute to OnPart CMMN 1.0 CMMN 1.1 Resolved closed
CR-92 Inconsistency between XSD and meta-model for condition on IfPart CMMN 1.0 CMMN 1.1 Resolved closed
CR-90 Missing attribute “name” for Process CMMN 1.0 CMMN 1.1 Resolved closed
CR-110 Missing "externalRef" in Process class CMMN 1.0 CMMN 1.1 Resolved closed
CR-104 Some figure in chapter 6 do not use the new Discretionary Association CMMN 1.0 CMMN 1.1 Resolved closed
CR-101 XSD Doesn't allow DiscretionaryItem to have entry/exit criteria CMMN 1.0 CMMN 1.1 Resolved closed
CR-107 Confusing Planning Table on figure 6.63 CMMN 1.0 CMMN 1.1 Resolved closed
CR-94 Add a new discretionary association CMMN 1.0 CMMN 1.1 Resolved closed
CR-87 We should add a Decision type task CMMN 1.0 CMMN 1.1 Resolved closed
CR-76 Missing PlanningTable on the CasePlanModel of figure 6.63 CMMN 1.0 CMMN 1.1 Resolved closed
CR-74 Missing notational element for discretionary Milestones and discretionary EventListeners CMMN 1.0 CMMN 1.1 Deferred closed
CR-67 Expression description prevent constant expressions CMMN 1.0 CMMN 1.1 Resolved closed
CR-69 CMMN does not include the notion of swim lanes CMMN 1.0 CMMN 1.1 Deferred closed
CR-120 Typo in the xsd: in Task we have inputs and outputs instead of input and output CMMN 1.0 CMMN 1.1 Resolved closed
CR-116 Missing attribute "name" in the XSD for ApplicabilityRule CMMN 1.0 CMMN 1.1 Resolved closed
CR-114 Missing authorizedRoleRefs in XSD for tUserEventListener CMMN 1.0 CMMN 1.1 Resolved closed
CR-21 CMMN needs to support Diagram Interchange CMMN 1.0 CMMN 1.1 Resolved closed
CR-14 Ambiguous OnPart references for cross-stage-boundary plan items CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-7 CMMN spec inconsistent with respect to Sentry dependencies crossing Stage boundaries CMMN 1.0 CMMN 1.1 Resolved closed
CR-3 Undesired limitation on PlanItemDefinitions CMMN 1.0 CMMN 1.1 Resolved closed
CR-23 Evaluation/Re-evaluation of RequiredRule unclear - what does "maintained" mean? CMMN 1.0 CMMN 1.1 Resolved closed
CR-19 Incorrect Example image CMMN 1.0 CMMN 1.1 Resolved closed
CR-82 Unrequired “body” element in expression in the XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-79 Terminology inconsistency between Metamodel and XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-78 EventListeners erroneously listed for RequiredRule CMMN 1.0 CMMN 1.1 Resolved closed
CR-72 XML-Schema tCaseFileItem definitionRef attribute must not be mandatory CMMN 1.0 CMMN 1.1 Resolved closed
CR-70 CMMNElement should have Documentation CMMN 1.0 CMMN 1.1 Resolved closed
CR-88 We should allow for the State of a file item to be placed in [Square] brackets CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-75 CMMN XSD - Inconsistent with the spec text CMMN 1.0 CMMN 1.1 Resolved closed
CR-77 Issue with Human Task XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-35 Unclear CasefileItem TargetRef and SourceRef and instance operations referring to them CMMN 1.0 CMMN 1.1 Resolved closed
CR-34 XSD attribute "processRef" MUST be required CMMN 1.0 CMMN 1.1 Resolved closed
CR-27 Extensibility of DefinitionTypeEnum and Property types CMMN 1.0 CMMN 1.1 Resolved closed
CR-20 CMMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions) CMMN 1.0 CMMN 1.1 Resolved closed
CR-15 Timerevent based on data not possible CMMN 1.0 CMMN 1.1 Resolved closed
CR-13 Unclear when an IfPart only sentry must be evaluated CMMN 1.0 CMMN 1.1 Resolved closed
CR-12 CaseTask.CaseRef should allow for expressions to support dynamic subcases CMMN 1.0 CMMN 1.1 Resolved closed
CR-11 Sentry behavior for OnParts referring to Repeating PlanItems is unclear CMMN 1.0 CMMN 1.1 Resolved closed
CR-8 PerformerRole should be applied to PlanItem rather than HumanTask CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-5 Discretionary Items should also have a Name property CMMN 1.0 CMMN 1.1 Resolved closed
CR-1 Inconsistencies between class diagram figures and attribute tables CMMN 1.0 CMMN 1.1 Resolved closed
CR-16 Two entry criteria cannot be connected CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-46 Mislabled table CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-53 Table labeled as a figure in page 40 CMMN 1.0 CMMN 1.1 Resolved closed
CR-59 Usage of Terminate state as Completion CMMN 1.0 CMMN 1.1 Resolved closed
CR-55 Reference missformated CMMN 1.0 CMMN 1.1 Resolved closed
CR-57 Future sentence in specification CMMN 1.0 CMMN 1.1 Resolved closed
CR-26 Missing "decimal" type in table 5.7 property types and their URIs CMMN 1.0 CMMN 1.1 Resolved closed
CR-22 Non-normative References do not include CMIS CMMN 1.0 CMMN 1.1 Resolved closed
CR-10 Table 7.9 contains invalid "To state" values for Resume transition CMMN 1.0 CMMN 1.1 Resolved closed
CR-9 Typo in specification, unclear what is intended here CMMN 1.0 CMMN 1.1 Resolved closed
CR-6 PlanItemControl of discretionaries should also allow repetitionrules CMMN 1.0 CMMN 1.1 Resolved closed
CR-4 "The construct in Figure 6.35" should be Figure 6.34 CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-2 The scope does not clarifies the relationship between CMMN and BPMN CMMN 1.0 CMMN 1.1 Resolved closed
CR-25 Missing reference to XML Schema and XPath specification CMMN 1.0 CMMN 1.1 Resolved closed
CR-24 CaseRoles have ugly definition in the XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-18 Incorrect References CMMN 1.0 CMMN 1.1 Resolved closed
CR-17 Inputs/outputs on task CMMN 1.0 CMMN 1.1 Closed; No Change closed
ITCR-57 Fix unclarity in IDL Union description CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-54 Update normative reference to point to CORBA 3.3 CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-38 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-28 Servant argument passing not precise enough CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-39 Missing public specifier CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-42 replace POA_B by adequate skeleton CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-41 _this for skeleton, not for implementation CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-44 Skeleton class as consistent template parameter for CORBA::servant_traits CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-43 abstract interfaces with corrected skeleton name CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-3 Errors on code snippet related to skeleton classes CPP11 1.0 CPP11 1.2 Resolved closed
ITCR-1 In-place construction of structure types CPP11 1.0 CPP11 1.2 Deferred closed
ITCR-12 Clarify valuetype factory mapping CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-11 Valuebox should also have swap support CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-8 provide unique class name as mapping of PortableServer::Servant CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-7 Constructor declarations in Servant code are wrong CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-6 Destructors of strong reference types should be public CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-17 Mention move constructor with abstract CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-16 usage of OBV trait should be improved CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-10 Add missing default initialization for valuetypes CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-9 wrong return type for Foo::some_function() CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-5 Question on unions default member CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-4 Code fragment should use skel class CPP11 1.0 CPP11 1.2 Closed; No Change closed
ITCR-15 Move constructor of ValueBase incorrect CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-14 Missing move assignment operator in class ColorValue CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-19 fixed member types use incorrect type CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-18 Destructor should just be virtual CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-13 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.2 Deferred closed
CORBA31-218 ZIOP has to be part of the core CORBA specification ZIOP 1.0 CORBA 3.1.1 Resolved closed
CORBA23-247 question re BiDir IIOP CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-246 New OBV "supports" keyword conflicts with CosLifeCycle CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-245 Abstract Interface issue (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA3-134 IDL keyword clash in CosNotification.idl CORBA 2.6 CORBA 3.0 Resolved closed
CORBA23-244 Query Service IDL code CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA25-57 CORBAservices IDL CORBA 2.2 CORBA 2.5 Resolved closed
COLL-12 CORBAservices (editorial page 17-23) COLL 1.0b1 COLL 1.0 Resolved closed
COLL-11 CORBAservices (editorial page 17-22) COLL 1.0b1 COLL 1.0 Resolved closed
COLL-10 CORBAservices (editorial page 17-21) COLL 1.0b1 COLL 1.0 Resolved closed
COBOL-6 Name scooping inappropriate within some mainframe environments COBOL 1.0b1 COBOL 1.0 Resolved closed
CORP-7 Change the VMM CORP 1.0b1 CORP 1.0 Resolved closed
CORP-6 Name of the model element for CORBAUnions CORP 1.0b1 CORP 1.0 Resolved closed
CORP-5 Add long double to the coverage of CORBA primitive types. CORP 1.0b1 CORP 1.0 Resolved closed
CORP-4 The UML 1.4 RTF may tighten the definition of a UML profile. CORP 1.0b1 CORP 1.0 Resolved closed
CORP-3 Namespace rules CORP 1.0b1 CORP 1.0 Resolved closed
CORP-2 The spec. doesn't say precisely which version of CORBA it is targeted to CORP 1.0b1 CORP 1.0 Resolved closed
CORBA23-243 OBV TypeCode problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA26-99 Include GIOP over Bluetooth into Wireless CORBA 1.1 CORBA 2.5 CORBA 2.6 Resolved closed
CORBA23-242 Module separator within repository IDs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-241 DynAny::get_value collision CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-240 Problem with C++ language mapping for OBV CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-239 public static org.omg.CORBA.ValueDef get_value_def(); CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-238 Clarify semantics CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-237 Which exceptions should be raised? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-236 Grammar rule issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-235 "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ] CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-234 CODESET_INCOMPATIBLE exception is not defined CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-232 Wide String (and String encoding) CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-231 IDL TypeExtension correction CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-233 IDL Type Extensions: DATA_CONVERSION exception CORBA 1.2 CORBA 2.3 Resolved closed
CORBA24-203 What should an ORB do when it does not find any profile in an IOR CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-202 Standard System Exception minor codes missing in Chapter 13 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-201 Component ids in 13.6.2.2 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-230 OBV chunk boundaries CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-200 Transmission of type codes across 2.2/2.3 boundaries CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-199 LOCATE_FORWARD_PERM and hash() CORBA 2.2 CORBA 2.4 Resolved closed
CORBA23-229 Clarification requested on GIOP 1.1 and wstring CORBA 2.2 CORBA 2.3 Resolved closed
CORBA31-217 Japan CORBA Part 2 PAS Ballot Comments - comment 12 CORBA 3.1 CORBA 3.1.1 Resolved closed
CPP11-266 20.17.9 Valuetype Inheritance CPP 1.0 CPP 1.1 Resolved closed
CPP11-265 sequence max < length CPP 1.0b2 CPP 1.1 Resolved closed
CPP11-264 Rounding and truncation of Fixed CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-263 Fixed-point initialization CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-262 C++ Servants: Adding Reference counting CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-261 Add _narrow() operation to each POA servant CPP 1.0b2 CPP 1.1 Resolved closed
CORBA23-228 TypeCode constants for bounded strings? CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-227 DynValue::get_members/set_members CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA24-198 IDL constant declarations CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-197 Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST CORBA 2.3.1 CORBA 2.4.2 Closed; No Change closed
CORBA25-56 SYNC_WITH_SERVER CORBA 2.4.2 CORBA 2.5 Closed; No Change closed
CORBA24-196 Changebars missing from POA chapter CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-226 Type code parameter ordering CORBA 2.2 CORBA 2.3 Resolved closed
CORBA21-113 RMI repository ID references to serial version UID CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-112 Second bit of response_flags CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-111 Issue: Problem with issue 2801 resolution CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-110 fragmentation broken with bi-dir giop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-109 CODESET_INCOMPATIBLE exception CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-108 A Messaging related issue in GIOP 1.2 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-107 IIOP 1.2 fragmentation presents an unrecoverable error situation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-106 New IDL types CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-105 Narrow Interop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-104 Contents of MultiComponent component an encapsulation? CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-103 Type any marshalling rules force slow implementation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-102 Marshalling of union type codes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-101 Typecode encoding is too long CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-100 Type code marshalling CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-97 CDR encoding of TypeCodes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-99 Typecode indirection issue CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-98 No provision for numbering the fragments in fragmented IIOP messages CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-96 Correct CDR encoding of an empty string CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-95 Typecode equality CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-94 Wchar and Char can both be multibyte CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-91 GIOP Exception formatting description (12.4.2) CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-93 Issue about CDR encoding for wide characters CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-92 Query about GIOP and IIOP version numbers in 98-01-03 CORBA 2.0 CORBA 2.1 Resolved closed
CCCMP-12 Section: 7.3.3 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-11 Section: 7.2.10 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-14 Section: 8.1.2, Figure 8.12 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-13 Section: 8.1.2 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-10 Section: 3 Normative References CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-9 More clarification text about order of CORBAStruct members is needed CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-8 clarification about relationships of specifications needed CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-7 Section: 8.1.2 p. 40 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-6 Section: 8.1.2 p. 44 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-5 Section: 8.1.2 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
C2WSDL12-25 Section: 1.2.7.10 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-24 xsd:url type not defined in schema C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-23 CORBA to WSDL/SOAP: example for attributes mapping C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-22 'CORBA to WSDL/SOAP: example for operation mapping C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-21 'CORBA to WSDL/SOAP Section 1.2.8.2 C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-20 CORBA fixed types C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-19 CORBA-WSDL/SOAP: Section 1.2.7.4 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-16 CORBA-WSDL/SOAP: Section 1.2.7.10 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-18 CORBA-WSDL/SOAP: section 1.2.8.2 , 1.2.8.4 and 1.2.8.5 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-17 CORBA-WSDL/SOAP: Section 1.2.7.10.3 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-15 CORBA-WSDL/SOAP: section 1.2.4 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-14 Section 1.2.3 repository id inconsistency C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-13 CORBA-WSDL/SOAP: Section 1.2.3 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-12 CORBA-WSDL/SOAP: Section 1.2.2.1 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-11 Section: 1.2.x (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Duplicate or Merged closed
CORBA31-216 Sections 8.1.1, 8.2.1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-212 Section 7.1, line1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-211 Figure 1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-215 Section 8.1.1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-214 7.2, sentence 3 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-213 - Figure 2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-210 use the proper notation for expressing Profiles CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-209 Minor comments re Components FTF CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-208 Section 7.2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-207 On Page 18 - Figure 11 Home mapping CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-206 Section 7, Overview CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-205 sections 1, 3, 4, 5 essentially empty CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA3-133 insufficient examples of component attributes CORBA 3.0.2 CORBA 3.0.3 Duplicate or Merged closed
CORBA3-132 Derived component supported interface restriction CORBA 3.0 CORBA 3.0.1 Resolved closed
CTS212-26 OMG Architecture Board review issues, Nov 2013 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-25 The reference in B4 should instead be added to section 3 (assuming it is normative) CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-24 Rule 10 example uses xsi2:nill – I think this should be xsi2:nil (only one L) CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-22 Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-21 The following in rule 10 is very unclear “In certain situations, this may cause issues for opaque data” CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-20 issue with rule 10 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-23 conflict between rules 10 and 13 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-19 The documents referenced in Rule 12 should appear in the normative references section CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-18 B2 rule 7: I’m not aware of such a thing as an “XML array” CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-17 Section 7 has the wrong document number for CTS2 – it should be formal/13-12-01 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-16 The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-15 the “Plan” in 6.2 with the RTF working in parallel is not being followed at all CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-14 No Beta document CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-13 Section 1: should rephrase “this submission” – it’s now a specification CTS2 1.1 CTS2 1.2 Resolved closed
CORBA24-192 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-191 destroy on POA CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-190 Valuetype "copying" semantics underspecified? CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-189 Scope of inherited valuetype initializers CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-188 Null valuetypes not supported by DynValue CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA25-55 International Strings in Encapsulations CORBA 2.3.1 CORBA 2.5 Resolved closed
CORBA24-187 Expected behavior of POA configured with ServantLocator receiving LocateRe CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-225 The insert_dyn_any and get_dyn_any operations are barely documented CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-224 OBV, value-reference substitution, Multiple Inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-223 WRONG_TRANSACTION CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA23-222 Proposal on floating point fixes CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA24-186 Section 3.3.8.16:deactivate_object() operation CORBA 2.1 CORBA 2.4 Resolved closed
CORBA23-221 Object::is_a CORBA 2.0 CORBA 2.3 Resolved closed
CORBA23-220 DII operations "get_response and get_next_response CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-219 6.5.6. Repository Paragraph 2 - objection CORBA 1.2 CORBA 2.3 Closed; No Change closed
CPP11-260 mapping IDL Unicode escapes to C++ CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-259 Mappings for hash, is_equivalent, _is_a and _non_existent CPP 1.0b1 CPP 1.0b2 Duplicate or Merged closed
CPP11-258 freebuf and destruction of elements CPP 1.0b1 CPP 1.1 Closed; No Change closed
CPP11-257 Re-opening modules CPP 1.0b1 CPP 1.0b2 Resolved closed
CORBAE-21 exception NoServant(); CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-20 Section: 8 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-19 Section: 5.2 and 5.7 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CPP1111-25 Reduce dependency on CORBA CPP11 1.0 CPP11 1.1 Resolved closed
CORBA32-1 Typo in set_values CORBA 3.1.1 CORBA 3.2 Resolved closed
CORBA32-2 context:delete_values has type CORBA 3.1.1 CORBA 3.2 Resolved closed
CORBA31-204 Section: exceptions CORBA 3.0.3 CORBA 3.1 Closed; No Change closed
CORBA31-203 Codec Interface Deficiencies CORBA 3.0.3 CORBA 3.1 Duplicate or Merged closed
CORBA3-131 Error in Chapter 21 of CORBA 3.0 CORBA 3.0.2 CORBA 3.0.3 Resolved closed
CORBA3-130 Wrong minor code listed in POAManager::deactivate CORBA 3.0 CORBA 3.0.1 Resolved closed
CORBA3-129 DATA_CONVERSION minor code 2 not listed in Table 4-3 CORBA 2.6.1 CORBA 3.0 Resolved closed
CORBA26-96 New core issue: need UNKNOWN reply status CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-98 TypeCode interface issue CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-97 Valuetype initialzers need exceptions CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-95 Syntax error in CORBA IDL CORBA 2.5 CORBA 2.6 Resolved closed
CPP12-43 Typedefs for struct members? CPP 1.1 CPP 1.2 Resolved closed
CPP12-42 Deprecated Ref identifier CPP 1.1 CPP 1.2 Resolved closed
CPP12-40 Server-side exception specifications and ISO C++ std::exception CPP 1.1 CPP 1.2 Resolved closed
CORBA25-54 Incorrect example for recursive definitions which can span multiple levels CORBA 2.4.2 CORBA 2.5 Resolved closed
CPP12-41 There is an incorrect page reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-39 Remnant of read-only return values and out params CPP 1.1 CPP 1.2 Resolved closed
CPP12-38 Backward compatibility with C CPP 1.1 CPP 1.2 Resolved closed
CPP12-37 Non-exception neutral code in C++ mapping. CPP 1.1 CPP 1.2 Resolved closed
CPP12-36 Need for TIE template for skeletons for valuetypes that support CPP 1.1 CPP 1.2 Resolved closed
CPP12-35 _name & _rep_id pure virtual? CPP 1.1 CPP 1.2 Resolved closed
CPP12-34 Requiring ref counting in ServantBase CPP 1.1 CPP 1.2 Resolved closed
CORBA24-185 Definition of TRANSIENT minor code 1 confusing CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-184 IDL format for RepositoryId CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-183 Valuetypes supporting local interfaces are local types? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-180 DynUnion incomplete CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-182 #pragma version issue CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-181 Servant deactivation callback? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CPP12-33 CORBA::Fixed needs a to_string() conversion function CPP 1.1 CPP 1.2 Resolved closed
CORBA24-179 Format of RMI Hashed Format repid CORBA 2.4 CORBA 2.4.2 Resolved closed
CPP12-32 Another issue with String_var CPP 1.1 CPP 1.2 Resolved closed
CPP12-31 Missing conversion operator on String_var CPP 1.1 CPP 1.2 Resolved closed
CORBA24-178 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-177 Minor typo CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-30 Any extraction widening to ValueBase CPP 1.1 CPP 1.2 Resolved closed
CORBA24-176 Section 4.3.7.1 get_client_policy? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-175 Typo on page 7-9 of 2.3.1 CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-29 Null assignment to String_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-28 _name and _rep_id CPP 1.1 CPP 1.2 Resolved closed
CORBA24-174 BAD_QOS system exception CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-27 Do valuetype POA servants get tie templates? CPP 1.1 CPP 1.2 Resolved closed
CPP12-25 Problem with OBV_ valuetype class constructor CPP 1.1 CPP 1.2 Resolved closed
CPP12-26 Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
CPP12-23 C++ Value Type issue (02) CPP 1.1 CPP 1.2 Resolved closed
CPP12-24 Obsolete text in 1.40.3 CPP 1.1 CPP 1.2 Resolved closed
CPP12-22 Valuebox for object reference underspecified CPP 1.1 CPP 1.2 Resolved closed
CPP12-21 C++ valuetype issue (01) CPP 1.1 CPP 1.2 Resolved closed
CORBA24-173 attributes and system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-20 Valuetype code typo in CORBA 2.3 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
CPP11-256 C++: ostream insertion CPP 1.0 CPP 1.1 Duplicate or Merged closed
CPP11-255 _var types for fixed-length underlying types CPP 1.0 CPP 1.1 Resolved closed
CORBA24-172 why was is_abstract added to structs in CORBA IR? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-218 Null Value semantics under specified CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-217 DynFactory or DynAnyFactory? CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-216 is_abstract parameter missing from create_interface() IDL CORBA 2.3 CORBA 2.3.1 Resolved closed
CPP11-254 string sequences and empty strings CPP 1.0 CPP 1.1 Resolved closed
CPP11-253 Incorrect types for type-safe Any extraction CPP 1.0 CPP 1.1 Resolved closed
CPP11-252 "Diamond of Death" in CosLifeCycleReference CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-215 Destruction of ORB CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-251 Typedef for ties? CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-214 OMG VMCID CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-250 Tie classes CPP 1.0b2 CPP 1.0 Closed; No Change closed
CORBA23-213 New proposal for recursive TypeCode creation CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-211 Typo on pages 10-53, 10-55, and 10-70 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-212 deactivate_object page no: 9-35 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-210 Proposal for creating recursive TypeCodes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-209 Types defined in the CORBA module? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-208 Missing orb.idl CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-206 Size of IDL char CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-207 Incorrect LifeCycle IDL? CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-249 Servant management rules CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-205 Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-204 CosObjectIdentity::ObjectIdentifiers can"t be UUIDs? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-203 Illegal IDL in CosTime module CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-202 TypeCode comparison proposal (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-201 TypeCode comparison proposal (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-200 Description of Wide String type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-199 name scoping issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-198 IDL struct issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-197 Type codes cannot describe all unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-196 Type code operations under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-195 Type code typos (as only one issue) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-194 Typo in chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-193 Does the DII support the standard object operations? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-192 Typos in IR IDL in Specification (050 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-191 Typos in IR IDL in Specification (04) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-190 Typos in IR IDL in Specification (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-189 Typos in IR IDL in Specification (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-188 Typos in IR IDL in spec (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-187 / in prefix pragma? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-186 Versioning by the back door? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-185 GIOP typo, section 4.2 (page 4.4) of CORBA 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-184 Domain Manager related specification shortcomings (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-183 Semantics and standard exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-182 Forward declarations and inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-248 Typos in parameter passing rules CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-181 Indentation on page 4-4 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-180 Editorial issue, chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-179 ORB_init CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-178 IDl "module" construct - IDL files CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-177 How to deal with object identity CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-176 Typo in type code section (13.3.4) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-174 Fixed point constants issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-173 Wide character and wide string literals CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-175 Type of fixed point quotients CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-172 Fixed point constant typo in 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-171 Marshalling is_equivalent CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-170 #pragma prefix issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-169 CORBA 2.2 - "native" and the interface repository CORBA 2.2 CORBA 2.3 Resolved closed
CORBA22-142 union typecode CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-141 CDR encoding of TypeCode names inconsistent with equal operation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA21-90 OMG IDL prefix pragma CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-89 Description of constant expression semantics is unclear CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-88 Object terminal missing from IDL grammar CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-87 WRONG_TRANSACTION CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-86 OTS 1.1 specification changes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-85 Interface Repository CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-84 CORBA::Bounds and CORBA::TypeCode::Bounds CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-83 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Duplicate or Merged closed
CORBA21-82 Do simple/anonymous types have repository IDs? CORBA 1.2 CORBA 2.0 Resolved closed
CPP11-247 Efficiency issue in C++ mapping CPP 1.0b1 CPP 1.0b2 Resolved closed
CORBA21-81 Exception as explicit parameter CORBA 1.2 CORBA 2.0 Resolved closed
CPP1111-24 Remove user defined literal support CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-23 Add namespace level swap CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-20 Small typos in servant reference section CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-19 Replace all _downcase/downcase with narrow CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-22 Relax constructor argument rules CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-21 Remove final for structured types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-2 typo exists in section 6.21 CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-1 RFP requirement on DDS-PSM-Cxx compatibility is violated CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-3 Lack of factory reference type CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-14 Early detection of bound violation on bounded types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-13 std::ostream insertion underspecified CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-5 Add missing implicit widening to any CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-4 Add support for _this on local objects CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-12 Missing specification of assignment operators of valuetypes CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-11 Meaning of (u)intN_t types unclear CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-10 Fixed type mapping should provide (explicit) operator bool CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-9 Invalid struct initialization example CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-15 CORBA::Exception should not use std::string type for name and repo_id CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-8 Remove _narrow methods CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-7 Extend IDL type traits for template meta programming CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-17 Use () instead of (void) CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-16 Minor typos CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-18 Introduce trait for local interface base type CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-6 Font issue CPP11 1.0b2 CPP11 1.1 Resolved closed
CWM11-93 We only need one COBOL Data Division model CWM 1.0 CWM 1.1 Resolved closed
CWM11-92 Logical-physical deployment modeling CWM 1.0 CWM 1.1 Resolved closed
CWM11-91 Diagram 8-7-3 missing lines CWM 1.0 CWM 1.1 Resolved closed
CWM11-90 Supplier and version underspecified CWM 1.0 CWM 1.1 Resolved closed
CURR11-47 ExchangeRateValue init interface need information CURR 1.0 CURR 1.1 Resolved closed
CURR11-46 IDL Changes to support date ranges on ExchangeRateValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-58 Correct interface symantics for createExchangeRate CURR 1.0 CURR 1.1 Resolved closed
CURR11-57 Correct Currency create method CURR 1.0 CURR 1.1 Resolved closed
CURR11-52 Change the name of getStateIdentifier to issueStateIdentifier CURR 1.0 CURR 1.1 Resolved closed
CURR11-51 Correct issues with CosObjectIdentity::IdentifiableObject in StateIDManage CURR 1.0 CURR 1.1 Resolved closed
CURR11-50 Clarification on whether stateID manages session or state access CURR 1.0 CURR 1.1 Resolved closed
CURR11-49 Legal value ranges for numerics in ExchangeRateValue should be discussed CURR 1.0 CURR 1.1 Resolved closed
CURR11-53 Add validity checkign for StateIdentifier CURR 1.0 CURR 1.1 Resolved closed
CURR11-54 what values are used to determine if a currency exists in CurrencyBook CURR 1.0 CURR 1.1 Resolved closed
CURR11-55 Clarify the areEquivelent interface of the CurrencyBook CURR 1.0 CURR 1.1 Resolved closed
CURR11-48 Missing details on preconditions on the ExchangeRateValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-56 Change get Currency to retrieveCurrency CURR 1.0 CURR 1.1 Resolved closed
CWM11-82 stereotype reference is missing from ModelElement CWM 1.0 CWM 1.1 Resolved closed
CWM11-81 taggedValue reference is missing from ModelElement CWM 1.0 CWM 1.1 Resolved closed
CWM11-80 provide an example of extending the Management packages CWM 1.0 CWM 1.1 Resolved closed
CWM11-79 diagram named "CWM Package Dependencies" shows wrong dependency arrow CWM 1.0 CWM 1.1 Resolved closed
CURR11-42 Add description of isCurrency Active CURR 1.0 CURR 1.1 Resolved closed
CURR11-44 MoneyValue init interface need information CURR 1.0 CURR 1.1 Resolved closed
CURR11-43 Add mechanism to create Money instances for moneyValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-45 exception semantics for MoneyValue CURR 1.0 CURR 1.1 Resolved closed
CWM-1 Specify meta-model & XMI parameters for CWM XMI formats CWM 1.0b1 CWM 1.0 Resolved closed
CURR11-74 Supplied Data for ISO Locales in MoneyFormatter needs to be discussed CURR 1.0 CURR 1.1 Resolved closed
CURR11-73 Change name of CBO::DAmountOfTime interface to CBO::AmountOfTime CURR 1.0 CURR 1.1 Resolved closed
CURR11-76 Value types need state CURR 1.0 CURR 1.1 Resolved closed
CURR11-75 Add clarification on formatting string in MoneyFormatter CURR 1.0 CURR 1.1 Resolved closed
CWM11-89 Optimize Instance data values CWM 1.0 CWM 1.1 Resolved closed
CWM11-88 Attribute.initialValue incorrectly implemented as mandatory. CWM 1.0 CWM 1.1 Resolved closed
CWM11-87 CWM model needs to be augmented to allow specification of level& hierarchy CWM 1.0 CWM 1.1 Resolved closed
CWM11-86 CWM does not reflect the latest version of UML CWM 1.0 CWM 1.1 Resolved closed
CWM11-85 Missing letters in chapter 9 diagrams. CWM 1.0 CWM 1.1 Resolved closed
CWM11-84 Data mining metamodel CWM 1.0 CWM 1.1 Resolved closed
CWM11-83 Revise the IMS metamodel CWM 1.0 CWM 1.1 Resolved closed
CURR11-64 Clarify legal values for the MoneyFormatter format strings CURR 1.0 CURR 1.1 Resolved closed
CURR11-61 removeExchangeRate() interface issue CURR 1.0 CURR 1.1 Resolved closed
CURR11-60 Modify and specify the behavior of the insertExchangeRate interface CURR 1.0 CURR 1.1 Resolved closed
CURR11-69 Create mechanism to modify what negative prefix is for formatting string CURR 1.0 CURR 1.1 Resolved closed
CURR11-66 Clarify exceptions for setFormattingString in MoneyFormatter CURR 1.0 CURR 1.1 Resolved closed
CURR11-65 Clarify contradiction betw setFormatByLocale & setFormattingString CURR 1.0 CURR 1.1 Resolved closed
CURR11-68 Interface changes for MoneyFormatter pattern handling CURR 1.0 CURR 1.1 Resolved closed
CURR11-67 Typo on SetPatternMnemonicSymbol name CURR 1.0 CURR 1.1 Resolved closed
CURR11-71 Add interfaces for internal precision on MoneyCalculator CURR 1.0 CURR 1.1 Resolved closed
CURR11-70 Clarify on comparison methods of the MoneyCalculator CURR 1.0 CURR 1.1 Resolved closed
CURR11-63 Clarify MoneyFormatter use of the # symbol CURR 1.0 CURR 1.1 Resolved closed
CURR11-62 Proposed interface changes to ExchangeRateManager CURR 1.0 CURR 1.1 Resolved closed
CURR11-72 Fix omitted precondition for MoneyCalculator CURR 1.0 CURR 1.1 Resolved closed
CURR11-59 Change the name of addExchangeRate to insertExchangeRate CURR 1.0 CURR 1.1 Resolved closed
CORBA26-87 Length of wstring in GIOP 1.1 CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-86 padding at the end of a non-fragmented 1.2 request message CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-83 IANA ports for IIOP need to be documented in Ch 13 and 15 CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-85 Interop, 15.7.3 unclear wording CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-84 Is GIOP 1.x sustainable any more? CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-82 Use of undefined "id" attribute CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-93 Question about corbaname URL CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-92 Incomplete grammar in section 15.3.4.8 CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-91 Indirections with chunking & fragmentation CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-89 In RMI rep Id, when is inclusion of SUID legal? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-88 GIOP is silent about extra data in the Request or Reply body CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-90 GIOP issue : fragmented replies with exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-94 Changing VSCID prefix to 24 bits CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-72 Component port introspection CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-71 "supports" terminology issue for CCM CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-77 CCM: Definition of import declaration unclear CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-70 CCM: Chapter 66 should be removed CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-69 IDL out parameters can't map to EJB? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-74 explicit definition of CCM exceptions mapped from EJB standard exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-73 Incorrect syntax in Components::Enumeration CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-81 minor IDL changes required in CCM API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-80 Little problem with introspection API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-79 CCM: Meaning of "exposed" scopes unclear. CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-68 CCM: usage of the MOF profile CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-76 CCM: Isolated scope tokens CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-75 Issue for Components: Missing language mapping CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-78 CCM: import and re-opening of modules CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-63 Extended Interface Repository CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-62 Problems with the Components Notification Event Interface CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-61 Component home interface inheritance CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-56 Components, Facets, and Object References Unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-55 New component issue: connection failure recovery CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-65 Components FTF: TypeCodeFactory CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-64 ComponentIR Interface fixes CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-58 Component assemblies do not follow composition pattern CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-57 Inter-component type semantics unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-54 Typo in assembly element paragraph heading CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-53 grammar rule for home_executor_body contradicts description CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-52 No Access to event filter form component CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-60 Component home polymorphism CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-59 Component assembly templates CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-67 CCM : Session2Context naming CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-66 CCM : Session2Context and Servants CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-51 No user access to filterable body in CCM spec. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-50 IDL question concerning CCM CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-49 CCM Events issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-48 typo in connections element definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-45 Deployment Object Life Cycles CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-44 Services available for a basic container CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-43 push() versus push_event() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-41 An assembly is always mono-vendor ??? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-40 Intent of Components::Events::(un)subscribe to bypass the notif. service ? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-39 Channel Setup for Emits ports. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-38 exception raised by Components::Events::subscribe() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-37 ExecutablePlacement definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-36 Local push() operation. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-47 repository element needed by softpkg DTD CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-46 description element need to be added to corbacomponent.dtd CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-42 equivalent interfaces issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CURR11-34 Exchange rates need to be date based. CURR 1.0 CURR 1.1 Resolved closed
CURR11-33 Clearer information describing different rounding types is needed CURR 1.0 CURR 1.1 Resolved closed
CURR11-32 Text indicating that vendors shall provide default values CURR 1.0 CURR 1.1 Resolved closed
CURR11-31 Extend ExceptionType enumerations CURR 1.0 CURR 1.1 Resolved closed
CURR11-36 Propose modification to the init method of CurrencyValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-35 vendor implementations can implement only parts and interoperate-Statement CURR 1.0 CURR 1.1 Resolved closed
CURR11-39 More clarification on the semantics of string arguements for CurrencyValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-38 Missing details on preconditions on the Currency interface as a whole CURR 1.0 CURR 1.1 Resolved closed
CURR11-41 Typos in CurrencyValue section CURR 1.0 CURR 1.1 Resolved closed
CURR11-40 Legal value ranges for numerics in CurrencyValue init should be discussed CURR 1.0 CURR 1.1 Resolved closed
CURR11-37 missing description on the init method for CurrencyValue CURR 1.0 CURR 1.1 Resolved closed
CSIV2-10 ISL changes to break dependency on Security and SECIOP modules CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-9 Multiple Privilege Authorities and Supported Naming Types CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-6 inconsistent definition of target_name field CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-5 Format of GSSUP GSS exported name object undefined CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-1 CSIv2 Protocol CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-12 OIDs CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-11 Module suggestions CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-2 GSSUP Names are inconsistent other security mechanisms. CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-8 INVALID recommended cipher suites CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-7 CSIv2 IOR Tagged component Identifier values CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-4 GSSUP names are incompatible with the Identity Token CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-3 Service ID missing CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CURR11-30 StateID Exception CURR 1.0 CURR 1.1 Resolved closed
CURR11-29 Change double to short for internal precision CURR 1.0 CURR 1.1 Resolved closed
CURR11-28 Add idl and text to describe the getAllExchangeRates method CURR 1.0 CURR 1.1 Resolved closed
CURR11-27 Add text for formatter that the format string will be used for parsing CURR 1.0 CURR 1.1 Resolved closed
CURR11-26 Change text description of behavior of ROUND_FLOOR and ROUND_CEILING CURR 1.0 CURR 1.1 Resolved closed
CURR11-25 Clarify on comparison methods of the calculato CURR 1.0 CURR 1.1 Resolved closed
CURR11-24 clarification on how the "#" is used in the money formatter CURR 1.0 CURR 1.1 Resolved closed
CSIV2-21 CSIv2 TSS state machine lacks states to enforce target policy for CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-20 The encoding of GSSUP ICT's is not clearly specified CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-16 New minor codes for NO_PERMISSION Exception in CSIv2 CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-15 How to Partition the ServiceConfiguration syntax space to support vendor sp CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-19 CSIv2 Issue: SECIOP does not have multiple addresses. CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-18 Inability to specify per method target security requirements CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-23 How to Partition the AuthorizationElementType regarding vendor extensions CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-22 clarification of csiv2 stateful conformance requirements CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-14 Issue: inconsistent definition of AuthorizationToken CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-13 Module SSLIOP Does Not Contain Host CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-17 No Tokens in EstablishContext Message CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CORBA25-53 Urgent issue: Alignment of LocateReply body CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-52 Incorrect table in section 15.4 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-48 Table 15-2 is missing entry for tk_local_interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-47 GIOP 1.2 AddressingDisposition processing on the client side CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-46 Fixed point marshalling CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-45 Null termination of strings CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-51 Incorrect text in 15.4.6.2 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-50 GIOP 1.1 Fragment problem CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-49 tk_indirect CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA26-32 operation get_implementation() referenced but not declared CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-31 Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events. CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-30 Issue on Assemblies and descriptors CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-33 What about valuetype factories? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-35 simple ELEMENT definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-34 range description in CPF files. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-23 Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-22 CCM issue chapter 69 ptc/99-10-04 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-21 Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-20 EJB/CCM mappings for the IR CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-19 IFR backward compatibility broken CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-18 Missing Rights Combinator in Security deployment descriptor CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-13 Purpose of "name" element CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-12 CCM Issue: CIDL Syntax doesn't allow for modules CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-29 Issue On the use of typed home (or CCMHome subtypes) CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-28 Where is HomeExecutorBase interface defined? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-27 In example p.615-86 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-26 p.615-85 ToonTownImpl CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-25 Why does not CCMHome include the operation create_component() ? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-24 operation CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-15 PACKAGING AND DEPLOYMENT METAMODEL CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-14 atribute not part of definition CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-11 Versioning needed for CORBA Core CORBA 2.2 CORBA 2.6.1 Resolved closed
CORBA26-17 Components: readonly_attr_declarator slightly ambiguous CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-16 Components: Relationship of CIDL and PSDL unclear CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA31-110 ValueMembersSeq CORBA 3.0.2 CORBA 3.1 Resolved closed
CORBA31-111 Make a typedef for the POA id new CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA26-10 section 7.1.1 claims to define the "NVList structure", but doesn't CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-9 Implied IDL for interfaces in modules CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-8 IDL for ORB::resolve_initial_references CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-7 set_length operation of the DynSequence interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-6 the IDL include directive should introduce declarations into the namespace CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-5 DynUnion operations CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-4 Problem with IDL Context interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-3 Chapter 11, section 11.3.8.19 (WrongPolicy)" CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-2 Support for is_a for local interfaces CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-1 Section 11.3.8.16 - ambiguity CORBA 2.5 CORBA 2.6 Resolved closed
CORBA25-44 Nil return from resolve_initial_references() CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-43 Interpretation of time field in UtcT? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-42 There is no mapping for fixed types in the COM/CORBA mapping CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-41 COBRA problem using pragma prefix for modules CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-40 CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion) CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-39 Local interface is-a Object? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-38 Wither pseudo-objects? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-37 Missing TypeCode identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-36 Problem with resolution to 4285 and 4306 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-35 get_interface() underspecified CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-34 Typo in UML for POA CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-33 DII create_request CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-32 Ambiguity in non_existent CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-31 String literal definition incorrect. CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-30 Inconsistent minor code for MARSHAL CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-29 Minor code CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-28 Missing POAManager identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-27 BAD_OPERATION needs minor code and completion status CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-26 Cross-reference refers to wrong section CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-25 Issue: Error in section 4.5.3.2 ORBInitRef CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-24 Section 10.5.22.2 what happens when conditions not met CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-23 Restrictions on native types CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-22 Clarification about include files and IDL compiler behavior CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-21 Definition of NamingContextExt interface in IDL of Appendix A not consisten CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-20 3.7.4 Forward Declaration (for interfaces) doesn't mention local CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-19 What is the semantics of the DataInputStream::read_*_array() operations? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-13 Introduction of identifiers CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-12 Type redefinition in derived interface CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-11 PortableServer::ObjectId CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-10 core issue: unchecked narrow CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-18 #include issue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-17 DynValueBox::set_boxed_value should also raise InvalidValue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-16 misleading wording in 10.5.22.2 Write Interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-15 Inconsistent text for unknown system exception CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-14 ForwardRequest from normal operations CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-3 POAManager::deactivate should not mandate ORB::shutdown implementation CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-2 POAManager::deactivate does not specify behavior for "reject" CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-1 Can a valuetype support multiple non-abstract interfaces via inheritance? CORBA 2.4 CORBA 2.5 Resolved closed
CORBA25-6 CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-5 ServantLocator preinvoke/ postinvoke semantics CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-4 Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-9 Container::lookup() ordering requirements CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-8 Section 2.1.7 of CORBA 2.3 and 2.4 CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-7 Legal IDL? CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA3-124 Issues related to CCM's XML descriptors: chapter 69.4.5.4 CCM 3.0 CORBA 3.0.2 Resolved closed
CORBA3-128 Creating IORs CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-127 There is no way to modify a POA's ORT and append to it CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-126 Interoperability of ObjectReferenceTemplate and Factory. CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-125 Object Adapter name problem in ORT CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-116 Productions 140, 141, 142 and 143 must be removed CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-115 paragraph 60.2.1 : There is two mistakes in keywords CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-123 Update Table 5-13 in the EJB Chapter of formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-122 Editorial issues in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-120 Remove section 4.4.1.4 in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-119 create operation of AssemblyFactory interface CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-114 CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ... CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-118 69.8.2 Property File XML Elements CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-117 Typo (??) in chapter 61 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-121 Corrections in XML DTDs for packaging CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-106 components-ftf: connectevent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-105 components-ftf: registercomponent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-104 components-ftf: repository id in software package descriptor CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-103 IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-113 Issues related to CCM's XML descriptors: chapter 695.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-112 Issues related to CCM's XML descriptors: chapter 69.7.2.38 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-107 Issue regarding language mapping for keyless homes CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-102 Generic operations for subscribing/unsubscribing at publishing ports CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-108 simple type element of the property file issue CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-111 Issues related to CCM's XML descriptors: chapter 69.7.2.25 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-110 Issues related to CCM's XML descriptors: chapter 69.4.5.16 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-109 Issues related to CCM's XML descriptors: chapter 69.4.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-95 add a ClientInterceptor then create_POA() in the post_init() method? CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-94 CORBA::WrongTransaction and Interceptors CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-93 How do Portable Interceptors interact with Messaging callbacks CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-92 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-91 ORBInitInfo::arguments() underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-90 Exception handling in Interceptor initialization CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-89 Derived component supported interface restriction (formal/2002-06-01) CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-88 Local types allowed as valuetype state? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-87 Why does PollableSet::number_left() return unsigned short? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-86 Pollable in more than one PollableSet? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-85 Oneway operations should not generate sendc_ and sendp_ variants CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-84 DII sendc reply delivery underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-83 Bad example code in 22.11.4.3 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-82 Messaging Poller generation is broken for interfaces with multiple inherite CORBA 1.1 CORBA 3.0.2 Resolved closed
CORBA3-81 name disambiguation for AMI interface & poller names is confusing CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-80 potential name clash with Messaging type-specific poller timeout argument CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-101 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Duplicate or Merged closed
CORBA3-100 AMI vs abstract & local interfaces CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-99 Sending codeset context more than once? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-98 Getting reply svc ctxts from PersistentRequests CPP 1.0 CORBA 3.0.2 Resolved closed
CORBA3-97 Type code creation CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-96 Unfortunate CDR Encapsulation of ASN.1 Encodings CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-79 Messaging type-specific poller valuetypes should be abstract CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-78 Errors in definition of Messaging poller types CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-77 Messaging: bad example code for type specific poller CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-76 SyncScope for oneway invocations CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-75 Messaging time based policy enforcement? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-74 determining TimeT or UtcT value CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-73 Is a router allowed to pick any value in the range for a priority? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-72 Who is responsible for generating the TIMEOUT exception CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-71 Object::validate_connection() CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-70 Sloppy text in CORBA 3.0, 4.3.8.1 get_policy CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-69 Object::get_client_policy problem CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-68 Inconsistent definition of semantics of RebindPolicy? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-63 pragma prefix syntax CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-62 Avoiding Interceptors for colocated method requests CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-61 Codeset negotiation and the CODESET_INCOMPATIBLE exception CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-60 Replace deprecated anonymous type declarations? CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-59 reference_to_servant CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-67 BAD_INV_ORDER minor code 5 and 10 mean the same thing? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-66 Serious backward compatibility issue in the PI CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-65 OpaqueValue/add_arg never mapped to languages CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-64 Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-58 Valuetypes supporting forward declared interfaces CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-57 Inconsitent exception handling with find_POA & unknown_adapter CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-56 IOR processing performance CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-47 Wide string in reply before codeset was negotiated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-46 conflict between CORBA specification and C++ mapping (_this method CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-51 Codeset negotiation requires clarification CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-50 The whole negotiation thing should be removed, Unicode should be mandated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-53 discussion on the create_union_tc operation could use some clarifications CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-52 IDL inheritance issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-49 interaction of #pragma and typeid, typeprefix CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-48 IPv6 in corbaloc URLs CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-55 GIOP version in replies CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-54 definition of the TypeCode interface (4.11.1) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-43 Issue with chunking CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-42 TypeCode indirections CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-41 Chapters 13.10.1.9, and 13.10.1.12 -- issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-38 Alignment for empty sequence? CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-37 CORBA 2.5 and Portable Interceptors mismerged CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-36 Detecting Recursion in Other Interceptors CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-27 X/Open Codeset registry is obsolete needs to be replaced CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-26 Clarify that each interception point executes in a distinct logical thread CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-45 11.3.2.1 Processing States (end of second paragraph and third paragraph CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-44 Potential problem using BiDir GIOP and codeset conversion service context CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-40 GIOP 1.2 encoding of wstring CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-39 ORBs using BOMs for UTF-16 (closely related to issue 4008) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-29 Problem with CSIv2 and GIOP LocateRequest CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-28 21.8.1 register_initial_reference CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-33 rep_id() operation on Object? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-32 Repository ID in nil references CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-31 Note on page 15-43, OBJECT_FORWARD_PERM CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-30 Interpretation of defined ServiceConfigurationSyntax constants is incomplet CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-35 CORBA components requires new GIOP version? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-34 TypeCodes for custom marshaled valuetypes CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-25 Stateful boolean causes all CSI mechanisms to operate the same way. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA21-80 Bug in C++ NVList mapping CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-79 OMG C++ Mapping: Implicit Conversion Operators CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-78 Persistent Any values CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-77 DII and DSI are useless with current Any CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-76 iterating over Any primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-75 decompose Any into constituent primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-69 Rethrowing exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-72 Return value of operator[] for array var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-71 Taking T out of T_var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-70 Freeing inaccessible storage for T_var as out parameter CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-74 RTTI vs. _narrow for exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-73 Implementation of parameter passing for T_var types CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-68 IDL grammar CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-67 8.1 Role of the Basic Object Adapter Para 1 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-66 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-65 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-64 7.2.5 Probing for Object Non-Existence Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-63 7.2.4 Equivalence Checking Operation Paragraph 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-62 7.2.1 Determining the Object Implementation and Interface CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-61 7.1 Converting Object References to Strings Para 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-60 6.5.6 Repository Paragraph 4 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-59 6.5.4 Container Last Paragraph - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-58 6.4.3 Interface Objects Paragraph 2 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-57 6.4.3 Interface Objects Paragrapg 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-56 6.3.1 Managing Interface Repositories CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-55 5.3.2 Registering Dynamic Implementation Routines Para 1- comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-54 5.2 Explicit Request State: ServerRequest Pseudo Object CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-53 4.6.5 delete_values Paragraph 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-52 4.3.3 get_response CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-51 4.2.3 invoke CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-50 4.1.2 Memory usage, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-49 4.1 Overview, Paragraph 3, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-48 3.15.2 Object Non-Existence, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-47 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-46 3.9 Exception Declaration CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-45 2.5 Structure of an Object Adapter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-44 2.1 Structure of an Object Request Broker CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-43 1.2.2 Requests Paragraph last - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-42 CORBA2.0, 1.2.2 Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-41 Scope of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-40 Unions with enum as discriminator type CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-39 _is_a with CORBA::Object as input parameter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-38 Unqualified names in scopes CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-37 Usage of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-36 Ambiguity in DII and DSI CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-35 Request reuse CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-34 Whether unions carry exact discriminant information CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-33 Recusive Type Definitions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA3-11 Detail lacking in when request interceptors are called CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-10 How correlate requests and replies when using pollable sets? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-18 no way to register value factory from ORB initializer CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-17 ORB accessor on POA? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-16 RoutingPolicy issue CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-24 ORB::shutdown vs. ORB::destroy CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-23 Encodings of Sequences of Certificates are not standard. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-20 Portable interceptors and invocation timeouts CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-19 Missing minor codes in Messaging Chapter CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-22 wchar endianness CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-21 No portable way to turn IOR components into object-reference policies CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-15 Portable Interceptors / register_initial_reference() CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-14 Policy Management in Portable Interceptors CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-9 ORBInitInfo needs the ORB CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-8 PI needs the ORB to be available in IDL CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-7 Question about routing policies CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-6 Portable Interceptors: object_to_string, string_to_object CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-5 Implementing proper handling of CloseConnection CORBA 2.3.1 CORBA 3.0.2 Resolved closed
CORBA3-13 Overriding POA policies CPP 1.1 CORBA 3.0.3 Resolved closed
CORBA3-12 Portable Interceptors: 9.2.3 text describing `Arguments' CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-2 No way to detect that ORB has outstanding deferred synchronous requests CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-1 constant decls broken CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-4 scheme name for IORs CORBA 2.3 CORBA 3.0.2 Resolved closed
CORBA3-3 issue with ForwardRequest exception in POA CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA21-31 Page 13C-36: Editorials CORBA 2.0 CORBA 2.1 Resolved closed
CORBAE-17 More wrong references in chapetr 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-16 Wrong references in chapter 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-13 CORBA/e and get_interface CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-12 Section: 9.2.1.1 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-18 Section: 8.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-15 Section: 11.4.1 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-14 Section: 18.2.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-11 Section: 6.2.12 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-10 The removal of static any from micro CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-9 Servant_to_id clarification CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-8 Section: 11.2.3 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-7 document style and use of headings CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-6 Section: 6.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-5 Add table that captures the features that are in/out of CORBA/e CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-4 state machine diagram CORBAe 1.0b1 CORBAe 1.0 Resolved closed
C2WSDL12-8 Section: 1.2.x (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-7 Section: 1.2.11 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-6 Section: 1.2.7.5 and 1.2.7.6 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-10 Section: 1.2.6.1 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-9 Section: 1.2.7.6 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-5 Section: 1.2.7.6 Multi-dimensional arrays in IDL C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-4 Section: 1.2.7.6 page 1-14 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-3 Section: 1.2.7.6 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-2 Section: 1.2.7.6 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
CORBA24-150 Validity of object references CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-149 An ORB should not accept an IOR with no usable profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-148 Should an ORB be allowed to drop non-standard profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-163 selected_profile_index origin CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-162 Absence of Wide Character Code Set CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-161 ORB throwing exception if it finds unknown service context CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-160 Wrong minor code specified in Chapter 13 CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-144 Table 13-1 needs update for valuetypes & abstract interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-143 marshalling of null values unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-142 CDR Encapsulation Issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-152 Preserving unencapsulated information CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-151 Indirection for value types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-147 chunked value encoding: CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-146 CORBA 2.3.1 missing text describing the response_expected field CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-145 Supporting TAG_MULTIPLE_COMPONENTS CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-157 GIOP version and CloseConnection CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-156 Valuetype in anys. Unmarshaling problem? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-153 Transferring Java exception reason string across the wire CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-159 Nesting depth in valuetype end tags CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-158 Valuetype encoding grammar in 15.3.4.7 is wrong CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-155 Marshaling fixed-point decimal types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-154 IIOP 1.2 Early Reply message in presence of fragmented Request CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-141 Minor code allocation inconsistency CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-139 .Passing the interface repository ID of the method in IIOP CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-138 Chunked GIOP marshalling for variable-length types CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-137 TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-136 Optimization of LOCATION_FORWARD replies CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-135 Compacting GIOP Requests by hashing down operation names CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-140 GIOP encoding of nil Abstract Interface is unspecified CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-134 Compacting GIOP Messages by using templates CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-133 Compacting GIOP messages by using indirections CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-132 Use of the type ComponentHome CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-131 USING Components::Enumeration CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-130 destroy() for local objects CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-129 New IDL keywords CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-128 Implementation of get_component CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-127 CORBA IR METAMODEL CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-126 Is the ccm_home method shown in Table 8-1 a typo? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-125 How is CCMHome::get_home_def mapped to EJB operations? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-124 What's the return type of CCM mappings of EJB finder and creator methods? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-123 Do EJB-mapped attributes go to the ComponentDefault interface? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-122 CCM Issue: Is CCMObject::remove intended to be available to the CCM client? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-168 Small optimization for the GIOP header CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-167 interop issue: CodeSets service context in GIOP 1.0 request CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-166 Version and byte order changes when fragmenting messages (interop) CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-165 Issue 2 -- resulting from UK comment UK-5: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-164 Issue 1 -- resulting from Japanese comment JPN-009E: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-171 wchar alignment in GIOP 1.2 CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-170 Is padding necessary for empty Reply body? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-169 GIOP _get_domain_managers ambiguous CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-121 CCM Issue: How are standard EJB exceptions mapped into the CCM View CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-120 Should Components::Enumeration be an IDL interface or an IDL abstract value CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-119 CCM Issue: Is a home needed? CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-118 Components Issues - Interface Repository ptc/99-10-03 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-117 Components Issues - Chapter 61 ptc/99-10-04 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-116 implementing import for C++ CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-115 Policies not locality-constrained? CPP 1.0 CORBA 2.4 Resolved closed
CORBA24-114 Locality-constrained objects CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-113 Locality constrained objects + externalization CORBA 2.2 CORBA 2.4 Closed; No Change closed
CORBA24-104 Nested Recursive Structs Legal in 2.3.x? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-103 incomplete rules for forward declaration of structs/unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-107 read_fixed() and write_fixed() methods missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-106 Initializers and user exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-105 IDL: Clashes with inherited identifiers CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-112 Should POA spec examples use string_to_ObjectId? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-111 Values for CORBA::ARG_IN,... not defined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-110 module IOP_N needs a real name CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-109 "omg.org" prefix missing from interceptor specification and its reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-108 ORB ID accessor CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-85 ValueMemberDef section omitted from CORBA 2.3.1 spec CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-84 Inheritance description incorrect CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-83 ORB mediation for servant managers, references for servant managers? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-92 Policy Management in the ORB core CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-91 Some problems CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-90 ORB shutdown vs destroy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-102 With reference to forward declarations of structs and unions. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-101 There is inconsistency in the POA.IDL and description in section 11.3.8.19 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-100 description of unknown_adapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-99 reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-98 Missing exception for activation CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-97 AbstractBase not declared. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-82 POA deactivate_object description is ambiguous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-81 how are valid ORBids determined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-80 POA namespace and ORB ID CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-94 servant_to_id versus servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-93 ORB::shutdown underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-87 Incorrect use of negative fixed scale CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-86 is_equivalent and policies CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-89 POA servant_to_id inconsistent with servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-88 Valuetypes with multiple interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-96 Pragma version 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-95 Non-escaped keywords in published IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-79 return type of TypeCode::fixed_scale() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-78 POA status during destruction is unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-77 Problem with valuetype parameter copying CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-64 Ordering issues in the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-63 Efficient construction of Any types w/o DynamicAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-68 Does a value in a valuebox make sense? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-67 Semantics for DynAny::equal underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-73 Definition of COMPLETED_NO needs to be clarified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-72 Minor glitch about forward declared things CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-70 Editorial mistake in IDL chapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-69 Can native be used in constructed IDL types? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-76 response_flags in interop draft CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-75 symbolic constants for minor exception codes CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-66 Inheritence table 3-10 wrong? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-65 poll_response() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-71 #pragma rules are too restrictive CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-74 valuetype factory inheritence? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-62 special-casing TypeCode is unnecessary CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-165 CDR encoding for fixed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-166 LocateRequest and LocateReply messages CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-167 profile ids & component ids CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-168 Need clarification on GIOP::TargetAddress CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA24-51 Errors in published IDL for CORBA module CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-50 Non-standard system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-49 Use of Principal in GIOP Module erroneous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-56 valuebox and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-55 OMG wchar <-> COM WCHAR in CORBA 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-61 local interfaces and the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-60 servant_to_id CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-54 What is the TypeCode for ValueBase? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-53 Do valueboxes have factories? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-52 DynAny & abstract interfaces don't mix! CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-48 create_POA and inactive state? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-47 value type substitutability CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-46 OMG IDL Syntax and Semantics issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-45 TypeCode issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-59 IDL scoping rules CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-57 null & void TCs and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-58 Bug in 11.3.7.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-37 Problem with the "Special scoping" rules in 3.15.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-36 Meaningless sentence on page 3-11? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-32 Type Code Section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-31 Minor codes for Standard System Exceptions in Chapter 8 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-30 Minor codes for Standard System Exceptions in Chapter 5 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-34 IDL and C++ relationship CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-33 PIDL vs Local CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-40 Missing "abstract" in forward declaration CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-39 The algorithm for TypeCode::equivalent in 10.7.1 was not updated CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-44 Editorial glitch in DynAny::destroy, section 9.2.3.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-43 What is the NO_RESPONSE exception good for? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-29 General Exception Question CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-28 Exception section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-42 Section 7.6: IDL context housecleaning CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-41 Question about IDL \uxxxx escape format CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-35 Preprocessing of IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-38 Codeset conversions and unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-17 Use of incomplete recursive TypeCodes underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-16 Semantics of DynAny with alias TypeCodes CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-15 URLs interact poorly with code set selection CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-12 DataInputStream specification is inefficient for Java CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-11 POA exception minor codes CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-10 Wchar as discriminator in union CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-23 Problem with text of POAManager::deactivate() CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-22 CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-19 creation of arguments to TypeCode creation ops CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-18 DynFixed editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-27 CORBA 2.3 Editorial issue for TypeCodes & abstract_interface CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-26 Editorial issue for CORBA 2.3, 1.3.8.20 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-9 CORBA 2.3: minor editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-8 chapter 3 and recursion CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-25 Component ids in 13.6.2.2 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-24 (CORBA Core) Data streams missing arrays of long double CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-14 Why are Standard Exceptions defined in IDL chapter? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-13 What is the RepId of Object? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-21 formal/99-08-01.txt missing pragmas CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-20 CORBA::ORB::RequestSeq definition obsolete CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-84 Incorrect IDL is section 5.5.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-83 RMI style repository ID hash code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-82 forward declaration in ptc/98-10-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-4 $issue.summary CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-3 mixing giop versions CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-92 UNIQUE_ID and ServantActivator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-91 Clarification on IdUniquenessPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-95 New "opaque" data type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-94 DynAny::equal operator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-93 sharing valuetypes across Anys CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-86 DynAny.insert_valuetype shoud be insert_val CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-85 confusing rules for operations on Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-7 ambiguity in wstrings having a Unicode escape sequence CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-6 POA: false placement of paragraph CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-5 OBV interface support inconsistencies CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-88 activate_object_with_id and exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-87 Repository ID for Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-2 interop issue: what system exceptions may be raised on GIOP 1.0? CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-1 The syntax for stringified IORs in section 13.6.6 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-90 deactivate_object asymmetry CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-89 ORB::shutdown again CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-70 Inconsistent spellings of "policy" related identifiers: CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-69 IR Changes in 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-63 Interceptors broken CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-62 clarification and bug in InterfaceDef::FullInterfaceDescription CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-61 Try to define obligatory and optional parts of the CORBA specification. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-60 Application Interface issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-59 Use UNICODE Character set CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-81 LocateReply body alignment issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-80 POA issue, section 11.3.8.10 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-79 POA that has IdAssignmentPolicy=SYSTEM--portability problem CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-76 Scope of SendingContextRunTime service context CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-75 Need to specify exception for abstract interface error CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-74 Error in IRObject definition in 98-12-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-73 What use is CORBA::exception_type? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-72 Inconsistent Definition of Flags type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-71 CORBA::Object::ping ? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-78 Can an any with a tk_null or tk_void TypeCode be encoded with CDR? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-77 omg.org prefix not well specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-68 What value type does ValueDef"s base_value() return? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-67 Inheritance of value types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-66 Problems in Chapter 5 IDL CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-65 POA Construction Policy. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-64 another problem with IDL specification section 3.9.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-58 Issue - no PIDL, just language bindings CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-57 Grammar section 3.9.2 missing "float" rules, and other problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-45 No description for NativeDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-44 Errors in figure 10-2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-43 Signature of unmarshal method is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-54 Value base and the IFR CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-53 Clarifications needed in section 5.2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-42 Clarify meaning of no IDL initializers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-41 Misleading text in section 3.2.5.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-56 Calling get_response twice? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-55 Forward-Declared Interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-47 No description for ValueBoxDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-46 is_a description is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-50 RMI Repository ID missing from section 10.6 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-49 Text was inserted in wrong place CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-52 Clarify text in section 15.3.7 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-51 Error in text describing TypeCode interface CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-48 Error in ValueDef IDL CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-28 Core uses both "standard" and "system" exception terminology CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-27 create_policy specification needs to be completed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-26 Need namespace for Policy Type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-40 Codebases with multiple URLs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-39 Supporting multiple abstract interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-38 Names of Data*Stream methods CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-25 Scoping resolution for member names CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-24 Typo in POA CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-23 void * in DII Chapter CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-30 is_a underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-29 Local operations on CORBA::Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-31 uses of recursive_tc CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-37 Custom Marshaling clarification CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-36 Missing minor code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-33 Custom marshalling & AbstractBase CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-32 Sequences of recursive structs/unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-35 POA SINGLE_THREAD_MODEL description ambiguous CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-34 POA threading policies CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-22 Exception for abstract interface inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-21 long double problem? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-6 Lifetime of ORB and validity of ORB pointe CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-5 Semantics of system exception completion_status CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-17 What does interface substitutability mean in CORBA? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-16 Which OBV initialiser to run is under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-12 Handling of minor codes for standard exceptions underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-11 page 3-47: Identifiers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-14 Missing equality for DynAny CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-13 set_servant_manager CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-10 Nested scopes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-9 Multiple paths to a recursive sequence typecode CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-8 Change to IDL for anonymous types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-7 DynStruct::get_members needs exception CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-20 Recursive exceptions? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-19 InconsistentTypeCode exception in CORBA 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-18 Recursive IDL types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-15 DynUnion::member() CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-4 resolve_initial_references under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-3 Domain Manager related specification shortcoming (02)-ConstructionPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-2 Domain manager related specification shortcoming(s) (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-1 Operation to add to CORBA::ORB pseudo-object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA22-133 marshalling service context CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-132 Alignment and offsets in the presence of fragmentation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-131 Changes to and strategy for 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-107 Type ids in OBJECT_FORWARD return message CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-111 Use of dynamic ports CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-110 CORBA::Object::non_existent CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-109 Correct IIOP marshalling of union TypeCodes CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-108 LOCATION_FORWARD byte alignment CPP 1.0b1 CORBA 2.2 Resolved closed
CTS2F2-82 CTS2 XML file appears to contain EA proprietary elements CTS2 1.0b1 CTS2 1.0 Resolved closed
CORBA22-140 Typos in PIDL to C++ mappings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-139 Typo in C++ mapping CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-138 C mapping for list_initial_services is incorrect CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-137 Defintion of Any CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-136 Any extractor signature problem CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-135 Missing Any inserter CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-134 IIOP object pointer resetting CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-128 Additional enumeration to the ReplyStatusType CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-127 Additional Requirement for GIOP 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-126 Clarification on IIOP2.1 12.3.2 fixed point type representation needed CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-130 Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-129 IIOP marshalling of empty strings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-115 Problem with GIOP CancelRequest when fragments are used CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-114 Transport Level Bridge CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-119 IDL Type Extensions: wstring CDR encoding issue CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-118 IDL Type Extensions: wchar and wstring CDR encoding CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-123 1.0 backward compat (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-122 1.0 backward compat (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-113 IORs and identifying Object Keys CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-112 Callbacks in IIOP CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-121 Fragment improvements (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-120 Fragment improvements (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-117 Type extensions char code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-116 Type Extensions and code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-125 Issue with service context CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-124 CloseConnection messages CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-96 union typecode (02) CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-95 locally constrained CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-94 IDL types are ambiguous with inheritance CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-100 Question about typecode creation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-99 #pragma processing CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-106 CORBA::Contained::describe() underspecified CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-98 Ambiguity in non_existent() specification CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-97 Appendix B lists incorrect CORBA Components IDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-103 Trader constraint language and international characters CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-102 defined_in member of ModuleDescription for top-level module CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-101 Inheritance of Exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-93 RIDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-92 Containers CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-105 Incorrect definition of "object type" CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-104 Resetting #pragma prefix? CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-91 Proposed IFR exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-90 TypedefDef issue CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-89 CORBA 2.1 IR Structdef typo CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-85 Issue with ObjectId_to_string and string_to_ObjectId CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-84 Bug in the 2.1.spec for IDL unions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-83 Figure 2-2 in CORBA 2.0 and CORBA 2.1 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-82 Octet and enum constants CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-81 Non ASCII alphabetics in IDL identifiers CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-80 Native types with respect to typecodes, DII, DSI,Interface Reposit. CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-79 TypeCode equality CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-88 Minor bug in 2.1 spec CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-87 Inheriting exceptions in IDL CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-86 Inclusion of standard exception CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-75 Syntax for basic types must be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-74 create_exception() is declared outside any interface scope CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-73 TCKind enum should be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-78 Do identifiers and keywords clash if they differ in case? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-77 Section 3.7.2: take new IDL type extensions into account CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-76 Section 7.8: editorial CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-70 sec 17.7.1: IDL for interface request doesn"t match C++ mapping CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-69 Sequence parameter specified is ignored CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-68 request() should be added to IDL (section 17.13.2) CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-67 Section 16.7: only C++ mapping defines string_free and string_dup CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-72 No defined value for OBJECT_NIL CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-71 Section 7.2: get_implementation function CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-64 "service"~~operation or interface? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-63 What exactly is a request CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-61 Scope and use of prefix pragma in IDL-style repository IDs CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-60 Terminology consistency CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-52 6.6.4 Pragma Directives for RepositoryId Para 1 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-51 6.6.1 OMG IDL Format Paragraph 5 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-56 6.7.2 TypeCode Constants Last Paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-55 6.7.1 The Type Code Interface Paragraph 4 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-59 Enums and enumerators CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-58 Internationalization CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-54 6.7.1 The TypeCode Interface All Paragraphs - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-53 6.7 TypeCodes Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-66 limited-length strings CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-65 Question about IDL grammar CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-57 CORE spec reference CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-62 inherit vs. include CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-50 6.5.22 InterfaceDef Paragraphs 7 and 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-49 6.5.22 InterfaceDef Paragraph 6 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-48 6.5.20 AttributeDef Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-38 6.5.4 Container Paragraph 6 - editorial CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-37 6.5.4 Container Paragraph 5 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-36 6.5.4 Container Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-35 6.5.3 Contained Paragraph 10 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-43 6.5.4 Container Paragraph 15 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-42 6.5.4 Container Paragraph 12 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-46 6.5.10 StructDef Last paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-45 6.5.8 ConstantDef Interface Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-40 6.5.4 Container Paragraph 10 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-39 6.5.4 Container Paragraph 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-44 6.5.6 Repository Paragraph 4 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-47 6.5.11 UnionDef Last Paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-41 6.5.4 Container Paragraph 11 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-34 6.5.3 Contained - Paragraph 7 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-33 6.5.3 Contained Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-32 6.5.2 IRObject Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-22 4.6 Context Object Operations, Para 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-21 4.2.2 add_arg Paragraph 5-comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-24 4.6.2 set_on_value Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-23 4.3.1 sen3 - comment 23 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-28 4.6.4 get_values Paragraph 5 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-27 4.6.4 get_values Paragraph 4 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-26 4.6.4 get_values Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-25 4.6.3 set_values CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-18 4.1.1 Common Data Structures, Paragraph 6, comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-17 Interface for managing interceptors is missing CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-31 6.4.3 Interface Objects Paragraph 3 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-30 4.6.7 delete Paragraph 4 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-20 4.2.1 create_request Paragraph 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-19 4.1.3 Return Status and Exceptions CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-29 4.6.5 delete_values Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-4 Do typecodes need literal constant representations in all mappings? CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-3 Missing info about the semantics of ORB_init and OA_init CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-14 Similar structure to IR::Identifier CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-13 Pseudo-IDL identifiers differ by case only CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-8 Typecodes for recursive sequences CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-7 lookup() questions CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-10 DSI and oneway operations CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-9 ServerRequest::op_def() CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-6 Interface Repository Error Handling CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-5 CORBA::InterfaceDef name collision CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-12 Apparent error in CORBA 2.0 Interoperability CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-11 Repository IDs CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-16 Portability and the #include directive CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-15 Recursive sequence TypeCodes CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-2 IFR: union elements associated with case labels CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-1 Inheritance of describe_contents() CORBA 1.2 CORBA 2.2 Resolved closed
CTS2F2-73 Missing documentation on StatementSubject CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-72 CTS2: Change cardinality of defaultLanguage from [0..1] to [0..*] CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-74 Introduction section about conventions and notation needs to be in all modules CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-76 Exception listed twice in EntityDescriptionQueryService CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-75 EntityDescriptionQueryService knownCodeSystem type is incorrect CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-77 CTS2: Delta stereotype is opposite of isQuery CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-81 MatchValueFormatException missing from documentation CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-80 Boolean is a UML data type and shouldn't be part of the model CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-79 Missing ValidationResponse class CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-78 String is a UML dataType and cannot be included as part of the model data types CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS211-12 CTS2: Additional options needed for Entity Read Query CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-11 CTS2: Format and language resolution precedence not described for REST CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-8 CTS2: Include the signature for the CLONE operation in Change Set CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-7 CTS2: Extensible Directories - Allow directories to be extended CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-15 CTS2: Rest signatures missing for ValueSetDefinitionResolution "resolveAsCompleteSet" function CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-14 CTS2: REST language signature "referencelanguage" needs to be more REST compliant CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-19 CTS2: CodeSystemCatalogEntry xml schema missing "hasOntologyLanguage" and "includes" elements CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-18 CTS2: Map Entry "MapFrom" and "MapTo" need optional description element CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-9 CTS2: No ROA link to value set resolution of current value set CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-17 CTS2: ValueSetDefinition REST signatures need to include shortcuts for tags CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-16 CTS2: Documentation for value set resolution needs to be corrected. CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-10 CTS2: "versiontag" has wrong type in MapVersion schema CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-13 CTS2: Redirect behavior isn't clear for uri reads CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-65 Create/Update in WADL use the wrong HTTP methods CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-64 CTS2: StructuralProfile - Statement and/or MapEntry CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-61 CTS2: currentVersion not typed in MapCatalogEntry CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-60 CTS2: ScopedEntityName.name type is too strong CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-63 CTS2: Message Header Documentation Missing CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-62 CTS2: Inconsistent element/complexType declarations CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-68 CTS2: AssociationQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-67 CTS2: ConceptDomainBindingReadService QueryControl parameters CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-66 CTS2: AssociationQueryService 'getAllSourceAndTargetEntities' wrong input parameter CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-70 CTS2: Concept Domain Catalog Query Service missing description CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-69 CTS2: Service map catalog typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-71 CTS2: section 1.1.2.1 Class CodeSystemCatalogEntryDirectory typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CDSS-10 Evaluation only conformance profile CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-9 EvaluationRequest and IterativeEvaluationRequest content ordering CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-8 Consider RESTful service specification CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-7 Security Issues CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-1 DSS: single targetNamespace "urn:dss.hssp.org" CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-4 Too many defined elements within one package name CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-3 Non UTF-8 character in schema comments CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-5 Use of xs:any data type for payload CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-2 All Defined Operations CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-6 Use of "Exception" as a class name in the model CDSS 1.0b1 CDSS 1.0 Resolved closed
CMMN-19 The XML document dtc-13-11-05.xsd is NOT valid (1 errors) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-18 Figure 11 CMMN 1.0b1 CMMN 1.0 Resolved closed
CTS211-26 CTS2: Parents URI needed in EntityDescription CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-25 CTS2: CodeSystemCatalogQueryService (resolve and resolveAsList) parameter 'directory' type incorrect CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-31 CTS2: Complete binding operation missing from specification CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-30 CTS2: URIAndEntityName references should all be changed to EntitySynopsis, allowing an optional description CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-29 CTS2: IteratableResolvedValueSet and ResolvedValueSet have inconsistent element names CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-28 CTS2: CTS2Exception doesn't match documentation CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-27 Need an optional attribute to carry the OID in addition to the URI CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-22 AssociationDirectory needs "associationID" CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-21 CTS2: Make "associationID" optional CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-32 CTS2: Filter PropertyReference documentation needs clarification CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-20 CTS2: Include a depth indicator for AssociationGraph CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-24 CTS2: ConceptDomainCatalogQueryService (resolve) parameter "directory" type incorrect CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-23 CTS2: URIAndEntityName XSD representation does not match UML CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-50 AssociationMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-49 AssociationHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-48 AssociationReadServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-47 AdvancedAssociationQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-59 EntityDescriptionMaintenanceServices WSDL changes CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-58 EntityDescriptionQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-46 EntityDescriptionReadServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-45 CodeSystemVersionCatalogHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-54 ConceptDomainBindingMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-53 ConceptDomainBindingQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-52 BaseImport/ExportServices WSDL correction CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-57 EntityDescriptionTransformService WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-56 ConceptDomainCatalogHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-51 AssociationTransformServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-55 ConceptDomainCatalogQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS211-1 CTS2: Possible issue with CTS2 URI CTS2 1.0b1 CTS2 1.1 Resolved closed
CTS211-5 CTS2: "documentURI" attribute description in ResourceVersionDescription is incorrect CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-2 CTS2: "entityType" description text incorrect - needs to be updated CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-4 CTS2: "SourceAndNotation" should be made optional in resource version CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-3 CTS2: referencedEntity in Value Set Definitions should include an optional description CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-6 CTS2: DocumentURI shouldn't be mandatory in ResourceVersionDescription CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-4 CTS 2: SortCriteria contains PropertyReference CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-3 CTS 2: Change 'applicableContext' cardinality in ConceptDomainBinding (XSD) to 0..1 CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-2 CTS2: Move 'bindingQualifier' in ConceptDomainBinding (XSD) to an Element CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-1 CTS 2: Change 'boundValueSet' cardinality in ConceptDomainBindingDirectoryEntry (XSD) to 1..1 CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-10 BaseMaintenanceService.updateChangeableMetadata parameters CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-9 Changeable/ChangeDescription typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-5 CTS 2: FilterComponent is a PropertyReference and contains a MatchAlgorithm reference CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-6 AnonymousStatement target cardinality CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-8 ChangeDescription stereotypes CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-7 AnonymousStatement typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS211-37 CTS2: Resource content filtering for Query CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-36 CTS2: WADL Graph URLs need to change to better reflect AssociationDirectory as input CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-34 CTS2: MapTargetList and MapTargetListList need a 'Message' wrapper for REST calls CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-33 CTS2: Cardinality of includesResolvedValueSet wrong on ResolvedValueSetHeader CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-41 CTS2: ValueSetDefinitionResolution 'resolve' method has incorrect return type CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-39 CTS2: Association derivation should be optional and not have a default CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-35 CTS2: MapEntry Read and Resolution need WADL 'byURI' REST signatures CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-38 CTS2: AssociationDirectory needs the derivation CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-40 Type of maxtoreturn is string in the WADL definitions. It should be NaturalNumber (or equiv) CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-21 SpecificEntityList incorrectly supertyped CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-20 Designation and Note have inconsistent pattern in schema CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-22 NamedEntityDescription and AnonymousEntityDescription incorrectly defined in schema CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-12 UpdateCodesystemCatalogEntry.usedOntologyEngineeringTool optionality CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-11 Core spec typos CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-24 Documentation issue on ProfileElement CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-23 ImplementationProfiles.ProfileElement not RESTful CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-13 CodesystemCatalogEntry.usedOntologyEngineeringTool CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-19 UpdateEntityDescription is missing elements and does not support "optparam" semantics CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-18 EntityDescriptionQueryService lacking supportedVersionTag CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-16 ChangeSet element doesn't have a MSG header CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-15 AssociationGraph p45 typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-17 EntityDescriptionReadService lacking local variables CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-14 Entity description services p20 typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-38 Refactor inline XSD types from WSDLs (SOAP PSM) CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-37 ResolvedValueSetReadService and QueryService omitted from spec CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-36 ResolvedValueSetDirectory misnamed and mistyped CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-35 AdvancedAssociationQuerySerivce not in WADL (REST PSM) CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-34 Association Information Model derivation and derivationReasoningAlgorithm CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-33 Typo on page 11 of statement information model CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-32 Typo on page 3 of Statement Information model CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-31 Statement needs an identifier CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-42 CodeSystemVersionCatalogReadServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-41 CodeSystemCatalogQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-40 CodeSystemCatalogHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-39 CodeSystemCatalogMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-30 ConceptDomainbinding needs an identifier CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-29 BaseQueryService filter property needs to be individualized CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-25 XML Schema for BaseService has wrong type for supported Profile CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-44 CodeSystemVersionCatalogMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-43 CodeSystemVersionCatalogQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-28 Changeable changeDescription cardinality constraint CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-27 EntityReferences - URIAndEntityNameList CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-26 Remove CONCEPT_DOMAIN_BINDING from ReferenceType CTS2 1.0b1 CTS2 1.0 Resolved closed
COAS-35 COAS operations that return ObservationData COAS 1.0b1 COAS 1.0 Resolved closed
COAS-32 Pg. 193 Under section - D.3 Secure Interoperability Concerns COAS 1.0b1 COAS 1.0 Resolved closed
COAS-31 Pg. 208 Under section - 12.7 AbbreviatedCorba.idl COAS 1.0b1 COAS 1.0 Resolved closed
COAS-34 Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservatio COAS 1.0b1 COAS 1.0 Resolved closed
COAS-33 Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram COAS 1.0b1 COAS 1.0 Resolved closed
COAS-29 Pg. 145-152 Under section - 3.8.1-3.8.17 COAS 1.0b1 COAS 1.0 Resolved closed
COAS-28 Pg. 141 Under section - 3.7.1 General COAS 1.0b1 COAS 1.0 Resolved closed
COAS-26 Pg. 129 Under section - 3.5.4 Sequence Types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-25 Pg. 120 Under section - 3.4.2 Supporting Types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-24 Pg. 81 Under section - 3.3.2.5 Constants COAS 1.0b1 COAS 1.0 Resolved closed
COAS-36 typedefs for TimeStamp and TimeSpan that are never used COAS 1.0b1 COAS 1.0 Resolved closed
COAS-27 Pg. 133 Under section - 3.6.1 Genera COAS 1.0b1 COAS 1.0 Resolved closed
COAS-30 Pg. 153 Under section - 3.9 Conformance Classes COAS 1.0b1 COAS 1.0 Resolved closed
COAS-17 interfaces are presented in alphabetical order and not in logical order COAS 1.0b1 COAS 1.0 Resolved closed
COAS-16 Pg. 108 Under section - 3.3.3.13 FederatedAccess COAS 1.0b1 COAS 1.0 Resolved closed
COAS-20 Pg. 70 Under section -3.3.2.1 Include Files COAS 1.0b1 COAS 1.0 Resolved closed
COAS-19 Pg. 5 Under section - 3.1.5 BOCA & CDL COAS 1.0b1 COAS 1.0 Resolved closed
COAS-23 Pg. 79 Under section - 3.3.2.4.9 TimeStamp COAS 1.0b1 COAS 1.0 Resolved closed
COAS-22 Pg. 75 Under section - 3.3.2.4.3 ObservationData COAS 1.0b1 COAS 1.0 Resolved closed
COAS-15 Pg. 95 Under section - 3.3.3.5 AsynchCallBack COAS 1.0b1 COAS 1.0 Resolved closed
COAS-14 Pg. 92 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-12 Pg. 90 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-11 Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10 COAS 1.0b1 COAS 1.0 Resolved closed
COAS-18 Pg. 5 Under section - 3.1.4 Objects By Value (OBV) COAS 1.0b1 COAS 1.0 Resolved closed
COAS-21 Pg. 71 Under section - 3.3.2.1 Include Files COAS 1.0b1 COAS 1.0 Resolved closed
COAS-10 Pg. 86 Under section - 3.3.2.8 Exceptions COAS 1.0b1 COAS 1.0 Resolved closed
COAS-13 Pg. 91 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-7 alternative verbs for Federated access and put_obsevations COAS 1.0b1 COAS 1.0 Resolved closed
COAS-9 Pg. 81 Under section - 3.3.2.5 Constants COAS 1.0b1 COAS 1.0 Resolved closed
COAS-8 how to use HL7 data types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-37 GCPR issue: Exceptions COAS 1.0b1 COAS 1.0 Resolved closed
COBOL-5 CORBA sequence IDL type in COBOL COBOL 1.0b1 COBOL 1.0 Resolved closed
COBOL-4 COBOL Typedefs NOT universally available COBOL 1.0b1 COBOL 1.0 Resolved closed
CMMN-13 Missing statement on compliance CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-15 Errors in XML-Schema for CMMN (CMMN-1,2,3) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-14 Add CMMN logo to front page of the spec CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-12 Wrong Expression containment mutiplicity CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-11 Wrong multiplicity of the two containments of process parameter in process CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-16 Sentries SHOULD be allowed for DiscretionaryItem's (CMMN-8) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-17 Figure 72 (Example CMMN model) is wrong in spec CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-5 Improve Motivation for introducing an EventListener CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-4 More intuitive symbols for entry and exit criterion CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-2 Contradicting Definitions of Sentry CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-1 Expand TimeEventListener CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-8 Process and Case Task are inconsistent with BPMN call activity notation (CMMN-6) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-7 Inconsistent AutomaticActivation and Repetition Decorators between CMMN and BPMN (CMMN-5) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-10 CMMN FTF Issue: Wrong multiplicity of containment of case file item in case file CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-9 Required/Optional and Discretionary Tasks notation is inconsistent with BPMN (CMMN-7) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-3 Error in description of Active state for a Stage or Task CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-6 Reference from Section 5.4.10.5 CMMN 1.0b1 CMMN 1.0 Resolved closed
CAD12-5 CadConnection, CadSystem: Avaliable_models() enhancement CAD 1.1 CAD 1.2 Resolved closed
CAD12-2 Suggest altering the input parameter CadFeature::ParameterSeq model_params CAD 1.1 CAD 1.2 Resolved closed
CAD12-1 altering the use of EntitySeqs to LongSeqs CAD 1.1 CAD 1.2 Resolved closed
CAD12-4 CadMain::ModelInstance::component()' collides CAD 1.1 CAD 1.2 Resolved closed
CAD12-3 CadGeometry::Curve::tessellate() CAD 1.1 CAD 1.2 Resolved closed
CAD11-19 Model Instances vs. Top-Level Entities CAD 1.0 CAD 1.1 Resolved closed
CAD11-18 Add some operations to CadFoundation module's interfaces CAD 1.0 CAD 1.1 Resolved closed
CAD11-21 Euclidean Dimension CAD 1.0 CAD 1.1 Resolved closed
CAD11-20 EntityFactory and ModelInstanceFactory CAD 1.0 CAD 1.1 Resolved closed
CAD11-34 interface Parameter CAD 1.0 CAD 1.1 Resolved closed
CAD11-25 "Cadsystem" interface issue CAD 1.0 CAD 1.1 Resolved closed
CAD11-24 "Entity-Types" CAD 1.0 CAD 1.1 Resolved closed
CAD11-23 Curve Parameters CAD 1.0 CAD 1.1 Resolved closed
CAD11-22 Tessellation Types CAD 1.0 CAD 1.1 Resolved closed
CAD11-27 remove CadGeometryExtens interface CAD 1.0 CAD 1.1 Resolved closed
CAD11-26 interface Model : CadFoundation:: Attributable replaced CAD 1.0 CAD 1.1 Resolved closed
CAD11-33 struct PolyLineStruct is defined but not used anywhere CAD 1.0 CAD 1.1 Resolved closed
CAD11-32 CadFoundation.idl: In the CadFoundation::EntityPropsStruct CAD 1.0 CAD 1.1 Resolved closed
CAD11-31 bounding_box" behavior CAD 1.0 CAD 1.1 Resolved closed
CAD11-30 Add operations to CadMain::Model CAD 1.0 CAD 1.1 Resolved closed
CAD11-29 Operation to identify opened Models CAD 1.0 CAD 1.1 Resolved closed
CAD11-28 Set color on Layer interface CAD 1.0 CAD 1.1 Resolved closed
CAD-15 What are units for 'angle' field in TessParametersStruct CAD 1.0b1 CAD 1.0 Resolved closed
CAD-14 TessellationStruct normals field should be VectorStructSeq CAD 1.0b1 CAD 1.0 Resolved closed
CAD-13 Should there be a get_parameter_set function at the Model interface level? CAD 1.0b1 CAD 1.0 Resolved closed
CAD-12 CadBrep Edge.nearest_points function needs clarification CAD 1.0b1 CAD 1.0 Resolved closed
CAD-11 CadBrep Edge.nearest_points function incorrect CAD 1.0b1 CAD 1.0 Resolved closed
CAD-10 CAD Services IDL issue (02) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-9 CAD Services IDL issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-8 Binding for Face.nurbs_representation needs major design overhaul/removal CAD 1.0b1 CAD 1.0 Resolved closed
CAD-7 CAD Services needs to clarify 'exact' for nurbs_representation functions CAD 1.0b1 CAD 1.0 Resolved closed
CAD-6 Edge.nurbs_representation should h. 'tolerance' argument declared as inout CAD 1.0b1 CAD 1.0 Resolved closed
CAD-5 Surface.nurbs_approximation should 'tolerance' argument declared as inout CAD 1.0b1 CAD 1.0 Resolved closed
CAD-4 Surface.nurbs_approximation should be renamed nurbs_representation CAD 1.0b1 CAD 1.0 Resolved closed
CAD-3 Need to add a "ColorStruct color;" to the PresentationStruct CAD 1.0b1 CAD 1.0 Resolved closed
CAD-2 IDL extracts in document are inconsistent about showing module declarations CAD 1.0b1 CAD 1.0 Resolved closed
CAD-1 CAD FTF issue regarding UML which looks kind of like CORBA profile CAD 1.0b1 CAD 1.0 Resolved closed
CAD-43 Incompletely specified operations - issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-42 Several properties in the CadBrep::PropertyStruct need clarification. CAD 1.0b1 CAD 1.0 Resolved closed
CAD-41 problems in the EntityCreation interface. CAD 1.0b1 CAD 1.0 Resolved closed
CAD-40 Entity Factory issue (Function 5) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-39 Entity Factory issue (Function 4) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-38 Entity Factory issue (Function 3) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-37 Entity Factory issue (Function 2) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-36 Entity Factory issue (Function) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-35 interface for STEP open shel CAD 1.0b1 CAD 1.0 Resolved closed
CAD-34 Deletion of CadFourndation::Entity descendants CAD 1.0b1 CAD 1.0 Resolved closed
CAD-33 Entity.Position() returns PointStructure instead of TransformationStructure CAD 1.0b1 CAD 1.0 Resolved closed
CAD-32 There is no way to delete any CadFoundation::Entity interface child. CAD 1.0b1 CAD 1.0 Resolved closed
CAD-31 CadFoundation::Entity interface CAD 1.0b1 CAD 1.0 Resolved closed
CAD-30 Surface.intersect_ray argument error CAD 1.0b1 CAD 1.0 Resolved closed
CAD-29 CadSystem Properties issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-28 I haven't found any way to create ModelInstance CAD 1.0b1 CAD 1.0 Resolved closed
CAD-27 Replace #include "CadFeature.idl with #include "CadFoundation.idl" CAD 1.0b1 CAD 1.0 Resolved closed
CAD-26 Method names in topological entities are not everywhere unified CAD 1.0b1 CAD 1.0 Resolved closed
CAD-25 how to add new topological entities to existing model with sharing of exist CAD 1.0b1 CAD 1.0 Resolved closed
CAD-24 method of CadMain::EdgeLoop has to be renamed CAD 1.0b1 CAD 1.0 Resolved closed
CAD-23 we have to generalize is_manifold() methods in all BRep entities CAD 1.0b1 CAD 1.0 Resolved closed
CAD-22 adding an attribute to the entity group CAD 1.0b1 CAD 1.0 Resolved closed
CAD-21 Section 3.4, Editorial CAD 1.0b1 CAD 1.0 Resolved closed
CAD-20 Sections 1.8, 2.8, 3.1, 3.2, Editorial CAD 1.0b1 CAD 1.0 Resolved closed
CAD-19 Support for STEP input / output? CAD 1.0b1 CAD 1.0 Resolved closed
CAD-18 Body.property_info, several values are calculated. What is the return accur CAD 1.0b1 CAD 1.0 Resolved closed
CAD-17 BodyTessellationStruct issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-16 Model level parameters for geometry creation issue CAD 1.0b1 CAD 1.0 Resolved closed
CPP11-228 CORBA::Bounds and CORBA::TypeCode::Bounds CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-227 Read-only restrictions on parameters CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-226 C++ mapping: missing from_wchar and to_wchar CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-225 C++ mapping for IN object references CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-224 IDL generated C++ types and stream operators CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-223 Wide string allocation (2) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-218 Why does get_principal() take an Environment parameter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-217 POA_*_tie classes in 18.1.4 can"t be supported CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-214 Boolean type left undefined by C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-213 Defect with anonymus types in union mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-220 Section 18.1.2: _this() and IMPLICIT_ACTIVATION need clarification CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-219 PortableServer:ObjectId_tow_wstring() and string_to_ObjectId() CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-216 Section 8.2: set_exception() supported by BOA? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-215 Section 17..13.1 release()method should be added to mappping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-222 Wide string allocation (1) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-221 Bounded strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-212 Interpretation of _narrow semantics CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-183 Distinction between _var and _ptr types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-182 Return value of maximum() for unbounded sequences CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-195 Sequence buffer types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-194 Sequence lacks common features CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-185 get_principal () needs an environment parameter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-184 Names of anonymous types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-181 Bounded sequence problem (Section 16.11 p. 16-23) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-180 Problem with Any::to_object memory management CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-189 C++ mapping complexity CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-188 string and objrev members of constructed types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-191 State of release flag for sequence CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-190 Sequence implementation CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-193 References returned from sequence operator[] after realloc CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-192 Sequence maximum() call CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-187 fixed- vs. variable-length types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-186 Implementation dependency for _var and _ptr CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-179 Any string extractor CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-178 Adding T_copy function CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-136 Unknown parts of an IOR and interoperability CORBA 2.2 CPP 1.1 Resolved closed
CPP11-135 Potential interop. problem in CORBA 2.3: pseudo-operation marshalling CORBA 2.2 CPP 1.0 Resolved closed
CPP11-134 Clarification of OBV GIOP encoding rules CORBA 2.2 CPP 1.0 Resolved closed
CPP11-141 Mapping for wide strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-140 Old References in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-139 Semantics of >>= operator in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-153 Errors in example code for boxed struct CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-152 Object reference members, _var, and widening CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-151 98-09-03, exception inconsistency CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-150 Is SystemException supposed to be concrete? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-149 DSI C++ issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-145 resolve_initial_references missing from Orb interface CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-144 Section 7.3.5 ValueBase editorial changes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-143 C++ mapping for strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-142 Any and WChar issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-148 New C++ issue about T_out classes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-147 from_string issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-146 void * functions for Any CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-138 Alias type codes in any values CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-137 Missing Mappings for Object CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-246 Signature of _narrow in exceptions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-245 C++ issue to coordinate with proposed resolution of issue 752 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-244 Missing text describing fixed point constant mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-234 Missing constructor for Fixed CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-233 fixed_digits and fixed_scale member functions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-243 C++ Any mapping proposed change CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-242 How to put a generic CORBA exception into an Any CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-232 macros for fixed arithmetic results CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-231 Typos on p 20-34 of orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-230 Fixed types in orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-229 CORBA::ORB::InvalidName ambigious in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-238 C++ Fixed Type (03) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-237 Fixed type (02) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-241 _out parameter typo CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-240 Typo in orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-236 C++ Fixed type issue (01) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-235 C++ mapping for fixed is broken (01) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-239 String member initialization CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-202 Access to sequence elements CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-201 Any and IN_COPY_VALUE CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-200 operator>>= on strings and object references CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-199 A_ptr and A_var should be distinct types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-211 Default constructor for String_var CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-210 explicit copy/adopt for String_var CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-209 TypeCode interpreter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-208 Any release flag and operator<<= CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-205 to/from string for Any type safety CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-204 nested ptr and var types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-197 Typo in table 3? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-196 Sequence creation CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-207 Accessors for release flag of sequence CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-206 T_copy for string and array CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-198 _var types for fixed-length types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-203 TypeCode mapping update for CORBA 2.) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-165 Interface issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-164 Transfer of C++ codes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-163 ORB mapping re Policy CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-169 Access to sequence buffers CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-168 Omission in union C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-167 Any inserters for strings need to use const pointers CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-166 C++ keyword mapping ambiguous CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-158 Extraction from Any by pointer CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-157 C++ spec uses reserved names in global namespace CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-156 string allocation functions -- description ambiguous CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-155 String sequence and allocbuff CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-154 _raise() should be const CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-160 boxed types for floating point values CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-159 Any inserters and extractors CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-162 CustomMarshal mapping type CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-161 CORBA2.3 C++ mapping for the TypeCode class (section 20.31.2) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-172 C++ classes for modules CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-171 Defining an operator for struct/union/sequence _var types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-170 T__alloc in C mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-175 Memory Management Clarification CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-174 Union discriminators in C++ CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-173 In String Argument Passing Question CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-177 inserter and extractor functions for exceptions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-176 Union problem CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-129 GIOP fragment alignment issue for CORBA 2.3 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-128 COMM_FAILURE and completion_status CORBA 2.2 CPP 1.0 Resolved closed
CPP11-127 Typo in page 15-44 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-126 CloseConnection CORBA 2.2 CPP 1.0 Resolved closed
CPP11-125 How to handle unexpected exceptions? CORBA 2.2 CPP 1.0 Resolved closed
CPP11-124 IIOP server-initiated connection closure problem CORBA 2.0 CPP 1.0 Resolved closed
CPP11-133 Move recently added text to correct place CORBA 2.2 CPP 1.0 Resolved closed
CPP11-132 OBV GIOP clarification needed CORBA 2.2 CPP 1.0 Resolved closed
CPP11-131 Tagged Component interactions CORBA 2.2 CPP 1.0 Resolved closed
CPP11-130 Obsolete text in ptc/98-08-13.pdf CORBA 2.2 CPP 1.0 Resolved closed
CPP11-109 Fixed(const char *) constructor problem CPP 1.0 CPP 1.1 Resolved closed
CPP11-108 Editorial typo in Section 1.36.3 of C++ mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-98 Two obvious typos in the C++ mapping for OBV (docs/formal/99-07-41.pdf) CPP 1.0 CPP 1.1 Resolved closed
CPP11-107 Object _out class copy constructor & assignment op wrong CPP 1.0 CPP 1.1 Resolved closed
CPP11-106 CORBA 2.3 Editorial problem in TypeCode CPP 1.0 CPP 1.1 Resolved closed
CPP11-101 Contents of string members (02) CPP 1.0 CPP 1.1 Resolved closed
CPP11-100 Contents of string members (01) CPP 1.0 CPP 1.1 Resolved closed
CPP11-102 String extractor semantics undefined? CPP 1.0 CPP 1.1 Resolved closed
CPP11-104 Exception constructors should be protected CPP 1.0 CPP 1.1 Resolved closed
CPP11-103 Exception::_raise() should be const? CPP 1.0 CPP 1.1 Resolved closed
CPP11-99 Union string member mapping defect? CPP 1.0 CPP 1.1 Resolved closed
CPP11-105 Unary operators for Fixed class have wrong return types CPP 1.0 CPP 1.1 Resolved closed
CPP11-114 1 of 4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-113 NamedValue not only an NVList element CPP 1.0 CPP 1.1 Resolved closed
CPP11-117 4 of 4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-116 don't understand the last paragraph of 1.18.2: CPP 1.0 CPP 1.1 Resolved closed
CPP11-119 Extraction operator for system exceptions? CPP 1.0 CPP 1.1 Resolved closed
CPP11-118 Need Any::to_value operation? CPP 1.0 CPP 1.1 Resolved closed
CPP11-115 2 of4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-122 Supporting typedefs for _var types? CPP 1.0b1 CPP 1.1 Duplicate or Merged closed
CPP11-121 Any::to_abstract_base needs statement about memory management CPP 1.0 CPP 1.1 Resolved closed
CPP11-112 Standard object operations & DynamicImplementation CPP 1.0 CPP 1.1 Resolved closed
CPP11-111 Inconsistency in 1.7 and 1.9 of mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-123 Typographical problems CPP 1.0 CPP 1.1 Resolved closed
CPP11-120 allocbuf() for bounded sequences? CPP 1.0 CPP 1.1 Resolved closed
CPP11-110 Fixed::round and truncate issue CPP 1.0 CPP 1.1 Resolved closed
CPP13-72 ORB interface destroy() operation issue CPP 1.1 CPP 1.3 Resolved closed
CPP13-71 _ptr_type and _var_type typedefs CPP 1.0b1 CPP 1.3 Resolved closed
CPP13-76 make it possible to write more generic C++ code CPP 1.2 CPP 1.3 Resolved closed
CPP13-75 Servant_var + spec typo? CPP 1.2 CPP 1.3 Resolved closed
CPP13-79 valuetype classes should add _out_type typedef CPP 1.2 CPP 1.3 Resolved closed
CPP13-78 Interface should add _out_type typedef CPP 1.2 CPP 1.3 Resolved closed
CPP13-77 C++ keywords should be updated CPP 1.2 CPP 1.3 Resolved closed
CPP13-74 Section 4.5.4: parameter to _narrow CPP 1.2 CPP 1.3 Resolved closed
CPP13-73 Context PIDL mapping bug CPP 1.1 CPP 1.3 Resolved closed
CPP13-80 get_policy should return Policy, not Policy_ptr CPP 1.2 CPP 1.3 Resolved closed
CPP11-97 operator>> for String_var CPP 1.0 CPP 1.1 Resolved closed
CPP11-96 Valuetypes and _out classes in C++ mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-89 generate concrete classes and factories for valuetypes without initializer CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-88 add a _var type for each servant type CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-87 tie doesn"t do ref counting CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-86 Misleading text for DSI invoke() and _primary_interface() CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-95 Valuetypes and arbitrary graphs CPP 1.0 CPP 1.1 Resolved closed
CPP11-94 Factories for StringValue and WStringValue CPP 1.0 CPP 1.1 Resolved closed
CPP11-84 _primary_interface CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-83 The C++ mapping for valuetype _narrow should not _add_ref CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-92 Valuetype argument passing CPP 1.0 CPP 1.1 Resolved closed
CPP11-91 Add AbstractBase base type to IDL language? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-90 narrow abstract interface class to concrete object? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-93 Sequences and get_buffer() CPP 1.0 CPP 1.1 Resolved closed
CPP11-82 sequence allocbuf parameter != 0 CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-85 Any missing LongLong operators, etc? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-43 Exception id for each exception type CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-42 Accessor for exception id CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-47 operator<< for ostreams and Exceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-49 C++ semantics vs. IDL semantics CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-48 ANy release flag and operator CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-53 Legal IDL cannot map to C++ CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-52 Double underscore identifier mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-46 make String_var reference but not adopt CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-45 buffer classes for sequences CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-50 u++ binding for ServerRequest pseudo object CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-51 [q] intf name == op name CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-44 TypeCode for each basic and IDL defined types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-41 Accessors for the Any release flag CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-40 Constructor taking discriminant as argument CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-39 Name field for SystemExceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-31 union accessors CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-30 callee-allocated storage modification CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-37 accessor members for structs CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-36 allocbuf and initialization of elements CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-34 Allocated storage for out and return strings CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-33 accessor function on SystemException CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-28 void* from Any for constructed types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-27 handling void* from Any CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-32 Mapping for IDL context CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-38 union accessors require temporaries CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-29 anonymus types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-35 C++ namespaces CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-63 Multiple inheritance of C++ Servants is ill-defined CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-59 Blocking semantics of get_next_response not well specified CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-58 Section 16.2, Section 16.6: editorial CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-67 No conversion defined from a B_var to an A_ptr CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-66 ServantBase mappings CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-62 C++ mapping of servants may result in ambigous run-time behavior CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-61 Implementation problem with policy objects using root POA CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-56 Interface definition must be standardized CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-55 String_var and Any_var are missing the T_ptr definition CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-65 C and C++ Mapping question CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-64 inout strings modifiable? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-60 sec. 18.1.2: explicit information on _this() is missing CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-57 IDL from Ennvironment has invalid attribute CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-54 const method qualification should be removed CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-25 Storage ownership issue CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-24 Global functions vs. T_var namespace CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-22 Array slice example CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-21 Semantics of sequence length() operation CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-17 Implementation description CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-16 Detection of initialization of T_var CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-14 example incorrect? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-13 Levels of portability conformance requested CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-20 Copying of out parameters CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-19 C vs. C++ coding style CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-18 Autoextension of sequences CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-26 Pointers vs. values CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-15 Assignment to T_var CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-23 Array_forany CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-76 Problems with deactivate_object() CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-75 Do POA servant classes need to use virtual inheritance? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-73 Spec does not mention the existance of an Any_out class CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-72 _var & _out types problems (01) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-74 Spec is too verse in defining the T_var types for fixed length CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-81 Passing Fixed to operations CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-80 Comparison operators for Fixed CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-70 C++ Sequence mapping Question CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-69 TypeCode_ptr base_typecode(TypeCode_ptr tc) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-79 Parameter passing rules for ValueFactory CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-78 C++ language mapping minor editorial revision CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-68 C++ mapping for fixed is broken (02) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-71 Missing operators in orbos/98-01-11 CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-77 Section 5.3.6.3 Value Factories CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-2 Fixed structs CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-5 Inconsistent interfaces for the operation pairs *duplicate* and CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-4 Testing exceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-8 Pseudo objects for DSI CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-7 Identifier conflicts resulting from the language mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-11 TypeCode/Value mismatch in ANY CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-10 illegal union access when discriminator is wrong CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-3 Passing of object reference in pointers CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-12 Representation of void* returned from ANY CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-6 interface mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-9 _ptr member accessors for string and objref CPP 1.0b1 CPP 1.1 Resolved closed
CPP12-9 Escaped keyword mapping? CPP 1.1 CPP 1.2 Resolved closed
CPP12-8 Local interfaces issue 1 CPP 1.1 CPP 1.2 Resolved closed
CPP12-16 implementing local interfaces in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-15 Initialized T_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-14 Missin operations in Object interface, ptc/01-06-07 CPP 1.1 CPP 1.2 Resolved closed
CPP12-19 String_var and C++ implicit conversions CPP 1.1 CPP 1.2 Resolved closed
CPP12-18 need mapping for get_orb and get_component on CORBA::Object CPP 1.1 CPP 1.2 Resolved closed
CPP12-17 No Mapping for Local interface in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-11 Bug on _var references CPP 1.1 CPP 1.2 Resolved closed
CPP12-10 Dangling reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-7 Structure member ordering CPP 1.1 CPP 1.2 Resolved closed
CPP12-6 semantics of valuetype _downcast operation unclear CPP 1.1 CPP 1.2 Resolved closed
CPP12-13 ValueRefCountBase::_add_ref CPP 1.1 CPP 1.2 Resolved closed
CPP12-12 C++ mapping for CORBA::LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-3 LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-2 mapping of local interfaces CPP 1.1 CPP 1.2 Resolved closed
CPP12-5 How to create a local object reference? CPP 1.1 CPP 1.2 Resolved closed
CPP12-4 CORBA::Object & LocalObject CPP 1.1 CPP 1.2 Resolved closed
C11-82 How to allocate storage for a basic type you wish to place in an any? C 1.0b1 C 1.1 Resolved closed
C11-81 Use of "objref_ptr" C 1.0b1 C 1.1 Resolved closed
C11-83 Correct arguments to send multiple requests C 1.0b1 C 1.1 Resolved closed
C11-73 Out of bound value behaviour for _maximum and _length in sequences C 1.0b1 C 1.1 Resolved closed
C11-72 Type declaration C 1.0b1 C 1.1 Resolved closed
C11-76 Order of parameters in the C mapping C 1.0b1 C 1.1 Resolved closed
C11-75 Editorial C 1.0b1 C 1.1 Resolved closed
C11-80 CORBA_string_alloc C 1.0b1 C 1.1 Resolved closed
C11-79 Argument order inconsistent (Section 14.25.2) C 1.0b1 C 1.1 Resolved closed
C11-74 Portably getting the value of the bounds of a sequence C 1.0b1 C 1.1 Resolved closed
C11-78 Reference to undefined term DIR (Section 14.24.1) C 1.0b1 C 1.1 Resolved closed
C11-71 Order of arguments in C Language mapped operation C 1.0b1 C 1.1 Resolved closed
C11-77 Wrong order of parameters C 1.0b1 C 1.1 Resolved closed
C11-64 Semantics of CORBA_exception_id()"s return type C 1.0b1 C 1.1 Resolved closed
C11-63 Suggested optimization for string duplication C 1.0b1 C 1.1 Resolved closed
C11-59 Unions represented with either union or struct C 1.0b1 C 1.1 Resolved closed
C11-58 All interfaces must be defined at global scope? C 1.0b1 C 1.1 Resolved closed
C11-70 Confusion about ORB handling call to pseudo objects via DII C 1.0b1 C 1.1 Resolved closed
C11-69 Entire section 14.1 should not be there (CORBA 14) C 1.0b1 C 1.1 Resolved closed
C11-67 CORBA_BOA_set_exception() parameter issues C 1.0b1 C 1.1 Resolved closed
C11-66 Specification type on CORBA_ORB_object_to_string example C 1.0b1 C 1.1 Resolved closed
C11-60 Sequence release flag implementation C 1.0b1 C 1.1 Resolved closed
C11-68 Support for efficient DII invocation (Section 17.7.1 CORBA 2.)) C 1.0b1 C 1.1 Resolved closed
C11-65 Contents of string literal exception identifier C 1.0b1 C 1.1 Resolved closed
C11-62 Malloc problems with sequence types C 1.0b1 C 1.1 Resolved closed
C11-61 Confusing sequence example C 1.0b1 C 1.1 Resolved closed
C11-56 C keywords C 1.0b1 C 1.1 Resolved closed
C11-57 Problems with underscores C 1.0b1 C 1.1 Resolved closed
C11-84 Content of an Any is a pointer to the type -- Issue C 1.0b1 C 1.1 Resolved closed

Issues Descriptions

Several processes and external projects need definitions for organizations, and related to that, locations

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    An organization ontology that covers formal organizations, legal entities, and organization membership is essential for the ongoing retail ontology effort, for development of an ontology for the emerging PPMN standard, and others.

    Note that representation of domicile requires the concept of a geopolitical entity, which the task force agrees belongs in a more general locations ontology. Thus, a locations ontology is also needed as part of a resolution for this issue.

  • Reported: MVF 1.0b2 — Sun, 4 Aug 2024 01:11 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Add new locations and organizations ontologies to the Commons library

    The resolution to this issue affects both the specification document and machine readable files. It adds one property to the designators ontology and incorporates two additional ontologies, one describing locations, which is needed for several processes: the Retail Industry Ontology, the RoSO ontology for robotics, a planned revision to the Multiple Vocabulary Facility (MVF), and a planned update to LCC, as well as external efforts, and an organizations ontology, also needed for the RIO ontology and external work.

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

Clean up a few issues with the Locations ontology

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    1. County and FederalCapitalArea should be subclasses of CountrySubdivision

    2. FederalState should have synonyms rather than this in the note "variously referred to as a state, province or canton".

    3. Several annotations on geographic region identifier and a few other concepts need clarification

  • Reported: Commons 1.1 — Fri, 16 Aug 2024 18:15 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Cleaned up a few issues identified in the locations ontology during review

    These include adjusting the class hierarchy for consistent representation of country subdivisions as well as minor adjustments to definitions

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

The definition of aspect needs refinement

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Rather than classifying 'something' an aspect should classify a set or group of things - at a higher metalevel than 'quality' in BFO, for example. This impacts the Classifiers ontology, in which Aspect is defined.

  • Reported: Commons 1.1 — Fri, 12 Apr 2024 18:40 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Clarified the definition of the Aspect class

    Revised metadata to be current and revised the definition from

    'characteristic or feature that can be used to dimensionalize, filter, or subset something'

    to

    'characteristic or feature that can be used to dimensionalize, filter, or a class, collection, or set of things'

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

Several OMG and external ontology efforts need to be able to talk about registration authorities

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Requirements range from retail to finance and health care, where certain constructs, such as identifiers, are registered with specific authorities, and understanding who has registered a particular identifier is essential to the definition of that identifier.

    Coverage should include definitions for registration authority, registrar (which could be a person or organization, and may or may not be part of the same organization as the authority), a registered identifier, which should be modeled as a contextual identifier, the registry and some registration scheme.

    Note that the resolution to this issue depends on Commons-1.2-8, including properties in the organizations ontology.

  • Reported: MVF 1.0b2 — Mon, 5 Aug 2024 17:47 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Add a new ontology covering registration authorities to the Commons library

    Requirements range from retail to finance, government, pharmaceuticals, and health care, where certain constructs, such as identifiers, are registered with specific authorities, and understanding who has registered a particular identifier is essential to the definition of that identifier.

    The OMG's FIGI standard, for example, allows for a single registration authority (RA), which is Bloomberg LP, but enables multiple registrars to act on behalf of the RA. Today registrars include Bloomberg LP as well as Kaiko.

    Coverage should include definitions for registration authority, registrar (which could be a person or organization, and may or may not be part of the same organization as the authority), a registered identifier, which should be modeled as a contextual identifier, the registry and some registration scheme.

    Note that the resolution to this issue depends on the resolutions in Ballot #3, Commons-1.2-8, including properties in the organizations ontology.

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

Several properties in the quantities and units ontology are overly constrained

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    One example of this is hasNumericValue. It is currently declared to be functional, but could be the parent property for several properties of some class. In this case, the resulting ontology could be logically inconsistent if the values are not the same (and even if they are, by coincidence, that's still a problem). Other properties that are also declared as functional should be reviewed for the same issue.

  • Reported: MVF 1.0b2 — Sun, 18 Feb 2024 02:25 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Revised the quantities and units ontology to remove unnecessary constraints

    1. Revised the quantities and units ontology to remove functional declarations on a number of properties. These constraints caused reasoning errors when any of the properties, such as hasNumericValue, were used as the superproperty of more than one subproperty on the same class (concept).
    2. Eliminated circular restrictions on system of quantities, system of units and added links back to the appropriate system from the quantity or unit
    3. Revised the license to include the copyrights and full text, added Airbus, Ontogenesis Solutions

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

The quantities and units ontology is missing the concept of a measurement reference

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This would assist in alignment with SysML v2, but more importantly allows alignment of some quantity value with a more general measurement reference rather than only a measurement unit, for representation of IU in pharma, for example.

  • Reported: MVF 1.0b2 — Tue, 13 Feb 2024 22:01 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Add measurement reference to the quantities and units ontology

    The resolution to this issue involves:
    1. Adding a new measurement reference class, which is a subclass of the union of measurement procedure, measurement unit, and reference material, though not equivalent because there may be other related concepts
    2. Adding / replacing the superclass for measurement procedure, measurement unit, and reference material with measurement reference as appropriate,
    3. Adding measurement reference as the parent for measurement scale, corresponding with SysML v2, and
    4. Adding a new property, has measurement reference, and making has measurement unit a subproperty of has measurement reference

    Note that the metadata required for this revision has been applied to the resolution for Commons12-5 and thus the resolution to this issue depends on the resolution to Commons12-5.

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

Need an ontology representing multidimensional arrays

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is needed for representation of tensor and vector quantities for the quantities and units ontology, and for representation of certain machine learning algorithms, among other requirements.

  • Reported: COMMONS 1.0b2 — Fri, 14 Jul 2023 18:03 GMT
  • Disposition: Deferred — COMMONS 1.2b1
  • Disposition Summary:

    Significant research is required to complete this ontology and related work on tensor and vector quantities

    The work to complete this resolution requires testing with the SysML v2 library of quantities and units, and may ultimately result in additional changes to the approach taken to represent quantities in general. This has been a significant effort to date, including a number of contributors who created the corresponding artifacts for SysML v2. We believe more care needs to be taken to test any resulting ontology and reference library, which is planned over the coming months.

    Because some of the other work on the Commons 1.2 specification was more urgently needed, we elected to defer this until the Commons 1.3 RTF.

  • Updated: Fri, 20 Dec 2024 22:18 GMT

The quantities and units ontology does not allow representation of unitless quantity values

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    There is a gap in the quantities and units ontology whereby we cannot represent counts of things, which do not necessarily have units, nor can we properly represent ratio values, which may involve scalar quantity values that do not have units. There is also a challenge in representing ratio values more generally, since there is no numeric value representing the ratio on the class.

  • Reported: Commons 1.1b1 — Tue, 13 Feb 2024 21:34 GMT
  • Disposition: Deferred — COMMONS 1.2b1
  • Disposition Summary:

    The issue of unitless measures should be addressed in the context of the work we are doing with tensors and vectors

    There is ongoing good work on an ontology for tensors and vectors, with planned revisions for tensor and vector quantities planned for the Commons 1.3 RTF due to the amount of work involved. This issue should be resolved in conjunction with that one in case there are relevant related revisions.

  • Updated: Fri, 20 Dec 2024 22:18 GMT

Several OMG and external processes need concepts for describing regulatory authorities

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    These include tax authorities for retail applications, banking regulators in finance, other regulators for manufacturing and engineering applications. A small ontology that supports the definition of regulatory authorities, including their jurisdiction, would be quite useful for these kinds of applications and is needed for the emerging retail industry ontology.

  • Reported: MVF 1.0b2 — Mon, 5 Aug 2024 22:23 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Augment the Commons library with an ontology for regulatory agencies to support retail, manufacturing, and other applications

    The primary use cases for regulatory agencies in retail are for tax authorities, but for retail pharmaceuticals, there is also a requirement to be able to represent medicines regulatory agencies and related governmental stakeholder, for example. A small ontology that supports the definition of regulatory authorities, including their jurisdiction, would be quite useful for these kinds of applications and is needed for the emerging retail industry ontology.

    Note that the resolution to this issue depends on the resolutions in Ballot #3, Commons-1.2-8, including properties in the organizations ontology.

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

Certain OMG processes need additional structured collection definitions

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Definitions of certain kinds of structured collections, including sets, lists, and some ordered collections are not well defined in OWL. A small ontology that includes definitions for these elements is needed for retail and other OMG work in progress.

  • Reported: MVF 1.0b2 — Tue, 6 Aug 2024 15:26 GMT
  • Disposition: Resolved — COMMONS 1.2b1
  • Disposition Summary:

    Augment the Commons library with a small ontology for structured collections

    Definitions of certain kinds of structured collections, including sets, lists, and some ordered collections are not well defined in OWL. Examples of ordered collections include chronologically ordered collections and indexed collections. A small ontology that includes definitions for these elements is needed for retail and other OMG work in progress.

    Note that the resolution to this issue depends on the resolutions in Ballot #3, Commons-1.2-8, including properties in the organizations ontology.

  • Updated: Fri, 20 Dec 2024 22:18 GMT
  • Attachments:

Misc Post-ballot-13 Fixes

  • Key: C2MS11-249
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There are a handful of tweaks that need to be made on top of C2MS11-187, discovered during the Ballot #13 effort:

    • In Device Message Additional Information. Device.n.Name should be R rather than D because Num-of-Devices is 1+.
    • In the Heartbeat Message Diagram, we didn't remove the "=30" in PUBRATE, though it was supposed to be removed, according to C2MS11-187 (resolution to C2MS11-188)
    • The same changes as C2MS11-25, should also be done for Heartbeat Message Tables and text and Resource Message Tables and text.
    • In the diagram for TLM CCSDS Packet, add the warning on stream-mode.
    • Replay Telemetry Data Request Message Diagram does not have correct Formats in the field names and comment.
    • In MVAL Response and MVAL Data message, as well as the corresponding Archive Messages, C2MS11-187 introduced ALARM-STATUS. Change the name of this field in the table as well as the diagram and diagram comments to ALARM-STATE.
    • Command Request and Command Echo messages didn't mark the CCSDSFRAME as DEPRECATED (did so in the descriptive text, but not in the field values for the table. Note the way this was done for Replay Telemetry Data Request Message Additional Information. Additionally, in all cases where we deprecate CCSDSFRAME, it should be bolded.
    • The diagram for product request message has a label issue and needs to be adjusted.
    • As part of C2MS11-191, we removed all the .xsds from the title page. However, that issue inadvertently did not remove the Fields.xsd. It should be removed as part of this issue.
    • There is missing text in the Section 8.13.7.2 Header for Navigation Data Messages. In all other cases, there is a description under this heading. This one should say, "The abbreviated Table 8-174 below shows the required values of the MESSAGE-TYPE and MESSAGE-SUBTYPE fields for the header of Navigation Data Messages." The corresponding table name should be "Header Field Values for Navigation Data Messages".
    • In C2MS11-187, table 8-20 Archive Message Retrieval Request Additional Information, the type is not shown for MSG.n.NUM-OF-FIELDS. This should be U16 and 'D'.
    • Use Critical instead of Severe for alarm levels throughout (affects model diagrams and additional info tables). Under the Log Message use text: "4. A display application may subscribe to Critical (Level 4) Severity messages." In Directive Message use text "to provide a GO/NOGO or rollup Normal, Warning, Distress or Critical status on the data link."
    • in the Heartbeat Message, NUM-OF-SUBSCRIPTIONS shows a "U16" in the Value column, which is redundant and should be removed.
    • Throughout the "Additional Information" tables, where there are inner tables with "Value" and "Description", it is often the case that some of these columns are left-justified and some centered, and this is often true with in the same table (see "Telemetry Processed Frame Message Additional Information"). Recommend centering the "Value" column of the inner table and left-justifying the "Description" column of the inner table. See "Mnemonic Value Response Message Additional Information" for a good and consistent example of what this would look like.
    • Related to the above, items in the 'Value' column for Message Additional Information tables are sometimes centered and sometimes left-justified. See Mnemonic Value Request Message. This needs to be made consistent.
    • In Mnemonic Value Request Message Additional Information table, MNEMONIC.n.SAMPLE-RATE uses a divided 'Value' column showing both '1+' and 'milliseconds'. Merge the cell, leave '1+', but get rid of 'milliseconds' and add 'miliseconds' to the 'Description' column.
    • In C2MS11-187, table 8-114 Archive Mnemonic Value Request Message Additional Information, the type is not shown for MNEMONIC.n.NAME. This should be String and 'D'.
  • Reported: C2MS 1.0 — Mon, 22 Apr 2024 00:33 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    resolve all these leftover changes needed as the final C2MS11-187 was reviewed and the specification document was edited.

    These changes depend and and are addendums to all other resolved issues in C2MS 1.1.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Table Formatting for Value and Description Columns

  • Key: C2MS11-254
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:
    • Throughout the "Additional Information" tables, where there are inner tables with "Value" and "Description", it is often the case that some of these columns are left-justified and some centered, and this is often true with in the same table (see "Telemetry Processed Frame Message Additional Information"). Recommend centering the "Value" column of the inner table and left-justifying the "Description" column of the inner table. See "Mnemonic Value Response Message Additional Information" for a good and consistent example of what this would look like.
    • Related to the above, items in the 'Value' column for Message Additional Information tables are sometimes centered and sometimes left-justified. See Mnemonic Value Request Message. This needs to be made consistent.
  • Reported: C2MS 1.0 — Tue, 7 May 2024 20:16 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Use consistent formatting in Additional Information Tables

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Rename Section 6

  • Key: C2MS11-260
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    With C2MS11-90 much explanatory text and tables regarding Message Fields and types have moved from Section 8 into Section 6. Because of this, rename from
    "6 PIM – C2MS Subject Names and Message Structure"
    to
    "6 PIM – C2MS Subject Names and Message Composition"

  • Reported: C2MS 1.0 — Wed, 8 May 2024 22:50 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Rename from
    "6 PIM – C2MS Subject Names and Message Structure"
    to
    "6 PIM – C2MS Subject Names and Message Composition"

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Clear up Text with Product Message ME5 and ME6.

  • Key: C2MS11-223
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Already identified as an issue in C2MS11-187, and resolved in its resolution, we are clarifying the text in the Additional Information Tables regarding PROD-SUBTYPE. The text describing ME5 and ME6 in Table 8-154 Properties of the Miscellaneous Elements for the Product Message needs to be updated as well.

  • Reported: C2MS 1.0 — Sun, 7 Apr 2024 21:33 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Table Text for ME5 and ME6 as Described

    Update text in Table 8-154 Properties of the Miscellaneous Elements for the Product Message

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Align Alarm Text/Colors with other SDTF Specs

  • Key: C2MS11-222
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Align Alarm Text/Colors with other SDTF Specs.

    Include a listing in the document that correlates colors with codes.

  • Reported: C2MS 1.0 — Wed, 20 Mar 2024 21:01 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    NOTE: Model figures will be shown in C2MS11-88 resolution.
    Table 8-9: Log message SEVERITY of 0=Debug, 1=Nominal, 2=Medium, 3=High, 4=Critical
    Change to DEBUG, INFO, WARN, ERROR, FATAL [NEED C2MS issue]
    Table 8-11: RED/YEL/NORM
    Deprecate RED/YEL/NORM. Add: NORMAL,WARNING,DISTRESS,SEVERE [NEED C2MS issue]
    Table 8-26: RESPONSE-STATUS enum 1=Ack, 2=Working/keep alive, 3=Successful completion, 4=Failed completion, 5=Invalid Request, 6=Final Response
    Table 8-53: DEVICE.n.STATUS enum 0=Debug, 1=Normal/Green, 2=Yellow, 3=Orange, 4=Red
    Rename to 0=Standby, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
    Table 8-58: COMPONENT-STATUS enum 0=Debug, 1=Normal/Green, 2=Yellow, 3=Orange, 4=Red
    Rename to 0=Standby, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
    Table 8-84: MNEMONIC.n.STATUS enum 1=Valid, 2=Valid/No data, 3=Invalid
    Table 8-104: Attributes: RED-HIGH, RED-LOW, YELLOW-HIGH, YELLOW-LOW
    Deprecate the individual items above. Add new MNEMONIC.n.SAMPLE.STATUS with enum of: 0=Unavailable, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
    And SAMPLE..QUALITY 0=Good, 1=Questionable
    Table 8-109: Attributes: RED-HIGH, RED-LOW, YELLOW-HIGH, YELLOW-LOW
    Deprecate the individual items above. Add new MNEMONIC.n.SAMPLE.STATUS with enum of: 0=Unavailable, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
    And SAMPLE..QUALITY 0=Good, 1=Questionable
    Table 8-126: Attributes: RED-HIGH, RED-LOW, YELLOW-HIGH, YELLOW-LOW
    Deprecate the individual items above. Add new MNEMONIC.n.SAMPLE.STATUS with enum of: 0=Unavailable, 1=Normal, 2=Warning, 3=Distress, 4=Severe [NEED C2MS issue]
    And SAMPLE..QUALITY 0=Good, 1=Questionable
    Table 8-136: XTCE-STATUS enum Astro defines colors for: 2=Invalid, 9=Complete, 10=Failed
    Table 8-141: CMD-ECHO-RESULT: NOTC=Not compared, GOOD=Good compare, MISC=Miscompare, TOUT=Timed out waiting for echo, UEX=Unexpected echo received
    Table 8-160: PRIORITY enum 1=Nominal, 2=Medium, 3=High
    Change to 1=Low [NEED C2MS issue]
    Table 8-171: DATA-QUALITY: RAW, VALIDATED, DEGRADED

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Expand TLM Changes into Related Messages

  • Key: C2MS11-211
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS11-163 we adjusted the base set of TLM messages to better handle CCSDS information and to include APID/SCID where appropriate.

    There are some related messages that needed to have been adjusted as well. This issue takes up where the already-approved 163 left off. Specifically, we need changes to:

    • Replay Telemetry Data Request Message
    • Command Request Message
    • Command Echo Message

    These changes align these adjacent messages to the to TLM message set and include SCID where appropriate.

  • Reported: C2MS 1.0 — Thu, 1 Feb 2024 14:16 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Make Changes to Adjacent TLM Messages in 1.1

    Make the changes specified in the "Revised Text" section of this issue.

    Note that in all "Additional Information" tables, the order should be SCID, VCID, APID where those fields exist. Therefore additional changes to these tables should be made according to these examples. This does not affect Message Subject tables.

    Note the updated types for SCID, VCID, and APID.

    Additionally, these should be called "CCSDS Virtual..." "CCSDS Application..." and "CCSDS Spacecraft..." throughout.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Resolve REQUEST-ID in Message Subjects

  • Key: C2MS11-214
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some Message Subjects:

    • Mnemonic Value Data Message
    • Archive Mnemonic Value Data Message
    • Command Echo Message
    • Product Message

    have Request ID as one of the Message Subject Miscellaneous Elements. However, the type of REQUEST-ID is now GUID.

    We need to figure out how to resolve this in the document text and tables. An RFC 4122 GUID does comply with Subject Token String, but we should address this.

  • Reported: C2MS 1.0 — Thu, 1 Feb 2024 15:31 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Document GUID as a Subject Element

    Make the referenced changes to the document. These changes are in addition to and adapted from the already-approved C2MS11-16 and C2MS11-49, so those changes should be addressed first, and then the changes listed here.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Rework some text for Archive Message Retrieval Request

  • Key: C2MS11-234
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    After discussion in the C2MS 1.1 RTF March, 2024, we decided to soften some of the language that was previously inserted as part of the C2MS11-43 resolution, since the shorthand method, though deprecated, is still allowed.

  • Reported: C2MS 1.0 — Wed, 10 Apr 2024 00:00 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    This issue shows changes to the already-approved text from the resolution for C2MS11-43, with the intent being to allow for use of the now-deprecated REQ-STRING if desired.

    The text here uses the C2MS11-43 text as a basis, with additions and subtractions shown to it as normal.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Inconsistent figure and table names for Replay TLM Messages

  • Key: C2MS11-219
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Replay Telemetry Data Request Message and Replay Telemetry Data Response Message sections use inconsistent naming for section headers tables and figures compared to all other sections of the document. For example:

    "Replay Telemetry Data Request Diagram"
    "Replay Telemetry Response Message Header"

    These should be made to use the full name of the message, just like other sections in the document.

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 21:07 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Align Label Text in 1.1

    This issue lists the items that need to be modified with the appropriate changes.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Miscellaneous 1.1 Text Cleanup

  • Key: C2MS11-238
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    As the final version of 1.1 is being prepared, there are some items that need revisiting from already-approved issues.

  • Reported: C2MS 1.0 — Thu, 11 Apr 2024 13:36 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Adjustment to text as shown. Items discovered while working C2MS11-187.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consolidate all "Additional Information" Table and Model Figure changes into one Issue

  • Key: C2MS11-187
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Because many separate changes have been made in the [MESSAGE-TYPE] Message Additional Information Tables and in the [MESSAGE-TYPE] Message Contents (model) Figures, this issue seeks to consolidate all such changes together for final review. Changes here should be considered, therefore, to supersede all other C2MS 1.1 changes to the specific tables and figures enclosed in this issue.

    All such tables/figures are in Chapter 8 PIM - Message Definitions.

  • Reported: C2MS 1.0 — Fri, 18 Aug 2023 23:30 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Consolidate already-approved C2MS 1.1 Changes

    Make all tables and figures in the document match what is in this issue. Note that if a table/figure is not shown here, it still may be modified in other already-approved issue(s). In other words, this proposal only governs the tables and figures listed here.

    The changes here include and are limited to:

    • [MESSAGE-TYPE] Message Additional Information Tables
    • [MESSAGE-TYPE] Message Contents (model) Figures
    • Occasional text associated with the above as indicated in this resolution

    As part of this issue, we are also revising the types for CCSDS Telemetry message fields, SCID, VCID and APID. After lengthy discussion in the SDTF and C2MS 1.1 RTF, it was decided that these should be U32 for SCID and U16 for VCID and APID. This does not affect Replay Telemetry Data Request Message which uses String types for these fields, because it supports specifying a comma-delimited list or a range as a String. This change is also not made to the now-deprecated Telemetry CCSDS Frame Message.

    Note, too, that as part of this resolution, we discovered and discussed in the SDTF and C2MS 1.1 RTF the need to rename one field type that is in conflict. Many messages have a PROD-SUBTYPE, a NUM-OF-PROD-SUBTYPES and a series of items called PROD-SUBTYPE.n. The series and its corresponding NUM-OF relate to a subcategory of PROD-SUBTYPES, so the name is in conflict and not possible to describe in UML. For this reason, the field names in question will now be NUM-OF-PROD-SUBTYPE-SUBCATEGORIES and PROD-SUBTYPE-SUBCATEGORY.n. This is manifest in Table 8-20 Archive Message Retrieval Request, 8-26 Archive Message Retrieval Response, 8-114 Archive Mnemonic Value Request Message, 8-119 Archive Mnemonic Value Response Message, 8-146 Product Request Message, 8-150 Product Response Message, and 8-156 Product Message.

    As part of this resolution, use HEADER-VERSION "2024" and CONTENT-VERSION "2024" for any messages whose content has changed and preserve CONTENT-VERSION "2019" for all others. In the model figures add ".0" to keep with convention from C2MS 1.0. Eg: "2024.0" and "2019.0".

    NOTES FOR REVIEWERS AND DOC EDITOR:

    Throughout the table changes in this document, generally deleted text is lined-out, inserted text is underlined, tables within cells of a table are handled inline, but have a different look in the jira wiki markup than will exist in the final table, for example:

    Field Name Type Presence Value   NotesDescription
    HEADER-VERSION Subject Token String R 20192024   Version Number for this message description
    MESSAGE-TYPE Subject Token String R Value Description Message type identifier: REQ, RESP, or MSG
          REQ Request  
          RESP Response  
          MSG Message  

    In the above table section, columns that have no header name should not be represented as columns in the final table. Tables-within-tables create rows with no row name, and sometimes columns with no values. So the above should appear in the final document as shown in attachment "C2MS-187 Tables-in-Tables"

    In some cases, if there is no change to a cell, especially for a table within a table, we may use the designator [NO CHANGE]. Any other special cases will be made as a note to the reviewer and document editor, as [NOTE: ***]. Tables should use the same basic format as present in the 1.0 Spec.

    Just the way the wiki markup works in JIRA, it's not easy to control column widths, so often text will be wrapped within a cell. The review/editor should take note to use the format of the existing document tables and make logical word breaks. For example, sometimes in the changes text the word SPECIFICATION might be split after SPECIFICAT with ION on the next line... clearly the document editor should make this look right in the final document.

    For the modified figures, in the "C2MS-187xxx original" attachments, I have included the figure caption in the original document in the image for the purpose of locating it when reviewing/editing the document. However, the caption is, of course, not part of the figure, so it's not being included in the "C2MS-187 xxx" revised attachment should not be interpreted as removal when editing the figure in the document. Some figures may be new, so there will be a "C2MS-187 xxx new" attachment, and I'll make note of where that belongs below.

    And just as a cautionary note for the review and document editor, other approved issues may reference one of these tables or figures, which are superseded here, but may also have other document changes, and there are other approved issues still that have their own changes not related to these figures and tables, so take care not to assume that other issues are superseded in their entirety by this issue.

    The original, revised, and new diagrams related to this issue are attached as zip files rather than individual attachments due to their large number.

    Finally, please see the attached Review Guide to help with contextual information related the consolidating effort of this issue resolution.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Rework Individual Message Header Tables

  • Key: C2MS11-193
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Each message includes a "[message name] Header table that repeats header field definitions as already listed in Table 8-3 Message Header Additional Information. Instead, this individual message table is intended to show what special values are applied to certain fields of the header. This needs to be made more clear, without duplicating information in the already-existing Header table. In other words, these tables should provide unique-to-the-message values rather than repeating header definitions.

    A specific example of why this is not practical is that the existing set of tables all show the HEADER-VERSION 2019. Because the HEADER-VERSION is being updated in 1.1, each of these 31 tables must also be updated. In order to avoid this kind of issue in the future, these tables need to be reduced to just the necessary message-specific values.

    See for example, "Table 8-108 Mnemonic Value Data Message Header". This table does not need to include the "Notes" column, since that is simply repeating word-for-word what exists elsewhere, and should not include the HEADER-VERSION row, since that is defined elsewhere, including its value.

    To make this better, change the column name of column one to "Header Field Name". Additionally, should change the table title to "Table 8-108 Mnemonic Value Data Message Header Values".

  • Reported: C2MS 1.0 — Tue, 9 Jan 2024 21:07 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Clear up header values tables

    Throughout the document, in all "[message type] Header tables:

    • change the name of the table
    • change the title of column one
    • remove the "Notes" column
    • remove the HEADER-VERSION row
    • remove the "More..." text and row at the end of the table (this text repeated 38 times in the document is not necessary)

    This resolution updates the two new tables added in C2MS11-163, and for these two tables, the form here should be considered to replace those same tables in that issue.

    Additionally, this resolution updates the two new tables added in C2MS11-45, and for these two tables, the form here should be considered to replace those same tables in that issue. Text of the table section is also updated for these two.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consolidate APID and AP ID to just APID

  • Key: C2MS11-217
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Throughout the document, we use APID and AP ID interchangeably. For consistency, we should reduce all these references to just APID.

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 15:57 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    In the 12 instances where AP ID is used in the document, change to APID. Sometimes add "CCSDS" for clarity.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects

  • Key: C2MS11-35
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects for all messages where that field is used. Also, see 2016 GMSEC ISD for discussion of destination component and add that back in to the description of Configuration Status Message. See pages 74 and 78.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:41 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Fix phrase "Component Name..." in ME1 and ME2 columns to COMPONENT and DESTINATION-COMPONENT

    Update tables and text with the terms COMPONENT for the sender, and DESTINATION-COMPONENT for the receiver or recipient.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consider forcing a limited subscription

  • Key: C2MS11-83
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the case of Mnemonic Value Request Message and Archive Mnemonic Value Request Message, the requestor can specify a STOP-TIME or DURATION, but both are optional. If neither is specified, the subscription is open-ended with no knowable end, until the requestor sends a 'STOP' message. In order to avoid infinite fulfillment of a subscription to a potentially lost requestor, we could enforce a concept that a requestor must specify either a STOP-TIME or Duration.

    In practice, this is an inadequate requirement, since a caller could specify a very long duration, like 1000 years, and circumvent the desire of this issue.

    However, this is issue simply captures the idea to promote further discussion.

  • Reported: C2MS 1.0 — Tue, 22 Mar 2022 21:15 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Add responder's fields for service DURATION and STOP-TIME support

    The responder to the request shall determine the time it can support based on the original request. For example, unlimited or very large durations or stop times past the end of the archive and so on may not be supported, in which case the responder may clip the response to the duration or stop-time it can support and this will be placed in the response. It's up to the requester to monitor this field and do something useful with it. It's an implementation detail as how the responder implements this other than providing the value in the response.

    Changes to text and to diagrams as shown herein.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Normalize the "Additional Information" Tables Showing Fields for Messages

  • Key: C2MS11-178
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Changes need to be made to the "Additional Information" tables that contain Field listing for each message. The necessary changes are to provide complete information and to unify the names of the column headers across all messages.

    Should add a type column to the fields table "Additional Info". Currently, the only indicator of type is in the UML diagram. Because of this, it is often the case that a reader of the table, must glance at the UML diagram in addition to reading the table.

    Additionally, the tables are not uniform within the 1.0 document. Some use "Value" for a certain column header, while others use "Value/Description". To resolve this, it would be useful to use "Value" in every table and to rename the current "Notes" column to "Description" which is more accurate.

  • Reported: C2MS 1.0 — Fri, 21 Jul 2023 16:23 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Add Type to Fields and Fix Column Names in the ("Additional Info") Tables

    The change here shows one exemplar, but this same change will be made to all "Additional Information" tables for all messages in a final roll-up issue that will show all the consolidated table changes.

    Add a column to the table showing type as already defined in the corresponding UML diagrams.

    Note that this description of the change also shows the already-approved change to C2MS11-14, which added the "Presence" column. Both are shown here to illustrate their relative positions in the table.

    Additionally, use "Value" for all tables (some have "Value" currently, others have "Value/Description" and replace "Notes" with "Description".

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Clarify Text Associated with Simple Service Req/Resp

  • Key: C2MS11-169
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    After discussion in C2MS RTF in Orlando 2023 Tech Meetings, we determined to clarify or clean up some text with Simple Service Request and Response messages as follows:

    • Say it’s not intended to be long-term but for quick on-boarding. Services meant for long-term use should create their own message set apart from Simple Service
    • Say that we intend to rework or replace Simple Service at some point in a future release.
    • Consider removing text about using it for a publish mode

    Note that the response message as it is lacks the Service-Group that was specified in the request message. This lack makes it impossible to correctly correlate a response to a request that did specify Service-Group. However, because we intend to 'rework' these messages in a future release, we won't make this change at present.

    A related issue will be created to replace simple service and deprecate current simple service, but will be deferred to later.

  • Reported: C2MS 1.0 — Tue, 11 Jul 2023 14:37 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Update Text Associated with Simple Service Request and Response

    Indicate that the Simple Service is meant as a temporary.

    Indicate that C2MS intends to rework this service, deprecating the current set of messages and creating new messages.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Align TLM Messages against Subject Elements and Fields

  • Key: C2MS11-163
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Issue C2MS11-54, already approved, has removed two subject elements that didn't belong in Telemetry TDM Frame Message. In fact, there are many more similar irregularities across all the Telemetry messages.

    The needed changes are described below, but also shown in the attachment (original and revised) that shows the fields and subject elements as they exist today and should be after corrected.

    • Add a new message type: Telemetry CCSDS CADU Message
    • Rename Telemetry CCSDS Frame Message to Telemetry CCSDS Transfer Frame Message
    • APID should be both a subject element and field in Telemetry CCSDS Packet, and in no other TLM messages.
    • VCID should be both a subject element and field in Telemetry CCSDS Packet and Telemetry CCSDS Transfer Frame, and in no other TLM messages
    • PHY-CHAN should be a field in the new Telemetry CCSDS CADU Message, with no subject element for it (Note that this message won't have APID, VCID or SCID represented.
    • Add SCID as a subject element and field in Telemetry CCSDS Packet and Telemetry CCSDS Transfer Frame messages
  • Reported: C2MS 1.0 — Fri, 14 Apr 2023 15:10 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Update TLM messages with current needs

    Align messages per the issue description.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Create an optional Message Envelope to hold Tracking Fields

  • Key: C2MS11-130
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. This "Message Envelope" is the logical place for managing tracking fields and other metadata related to, but not part of a C2MS message body.

    This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning related to C2 of a satellite.

    Note that this concept was originally moved to C2MQ. However, because C2MQ is a long way away and because message envelope is a useful construct within C2MS, it was determined at the Austin (Dec, 2023) C2MS meeting to bring this back in to C2MS and take the envelope concept out of C2MQ (leaving it to cover service-based interactions outside of the messages). Therefore, this is a re-entry of the envelope mechanism.

    As part of this effort, we should do the following:

    Add fields that allow encryption of content sections of the C2MS message body as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.

    The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.

  • Reported: C2MS 1.0 — Tue, 7 Feb 2023 23:08 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Add Optional Message Envelope in 1.1

    Add a new section at the same level as C2MS Message Header and before it. C2MS Message Header is currently section 8.1. The new section should move into this place as section 8.1, with C2MS Message Header moving to 8.2, with all subsequent messages moving down by one as well. This new section details a C2MS Message Envelope that has many of the fields currently in Message Header.

    Many fields will exist both in Message Envelope and in Message Header. A separate issue (C2MS11-182) covers deprecating these fields and this issue is expected to be deferred to 1.2.

    Some fields will be new to the Envelope and will not also exist in the Header.

    The Envelope will be "optional" in the sense that it is not required to be used (for now), but a note will indicate that at a future time, this will become the required mechanism for message handling.

    Additionally, it is helpful in the flow of Section 8 "PIM- Message Definitions" to modify some of the front matter that is less consistent now that there is an Envelope as follows:

    Remove the Figure 8-1. High Level UML Class Diagram and the paragraph immediately preceding it. All this material is low-value and would have to be changed greatly to conform to the this issue as well as to C2MS11-18, which is already approved.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Remove XSDs as Normative Documents

  • Key: C2MS11-191
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some XSDs were provided by NASA when v1.0 was created. However, these are only useful in a PSM for XML and should not be considered normative for the PIM. We don't have any intention to maintain/update these, so they should be removed. If NASA wants to create and deliver these to users, that is fine, but the OMG should not be the broker for these files.

    See the listing of "Normative Documents" here: https://www.omg.org/spec/C2MS/1.0

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 20:21 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Remove XSD Listing from Doc and Do Not Publish on OMG Page

    The XSD Listing on the OMG C2MS 1.0 Specification webpage will remain, but these are not to be included in the OMG C2MS 1.1 Specification page when created. The model .xmi file will be the only file listed under "NORMATIVE MACHINE READABLE DOCUMENTS".

    Additionally, remove references to XSDs from the title page of the specification document.

    A new .xmi file will be provided to the OMG, and, of course, the link to the .xmi will be updated to point to the new specification page, but that is left to the Document Editor, since there is nothing to link to as of the creation of this proposal.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

SERV message, add field SERVICE-GROUP

  • Key: C2MS11-111
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add field SERVICE-GROUP (String, Optional) to the message. ME2 should refer to this field for its value.

  • Reported: C2MS 1.0 — Thu, 22 Sep 2022 00:11 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Add SERVICE-GROUP to field

    Add SERVICE-GROUP to the Simple Service Request Message fields. Also fix some text to match the new text of the table.

    Add SERVICE-NAME to the Simple Service Response Message fields.

    Additionally, the type for SERVICE-NAME is listed as String. This is valid if the field is not also used in the Message Subject.
    To guide the user in this concept, text is being updated in the fields table for both Request and Response.

    Modify the associated diagrams as shown in attachments.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

PROD message, add fields PROD_SUBTYPE

  • Key: C2MS11-110
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    There are n+2 number of optional elements between ME4 and ME7. These fields map the field(s) PROD-SUBTYPE.n.NAME.
    API Workaround: API only maps the first two of these product subtypes, and the user will have set subject if they want more.
    Required C2MS Spec changes: Ditch the n+2 logic in the middle of a message subject and only display the first two PROD-SUBTYPE values in the subject (or FILL if not used). A subject that can have dynamically shifting positions of its subject elements has serious implications on compatibility.

  • Reported: C2MS 1.0 — Thu, 22 Sep 2022 00:10 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    *PROD and SUBTYPE should be enough but if not... *

    We lack use cases that show and problem here. This is just a possible problem for what seems like the unlikely case of product with a subtype that isn't enough to differentiate it from another one, and that then the 2 additional ME fields wouldn't be sufficient.

    Overall with 4 pre-canned ME required and optional fields for a subject, it's difficult to see that this is not enough to differentiate some imaginary product in a topic/subject.

    In fact due the complexity of such a product I kind of think it's better to just let such a need if it ever exists to just find some other localized way to handle it.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Header UNIQUE-ID is Type "Header String"

  • Key: C2MS11-143
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    UNIQUE-ID in the Header is of type Header String (to be Subject Token String due to C2MS11-49). According to table 8-3: "Globally unique ID – reserved for use by implementation (PSM)". Note that a "Header String" is limited to upper and lower alphanumeric plus '-' and '_'. Recommendation of C2MS is that best practice is to keep Header String to no more than 12 characters.

    So, Header String or Subject Token String isn't the right type.

    I think we need to know what GMSEC uses for a type of UNIQUE-ID. But, it possible, it would be good if it was a GUID, relating to C2MS11-16.

  • Reported: C2MS 1.0 — Sat, 18 Mar 2023 22:08 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Change Type of UNIQUE-ID from "Header String" to GUID

    This change assumes that CSMS11-60 which creates a new C2MS type called "GUID" is accepted.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Make all subjects be buildable from fields in the message

  • Key: C2MS11-25
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Almost all miscellaneous subject elements for messages are specified as mapping to fields in the message. But a few are not. For example, see the Miscellaneous Elements table 8-46 for the Control message. The elements DESTINATION_NODE and DESTINATION_FACILITY do not exist as fields in the message. (Note: it may be more appropriate to add some of these fields to the Message Header rather than many/most messages.) In this particular example, this may be resolved by C2MS11-28, but each message type would need to be evaluated to see what other subject elements are not mapped to fields.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:59 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Address node and facility terms to DESTINATION-NODE and DESTINATION-FACILITY

    The following fields are added to 8.1 C2MS Message Header, optional fields:

    DESTINATION-NODE=Header String
    DESTINATION-FACILITY=Header String

    These fields are also now associated ME3 and ME4 in all other tables within the document
    where they are used or not otherwise specified.

    ==================================================================

    8.5.1.1 Configuration Status Message Subjects
    Table 8-40. Configuration Status Message
    Column ME3 [Node] --> ME3 [COMPONENT-NODE]
    Column ME4 [Facility] --> ME3 [COMPONENT-FACILITY]

    ==================================================================

    Table 8-41. Properties of the Miscellaneous Elements for the Configuration Status Message

    ME3 = destination node ---> DESTINATION-NODE
    ME4 = destination facility --> DESTINATION-FACILITY

    (soon after that table)

    Examples
    Publishing / Sending Configuration Status messages:
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1 or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.COMPONENT or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.COMPONENT.NODE.FACILITY

    ****TO*****

    Examples
    Publishing / Sending Configuration Status messages:
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1 or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.DESTINATION-COMPONENT or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CFG.APP1.DESTINATION-COMPONENT.DESTINATION-NODE.DESTINATION-FACILITY

    ==================================================================
    8.5.2.1 Control Message Subjects
    Table 8.45. Control Message Subject Naming

    Column ME3 [Node] --> ME3 [COMPONENT-NODE]
    Column ME4 [Facility] --> ME3 [COMPONENT-FACILITY]

    Table 8-46. Properties of the Miscellaneous Elements for the Control Message

    ME3 = destination node ---> DESTINATION-NODE
    ME4 = destination facility --> DESTINATION-FACILITY

    (Then...)

    Examples
    Publishing / Sending Control messages:
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1 or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.COMPONENT or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.COMPONENT.NODE.FACILITY or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.COMPONENT.NODE.FACILITY.KEY
    WORD

    ********TO*********

    Examples
    Publishing / Sending Control messages:
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1 or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.DESTINATION-COMPONENT or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.DESTINATION-COMPONENT.DESTINATION-NODE.DESTINATION-FACILITY or
    C2MS.DOM1.DOM2.MSSN.CNS1.SAT1.MSG.CNTL.APP1.DESTINATION-COMPONENT.DESTINATION-NODE.DESTINATION-FACILITY.KEY
    WORD

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Update Text Associated with REQUEST-ID as Replacement Issue

  • Key: C2MS11-139
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    We have previously approved C2MS11-55 that changes the concept of REQUEST-ID as Replacement. After reviewing this change with the EGS Team, it is apparent that we could tighten up some of the text in the proposed change to make it more clear what are valid second-uses of REQUEST-ID and what are invalid, along with the expected response to an invalid use.

    It should be invalid in Replay Telemetry or MVAL Request to issue a start after a start has already been done using the same REQUEST-ID. In Replay Telemetry, we probably need to think about it. If an invalid re-use of REQUEST-ID is sent in a request message, an indicator should be returned in a response for Invalid Request.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 20:03 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    In this resolution, we show the already-accepted text associated with C2MS-55 which is not yet in the C2MS Document as the starting point, with text changes as indicated. In this way, this resolution fixes text that is not yet in the document.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

VCID and APID in Message Subject for TLMTDM Frame

  • Key: C2MS11-54
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Subject for TLMTDM Frame Messages includes the following:
    -ME3 = VCID
    -ME4 = APID

    However these fields:
    a) don't exist in the TLMTDM Frame Message, so can't be populated to the message subject,
    b) belong only to CCSDS frames, not TDM frames.

    These Message Subject Miscellaneous Elements should be removed and replaced with "FILL" to preserve ME5 as Collection Point.

  • Reported: C2MS 1.0 — Thu, 3 Mar 2022 22:57 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do it in 1.1

    Change table contents and examples.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

REQUEST-ID field does not support usage as a GUID

  • Key: C2MS11-16
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    From Justin: The REQUEST-ID field was defined as a U16. Recommend this field be changed to be a string to allow it to be utilized as a GUID. This allows it to work better for transport of existing interfaces that utilize a GUID to ensure message uniqueness, especially when multiple instances of the application are running concurrently.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:11 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Add GUID type

    After discussion, it has been proposed that we do this one in 1.1.

    Showing the change to one figure (Figure 8-7. Directive Response Diagram), which illustrates replacing the REQUEST-ID type from U16 to GUID. The others mentioned will all be changed in the same fashion. Rather than making all the changes here, we are voting on this style. There will be a subsequent issue to capture ALL the Figure and Table changes accounting for all the C2MS1.1 issues already accepted.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Text for AMVAL REQ references non-existing fields

  • Key: C2MS11-101
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    For the Archive Mnemonic Value Request Message, under the explanatory text, there is a paragraph stating:

    "Optionally, if known or applicable, the requestor can specify the file type and file attributes with the optional dependent fields under the Output Product Category and Output File Attributes sections."

    I'm not sure what this is referring to. There are no Product Category or Output File Attributes dependent fields in the Message. The terms "Output Product Category" and "Output File Attributes" occur in the document only in this paragraph.

    The text either needs to be clarified or removed.

  • Reported: C2MS 1.0 — Wed, 29 Jun 2022 13:05 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Remove nonsensical text

    The text states "THIRD, for all the options above, the requestor must do the following:
    • Identify the number and names of the mnemonics along with their extraction criteria.
    • Optionally, if known or applicable, the requestor can specify the file type and file attributes with
    the optional dependent fields under the Output Product Category and Output File Attributes
    sections.
    "
    and should be

    THIRD, for all the options above, the requestor must do the following:
    • Identify the number and names of the mnemonics along with their extraction criteria.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Time Type table clarification for the DDD portion

  • Key: C2MS11-27
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Document clarification: The DDD portion of the Time Type, as shown in table 8-2 on page 40, has a range of 1-365 (or 366). But when using a relative time (by preceding the value with a "+" or a "-"), the DDD portion can contain a zero value. Make this clear and add a couple more relative time examples.

    Consider replacing C2MS invented date format with RFC3339 or ISO8601 to include relative time.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:17 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Improve Description of DDD field for Time Field Type

    Change text in Definition and Range columns of specified table.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Remove APID from TLMFRAME

  • Key: C2MS11-114
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The APID is associated with a telemetry packet, not the frame.

  • Reported: C2MS 1.0 — Fri, 18 Nov 2022 18:16 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Duplicated of C2MS11-163

    A number of these have been identified, but after discussion with the RTF and larger SDTF, we have decided to align across all these telemetry messages. C2MS11-63 has been created for that purpose, so marking this as a duplicate of that issue.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Remove APID from TLMPROC

  • Key: C2MS11-115
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The APID is associated with packets, not the telemetry frame.

  • Reported: C2MS 1.0 — Fri, 18 Nov 2022 18:17 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Duplicate of C2MS11-163

    A number of these have been identified, but after discussion with the RTF and larger SDTF, we have decided to align across all these telemetry messages. C2MS11-63 has been created for that purpose, so marking this as a duplicate of that issue.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Improve text related to ONESHOT in Mval Request Message

  • Key: C2MS11-141
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.

    This is described in Mnemonic Value Request Message as:
    “The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously.”

    and

    Mnemonic Value Response Message:
    "For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."

    However, in a significant way, these statements conflict with the next line:
    "For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."

    In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).

    As written, the text has to be read carefully to understand the "yes and maybe" logic. I suggest adding some supporting text to clarify this.

  • Reported: C2MS 1.0 — Thu, 16 Mar 2023 00:16 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Improve text to make clear that the 'Start' and 'Oneshot' both result in a set of data being returned in the response, with the 'Start' request also being followed by a seiries of Mval data messages..

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Clarify Correlation PUBLISH-RATE and SAMPLE-RATE on Mnemonic Value Request Message

  • Key: C2MS11-56
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In Mnemonic Value Request Message, there is a PUBLISH-RATE and there is a SAMPLE-RATE that can be specified for each MVAL. The correlation between these is somewhat open to interpretation. For example, the text of the SAMPLE-CRITERIA, associated with SAMPLE-RATE, says it drives "when data should be provided" which overlaps with the PUBLISH-RATE. If taking SAMPLE-RATE to be independent of PUBLISH-RATE, it means something else entirely.

    The supporting text of the Mnemonic Value Request Message needs to make clear how these interact.

    Note that we previously determined to remove SAMPLE-RATE due to perceived overlap, but have since decided to leave it in place and make clear its usage.

  • Reported: C2MS 1.0 — Fri, 4 Mar 2022 00:40 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do it in 1.1 second attempt

    Note that there was a previously accepted proposal to remove remove the SAMPLE-RATE field and corresponding text. Upon further review, we should have kept the field and clarified the text. The text could be interpreted in two ways. One way would still be valid, if we make the text more clear.

    Note, two, that with the prior approved change, now undone, we modified a diagram. That modification is no longer valid. So, I've included the original model diagram, here, to show that it is unchanged from the original.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

NUM-OF-[ITEMS] Should be Required

  • Key: C2MS11-135
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    As part of C2MS11-14, which was already approved, there was a subtle inconsistency through its text and image changes. This issue is to capture the change for final submission of the documentation for C2MS 1.1.

    In that issue, in the Configuration Status Message there is a field, NUM-OF-ASSOCS. It is marked optional in the diagram, but required in the text table.

    In the Heartbeat Message, NUM-OF-SUBSCRIPTIONS is shown as optional, both in the diagram and in the text table.

    In the Mnemonic Value Request Message, NUM-OF-MNEMONICS is shown as required, both in the diagram and in the text table.

    In all cases throughout C2MS where there is a NUM-OF-[ITEMS] field, it should be required in the corresponding diagram and text table.

    This is to align it with the obvious. The NUM-OF field indicates how many items are present in a set, such as MNEMONICS. If there are none, this field should simply be set to 0. However, if it were optional, that would mean that the field would either be present or set to 0. The former is preferred for clarity.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 12:05 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Redo the diagrams and one table from C2MS11.14 resolution, since these had used 'optional' NUM-OF-... fields. These should have been required. As with C2MS11-14, this type of change will be replicated in all messages throughout the document that have NUM-OF-* fields, once approved, and a new final issue will be created to capture all the changes. In the case of these diagrams, the originals from before C2MS11-14 are shown, with revised diagrams.

    Additionally, one table showed optional, should have been required... the update is shown in the revised text. In the case of the table update, it assumes all the changes already, and simply updates the one field from C2MS11-14.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Revisit SAMPLE-RATE

  • Key: C2MS11-137
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    C2MS11-56, already approved, removed MNEMONIC.n.SAMPLE-RATE. In conveying this to the EGS Team, including MAV (NASA) and Ryan Conrad (MITRE) there was concern that we were losing fidelity with the data by only using PUBLISH-RATE to create messages but not having multiple samples at a rate of SAMPLE-RATE.

    When we were considering this one, we approached it from the perspective that SAMPLE-RATE and PUBLISH-RATE created a dual-mechanism for when to send the MVAL message. While this is still and issue, there may be a way to allow both desired results in a combined way.

    One concern of both the C2MS Team and the EGS Team is in getting too many messages published. This is a clear concern with the SAMPLE-RATE, because of the CRITERIA's indication of "when data should be provided for the mnemonic", including on "Change". In fact, it's likely that CRITERIA is the suspect field basically determining how often to "provide" the data rather than SAMPLE-RATE.

    Perhaps we could do the following:

    • state in C2MS that the messages will only be produced at the PUBLISH-RATE, but that if SAMPLE-RATE is tighter, then there will be multiple samples in the message.
    • Instead of removing SAMPLE-RATE, we remove CRITERIA, so that the SAMPLE rate simply determines how often to sample

    Whatever we do, we need to revisit SAMPLE-RATE before finalizing 1.1.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 17:39 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Duplicate of C2MS11-56

    We originally made a change to C2MS11-56, and this issue was to revisit that change. After review, we reopened 56 and make the complete change there. That makes is issue a dup of 56.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

MNEMONIC CRITERIA Needs alignment with C2MS11-56

  • Key: C2MS11-136
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There is an already-accepted issue, C2MS11-56, that removed MNEMONIC.n.SAMPLE-RATE, but that issue did not address the related field, MNEMONIC.n.CRITERIA.

    In that other issue, the MNEMONIC.n.SAMPLE-RATE was removed because it overlapped with the PUBLISH-RATE of the base message.

    Since SAMPLE-RATE has been removed, one of the following additional steps needs to be taken:

    Option A - remove the value "3 = Sample Rate" from MNEMONIC.n.CRITERIA

    Option B - Remove MNEMONIC.n.CRITERIA completely for the same reasons SAMPLE-RATE was removed

    Option B - Move MNEMONIC.n.CRITERIA to a field in the base message now to be called "PUBLISH-CRITEREA" with the following possible values:
    1 = Change (value, flags, status) [publish when any MVAL experiences a change]
    2 = Every Sample [publish when any new sample arrives for any MVAL]
    3 = Publish Rate [publish at the rate specified in PUBLISH-RATE, already in the base message]

    The bottom line is that just as in C2MS11-56, it doesn't make sense to have different publish/sample rates for the main message and each MVAL, so any of the above options are preferred over what it is in 1.0. (Mike: Personally, I like Option C).

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 15:21 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Duplicate of C2MS11-56

    We originally made a change to C2MS11-56, and this issue was to revisit that change. After review, we reopened 56 and make the complete change there. That makes is issue a dup of 56.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Add field APID (and VCID) to Telemetry CCSDS Packet Message

  • Key: C2MS11-39
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    This value is used in the subject, so should be added to the message.
    (NOTE: do NOT add this field to the CCSDS Frame message; TBD for Processed Telemetry Message and TDM Frame message. Also, check the VC ID usage appropriateness in all 4 TLM messages.)

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:58 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Duplicates C2MS11-163

    A number of these have been identified, but after discussion with the RTF and larger SDTF, we have decided to align across all these telemetry messages. C2MS11-63 has been created for that purpose, so marking this as a duplicate of that issue.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Add DESTINATION-NODE and DESTINATION-FACILITY as fields

  • Key: C2MS11-36
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    One goal for consistency (and ease of implementation and use of said implementation) is to have all subject elements also be fields in the message. Adding DESTINATION-COMPONENT late in the adoption process of C2MS was a step in this direction, but DESTINATION-NODE and DESTINATION-FACILITY are needed also. See page 82 for example for CFG messages.

    (Note: this applies to all 5 C2CX messages - CFG, CNTL, DEV, HB, and RES)

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:45 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Move to C2MQ

    This is part of C2MQ

  • Updated: Mon, 16 Sep 2024 14:18 GMT

TLM CCSDS FRAME, TLM Processed Frame messages need AP-ID fields

  • Key: C2MS11-108
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value.

  • Reported: C2MS 1.0 — Thu, 22 Sep 2022 00:02 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    APID should NOT be present directly in the frame

    Application identifiers are present in the CCSDS packet headers on a per packet basis. Frames have not been processed out to packets yet. Therefore, having a APID ("app-id") field in a frame message is not appropriate.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Real-world STREAM-MODE Issues

  • Key: C2MS11-90
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    A number of C2MS Messages include the concept of marking the mode of the data as “real-time (RT), replay (RPY), simulation (SIM), or test (TEST)” through a required field, STREAM-MODE.

    The specific messages are:

    • Telemetry CCSDS Packet Message
    • Telemetry CCSDS Frame Message
    • Telemetry TDM Frame Message
    • Telemetry Processed Frame Message
    • Replay Telemetry Data Request Message
    • Attitude Parameter Message
    • Attitude Ephemeris Message
    • Orbit Parameter Message
    • Orbit Mean-Elements Message
    • Orbit Ephemeris Message
    • Tracking Data Message

    Where used, STREAM-MODE is a required field. A typical explanation in the C2MS Spec is that, “The STREAM-MODE field is used to classify the kind or source of the” message.
    Although this may be useful in a closed experimental/engineering system, the concepts are not appropriate for an operational SATOPS system, where replay, test, sim data should never be mixed with real-world operational data. In a system with many components, the use of the STREAM-MODE field assumes that every component will properly handle the distinction for every message. As an example, a FireThrusters CMD message is received and the component fails to note that this particular message is a RPY STREAM-MODE and thinks to itself… ‘huh, I thought we fired thrusters, yesterday… but, OK, here it goes…”. In another example, a SelfDestruct CMD message is received and the component fails to note that the message is marked as TEST or SIM…

    Instead of marking messages themselves, this type of distinction should be performed environmentally; one system is the operational system, other, separate systems are for simulation or test, another separate system performs forensics (replay). Keeping these purposed environments isolated from each other ensures that data never intermixes where not appropriate.
    The resolution to this concern could be any of the following:

    1. Remove the STREAM-MODE field — breaks backward compatibility, and affects any system already using this field. However, it represents a clean break from a field that should never be used in practice, anyway.
    2. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and mark the field as deprecated (deprecated = should no longer be used and will be removed in a future major release) — maintains backward compatibility, but signals to users to cease using the field.
    3. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and provide a best-practices statement; something to the effect of, “Although maintained for backward compatibility, the use of this field is strongly discouraged for operational systems, where test, sim, or replay data should never mix with real-world operational data” — this weakest approach leaves the use of the field in the hands of the user, but would be a bit embarrassing from the standpoint of a specification to preserve a capability that is strongly discouraged.

    See attachment for non-exhaustive use in C2MS Spec.

  • Reported: C2MS 1.0 — Fri, 10 Jun 2022 13:45 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    *Update Text to Indicate that this Should not be Used at Enterprise-level *

    Create a section to describe this capability as appropriate for small-scale or experimental SATOPS, but inappropriate for formal enterprise-level operations.

    Put a note in each field of the effected messages to indicate this as well.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Deprecate Archive Message Retrieval Messages

  • Key: C2MS11-43
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Archive Message Retrieval Request Message and related Archive Message Retrieval Response Message should be considered for deprecation.

    These are useful messages in an engineering environment when all messages and their corresponding storage method allows unfettered access to all consumers regardless of authentication/authorization, but in a real-world operational environment, this construct is much too uncontrolled.

    For example, the Archive Message Request allows, and suggests, sending a SQL statement or script expression in the REQ-STRING field, which the service provider would execute on behalf of the requestor, creating an exploitable cyber attack opportunity for malicious software.

    Even if the REQ-STRING were removed and the request only allowed for PROD-TYPE/PROD-SUBTYPE (the other way to request the archive), this would allow for all messages that ever flowed in the environment to be forwarded to a single requestor. In an unsecured system, that might make sense, but it is not appropriate in any system that closely controls who is allowed to send/receive any given message.

  • Reported: C2MS 1.0 — Fri, 10 Dec 2021 03:20 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Deprecate REQ-STRING in Archive Message Retrieval Request

    Deprecate the REQ-STRING field in Archive Message Retrieval Request. This mechanism is not secure, allowing a requestor to provide a SQL statement or Script to be executed by the service on their behalf.

    Describe the rationale for the change to the reader.

    Provide a note that the "longhand" version of the query will continue to be supported.

    Note that some fields that were previously "dependent" are now "required" because they were only required when using the "longhand" method (which is now the only methd).

    Replace the UML diagram to with the new version that moves the previously dependent fields into the required category and adds the note that the REQ-STRING field is Deprecated. Note that because of other changes going into this same version, the Required and Optional blocks are being redone as well, so the illustrated new version is to show the type of change that is to be made, but will actually be different from this when all is said and done. But this issue is only concerned with the delta that is effected by this issue.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Deprecate REQ-STRING in Product Request Message

  • Key: C2MS11-120
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Similar to C2MS11-43, this issue is to consider deprecating REQ-STRING in the Product Request Message. The desciption of the field is a bit different than in the Archive Request Message, so just needs some investigation to make sure that this message is still usable without the field.

  • Reported: C2MS 1.0 — Fri, 16 Dec 2022 23:53 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Clarify usage in 1.1 to discourage remote execution

    Remove references to database "query" or script expression where the field is listed in the table. Below the table, state that this should specifically not be a database query or script expression.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consider Making Fields in UML Public vs Private

  • Key: C2MS11-121
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    All fields in the UML Model classes are shown as Private. This would make sense if these blocks were really supposed to be classes, but in their usage in C2MS, these are handled as structures with all fields accessible.

    Since we are already going to change every UML diagram in C2MS 1.1, we should consider if it would be good to change these all to Public.

    See the attachment for a comparison between fields. Private fields are marked with '-', while private fields (like DATA shown as an example) are marked with '+'.

  • Reported: C2MS 1.0 — Fri, 16 Dec 2022 23:58 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    No change to be done

    After discussion between Kevin and Mike, we decided that no change is needed or warranted. Leaving data members private implies better data abstraction for classes with getters and setters, changing to public implies using structs without getters/setters. Which is better or more appropriate seems like a decision for the PSM, rather than the PIM. Leaving this way is less change, and nobody has asked for this. It seems unlikely to be something people will clamor for.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

TLMTDM message, add AP-ID and VCID fields

  • Key: C2MS11-109
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value. Add field VCID (String, Optional) to the message. ME4 should refer to this field for its value.

    Are required for CCSDS packets only, and optional otherwise.

  • Reported: C2MS 1.0 — Thu, 22 Sep 2022 00:06 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    CCSDS Application ID is not present in non-CCSDS telemetry packaging

    The CCSDS application id ("APID", "app id") is only present in CCSDS headers for packets. It is not appropriate in other kinds of telemetry packaging.

    This is has been removed in C2MS11-54.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

C2MS specification on page 168 is not clear regarding CMD-FORMAT=MNEMONIC

  • Key: C2MS11-41
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    It is not clear in the C2MS specification how to use/support the CMD-FORMAT=MNEMONIC on page 168. Explanation of the encoding should be provided to understand how to represent a command mnemonic and its arguments.

  • Reported: C2MS 1.0 — Tue, 6 Jul 2021 13:01 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    This duplicates the later, but more detailed, C2MS11-88

    This is a duplicate.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Align MESSAGE-CLASS with Usage

  • Key: C2MS11-112
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    C2MS 1.0 defines MESSAGE-CLASS as an optional field (in the C2MS Header, "Generic field for missions to classify their message set to aid message disposition.").

    A principal user of C2MS reclassifies MESSAGE-CLASS as a required field with a finite set of defined enum-like values.

    In order to help align this user with C2MS, the C2MS MESSAGE-CLASS field should become required. Alternatively, C2MS should define a way for a consumer of the C2MS definitions to require what is to C2MS an optional field with defined values.

  • Reported: C2MS 1.0 — Thu, 20 Oct 2022 20:00 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    No need to change in C2MS

    After RTF discussion, there is no need to make this field required in C2MS. Systems that use C2MS can enforce requiring this field through business/domain logic.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Log message scope too broad, need Alert/Status style message introduced

  • Key: C2MS11-15
  • Status: closed  
  • Source: The MITRE Corporation ( Ryan Conrad)
  • Summary:

    The LOG message is nice to cover a certain scope of messages needing to be utilize by developers using the specification, however the ProductMessage again and again finds itself utilized instead of the LOG message because of the structure the LOG message has versus the ProductMessage for making things like status or event messages.

    Because of this, I had looked at the ALMAS specification from Navy and the CAP (Common Alerting Protocol) from OMG to come up with an Alert Notification and Alert Ack message that would be greatly helpful in making a solid Header for alert and status messages that could be different in scope than typical LOG messages.

    I have these messages defined in GMSEC/COMPATC2, and would need to attach it for you to see the details. Thank you

  • Reported: C2MS 1.0b2 — Mon, 30 Sep 2019 18:57 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    The log message is fine, propose a new alert/event message instead

    Instead of modifying log beyond its original design goals, anyone may propose a new alert/event message for a future revision. Example: C2MS-1.2.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

CFG, CNTL, DEV, HB, RSRC Messages need fields DESTINATION-NODE and DESTINATION-FACILITY

  • Key: C2MS11-106
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Subject not able to be fully created from Message fields in all cases.

    Add fields DESTINATION-NODE (String, Optional) and DESTINATION-FACILITY (String, Optional) to the messages. ME3 and ME4 should refer to those two fields for their values, respectively.

  • Reported: C2MS 1.0 — Wed, 21 Sep 2022 23:53 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    This is a duplicate of C2MS11-36

    This is a duplicate of C2MS11-36.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

TLMPKT Message needs field AP-ID

  • Key: C2MS11-107
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add field AP-ID (String, Required) to the message. ME4 should refer to this field for its value. If field AP-ID is added as OPTIONAL, then ME4 should also be changed to OPTIONAL.

  • Reported: C2MS 1.0 — Wed, 21 Sep 2022 23:58 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Duplicate of C2MS11-39

    Duplicate of C2MS11-39

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Specify multiplicity for required and optional fields

  • Key: C2MS11-14
  • Status: closed  
  • Source: Parsons ( Gerry Simon)
  • Summary:

    Set the association multiplicity for required fields to '1' and optional fields to '0..1'

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:37 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Documentation Change to be Made in 1.1

    The following changes will be made:

    • Make changes to Section 8 PIM – Message Definitions under Field Name to clarify the notation used for "series".

      • Add a diagram to illustrate the text

    • Make changes to Section 8 PIM – Message Definitions under Required, Optional, Dependent and Tracking to clarify how R/O/D are used and to separate out Tracking since that does not indicate R/O/D.

      • Add a diagram to illustrate the text

    Make global changes as represented below:

    • Make changes to all Message Diagrams, beginning with Figure 8-2. Message Header Diagram and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. Note that we no longer need the concept of a block called "Required Fields" and another called "Optional Fields". Additionally, each changed diagram will use fields in the same order as found in the "Additional Information" table for the message to improve readability.
      • This is illustrated in the attached before and after diagrams for the following, each showing a slightly different aspect of the changes:
        • the Directive Response Message
        • the Configuration Status Message
        • the Heartbeat Message
        • the Mnemonic Value Request Message
      • The identical pattern will be applied across all the above mentioned figures. Note that the 'revised' diagrams already show changes previously approved from C2MS11-18 (making all messages subclass C2MS Message which contains a Header) and C2MS11-31 (Clarify the UML diagrams regarding the values for the fields inherited from Message Header).

    • Make changes to all Message "Additional Information" tables, beginning with Table 8-3. Message Header Additional Information and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. This will verify that all tracking fields are described in the tables clearly.
      • This is illustrated in the "revised text" of this issue with table changes for the same four messages listed above, again, each showing a slightly different aspect of the changes. The identical pattern will be applied across all the above mentioned figures.

    • This proposal constitutes a plan to do the above if voted on, though there will be a follow-on vote with a separate issue/proposal to show all the changes before and after for completeness. Vote 'yes' on this one if you plan to vote 'yes' on the final (to avoid extensive work without commitment).
    • If this proposal is accepted, a complete set of before and after images will be provided as part a second issue/proposal and if accepted will be provided as part of the RTF Report assuming that second issue/proposal is accepted.
      • Note that the final images may be a convergence with other voted in global figure changes, such as (but not limited to) C2MS11-18. In other words, if this proposal is accepted and others like C2MS11-18 the proposals are also accepted, all sets of changes will be made in the final "after" images in the RTF Report.
  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Make Fields Table and UML Match the Order of Fields for greater Readabliity

  • Key: C2MS11-17
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    It would greatly aid readability of the specification if the tables listing the message contents by field separated the required fields from the optional fields. By doing this, the UML and descriptive tables would be in alignment.

    This is true throughout, but for one pretty clear example, see section 8.6.1.3. The UML (figure 8-13) (page 101) and the table (table 8-69) are hard to read together when looking at both.

    In this case, there are two blocks in the UML diagram that contain fields: one block is "Required Fields" and the other "Optional Fields". The table, simply shows fields. When reading down the fields in the table, the listed fields come from the two different UML blocks in the following order:

    1-Required
    2-Optional
    3-Required
    4-Optional
    5-Optional
    6-Required
    7-Required
    8-Optional
    9-Optional
    10-Required

    It would be much more clear to have all the fields in the table be listed in the same order as the UML diagram, with Required first, followed by Optional, along with a column specifying required or optional. Alternatively, there could be two tables: one for required fields in the same order as the "Required Fields" block of UML, and a second table with all the optional fields in the same order as the "Optional Fields" block of UML.

    As mentioned above, this is one example, but this disconnect between the UML and the Fields table is true throughout the document.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:33 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Changes are being made in C2MS11-14

    This issue has been merged into (and is a duplicate of) C2MS11-14.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Clarify the ".... Message Header Notes" tables re: being included in each message

  • Key: C2MS11-30
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The ".... Message Header Notes" tables can be confusing. For example, table 8-8. It should be made clear that the fields listed in those tables are from the Message Header definition, but the values apply only for that specific message. A small wording change would go a long way to helping, especially for newer users.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:39 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    The issue reported is non-specific

    The issue reported suggests wording changes to a table or tables related to ... Message Header Notes. But doesn't specifically say what changes should made. Reviewing the text indicated doesn't clarify it, no obvious issue is found.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consider Renaming "Header String" type to "Subject Token String"

  • Key: C2MS11-49
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    I believe the distinction between "Header String" and "String" types is to enforce compliance with Subject Element format (UPPERCASE Alphanumeric, "-" and "_" as only valid values). The description of "Header string" in Table 8-1, Field Type Definitions, indicates that this type is used for "subject name elements".

    It's a bit confusing to call this a "Header String", because not all Strings in the Header are Header Strings, and some fields are Header String type even though they are not in the Header (Some examples: USER, SUBCLASS, REFERENCE-ID, and OCCURRENCE-TYPE in Log, CNTL-KEYWORD in Control Message).

    In all cases, the fields that are Header String type are intended to be used as subject elements.

    One side note, that would need to be fixed, either way is that the actual type listed in Table 8-1, Field Type Definitions, lists the type in two places as "Header string" (lowercase s on string), where everywhere else in the document and in UML model figures, it is listed as "Header String".

  • Reported: C2MS 1.0 — Fri, 25 Feb 2022 13:37 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    do it in 1.1

    Make changes in the document to replace "Header String" (or sometimes "Header string") with "Subject Token String". Remove the UPPERCASE limitation everywhere except for the first subject element "C2MS". Increase the suggested length limit from 12 to 25 characters. Make consistent the use of "C2MS Subject Name" and "subject name" capitalization (capitalized as C2MS Subject Name, other wise not capitalized).

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

REQUEST-ID as "Replacement" and related STOP

  • Key: C2MS11-55
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Numerous field tables in C2MS allow reusing the same REQUEST-ID for a request to provide a "replacement". For example, MVAL REQ Message says in the Fields table (Table 8-99) under REQUEST-ID:

    "ID to identify the request message - if different request messages have the same value, the request is a replacement; else, it is a new request"

    In all cases, this is the only explanatory text of what is meant by "replacement". This is pretty ambiguous about expected result. So, for example,

    • If I send an initial request to start receiving MVAL A and B, and then send another request of the same REQUEST-ID for MVAL C, is the result that I'm now subscribed to A, B and C, or just to C?
    • If I send a request to start receiving MVAL X and Y with a PUBLISH-RATE of 1 and then send another request for a duration of 120 minutes, and then send another request wit the same REQUEST-ID for MVAL Y with a PUBLISH-RATE of 5, am I subscribed to X at 1 and Y at 5, or just Y at 5?

    There's no description of semantics regarding what is being replaced.

    A related issue is STOP request, specifying non-symmetrical MVALs, and what to do in that situation.

    • If I send a request to start receiving MVAL 11 and 12, and then send a STOP, but only specify MVAL 11, do I still get 12?

    In C2MS 1.0, in every instance of sending a REQUEST-ID as part of a request, the Notes for the field states the identical, "ID to identify the request message – if different request messages have the same value, the request is a replacement; else, it is a new request." However this copy-paste doesn't always make sense.

    Re-use of a REQUEST-ID only makes sense if the request leaves some process continuing to fulfill data streaming. Only two request messages have a start/stop concept. Therefore, this resolution assumes no other messages have a use case for 'replacement' and removes the confusing extra text.

    Additionally, the concept of 'replacement' is not needed in the two cases where start/stop actions are present... just stop the old one and start a new one. Using 'replacement' can lead to confusion.

  • Reported: C2MS 1.0 — Fri, 4 Mar 2022 00:28 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do it in 1.1

    Remove the reference about replacement from the Notes column of the corresponding table for messages that don't have any ongoing aspect controlled by start/stop. These are the following:

    • Archive Message Retrieval Request Message (Table 8-20)
    • Directive Request Message (Table 8-32)
    • Archive Mnemonic Value Request Message (Table 8-114)
    • Command Request Message (Table 8-131)
    • Product Request Message (Table 8-146)
    • Simple Service Request Message (Table 8-160)

    Modify the text and table notes associated with the following messages to include explanation of the re-use of REQUEST-ID.

    • Replay Telemetry Data Request
    • Mnemonic Value Request Message
  • Updated: Mon, 16 Sep 2024 14:18 GMT

Add Message-level Security Constructs

  • Key: C2MS11-48
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Add fields that allow encryption of content sections of C2MS messages as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.

    The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.

    Note that currently, GMSEC provides a level of encryption/signing, but my thought is that it would be preferred to allow the mission to manage this outside the transport layer. Providing encryption/signing FIELDS in the message definition allows for this decouplling.

    I've got some specific ideas about how to do this, which I can share, but just want to capture the need here.

  • Reported: C2MS 1.0 — Tue, 22 Feb 2022 16:50 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Part of a TBD Sister Spec

    Although it would be a good idea to have security info accompany the message, it really is part of a TBD Sister Spec. Perhaps a Message Envelope that interacts with the MW, rather than embedded within the C2MS message.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Missing Echo Request

  • Key: C2MS11-87
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There is no “need Echo” in the EGS REQ CMD Message. At present, all we can say is that based on MUS configuration, EGS CMDECHO may be generated.

    I propose using a new Boolean CMD-ECHO field in Command Request Message to indicate if an ECHO should be sent at any configured point along the ground chain as the command is transmitted.

    This would be an Optional field, defaulting to FALSE.

  • Reported: C2MS 1.0 — Tue, 7 Jun 2022 12:48 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    do it in 1.1

    See description for what to do

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

In message Archive Message Retrieval Response, fix Header field names

  • Key: C2MS11-34
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Typo in the diagram only for Archive Message Retrieval Response calls the Header fields it uses MSG-TYPE and MSG-SUBTYPE. They should be MESSAGE-TYPE and MESSAGE-SUBTYPE, respectively. See page 64, figure 8-5.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:38 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Fix Typos in Figure.

    Note if accepted along with other proposals that alter figures, there will be a rollup figure changes issue that will contain all the before and after pics to be voted on and submitted for final set of figure changes.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Move Tracking Fields to a "Message Envelope"

  • Key: C2MS11-75
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. Recommended here, is to define a C2MB Sister spec that encompasses the 'how' of sending C2MS messages. This is the logical place for managing tracking fields in a "Message Envelope".

    This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning in C2MS itself.

  • Reported: C2MS 1.0 — Sun, 20 Mar 2022 01:04 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Part of a TBD Sister Spec

    Do this as part of a future possible C2MQ Spec.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

In Message Header, make NODE and USER-NAME string rather than Header String

  • Key: C2MS11-29
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The NODE and USER-NAME fields are tracking fields supplied by the implementation (API). They should just be whatever strings are returned by the local o/s rather than forcing them to be of type Header String (upper alphanumeric, "-", "_").

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:23 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Change the C2MS Message Header diagram. Note that this diagram will change because of other resolved issues. So, this proposal is to vote on this change. All diagram changes will be consolidated together in a future issue/proposal for final versions.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Add DESTINATION_NODE and DESTINATION_FACILITY to Message Header

  • Key: C2MS11-28
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    In the Message Header (pages 41-45), add the fields DESTINATION_NODE and DESTINATION_FACILITY as Optional with type of Header String. This enhances the routing/subscribing options currently available for the DESTINATION_COMPONENT field.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:20 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Move to C2MQ

    It was determined at the RTF in September that this should be transferred to C2MQ.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

All Messages Subclass Message Header

  • Key: C2MS11-18
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The way the UML is shown for each message, each C2MS message inherits the Message Header type. This isn't really semantically correct.

    Consider the diagram from section 8.6.3.3 (although this is true throughout all message specifications), which is included as Attachment 1. Organized this way, this UML means that Telemetry TDM Frame Message IS A Message Header, rather than that it contains a Message Header.

    THere are two options for making this a little more clear:

    Option A is that Instead, they should be subclasses of something called "C2MS Message" that itself contains a Message Header, as shown in Attachment 2, in which Telemetry TDM Frame Message IS A C2MS Message, and all C2MS Messages contain a Message Header.

    Option B is to use composition where each message contains a message header. This is as shown in Attachment 3.

    It's not a major point, but would increase readability and have better optics.

    After discussion, Option B seems like the right choice.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:53 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Documentation Change to be Made in 1.1

    The following changes will be made:

    1. Update text in Section 8.1 C2MS Message Header to remove the concept that all C2MS Messages are sub-classes of C2MS Message Header, but rather are sub-classes of a new C2MS Message class that comprises a C2MS Message Header.
    2. Modify Figure 8-2. Message Header Diagram to show the new C2MS Message class containing the Message Header, as shown in the attachments.
    3. Make the changes to all Message Diagrams, beginning with Figure 8-4. Archive Message Retrieval Request Diagram and ending with Figure 8-40. Tracking Data Message Diagram to make the message contain, rather than specialize the C2MS Message Header.
      • This is illustrated in the attached before and after diagrams for the Telemetry TDM Frame Message.
      • The identical pattern will be applied across all the above mentioned figures.

    If this proposal is accepted, a complete set of before and after images will be provided as part of the RTF Report

    • Note that the final images may be a convergence with other voted in global changes, such as is proposed with C2MS11-59. In other words, if this proposal is accepted and C2MS11-59 is also accepted, both sets of changes will be made in the final "after" images in the RTF Report.
  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Clarify the UML diagrams regarding the values for the fields inherited from Message Header

  • Key: C2MS11-31
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    This issue is related to C2MS11-30, which is about the table immediately prior to every message UML diagram. The UML diagrams, for example figure 8-3, seem to indicate that "MESSAGE-TYPE" and "MESSAGE-SUBTYPE" are fields in the individual message when they are actually in the Message Header.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:43 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Remove the current block attributes, and instead show Constraints as in:

    {Message Header.MESSAGE-TYPE == MSG, Message Header.MESSAGE-SUBTYPE == LOG}

    with the required values. Display the full Message Header classifier for clarity.

    If this proposal is accepted, a complete set of before and after images will be provided as part of the RTF Report

    Note that the final images may be a convergence with other voted in global changes. In other words, if this proposal is accepted and other figure-affecting proposals are also accepted, all sets of changes will be made in the final "after" images in the RTF Report.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Add field for USER to Message Header

  • Key: C2MS11-32
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    In Log, Directive Request, and Simple Service Request, there is a USER field for use by communicating applications. This field should be moved to the Message Header, so that any message can utilize this field.

    Note: in the Log Message this field is used in the subject, so is defined as a Header String. In the Directive and Simple Service messages, it is not used in the subject so is defined as a string.

    Note 2: There is another field in the Message Header called USER-NAME; this is a tracking Field, so is reserved for use by the implementation and is the account/user name that started the application.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 18:01 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Move to C2MQ

    This is really part of the C2MQ effort, so rather than add it to C2MS only to later move it to C2MQ is not preferred.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

In the Control Message, the field CNTL-STRING should be required

  • Key: C2MS11-38
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Change the CNTL-STRING field in the Control Message from optional to required. That field is the reason for the message. This also will be consistent with Directive Message, where DIRECTIVE-STRING is required. See Figure 8-9.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:52 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Fix Figure.

    Note if accepted along with other proposals that alter figures, there will be a rollup figure changes issue that will contain all the before and after pics to be voted on and submitted for final set of figure changes.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Add security fields that GMSEC API inserts into encrypted messages as Tracking Fields in C2MS

  • Key: C2MS11-33
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The intent of tracking fields is to reserve them for use by the implementation. So, to be complete, these fields should be added to the specification. If any of these fields were to be inadvertently added to the messages by an application, the implementation (GMSEC API) could potentially overwrite their values.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:33 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Move to a TBD Sister SPEC

    Tracking fields and encryption handling are likely to become part of the in-RFP C2MQ, so this should be transferred to that spec, rather than being implemented now in C2MS only to remove it soon.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Remove value for CNTL-STRING from CNTL message

  • Key: C2MS11-37
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The field CNTL-KEYWORD in the Control Message is supposed to contain the keyword extracted from the field CNTL-STRING. It should not be fixed. So, remove the value from the diagram. Figure 8-9. This is a Model change.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:49 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Do this in 1.1

    Fix Figure.

    Note if accepted along with other proposals that alter figures, there will be a rollup figure changes issue that will contain all the before and after pics to be voted on and submitted for final set of figure changes.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:


Document that Header String type is to be at least one ASCII character

  • Key: C2MS11-26
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    This is just a documentation clarification. Header Strings are the type used for building message subjects. It's invalid for a message subject element to be null. So, Header Strings need to be at least one character.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:09 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Add Text to Table Describing Field

    Add a sentence to the "Range/Comments" column of the Field Type Definitions Table.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Requesting data via pub/sub requires knowing publisher's service name

  • Key: C2MS11-10
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Requesting data, such as telemetry, via pub/sub requires knowing the publisher's server name. There should be a way to request data without this being already known. This could potentially be solved by a registry concept, as in C2MS11-1, but this particular issue proposes adding a service-matching capability wherein the requester is asking for a subscription to some data and the request results in linking the subscription to a service that provides that data.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:48 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Move to a TBD Sister SPEC

    There will be discussion in the SDTF about creating a Sister SPEC to C2MS that is more about HOW these messages are created, sent, handled. For now, call this C2MB (message bus). If created this spec would the the logical place for this particular issue.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Control Message SPECIAL_INFO Field type should be String

  • Key: C2MS11-40
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the Control Message, the field SPECIAL_INFO is Binary type in the UML diagram (Figure 8-9), but is described as "For application use. Any additional information can be provided here." (Table 8-48).

    Because C2MS has no definition or understanding of the binary format, it is probably better if the type be changed to "String", so that opaque data is not transmitted around the system where only the producer and consumer can understand what it is. Log messages, for example, would not be able to record, in any meaningful way, what was sent in the control message.

  • Reported: C2MS 1.0 — Tue, 6 Oct 2020 17:46 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    close

    The field needs to be as-is, so closing this issue..

  • Updated: Mon, 16 Sep 2024 14:18 GMT

"Mnemonic" should be called "Parameter"

  • Key: C2MS11-12
  • Status: closed  
  • Source: Parsons ( Gerry Simon)
  • Summary:

    This to be consistent with the XTCE Specification. Moreover Mnemonic isn't accurate as the very definition of mnemonic is a shorthand "code" for the actual parameter name.

    Recommend close/deferring this issue, but believe it's important to capture our rationale as the community will ask why the inconsistency between SDTF specifications.

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:48 GMT
  • Disposition: Closed; No Change — C2MS 1.1b1
  • Disposition Summary:

    Will not implement.

    Would be more correct, but has too much committed use already with GMSEC and existing users/missions.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Message-level Security Credentials

  • Key: C2MS11-22
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Justin Boss:
    A username or alternate security credential should be able to be provided with all C2MS requests (and possibly should be required)?

    Systems should not automatically trust remote clients and therefore a credential should be required with all messages. This would allow components to authorize and audit requests on a per-user/connection level.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 03:38 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Part of a TBD Sister Spec

    Although it would be a good idea to have security info accompany the message, it really is part of a TBD Sister Spec. Perhaps a Message Envelope that interacts with the MW, rather than embedded within the C2MS message.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Larger Data Types

  • Key: C2MS11-21
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). (From Justin Boss)

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 15:44 GMT
  • Disposition: Duplicate or Merged — C2MS 1.1b1
  • Disposition Summary:

    Duplicate of C2MS11-19

    Not needed, as this duplicates another issue

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Pub/Sub subscription status unknown

  • Key: C2MS11-9
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    C2MS should offer a mechanism for clients and/or servers to be able to check validity of a subscription.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:43 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Part of a TBD Sister Spec

    Part of a TBD Sister Spec

  • Updated: Mon, 16 Sep 2024 14:18 GMT

C2CX Heartbeat comments

  • Key: C2MS11-2
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (C2CX Heartbeat) Section 8.5.4

    • Suggest not having CPU / Memory utilization in the messages. That would be better implemented through normal system monitoring mechanisms (e.g., SNMP). Code to retrieve such information is typically platform-specific and is not related to the business logic of the component.
    • If such information is required, suggest having a system monitoring component instead.
    • Unclear exactly how this would work in a clustered environment. Different hosts implementing the same service would provide conflicting answers.
    • Unclear why the commentary on why memory leaks are bad is in the spec
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:21 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Field and Text Changes to Heartbeat Message

    Following changes to be made:

    1. Remove CPU / Memory utilization in the messages
    2. Replace Heartbeat Message Diagram
    3. Remove text about memory leaks

    See C2MS11-2 for rationale.

    See attachments for original and revised figure, Figure 8-11. Heartbeat Message Diagram

    Note: There had been discussion about whether it would be OK to remove fields from the spec. At a 2022 C2MS RTF Meeting, Jay was good with removing the fields.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Archive Mnemonic Value Request comments

  • Key: C2MS11-3
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (Archive Mnemonic Value Request) Section 8.9.1

    • Need official registry for FORMAT values

    The AMVR message has a field called FORMAT that is of type String, but there is no enumeration of possible formats. This could be handled by requestor and supplier agree on a format.

    FORMAT is used to define the file format of the return data.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:25 GMT
  • Disposition: Resolved — C2MS 1.1b1
  • Disposition Summary:

    Clarify FORMAT field of AMVAL Request Message

    Change the "notes" relating to FORMAT of the message to indicate, similar to SPECIAL-INFO field in Directive Request Message, that this is "For application use".

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Acknowledge Final Status inconsistency

  • Key: C2MS11-8
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Based on review of latest specification, the problem detailed in C2MS-5 is still present. This problem makes it not possible for a client application to properly be developed to support all MEPs. If a client application is developed to support MEP2, then it will ignore all future responses after the first ACK comes in when communicating with a server that supports MEP4 or MEP5. If a client application is developed to support MEP4 and MEP5, then it will never think that a request finished when communicating with a server that supports MEP2.

    As is currently specified, via table 6-9 on page 20, the Acknowledge is listed as a Final Status. Though it is only a final status in MEP2.

    Possible solutions:
    1. Remove MEP2. This would make Acknowledge in Table 6-9 have a Final Status of "No"
    2. Add an additional status code of Acknowledge Complete (perhaps #7). In this option, Acknowledge (#1) would have Final Status of "No", though new Acknowledge Complete (#7) would have Initial Status of "Yes", Intermediate Status of "No", and Final Status of "Yes".

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:44 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    This is a good idea, but deferring this to a later release due to time

    I've run out of time to get this done in 1.1. It's important, but there is already so much work put into 1.1, we need to close that release and can do this one in 1.2.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Lack of a registry concept

  • Key: C2MS11-1
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Discoverability of data is still a major concern due to the lack of a registry.

    • Unclear how components are supposed to find out about available resources
    • Unclear how components are supposed to find out about related subjects
    • What is the associated heartbeat subject of a client, particularly a temporary one?
    • ME1 depends on knowing the name of the other end beforehand. Where is this supposed to come from and why should a component have to care about that?
    • Recommend a registry be considered and answers to question above.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:10 GMT
  • Disposition: Transfered — C2MS 1.1b1
  • Disposition Summary:

    Part of a TBD Sister Spec

    This may be useful for "offline" data sharing services. Probably not for realtime operations on the floor. ... but probably not within scope of C2MS, because this spec defines the message set, not how they are used.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS11-6
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    For a complete implementation of C2MS on the systems I use, we need some kind of Procedure Script Execution set of messages. These would include being able to launch procedures, monitor them, show progress, etc. This could be a topic of some significant discussion and is entirely new scope. The closest analogue I have so far found is the Activity Tracking stuff in the CCSDS Mission Operations Common Services.

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:28 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    This is a good item to capture, but probably represents substantial work and new message types.

    This proposal is to defer it to a future major release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Data Dictionary Messages

  • Key: C2MS11-5
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    It seems that there is a consensus that we need database data dictionary informational messages. It seems to be in work. Capturing the item here.

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:23 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer Data Dictionary to Future Revision

    Incorporating data dictionary messages is a large effort and would provide XTCE described information about parameters, telemetry containers, telecommand containers, streams, etc. This cannot be achieved by the existing RTF so needs to be deferred to a time when we come together to do this.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

XML PSM recommended

  • Key: C2MS11-7
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Due to lack of the ability to have multiple independent implementations of GMSEC due to its message-building API functions in source code, it would be appreciated if there were an XML PSM available. This would allow for an independent implementation apart from the single known implementation at this time. At this time, there is no known PSM that enables implementation of C2MS at this time that does not depend on FOSS or government-licensed IP.

    This is based on inputs from C2MS-2.

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:07 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    This requires an RFP, post 1.1 and/or UML diagram update

    This should be deferred until the 1.x UML diagram work is complete which will form a PIM.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

C2MS: Optional Transfer Frame/Packet attributes should be described in schema

  • Key: C2MS11-42
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Non-self-describing CCSDS attributes for either transfer frames or space packets should be provided as dependent attributes of the frame messages. This would enable full integration between a sender and receiver. Right now, whether these optional fields are provided is unknown, causing the proper rendering of the frame to not be possible without outside negotiation (beyond the specification).

    Examples:

    Frame Header Error Control of the AOS transfer frame (AOS Space Data Link Protocol (ccsds.org)), where nothing prior to it in the definition specifies whether it is there or not:

    4.1.2.6 Frame Header Error Control
    4.1.2.6.1 If implemented, Bits 48-63 of the Transfer Frame Primary Header shall contain the Frame Header Error Control. NOTE – The 10-bit Master Channel Identifier, the 6-bit Virtual Channel Identifier, and the 8-bit Signaling Field may all be protected by an optional error detecting and correcting code, whose check symbols are contained within this 16-bit field.
    4.1.2.6.2 The presence or absence of the optional Frame Header Error Control shall be established by management.
    4.1.2.6.3 If present, the Frame Header Error Control shall exist in every Transfer Frame transmitted within the same Physical Channel.

    Space Packets and the secondary header (Space Packet Protocol (ccsds.org)): A space packet might have a secondary header with a variable length time code, a variable length ancillary data field, or both. A space packet might have a secondary header, a user data field, or both. The length is not specified for any of them. When present, the format of the time code can be one of several options, but which one is not specified:

    4.1.3.3.3 Secondary Header Flag 4.1.3.3.3.1 Bit 4 of the Packet Primary Header shall contain the Secondary Header Flag. 4.1.3.3.3.2 The Secondary Header Flag shall indicate the presence or absence of the Packet Secondary Header within this Space Packet. It shall be ‘1’ if a Packet Secondary Header is present; it shall be ‘0’ if a Packet Secondary Header is not present. 4.1.3.3.3.3 The Secondary Header Flag shall be static with respect to the APID and managed data path throughout a Mission Phase. 4.1.3.3.3.4 The Secondary Header Flag shall be set to ‘0’ for Idle Packets

    4.1.4.2.1.5 If present, the Packet Secondary Header shall consist of either: a) a Time Code Field (variable length) only; b) an Ancillary Data Field (variable length) only; or c) a Time Code Field followed by an Ancillary Data Field. 4.1.4.2.1.6 The chosen option shall remain static for a specific managed data path throughout all Mission Phases. NOTE – The format of the Packet Secondary Header is shown in figure 4-3. ANCILLARY DATA FIELD (optional) variable PACKET SECONDARY HEADER TIME CODE FIELD (optional) variable Figure 4-3: Packet Secondary Header

    4.1.4.2.2 Time Code Field 4.1.4.2.2.1 If present, the Time Code Field shall consist of an integral number of octets. 4.1.4.2.2.2 The Time Code Field shall consist of one of the CCSDS segmented binary or unsegmented binary time codes specified in reference [3].CCSDS RECOMMENDED STANDARD FOR SPACE PACKET PROTOCOL CCSDS 133.0-B-2 Page 4-8 June 2020 NOTE – The time codes defined in reference [3] consist of an optional P-Field (Preamble Field), which identifies the time code and its characteristics and a mandatory T[1]Field (Time Field). Examples of time codes are CCSDS Unsegmented Time Code and CCSDS Day Segmented Time Code. Examples of characteristics are ambiguity period, epoch, length, and resolution. 4.1.4.2.2.3 The time code selected shall be fixed for a given managed data path throughout all Mission Phases. 4.1.4.2.2.4 If the characteristics of the chosen time code are fixed, the corresponding P[1]field (as described in reference [3]) need not be present. If the characteristics are allowed to change, the P-field shall be present so as to identify the changes. 4.1.4.2.2.5 The presence or absence of the P-field in the Time Code Field shall be fixed for a given managed data path throughout all Mission Phases. If present, it shall immediately precede the T-field that is defined in reference [3]

    4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

    4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

  • Reported: C2MS 1.0 — Tue, 13 Jul 2021 12:26 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Topic requires deeper examination and solution in future revision

    The topic is larger than the time frame to address in version 1.1 but is accepted overall.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

C2MS Database Query (DBQUERY) messages

  • Key: C2MS11-45
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Add the DBQUERY messages that were defined by NASA to the formal specification.

    These messages are listed as being part of the OMG specification here:
    https://software.nasa.gov/software/GSC-18536-1

    "A Graphics User Interface (GUI) based desktop viewer for XML Telemetry and Command Exchange (XTCE) files which allows some editing of the various XTCE properties of that open file, and then allows saving the updated information back to file. It includes a Goddard Mission Services Evolution Center (GMSEC) GMSEC Search XTCE (GSX) connector to support some GMSEC/ (Command and Control Message Specification) C2MS Database Query (DBQUERY) messages to search for some XTCE information which is then sent over GMSEC bus to the initiator of the search request."

  • Reported: C2MS 1.0 — Wed, 26 Jan 2022 18:09 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Redo this in 1.2

    It turned out that this needs more work. Kevin to supply full analysis and rework this for 1.2.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

For consistency, all message types should have a name that ends with "message"

  • Key: C2MS11-11
  • Status: closed  
  • Source: Parsons ( Gerry Simon)
  • Summary:

    For most of the message types in C2MS, this convention is followed. The exceptions are:

    -Archive Message Retrieval Request
    -Archive Message Retrieval Response

    These were likely left this way because they already have "Message" in the name, though with a different meaning. Archive Message Retrieval Request Message does sound redundant. Perhaps renaming to any of the following would help:

    • Archived Messages Request Message
    • Archive Retrieval Request Message
    • Archive Request Message
    • Archive Message Request Message

    Not using "Archive Message" in the title is a bit confusing because there is Archive data that is not simply archived messages, see "Archive Mnemonic Value Request Message"

    Note that when originally entered, this issue listed all the following... but in 1.1, the only messages not ending in "Message" are the Archive request/responses.

    -Archive Message Retrieval Request
    -Archive Message Retrieval Response
    -Telemetry Message for CCSDS Packet
    -Telemetry Message for CCSDS Frame
    -Telemetry Message for TDM Frame

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:39 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    Only the two messages are affected, and the solution is to rename these, so deferring to 2.0.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS11-4
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    The messages for mnemonic access do not appear to include a request/response for "setting" the value of a parameter (mnemonic) from an application participating using C2MS. This capability is used for ground and other types of non-telemetered parameters (mnemonics).

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:21 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    In Austin (Dec/2022) RTF, we determined that this should be deferred to 2.0, since it represents a more significant change.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Add a Message Exchange Pattern (MEP) for a component to forward requests/responses

  • Key: C2MS11-24
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Some services may depend on other services to satisfy a request. Create a MEP that discusses and shows how this could work.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:52 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to later release

    This needs a use case. Probably best to defer at this point, with so many other issues on the docket.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consider a mechanism to request archived Commands and Events

  • Key: C2MS11-44
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    TLM and MVALs can be retrieved from the archive, but it would be useful to define a way to retrieve archived Commands and Events as well, since these represent, along with TLM, the SatOPs messages.

  • Reported: C2MS 1.0 — Fri, 10 Dec 2021 03:22 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Add Session Type and Session UID to Standard Subject in a future version but defer for now

    Add Session Type and Session UID to Standard Subject in a future version but defer for now

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Harmonize Replay TLM and Archive Mnemonic Message Sets

  • Key: C2MS11-20
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Harmonization Needed

    I’d like to recommend a review of the Replay Telemetry Data Request Message compared to the Archive Mnemonic Value Request Message. These two messages should be nearly identical in form, but appear to have grown up in neighborhoods on opposite sides of the tracks.

    Some base behaviors are different between the two. Many fields exist in one request message but not the other. In one case, the same field exists in both request messages, but has a different meaning. The response paradigm is different between the two message sets.

    This issue is to harmonize the two message sets.

    Throughout this discussion, I’ll use the following abbreviations:

    • “RTDRM” - Replay Telemetry Data Request Message
    • “AMVRM” - Archive Mnemonic Value Request Message

    Sections below describe elements of the two that are dissimilar:

    Message Naming

    For TLM, the Message is called Replay Telemetry Data Request Message (RTDRM). For the MVAL it is Archive Mnemonic Value Request Message (AMVRM). Since both have the concept (implemented differently) of replay, but the AMVRM has a way to receive the data as an output file, I think that “Archive” is more meaningful. In fact the descriptive text under the RTDRM, refers to the “Telemetry Archive component”. So, I’d suggest renaming the RTDRM to Archive Telemetry Data Request Message to match better with Archive Mnemonic Value Request Message.

    Real-time and Future “Replay”

    Replay Telemetry Data Message set includes a long description of how to use the “replay” service provider as a way to get real-time, or even future TLM messages (Section 8.7). There is no analog in Archive Mnemonic Value Messages.

    I recommend we don’t include that discussion in the Archive Mnemonic Value Messages. It seems odd to have “replay” messages for something that isn’t replay. I believe the same intent can be achieved by simply requesting a “replay” whose end-date-time is in the future, and indicate that the archive service will continue to send out TLM, as long as it is put in the archive during that window. That is logically similar, without trying to fake out the system, because the data would still originate from the archive.

    The STREAM-MODE of the RTDRM (sec 8.7.1.3) can be RT or RPY, to accommodate the intent of separating real-time from replay. I don’t’ think this is needed. If we assume that we only replay data that is in the archive, whether it is arriving into the archive now or in the future, this is logically the same and wouldn’t require special handling in the message definition.

    Section 8.7.1 indicates that the two fields PLAYBACK-RATIO and DATA-RATE (described in sec 8.7.1.3) only apply if the STREAM-MODE is RT. However, having to specify STREAM-MODE as RT or RPY doesn’t seen necessary. These values could easily be applied to RPY: this would mean that the playback rate would be some ratio of the timing of the original TLM (play back at the same rate it was originally received, or some ratio related to it) or play it back at a certain data rate, from the archive. The distinction makes it awkward and I don’t think it’s necessary. The AMVRM uses PLAYBACK-RATIO and DATA-RATE with exactly these meanings, without any indicator of STREAM-MODE.

    I’m confused about what is meant by the fields of the RTDRM in Section 8.7.1.3 for files. There is a NUM-OF-FILES and a FILE.n.NAME-PATTERN, with very limited description of how this is to be used. The only clue is in Section 8.7.1, where there is indication that this only applies to a “real-time data stream”. I’m not sure how the requester is to know the names of files in the archive and why this would only apply to RT. Probably should be removed, unless we have a specific use-case for it.

    STREAM-MODE

    STREAM-MODE (described in sec 8.7.1.3) exists in RTDRM, but not in AMVRM at all. This would be useful in AMVRM, because STREAM-MODE can indicate SIM or TEST. RT and RPY are not needed, as described above.

    Request All Data Construct

    In addition to retrieving MVAL Data Messages as a stream, the AMVRM also has the concept of requesting the entire data set in a single message. In fact, this can either be in the payload of the single message or the data can be placed in a file at a specified URI. The RTDRM does not have this concept at all, and all retrieved TLM must be in a set of streamed messages. I like this capability of the AMVRM and recommend that it be added to the RTDRM.

    One oddity in this concept is that in the AMVRM (sec 8.9.1.3), if the RESPONSE-VIA-MSG is set to RESP.AMVAL, then it can be delivered in the single message or at a URI. However, the selection is controlled by two Boolean fields: DELIVER-VIA-REFERENCE (URI) and DELIVER-VIA-INCLUDE (message payload). It’s odd that these are separate Booleans, because there is no description of what would happen if they are both set to ‘0’ or if they are both set to ‘1’. I can surmise that setting both to ‘0’ would be an error and setting both to ‘1’ would mean to deliver the data set in both the single data message and also at the URI, but it’s hard to imagine the usefulness of doing so. I’d recommend we drop DELIVER-VIA-INCLUDE and just use the DELIVER-VIA-REFERENCE to mean that the data is to be EITHER in a URI OR in the data message.

    ACTION Field

    The RTDRM has an ACTION field to control flow (start, stop, etc). There is no analogue in AMVRM, but there probably should be.

    PDB-VERSION Field

    The AMVRM has a PDB-VERSION field. This field does not exist in RTDRM. To me this seems way down in the weeds, and was probably an add-on for a special one-off case somewhere along the line. Is it necessary? If not it should be removed. If so, it should be added to RTDRM as well.

    ORBIT Field

    RTDRM can specify a particular orbit. This field does not exist in AMVRM.

    Filename Fields

    RTDRM, as discussed earlier, has fields for the source files for TLM. This concept doesn’t exist for AMVRM. Unless we can come up with a specific use case for this (along with a better description of the fields in the RTDRM), I’d be in favor or dropping it from RTDRM. Otherwise, it should probably be added to AMVRM for consistency.

    FORMAT Field

    Both RTDRM and AMVRM have a FORMAT field. They are used for different purposes. I’d recommend calling the one in RTDRM TLM_FORMAT and the one in AMVRM something like FILE_FORMAT since that corresponds to their use.

    VCID and APID Fields

    RTDRM has VCID and APID fields. The AMVRM does not. Yet, the MVALs originated from the same TLM stream, so these seem applicable to AMVRM. Needs discussion. Note that both request messages have COLLECTION-POINT with identical meaning, so the origination of TLM and MVALs are tied in that way.

    Mnemonic Value Data Message vs Archive Mnemonic Value Data Message vs TLM Messages

    In the RTDRM, asking to retrieve TLM messages results in identical TLM messages to when these messages came in, real-time. The only exception is in the STREAM-MODE of that message type, which is set to RT for original messages, or RPY for messages coming out of the archive. This is a useful construct.

    However, for AMVRM, the original real-time messages have one format, defined in section 8.8.3.3 and a different format for messages retrieved from the archive, described in section 8.9.3.3.

    It seems logical to use either one pattern or the other. I prefer the pattern used by TLM, where the original message format reappears, but with a designator that it is a RPY message.

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 16:28 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    This is a good reason to have a C2MS Roadmap discussion. For now, defer to a later release (2.0?)

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Larger Data Types

  • Key: C2MS11-19
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    From Justin: In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). May need a separate field to indicate the type of data in these fields.

    [NOTE: the reason for deferment is simply say making the RAW-VALUE a 64 bit and the EU-VALUE 128-bit float falls outside of hardware support and programming language support -- and adding a DATA-TYPE field to support the specification of any valid c2ms data-type in either field seems like a big change that should be considered more fully.]

    The current spec supports a RAW-VALUE and EU-VALUE (converted/calibrated) fields. Currently the RAW one is a 32-bit signed integer and the EU one is a double (64-bit). To support a broader value type and range, this change adds a RAW-VALUE-TYPE and an EU-VALUE-TYPE to any message these fields are in. In some cases, if the message has both a RAW and EU value, these could in some cases be identical. Additional optional (special case) fields are also added RAW-VALUE-LENGTH and EU-VALUE-LENGTH, these two are discussed below.

    The RAW-VALUE-TYPE and EU-VALUE-TYPE would be one of the C2MS data-types and be valid for all samples in the message. Hence, they are only specified once per message.

    For example, a typical combination might be: RAW-VALUE-TYPE=I32, EU-VALUE-TYPE=F64 for numeric calibrated telemetered values.

    The main reason in some cases to preserve both the RAW and the EU value is that in some cases there's a need to re-calibrate existing values and the raw can then be used to do that... [are there any others?]

    [It's worth noting that RAW here may mean literally bit-by-bit what's in the packet or it could mean "host corrected" (byte swapped) but without calibration -- we should sort that out. In fact, C2MS does not say that I can tell ... I'm aware that some orgs support the notion of raw from the packet, host-converted (byte/bit corrected), and fully calibrated) in which case within discussion we may want to have 3 fields, which seems excessive. I think I prefer 'host-corrected' for the raw, as we can only do so much, and some folks might not have the truly raw bits available anyway...]

    RAW-FIELD-TYPE and EU-TYPE-TYPE are of type String. The legal values are specified in table 8.1 column Field-type. Note that these should probably be mixed character legal in these fields.

    Two OPTIONAL fields are available for type binary (blob) and variable. These types SHALL supply RAW-VALUE-LENGTH and EU-VALUE-LENGTH which are both I32 and specify the number of bytes for either field value. Negative values are illegal. From an implementation point of view in regard to these variable length fields, that messages beyond a few megabytes are likely not supported.

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 15:48 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Add RAW-VALUE-TYPE and EU-VALUE-TYPE and two additional optional fields.

    [NOTE: the reason for deferment is simply say making the RAW-VALUE a 64 bit and the EU-VALUE 128-bit float falls outside of hardware support and programming language support -- and adding a DATA-TYPE field to support the specification of any valid c2ms data-type in either field seems like a big change that should be considered more fully.]

    The current spec supports a RAW-VALUE and EU-VALUE (converted/calibrated) fields. Currently the RAW one is a 32-bit signed integer and the EU one is a double (64-bit). To support a broader value type and range, this change adds a RAW-VALUE-TYPE and an EU-VALUE-TYPE to any message these fields are in. In some cases, if the message has both a RAW and EU value, these could in some cases be identical. Additional optional (special case) fields are also added RAW-VALUE-LENGTH and EU-VALUE-LENGTH, these two are discussed below.

    The RAW-VALUE-TYPE and EU-VALUE-TYPE would be one of the C2MS data-types and be valid for all samples in the message. Hence, they are only specified once per message.

    For example, a typical combination might be: RAW-VALUE-TYPE=I32, EU-VALUE-TYPE=F64 for numeric calibrated telemetered values.

    The main reason in some cases to preserve both the RAW and the EU value is that in some cases there's a need to re-calibrate existing values and the raw can then be used to do that... [are there any others?]

    [It's worth noting that RAW here may mean literally bit-by-bit what's in the packet or it could mean "host corrected" (byte swapped) but without calibration -- we should sort that out. In fact, C2MS does not say that I can tell ... I'm aware that some orgs support the notion of raw from the packet, host-converted (byte/bit corrected), and fully calibrated) in which case within discussion we may want to have 3 fields, which seems excessive. I think I prefer 'host-corrected' for the raw, as we can only do so much, and some folks might not have the truly raw bits available anyway...]

    RAW-FIELD-TYPE and EU-TYPE-TYPE are of type String. The legal values are specified in table 8.1 column Field-type. Note that these should probably be mixed character legal in these fields.

    Two OPTIONAL fields are available for type binary (blob) and variable. These types SHALL supply RAW-VALUE-LENGTH and EU-VALUE-LENGTH which are both I32 and specify the number of bytes for either field value. Negative values are illegal. From an implementation point of view in regard to these variable length fields, that messages beyond a few megabytes are likely not supported.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Replace Unsolicited Echo with a Separate Message

  • Key: C2MS11-140
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    According to the Command Echo Request:

    “This message is nominally sent after a Command Request is processed by the final destination (e.g., antenna or spacecraft). The Command Echo Message can also be generated without a prior Command Request Message being sent; this is known as an 'unsolicited echo' and can be generated by ground station equipment as a result of the antenna receiving noise or interference.”

    The concept of an unsolicited echo seems very strange, because it raises the question of what is being echoed, if it is not the command.

    The Command Echo Message Additional Information table has a CMD-ECHO-RESULT value of UNEX "Unexpected echo received" which I suspect is tied to the "unsolicited echo".

    If an unsolicited echo is meant to convey that the ground equipment is receiving noise or interference from the antenna, I believe a better approach would be to define a message to capture the noise or interference as an occurrence in the ground string and to send that, rather than to overload the Command Echo Message.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 20:20 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Move to a later release

    We may need a new message type, or simply stop saying that there is an unsolicited echo, but either way, it's not urgent enough for 1.1's short timeline.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Add documentation within the model

  • Key: C2MS11-13
  • Status: closed  
  • Source: Parsons ( Gerry Simon)
  • Summary:

    In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:31 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to later version when process is clear

    Until we have a way to generate the doc from the model, we don't want to duplicate or create copy-paste issues or especially to become inconsistent between the document and the model documentation. The RTF meeting in June 2022 determined to defer it.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

In message tables, rework the "value" column to allow for fixed values vs. default values

  • Key: C2MS11-23
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Many fields in many messages contain value information. Some of the values are defaults and some are intended to be constant. Also, this information is in the "notes" column. There should be a way to differentiate between fixed and default values more easily than reading the notes fields. Also, this will make encoding those attributes in the .xsd PSM easier.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:48 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    This would have been nice to fix in 1.1, but more urgent issues still need work in that release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

STREAM-MODE Issues with Replay Telemetry Message

  • Key: C2MS11-144
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There is a STREAM-MODE in Replay Telemetry Message, but in this case, I believe what it is there for is to say what types of telemetry messages to replay. It's not part of the Subject, the way STREAM-MODE is for other messages. I'm not sure it makes sense in this message type and should be re-evaluated. At a minimum, beefing up the description of it would be helpful.

  • Reported: C2MS 1.0 — Sun, 19 Mar 2023 21:16 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Needs some re-evaluation, so moving out of 1.1

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Using REQ Messages for 'Publish'

  • Key: C2MS11-47
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The "Publish" MEP second paragraph talks about using either MSG or REQ messages as a means of publishing. I think this could use some revisiting.

    It seems on that a REQ message "may or may not require a response. For example, one component may request another component to take some action and does not need to know immediately if the action was successful or not." f(section 6.3.2.1, pg 15). This is then enabled by specifying a BOOLEAN value for "RESPONSE" indicating whether a reponse is expected in a REQ message.

    To me, it seems like not expecting a response when issuing a REQ message is a corner case. Even in the example above, how do I know that ANY component received the REQ? I would prefer to say that components that process a REQ message are expected to respond AT LEAST with a RESP Message acknowledging receipt. If the sender chooses not to look for one, fine, but it seems like an odd pattern to make a request and ignore whether anyone heard you.

    This would aid in simplifying the Publish MEP to reduce it to just MSG. Actually, if we don't do this, we need to fix the sequence diagram on pg 24, anyway, because as shown it's incorrect; requiring sending a MSG before sending a REQ. It's really meant to be either-or. So, if we remove REQ as a Publish mechanism, the diagram will be adjusted to be correct. If we don't remove it, we need to split the SD into two separate diagrams.

    With all this in mind, I'd suggest:

    • that the Publish MEP use only MSG Messages, which is what they are intended for
    • and stating that REQ messages expect a response, even if it is only an acknowledgement (this would also remove the RESPOSE:BOOLEAN field from REQ messages.
    • this results in modifying the Sequence Diagram for Publish MEP (Note that this diagram is actually incorrect, anyway, because as shown, it says that to Publish, the publisher sends a MSG and then a REQ.) At a minimum, this diagram needs to be fixed, even if we don't make the semantic changes described here.

    Note that if we remove "RESPONSE:BOOLEAN" concept, this affects the following:
    8.4.1.3 Directive Request Contents
    8.10.1.3 Command Request Message Contents
    8.12.1.3 Simple Service Request Message Contents

    Additionally, we'd need to look for scattered text in the spec that says REQ does not require a response.

  • Reported: C2MS 1.0 — Thu, 17 Feb 2022 16:54 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    This would have been nice to do, but deferring because of it being a lower priority that several other issues still needing attention in 1.1.

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Split ME1 in Simple Service Req/Resp

  • Key: C2MS11-131
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Simple Service Request uses ME1 to indicate the target of the request, but this can have one of two mutually-exclusive forms:

    • Service Provider Name (a named instance of a component, such as FDServiceApp1)
    • A Service Name not related to a specific component (such as Flight Dynamics)

    Meanwhile, the Simple Service Response also uses ME1 in a similar, but slightly different way. In the RESP, ME1 represents one of two mutually exclusive forms:

    • A Requestor Name (a named instance of a components that requested a service, or will receive data from the Service Provider, such as C2App7)
    • A Service Name not specific to a component (such as Flight Dynamics)

    Note that when using ME1 to designate a component, it is always the target recipient of the request/response, but when specifying a Service Name, it is always the name of the Service Provided, which is more related to the responder than the requestor. In this way, the Request Message uses that form of ME1 to designate the recipient, but the Response Message in that form designates to the provider.

    This dual-hatting of ME1 is pretty confusing. One major user of C2MS has modified these messages to separate out the two uses of ME1 into ME1 and ME2, shifting ME2 and ME3 to the right.

    This issue reqeusts to do that same thing, matching the modification made by that major user.

  • Reported: C2MS 1.0 — Thu, 16 Feb 2023 15:53 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Move to a later release

    This will take some thought, so moving beyond the tight-timelines of 1.1.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Create CMD-MNEMONIC Field in Command Request Message

  • Key: C2MS11-88
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the Command Request Message, the Binary "CMD-DATA" message contains the packet/fram/CLTU, etc, for all CMD-FORMAT types. However, if the CMD-FORMAT type is MNEMONIC this doesn't make as much sense.

    Suggestion here is to create a new field in Command Request Message, "CMD-MNEMONIC" as type STRING to hold the human-readable MNEMONIC for command lookup if the CMD-FORMAT is of type MNEMONIC.

    In this way, both CMD-DATA and CMD-MNEMONIC would be Dependent fields, with usage based on the contents of CMD-FORMAT.

    RTF proposed (Burlingame, 2022) to do a second message type for MNE types, with 0-n parameters, each parameter specifying a type. Mike to create proposal text.

  • Reported: C2MS 1.0 — Tue, 7 Jun 2022 12:54 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    propose a new message type for MNE with Req/Resp, but deferred to 1.2

    We will want do to do a second message type for MNE types, with 0-n parameters, each parameter specifying a type. Mike to create proposal text.

    However, this is being deferred to after 1.1.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Remove Superfluous Fields from Header and Envelope

  • Key: C2MS11-184
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Many fields in the C2MS Header (which have of necessity also been put in the C2MS Envelope) should be evaluated for change or removal in the next major release. Change to be made in both C2MS Message and C2MS Envelope. Examples:

    • ROLE should be renamed COMPONENT-ROLE to avoid confusion with user role (authorization).
    • USER-NAME should be removed. This seems to be only debug info and does not have anything to do with authentication/authorization. The new fields SENDER-IDENTITY and SENDER-ACCESS in the envelope provide that.
    • FACILITY/NODE/PROCESS-ID/CONNECTION-ID are candidates for removal. These seem only valuable for debugging. Debug info doesn't belong in a standard, IMO.
    • CONNECTION-ID should be removed. This is definitely only valuable for debugging.
    • MW-INFO - no idea why this is there. Probably need a use case or example of what this is used for, but it doesn't seem to belong.
  • Reported: C2MS 1.0 — Sun, 23 Jul 2023 15:30 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to next major release

    This should be done, but needs to be in a major release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Command Echo Not Provided Message

  • Key: C2MS11-138
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    We have already added a CMD-ECHO boolean to the Command Request Message in C2MS11-87. However, there is a possible scenario where just because we asked for one, there is no way for one to be delivered.

    According to C2MS11-87, the field is an attempt to "Indicate if an ECHO should be sent at any configured point(s) along the ground chain as the command is transmitted."

    The question of this issue is around what to do if the back-end system is not capable of or is not configured to send an Echo. In that case, there would quietly be no echo at all in spite of setting that flag to true. Gerry has brought up that perhaps we need a message type that is "unable to echo" or use the CMD ECHO message with a value of "here's your echo, but we aren't able to collect any information".

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 19:46 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Move to a later release

    This will require some analysis, it's not urgent enough for 1.1's short timeline.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Use Semantic Versioning for Version Number of Messages

  • Key: C2MS11-190
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    This is one for C2MS 2.0. Capturing it here, because this is the only avenue to enter issues at present.

    Instead of a F32 for version number, which then uses a year, like 2024.0, we should change this to a formatted string that uses Semantic Versioning, with a string that looks like the following:

    MAJOR.MINOR.PATCH

    Examples: "2.0.0", "2.1.1"

    Note that this means changing the base type and the meaning of the current version numbers.

    Note, too, that this shouldn't simply be type STRING, but should be something like VERSION-STR with the format defined by C2MS.

    Also, consider getting rid of the separate header version and message content version. This is just something to bring up to the group.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:53 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Reconsider Oneshot in MVAL Request/Response

  • Key: C2MS11-151
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.

    This is described in Mnemonic Value Request Message as:
    "The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously."

    and

    Mnemonic Value Response Message:
    "For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."

    However, in a significant way, these statements conflict with the next line:
    "For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."

    In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).

    The effect of this is that the MVAL Req/Resp works in a primary subscription-based manner or in a different manner when specifying ONESHOT.

    With this in place the MVAL Req/Resp sometimes follow the Request/Response Message Exchange Patter, and other times follow the Request/Response/Publish MEP. In fact, figure 8-19 Mnemonic Value Message Sequence Diagram illustrates the Request/Response/Publish MEP. It is not valid for the Request/Response MEP. No example of the Request/Response MEP is shown for this message.

    Furthermore, some fields are handled specially depending on which MEP is used. For example, it is stated in the spec that when using ONESHOT, the following fields are ignored in the Request:
    • PUBLISH-RATE
    • DURATION
    • MNEMONIC.n.CRITERIA
    • MNEMONIC.n.SAMPLE-RATE

    Meanwhile, in the Reponse, RESPONSE-STATUS field values 3 and 4, likely only apply to ONESHOT, while 1 likely only applies to non-ONESHOT. requests.

    This odd dual-purposing of these messages was all likely done at some point out of convenience of overloading existing messages rather than creating new messages that would have been a more coherent design.

    It has the effect, for a 'Start' of the consumer needing to read both the MVAL Return message for data and then a series of MVAL data message, rather than simply reading MVAL data messages.

    In order to remove this overload, I suggest one of the following:

    1 - deprecating ONESHOT and related fields in those messages and creating a new Message Type for retrieving current values. These could be called Mnemonic Current Value Request Message and Mnemonic Current Value Response Message.

    2 - removing the value fields from the Response Message above, then simply convert the ONESHOT to a form of Request/Response/Publish MEP in which only one publish happens, and then the subscription ends. Subscription termination is already part of the spec, because of DURATION. The way this would work is the requestor sends a request message marked for ONESHOT, the service sends a response message, the service sends a single Mnemonic Value Data Message, the subscription is terminated. In this way, Mvals are only communicated in one message: Mval Data Message, easing the burden for handling two message types.

    In a certain sense, I like the first option better, because it addresses the need to get current values using dedicated messages. However, the second approach is a much smaller change and represents a solution that is FAR more straight-forward than the way it is implemented today.

  • Reported: C2MS 1.0 — Thu, 23 Mar 2023 13:01 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    move to a later release

    This should be considered in a later release, maybe 2.0.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Add a section describing expected use

  • Key: C2MS11-189
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    This is for 1.2, but have to enter it in 1.1 as that is the only current jira project. I expect it to be deferred, but think it should be done in 1.2.

    There is frequently confusion about how C2MS should be used. Normal use patterns are not described in the C2MS document, and this would be useful to add as a guide to users. This is especially true when C2MS is used in an enterprise environment, because common interpretation is critical.

    The idea is to communicate context for how C2MS has been created and how it is expected to be used.

    This could be in the form of a section called "System Architecture", "Guidance", "User Guide", or something like that.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:36 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to 1.2

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages

  • Key: C2MS11-173
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The text for MVAL and related messages doesn't explain or give examples of how to specify for example an array or record – for example a BATV[1] or something more complicated like: SBUS.STATUS.PFRAME[27].STACK_DEPTH.

    Any text addressing this should also discuss the XTCE repeat concept which the author of this issue believes today is handled by NUM-OF-SAMPLES.

  • Reported: C2MS 1.0 — Wed, 12 Jul 2023 19:02 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Remove the Req/Resp/Pub MEP

  • Key: C2MS11-192
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS2.0, we need to revisit the Req/Resp/Pub MEP, as is the same with MVAL Req, followed by an MVAL Resp, followed by an indefinite number and duration of MVAL Data Messages.

    This should really be either a standard Pub-Sub construct or should just be a simple req/response.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 20:23 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Replace simple service REQ/RESP

  • Key: C2MS11-170
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Replace simple service REQ/RESP and deprecate current simple service messages.

    Numerous issues are present with the current Simple Service REQ/RESP Messages. These include:

    • Destination Component is overloaded with two different meanings, depending on use.
    • Using Destination Component for SERVICE-NAME essentially requires the mission to establish a naming convention to separate SERVICE-NAME from DESTINATION-COMPONENT strings in order to tell the difference between them.
    • The Request can include a SERVICE-GROUP to further the SERVICE-NAME, sort of like namespacing, but this SERVICE-GROUP is not included in the Response message, which means that if needed in the Request, it is not possible to correctly correlate a Response to a Request.
    • The paradigm does not include a publish MEP natively, so at some point in the past, GMSEC/C2MS declared that a Request Message could be used to publish information, completely outside the Req/Resp MEP.
    • Current usage is to submit a request and then to have the response message indicate either the DESTINATION-COMPONENT of the original requestor or, alternately, the SERVICE-NAME associated with the original request. In keeping with other response messages, it should probably be just the DESTINATION-COMPONENT. It doesn't really need to have the option to use SERVICE-NAME, because the requestor is known. It also creates an odd and confusing alternate use, where in the current mode, the DESTINATION-COMPONENT is the requestor, but the SERVICE-NAME is related to the provider.

    Together, this makes the Simple Service Messages hopelessly tangled. The effort here is to start from scratch, deprecate the existing messages and move forward with something more workable.

    In this there are two factors that need consideration:

    • The Simple Service (and its replacement) should be intended for emerging services that go online in an existing domain, but that have not yet been able to establish their own set of dedicated C2MS-derived messages. It should not be the case that services live forever on this Simple Service (or replacement) mechanism.
    • The C2MS Messages themselves, perhaps in 2.0? should have a mechanism for extension without having to define new messages types. In other words, a service provider should be able to create a C2MS message that is simply expanded by what the service provider needs. If this can be accomplished, the Simple Service Paradigm is greatly aided, either by providing an easier path to offload the temporary use of Simple Service, or even by obviating the need for Simple Service.
  • Reported: C2MS 1.0 — Tue, 11 Jul 2023 14:51 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    This issue is important to work on, but doesn't fit in the timeframe of C2MS 1.1.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency

  • Key: C2MS11-177
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some fields and message elements that should be required are listed as optional. For example, in the Telemetry CCSDS Packet Message, ME SCID was added in 1.1, so had to me marked optional, but it should be required. APID already existed in that message as a Message Element, but not as a field, so whereas the ME is required, the field had to be made optional (for backward compatibility).

    Additionally, in section 6.2.2 Format of C2MS Subject Names, there is a description that says, "If an element is required but not applicable for that mission or to that type of message, the publisher inserts “FILL” (no quotes) for that element." However, this should be cleaned up. If a field is required it should be required, if not, then it should not be required. Need a run through the messages to see how this can be improved.

  • Reported: C2MS 1.0 — Sun, 16 Jul 2023 21:35 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Do this in the next major release

    This should be done, but in the next major release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

At Next Major Revision: Order MEs and Fields Consistently

  • Key: C2MS11-176
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some Message Elements and Fields are in different order from message to message. The fields are just a listing so not as important, but the MEs are order-dependent. One example of how this is an issue is that the Telemetry CCSDS Packet Message added a new ME, but this had to go to the end (ME6) because of backward compatibility. This creates a strange ordering with VCID, APID, Collection Point, SCID. This is just one example, but the need is to evaluate all the MEs and fields and see if any need to be moved to make messages more uniform in structure.

    Additionally, there are cases where some MEs have been removed between 1.0 and 1.x, leaving "not used"/"FILL" in the corresponding positions of MEs and these need cleaning up.

  • Reported: C2MS 1.0 — Sun, 16 Jul 2023 21:29 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Next Major Release

    This should be done, but can't be done until the next major release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Deprecate fields duplicated between C2MS Messages and the Message Envelope

  • Key: C2MS11-182
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    With the advent of the C2MS Message Envelope, some tracking or meta-data fields exist in both the new Message Envelope and in the already-existing C2MS Message. For now, it is the case that we want to leave fields in the C2MS message and encourage migration toward Message Envelope usage. In a follow-on release, the duplicated fields should be deprecated in the C2MS Message.

  • Reported: C2MS 1.0 — Sat, 22 Jul 2023 20:27 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Plan on doing this in 1.2

    This needs to be done, but should wait at least one release cycle.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Revisit Tracking Fields

  • Key: C2MS11-200
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS 1.0, there is no indicator whether a tracking field (special fields in the Message Header and Heartbeat Messages) is required, optional or dependent. As such, in C2MS 1.1, we are marking these all optional, except for Heartbeat.SUBSCRIPTION.n.SUBJECT.PATTERN, which is being marked as dependent (required if NUM-OF-SUBSCRIPTIONS is > 0).

    These should all be evaluated for R/O/D. One special case is HEARTBEAT.NUM-OF-SUBSCRIPTIONS. Normally, this should be required, because of C2MS11-135. However, in discussion for C2MS11-187, we went back to optional for this field. The rationale for this is that because it is a tracking field and therefore reserved for use by the PSM, rather than the generator of the message, it is difficult to understand what it means for a tracking field to be required. This reflects a shortcoming of the current C2MS documentation where it's not very clear what it means for a field to be a tracking field.

    Finally, there are some tracking fields that should be considered for removal, such as CONNECTION-ID, MW-INFO, and USER from the Message Header. These fields seem useful for debugging, but not operations.

    With the context stated above, the following need to be addressed in a future revision of C2MS:

    • Revisit which tracking fields should remain and deprecate the others.
        • As part of this, note that outside the Message Header, the only C2MS message that defines tracking fields is the Heartbeat Message. Do these belong? It just seems strange.
    • Determine R/O/D (required/optional/dependent) for each tracking field. Note that in an OMG meeting in Jan, 2024, broad-brushing it, it appeared that UNIQUE-ID and PUBLISH-TIME in the Message Header and NUM-OF-SUBSCRIPTIONS in the Heartbeat could be required, and the others optional in the Message Header.
    • Document the expected use for these tracking fields, including:
        • What the expected population of tracking fields is by both the Message Sender and the underlying PSM. (example, many of these are set as part of the GMSEC API and are supposed to be left alone before invoking the API in the one PSM that we currently have, but this is inner-workings knowledge and not clearly specified in C2MS).
        • What the expected use of these tracking fields, if any, is by a Message Recipient. For example, are these stripped off by the PSM before delivery? That would be symmetrical if the PSM populates the fields, but no mention of this exists in the current documentation. Some fields may be handled differently from others... for example UNIQUE-ID makes sense, but is the PSM really going to deliver CONNECTION-ID to the Message Recipient?
        • What does it mean if a tracking field is required? If only the PSM sets them, this would mean that a message would have to be created without a required field and then handed to the PSM, which is required to populate it.... this all needs clarity in the documentation.
  • Reported: C2MS 1.0 — Fri, 12 Jan 2024 22:17 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consider Deprecating and Later Removing Resource Message

  • Key: C2MS11-199
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Resource Message stated objective is to enable publishing "computer performance data" via a defined C2MS message. However, using C2MS messages to monitor CPU load, memory utilization, and network port status seems wholly out of scope for satellite command and control. This provides what is essentially a rudimentary mechanism for resource monitoring, which could easily be better accomplished through industry standard mechanisms completely outside of C2MS.

    In C2MS11-2, we removed CPU and memory related data from the Heartbeat Message. It makes sense to completely remove the Resource Message (via deprecation) for the same reason.

  • Reported: C2MS 1.0 — Fri, 12 Jan 2024 21:43 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Re-evaluate Optional Boolean Fields

  • Key: C2MS11-204
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some message fields of type Boolean are listed as optional. This has a pretty ambiguous meaning for a boolean, which if present, is always True or False.

    For one non-exhaustive example, some messages include a FINAL-MESSAGE boolean field that is optional. What does it mean when not present? It could be inferred that it is equivalent to False, but it could also be inferred that this is ignored when there is only one message, which would be the same as True.

    We need to go through all these usages individually and decide if these should be required, rather than optional.

  • Reported: C2MS 1.0 — Thu, 18 Jan 2024 21:04 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

mnemonic.n.sample.m.quality seems to be wrong type

  • Key: C2MS11-209
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the messages where it exists, mnemonic.n.sample.m.quality is of type Boolean, with False meaning Good Quality and True meaning Questionable Quality. This just seems wrong. Probably should be a U16 with 1 = good and 0 = questionable.

  • Reported: C2MS 1.0 — Fri, 26 Jan 2024 00:18 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    This may be a rework of these fields, so likely needs to be in a 2.0 release, but at a minimum, we don't have time to rework in 1.1.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Non-sensical Description for PROD-MSGS-TO-SEND

  • Key: C2MS11-208
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In Product Response Message, PROD-MSGS-TO-SEND field is an unsigned type, with a stated minimum "value" of 0+, but says in the description text the following:

    A value of “-1” can be used to indicate “Unknown”.

    Should probably find a different way to indicate unknown, such as not including this optional field in the message.

  • Reported: C2MS 1.0 — Wed, 24 Jan 2024 21:55 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Look into this and resolve in a release after C2MS 1.1.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Inconsistent Optional/Required Fields

  • Key: C2MS11-207
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The MVAL Response and MVAL Data messages both can contain individual MVALs. But in one, certain MVAL fields are required, while in other they are not. These need to be made consistent.

    Note that this applies to AMVAL Response and AMVAL Data messages as well.

  • Reported: C2MS 1.0 — Wed, 24 Jan 2024 21:51 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Do this analysis and modification, if any, in a future release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Normalize Headers and Text in the new DB Query Messages

  • Key: C2MS11-212
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the already-approved C2MS11-45, we added DB Query Messages. However, this issue did not include a text description for each message, which is common for all other C2MS Messages.

    Specifically, the new sections 8.14.1 and 8.14.2 need a description in order to be consistent with other C2MS Messages.

    Additionally, some of the subsection headers, table and figure titles don't conform to usage in the remainder of the document.

  • Reported: C2MS 1.0 — Thu, 1 Feb 2024 14:21 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Revisit DB Query in 1.2

    With C2MS11-45, we had intended to add DB Query messages to C2MS 1.1. However, late in the cycle for 1.1, it was determined that the messages added as part of that issue were not ready to be included in C2MS. This issue, then captures some changes that were to be included as adaptations to C2MS11-45 as part of 1.1, but are now to be deferred to later.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Consolidate Navigation Data Messages

  • Key: C2MS11-242
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The various Navigation Data Messages are nearly identical. They should be consolidated into a hierarchy that defines a Navigation Data Message base class and then let the others derive from it for better model structure. The Tracking Data Message has a few extra fields. Otherwise, everything is identical across all messages except for some type values.

    I thought about doing this when I was updating the model in 1.1, but would have also had to update the chapter text and didn't have time for all that in 1.1.

  • Reported: C2MS 1.0 — Mon, 15 Apr 2024 18:12 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    do this in a later release

    do this in a later release, probably 1.2

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model

  • Key: C2MS11-221
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There are many 'classes' in the model (because that's what is in the message) for Mnemonic, frequently with different values. Same probably true of Sample and others. It would be great if these structs in the messages and classes in the model were better reused so that we don't have two different items both called "Mnemonic".

    This issue sort of harkens back to when we had things like "Required Fields" in each message in the model, with no relationship to each other.

  • Reported: C2MS 1.0 — Tue, 6 Feb 2024 18:41 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    For when we do a restructure of C2MS.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Rework Log Message

  • Key: C2MS11-240
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Log Message in 1.0 is vague in the sense of what it is supposed to be used for. Is it an application-level log (similar to Log4j or is it an event alerting mechanism for ground and/or satellite events. It might be useful to split it into application logging vs ground or satellite alerting. Need to analyze its intended and current use to the extent possible and recommend a way forward that clearly demarcates event alerts from logging.

  • Reported: C2MS 1.0 — Sun, 14 Apr 2024 23:36 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    This analysis and proposed update should be undertaken in C2MS 1.2.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Lack of Required Fields in Sub-elements

  • Key: C2MS11-225
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    We have a number of cases where there is a listing of something, like Files in Product Message. Although Num-of-files is required, nothing in the file itself is required.

    Should review these and decide if any of these are dependent, and therefore required for each File.

    Note that this is true in many other cases, need to find them all and come up with a plan for each.

  • Reported: C2MS 1.0 — Sun, 7 Apr 2024 22:57 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    This is work that should be done in a future release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

AMVAL Value Response Doesn't Mirror MVAL Value Response Message

  • Key: C2MS11-210
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    MVAL and AMVAL seem pretty close in most respects, but MVAL Response Message has many fields that are not present in AMVAL Response Message. Probably just need to do some analysis regarding comparative usages and fields to determine if it is correct as-is and if not, add the missing fields to AMVAL Resp.

  • Reported: C2MS 1.0 — Fri, 26 Jan 2024 00:20 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Do this analysis and modification in a later release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Required or Optional for MNEMONIC Status on Data Messages

  • Key: C2MS11-236
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In Mnemonic Value Data Message and Archive Mnemonic Value Data Message, the MNEMONIC.n.STATUS is Optional. Need to consider if it should be required for each MNEMONIC in the data message.

  • Reported: C2MS 1.0 — Wed, 10 Apr 2024 16:25 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Defer analysis and rework, if any, to a future release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Need Review/Documented Explanation of NUM-OF-PROD-SUBTYPE-SUBCATEGORIES

  • Key: C2MS11-218
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The purpose NUM-OF-PROD-SUBTYPE-SUBCATEGORIES in several messages is not clear and needs to be reviewed and either removed or expanded upon. Note that this is called NUM-OF-PRODUCT-SUBTYPES in C2MS 1.0, but the explanations are simply preserved from 1.0 into 1.1 where the field was renamed, so this issue persists. One interesting aspect of this is that these subtype subcategories are represented in the subject of the Product Message ME5 and ME6, and all other messages that have it refer to this Subject construct.

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 17:42 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Review and update text explanations (or remove the fields) in a later release.

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message

  • Key: C2MS11-250
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    TLM Processed Frame Message currently requires 1+ NUM-OF-MNEMONICS, which makes sense, except that "Search" is a valid status for FRAMESYNC-STATUS. If that status is Search, it doesn't seem possible for there to be MNEMONICS... yet, if there are no MNEMNOICS, because FRAMESYNC-STATUS is Search, then why would there be a TLM Processed Frame Message?

    Need to do some analysis on this and decide how to handle this conundrum in the document. Should 0+ be the value of NUM-OF-MNEMONICS, or should 1=Search not be a valid FRAMESYNC-STATUS, and either way, this needs to be explained to the user of this message.

    Finally, does FRAMESYNC-STATUS even belong in this "Processed Frame" message? This might have been a long-ago copy-paste error. A frame synch status of 'Verify' is used typically to say that the processing component has the frame but is looking for the next framesync marker after which it moves to 'Lock' state, and will keep everything flowing, while 'Check' means that after processing some frames in 'Lock' state, it's now trying to locate the framesync marker again (like short frame, for example). Either way, it just seems (to me) that we would only produce "Processed Frames" if the FRAMESYNC-STATUS is 'Lock'. There may be exceptional cases where a component is asked to produce MNEMONICS even under the 'Verify' or 'Check' states, but this would be rare, and error prone. So, maybe just getting rid of 'Search' would be OK-ish, but again, just need to re-evaluate this one.

  • Reported: C2MS 1.0 — Mon, 22 Apr 2024 00:52 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Do this later

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Undo Addition of DB Query Messages in 1.1

  • Key: C2MS11-244
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS11-45, approved in Ballot #10, the C2MS11 RTF added two new DB Query messages to C2MS 1.1. However, late in the 1.1 cycle, it was determined that these new messages are inadequate at the present time and need significant rework. The decision was made by the author of the DB Query messages to remove these from 1.1 and resubmit updated versions in a later release (1.2).

    Therefore this issue is intended to undo the effect of C2MS11-45, so that those changes are not included in 1.1.

    Note related issue (that was added to capture some of, but not all, of the updates needed) C2MS11-212.

    An attached word doc includes markup text that was intended to augment the previously-approved C2MS11-45. This is simply included to aid recreation of a resolution issue in the future 1.2.

    Two other attachments contain the originally-approved text for the spec. These should all be combined and reworked.

  • Reported: C2MS 1.0 — Tue, 16 Apr 2024 21:29 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT
  • Attachments:

Improve Example Text for Publish Rate

  • Key: C2MS11-251
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In section 8.8.1.3 Mnemonic Value Request Message Contents, there is a kind of odd example paragraph under the explanation of PUBLISH-RATE, that states: "For example, the data provider may know that it is limited to an output rate of 1 megabyte per second. If it is currently near its maximum output rate and after calculating the additional load of the request it would exceed that rate, the data provider may reject the Mnemonic Value Request with a "Failed Completion" status in the RESPONSE-STATUS field, and an optional status of "Unable to meet demand" in the RETURN-VALUE field."

    This should probably be placed elsewhere (under a different heading in the same area) and possibly reworded, as an example of not being able to meet the request, instead of an example of PUBLISH-RATE.

    The issue is that PUBLISH-RATE is described, then a caveat is given, then an example of the caveat. It winds up confusing as an example of PUBLISH-RATE.

  • Reported: C2MS 1.0 — Thu, 25 Apr 2024 14:11 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Do this later

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Align TLM Terms

  • Key: C2MS11-253
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    This is probably one for 2.0...

    Message subtypes include the following that need to be address, possibly reworked/renamed:

    • TLMPKT that should be renamed TLMCCSDSPKT
    • TLMFRAME (already deprecated).
    • TLMCCSDSCADUFRAME (new in 1.1 and OK)
    • TLMCCSDSTRANSFERFRAME (new in 1.1 and OK)
    • TLMTDM that probably should be renamed TLMTDMFRAME

    Additionally, there is an enumerated value CCSDSPKT in Replay Telemetry Data Request Message and CCSDSPACKET in Command Request Message and Command Echo Message. These two should be make the same name.

  • Reported: C2MS 1.0 — Tue, 7 May 2024 17:34 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    defer to a later 2.0 release

    Defer

  • Updated: Mon, 16 Sep 2024 14:18 GMT

What to do when Priority isn't Specified

  • Key: C2MS11-248
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Priority is an optional field on a couple of messages. We need to do some analysis regarding what it means if Priority isn't specified, and consider making textual guidance in the document.

    Affected messages:

    • Directive Request Message
    • Simple Service Request Message
  • Reported: C2MS 1.0 — Mon, 22 Apr 2024 00:24 GMT
  • Disposition: Deferred — C2MS 1.1b1
  • Disposition Summary:

    Defer to a later release

    Do this in 1.1

  • Updated: Mon, 16 Sep 2024 14:18 GMT

Create examples of use of the profile

  • Key: CSRM11-3
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Originally the first versions of CSRM had examples. However, when the spec was reduced to a profile, the examples were removed. Because of some of the changes, not all examples are viable, so it is proposed we create new examples. Dave Kaslow also requested that the examples be categorized as a simplified and expert use of the profile to aid adoption by students.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Disposition: Resolved — CSRM 1.1b1
  • Disposition Summary:

    Add mention of Educational examples

    We have updated and feel that the CSRM is good enough to include, with the specification as educational attachments. We also need to change the text of the specification to mention the availability of MDZIP and XMI versions.

    Attached are example versions of the CSRM as ZIP collections in both MDZIP and XMI formats. I will attach a version with the latest version of XMI as part of the release.

  • Updated: Mon, 25 Mar 2024 14:22 GMT
  • Attachments:

Icons for profile

  • Key: CSRM11-1
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The original icons used for stereotypes in the profile were drafts and need to be replaced with better versions. The icons also need to be delivered as SVG.

    The document does not currently show these icons, so diagrams need to be updated or an appendix added to the icons.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Disposition: Resolved — CSRM 1.1b1
  • Disposition Summary:

    Icons supplied as educational attachment for use by implementors

    Add the following paragraph to section 2, Conformance.

    The profile of this version contains icons for most of the stereotypes. These icons are to be considered educational examples that may be replaced with implementation-specific versions. As an aid to implementers, a collection of Scalable Vector Graphic (SVG) files used for the current icons in the profile (currently embedded as encoded SVG) are included as an educational attachment that may be used as a starting point for implementers to create implementation-specific icons.

  • Updated: Mon, 25 Mar 2024 14:22 GMT

Add constraints to aid in correctness of profile useage

  • Key: CSRM11-2
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Constraints should be added to aid in the creating of correct models. For example, an MoE needs to be related to a moeRequirement which in turn is refined by a moeSpecification.

    In addition, by categorization and content of warings and error of the constraints, we could add hints for new users of minimal and advanced concepts.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Disposition: Closed; Out Of Scope — CSRM 1.1b1
  • Disposition Summary:

    Defer tp RTF 1.2

    Need a better set of actual uses of the model to create and test constraints. Defer to 1.2 RTF.

  • Updated: Mon, 25 Mar 2024 14:22 GMT

Recommended Additions

  • Key: CSRM11-4
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    To make the case for updating CSRM stereotypes. Once agreement is reached, updates to the CSRM Specification will be developed.
    This is a big deal and needs lots of discussion.

    Figures 1 lists CSRM element stereotypes. Black font denotes current baseline as captured in the normative CSRM Profile. Blue font denotes recommended additions.

    Figure 2 lists requirement elements related properties that are part of the SysML language.

    Figure 3 illustrates one of many ways to establish relationships between the mission stakeholders, requirements, technical measures, and use cases stereotypes. These stereotypes are denoted by italicized font in Figure 1.
    The relationships are captured in the element specifications and are displayed and maintained in diagrams and tables as shown in Figure 1.
    Object Constraint Language

    There has been discussion about codifying the allowable relationships using Object Constraint Language (OCL). OCL is a declarative language describing rules applying to Unified Modeling Language (UML) models. For example, a refine relationship can exist between a requirement. and any other model element, whereas a derive relationship can only exist between requirements.

    That could be done founded on the examples in Figure 3. This would be of limited benefit. A mission team will be using the stereotypes and relationships best suited to their mission and the stereotypes in Figure 3 are very limited as compared to Figure 1.

    A case could be made to established relationships for the stereotypes in Figure 1. But that is out-of-Scope for the SSWG CSRM effort.

    An Issue that Needs Resolution.

    The intent of defining addition stereotypes as shown in Figure 1 is to provide stereotypes for a variety of mission architectures. However, several of the stereotypes are identified as CubeSat stereotypes. But they are not unique to CubeSats. The only thing that makes a model a CubeSat model is the incorporation of a CubeSat form factor such as the Cal Poly CubeSat Design Specification.

    My recommendation is to rename the stereotypes as show in Table 1 below.

    Table 1. Renaming of Stereotypes (Proposed name changes from Figure 1)
    CubeSatRequirement SatelliteRequirement
    CubeSatSubsystemRequirement SatelliteSubsystemRequirement
    CubeSatComponentRequirement SatelliteComponentRequirement
    CubeSatUseCase SatelliteUseCase
    CubeSatSubsystemUseCase SatelliteSubsystemUseCase

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Disposition: Closed; Out Of Scope — CSRM 1.1b1
  • Disposition Summary:

    Close because this was against beta

    This issue is no longer relevant. Should have been closed in FTF instead of deferred.

  • Updated: Mon, 25 Mar 2024 14:22 GMT
  • Attachments:

Incorrect constructor referenced in Fixed description

  • Key: CPP1117-8
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    This chapter says:

    The Fixed(std::string&) constructor converts a string representation of a fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

    But there is no constructor that accepts a non-const std::string&, the text should say

    The Fixed(const std::string&) constructor converts a string representation of a
    fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 15:56 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Correct the spec text to match the source code

    Add the missing "const" as described in the issue.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Typo

  • Key: CPP1117-9
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Double "to to" in the first sentence:

    IDL bitset types are mapped to to C++ structs that meet the C++11 requirements for aggregate initialization.

    Should be

    IDL bitset types are mapped to C++ structs that meet the C++11 requirements for aggregate initialization.

  • Reported: CPP11 1.6b1 — Mon, 17 Jul 2023 08:54 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Fix typo

    As per issue description

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing annotation mapping

  • Key: CPP1117-13
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec should mention how the IDL4-mentioned annotations impact the mapping, I think the spec should list at least @value, @default_literal, @default, @range @min @max @bit_bound @external

    See IDL4 to CPP and the IDL4 spec itself

  • Reported: CPP11 1.6b1 — Fri, 4 Aug 2023 07:01 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add mappings for some more IDL 4 Standardized Annotations

    New mappings for @value, @default_literal, @default, and @bit_bound – in each case drawing from uses in the beta IDL4-to-C++ mapping and/or XTypes.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing description related to union member modifier

  • Key: CPP1117-7
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    In the specification an addition was made about the default argument when the union member has multiple legal discriminator values:

    Union members associated with the "default" label and those associated with multiple labels may have multiple legal discriminator values. For these members, the modifiers (those that return void) have a second parameter which has the discriminator's type. This parameter has a default argument. For members associated with multiple labels, the value of the default argument is the value of the case label that appears first in IDL. For members associated with the default label, the value of the default argument is an implementation-defined value that selects the member.

    There is nothing in the text that describes what happens when a discriminator value is passed which doesn't belong to the member, this is implicitly in the example code further down "u.obj(a, 2)", but this should be explicit in the text also, passing a not allowed discriminator should result in a BAD_PARAM exception

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 09:20 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add description of error handling for 2-parameter union modifier functions

    To be consistent with the existing parts of the spec, make it clear that invalid parameters result in a BAD_PARAM exception.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Change struct VariableExt constructor

  • Key: CPP1117-11
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Instead of `VariableExt(const Variable&, bool);` it should be `VariableExt(Variable, bool);` so that in the implementation we can use std::move, this is as all complex types are passed into the constructor of a struct

  • Reported: CPP11 1.6b1 — Wed, 2 Aug 2023 08:42 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    In example code, function signature of constructors is non-normative

    In section 6.31.3 make it clear that the specific types of the constructor parameters (if they use pass by value or pass by const-reference) is up to the implementation.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Improve bitmask mapping

  • Key: CPP1117-10
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bitmask mapping is very basic, it doesn't give any type safety or more modern API. The spec should be improved, the <X>Bits type should be removed, only one type should be used. Also when there are multiple bitmasks with the same bitfield name they could result in a name clash. Maybe map to a enum class and add the operators ~,|,^,& for the enum class as inline operations to modify the enum class as a bitmask. At that moment the Bit type can be removed.

    When time permits I will make a proof of concept for TAOX11

  • Reported: CPP11 1.6b1 — Mon, 31 Jul 2023 06:55 GMT
  • Disposition: Deferred — CPP11 1.7
  • Disposition Summary:

    Defer breaking change to the bitmask mapping

    The existing mapping in IDL-to-C++11 is based on DDS XTypes where it has been in a formal standard for a number of years.
    There are certainly reasons to have a mapping that makes better use of the C++ type system, but this would come at a cost in terms of divergence from OMG precedent.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Add standardized annotation to override the IDL map to std::map mapping

  • Key: CPP1117-1
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    For some use cases it would be more efficient to map a IDL map to a std::unordered_map (see https://en.cppreference.com/w/cpp/container/unordered_map), maybe standardize an annotation which can be used to override the mapping to std::map to the type as specified by the annotation?

  • Reported: CPP11 1.7 — Wed, 17 Aug 2022 08:55 GMT
  • Disposition: Deferred — CPP11 1.7
  • Disposition Summary:

    Defer

    Other languages have similar issues like using TreeMap or HashMap in Java.

    Defer resolution on this until standard annotation can be provided in the IDL 4 spec or the IDL Working Group has a common approach to use across language mappings.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Typo in example

  • Key: CPP1117-2
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    using M2 = IDL::bounded_map<std::string, T, 20;

    should be

    using M2 = IDL::bounded_map<std::string, T, 20>;

  • Reported: CPP11 1.7 — Wed, 20 Oct 2021 06:24 GMT
  • Disposition: Closed; No Change — CPP11 1.7
  • Disposition Summary:

    Typo is not in base document

    ptc/21-11-02 doesn't have this typo

  • Updated: Tue, 9 Jan 2024 19:49 GMT

6.7.8 Argument Passing Considerations should refer to "Basic Data Types" not "primitive"

  • Key: CPP1117-3
  • Status: closed  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    The section says:

    "For all primitive types, enums, and
    reference types, an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
    passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

    This is the only use of "primitive types" in the spec. "Basic Data Types" should be preferred. Would suggest:

    "For all Basic Data Types [link/ref to 6.6 Mapping for Basic Data Types], enums [link/ref to 6.9 Mapping for Enums], and
    reference types [link/ref to 6.7.1 Reference Types], an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
    passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

  • Reported: CPP11 1.7 — Fri, 10 Dec 2021 15:02 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Update text in Arg Passing to refer to Basic Data Types

    Update as specified in parent issue

  • Updated: Tue, 9 Jan 2024 19:49 GMT

bit_bound

  • Key: CPP1117-14
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec defines the type trait bit_bound as `std::integral_constant<uint32_t, b>`, but as bit_bound is maximal of 64, this could be `std::integral_constant<uint8_t, b>`

  • Reported: CPP11 1.6b1 — Mon, 7 Aug 2023 07:29 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Update type used for bit_bound in bit mask traits

    The integral_constant template from the C++ standard library should be instantiated with uint8_t instead of uint32_t

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Add bit_bound/underlying_type for enum traits

  • Key: CPP1117-12
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bit_bound annotation can be applied to the enum, so the bit_bound and underlying_type traits should also be added to the enum

  • Reported: CPP11 1.6b1 — Sat, 5 Aug 2023 14:47 GMT
  • Disposition: Duplicate or Merged — CPP11 1.7
  • Disposition Summary:

    Add type traits for enums

    Including this in the resolution to CPP1117-13.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Rename the new composites ontology to roles and compositions

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    After additional review, RTF members suggested that a better name for the ontology would be roles and compositions. Other feedback identified a typo, suggested that we add the notion of independent identity in the definition of composition for clarification, and remove the functional axiom on the property isPlayedBy, which might overly constrain its utility.

  • Reported: COMMONS 1.0b2 — Thu, 17 Aug 2023 20:56 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Rename the new composites ontology and revise definitions per additional RTF discussion

    The resolution to this issue depends on the resolution to COMMONS-11-4, adding a new Composites ontology, and revises the results of that resolution, including renaming and moving the sections in the specification as well as renaming the ontology, per further RTF discussion.

    Note that the change barred version of the document does not reflect the original sections (i.e., adding and then deleting 8.5, for ease of managing the resulting document in LibreOffice.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Several OMG and external projects need a pattern for representing compositions

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    In pharmaceuticals and other industries, products are often composed of other things. The 'recipe' for manufacturing a product includes various ingredients, which are roles that substances, components. or other things take on in the context of that product.

    Further, there are cases where the composition of some product is context specific. Product documentation may be jurisdictionally defined due to regulatory constraints, for example. The representation of some ingredients in certain pharmaceutical products, including the way these elements are described on packaging, is jurisdiction specific, even thought the product itself has exactly the same composition via exactly the same manufacturing processes world wide.

    A general pattern for this kind of composition would be quite useful for a number of domain areas and is a good candidate for inclusions in the Commons library.

  • Reported: COMMONS 1.0b2 — Sat, 5 Aug 2023 21:14 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Augment the Commons library with an ontology defining compositions and roles

    Introduce a new ontology representing composition and role as classes and relationships between them for use in addressing the requirements outlined in the issue description

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Need to add start and end time and explicit time period in Commons

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Currently we have an explicit date period, but not explicit time period, which is needed for PPMN, among other processes. This is also required for Robotics.

  • Reported: COMMONS 1.0b2 — Fri, 14 Jul 2023 18:05 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Added a number of properties to the Dates and Times ontology related to start and end time

    The resolution to this issue adds two classes to the ontology: TimePeriod and ExplicitTimePeriod, and a number of properties, including a general purpose hasTime property as well as hasDateOfIssuance, hasEnd, hasEndTime, hasStart, hasStartTime, and hasTimePeriod, per request of two task forces, Robotics Service Ontology (RoSO) and Pedigree and Provenance Metamodel and Notation (PPMN).

    Note: in the text revisions, under item 5, there are no sections labeled i and n because solitaire turned them into odd emojis.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Several OMG task forces have a need for a common ontology for quantities and units

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    A preliminary quantities and units ontology was developed for FIBO for use with commodities. Several other groups at OMG need this ontology, as do external users of the Commons library. The ontology should be mappable to the SysML v2 library so that we can generate the individuals in that library for use in knowledge graph applications. It should also be consistent, to the degree possible, with the latest changes to the VIM, with BIPM requirements, and with ISO 11240 for use in the pharmaceutical domain.

    There is a dependency in the quantities and units ontology on a small documents ontology, to provide the reference documentation for certain units. This ontology is relatively small, however, and can easily be mapped to other ontologies defining documents.

  • Reported: COMMONS 1.0b2 — Fri, 16 Jun 2023 20:52 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Introduce two new ontologies, a documents ontology and a quantities and units ontology that depends on it

    Several OMG task forces and other external industry groups in pharmaceuticals, manufacturing, finance and others, there is a widely recognized need for a well-designed ontology supporting quantities and units. While a number of ontologies exist that claim to fill this gap, few are well designed and some have moved away from OWL in order to meet other demands. Within OMG, the healthcare, finance, robotics, and retail task forces all have requirements for a quantities and units ontology. Given the latest advances in SysML, such an ontology should align well with the library of quantities and units in SysML v2 so that the equivalent reference content in RDF/OWL can be automatically generated.

    The ontologies included in this resolution fill that need, although they are limited to scalar quantities at this juncture. The RTF intends to create a new arrays / vectors / tensors ontology and a companion quantities and units extension to support tensor and vector quantities over the coming months. Most applications do not need that level of sophistication however, and thus the RTF has determined that submission of the scalar version should happen sooner than later to fulfill requirements of other task forces.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Several OMG and external projects need a pattern for representing parties, the roles that they play and situations in which they are involved in

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    A situation is a complex, typically time-bound, setting, state of being, or relationship that is relatively stable for some period of time. An ontology defining such situations, including the complex property chains that link the actors and undergoers in such situations to the roles that they play is essential in finance, pharma, retail, robotics, and many other industries.

    A well-tested ontology that describes these patterns would be a useful addition to the Commons library. In addition, this ontology (and the new composition ontology on which it depends) is urgently needed for the Robotics Service Ontology (RoSO), whose planned revised submission is planned for September 2023.

    Note that the resolution of this issue requires the ontology added under COMMONS-11-4.

  • Reported: COMMONS 1.0b2 — Sat, 5 Aug 2023 22:53 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Augment the Commons library with an ontology defining parties and situations

    The parties and situations ontology defines concepts including agent and agent role, party and party role, situation - which is a state of affairs / reified relationship that holds for some period of time, and other related roles and relations that are commonly required across many domains.

    Note that the resolution to this issue depends on resolutions to COMMONS-11-1, COMMONS-11-3, and COMMONS-11-8 have been applied first, and that sections have been renumbered and organized alphabetically by ontology name prior to applying this resolution.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Need an ontology representing multidimensional arrays

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is needed for representation of tensor and vector quantities for the quantities and units ontology, and for representation of certain machine learning algorithms, among other requirements.

  • Reported: COMMONS 1.0b2 — Fri, 14 Jul 2023 18:03 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    Development of an ontology for Arrays, Tensors and Vectors

    This issue will take more time and thoughtful effort to resolve, and the task force agreed to defer it as well as this aspect of quantities and units to the next revision.The new quantities and units ontology supports scalar quantities, which is what most users, including robotics, retail, and finance, need. The tensor and vector aspects are primarily used in specific disciplines of engineering.

  • Updated: Wed, 20 Dec 2023 15:27 GMT

xmi profile


Use @key instead of @Key


The properties in the collections ontology are confusing to users

  • Key: COMMONS-12
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Users are confused as to whether they need comprises or hasConstituent or hasMember or hasPart.

    In order to address this, we need to augment some of the properties with disjointness, such as between comprises and hasPart. Then we need to make clear that membership involves discrete elements and constituency may or may not involve discrete elements. hasConstituent can be used with cardinality constraints whereas hasPart cannot be due to OWL reasoning constraints.

  • Reported: Commons 1.0b1 — Fri, 12 Aug 2022 19:13 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Clarify the use of several properties in the Collections ontology

    Clarify the definition of properties related to inclusion, including when to use comprises vs. hasPart (which is transitive), and hasConstituent vs. hasMember (whose elements are discrete and countable), making hasConstituent and hasMember disjoint in the Collections ontology

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Need to be able to indicate whether or not something can only be classified by a single classifier from a specific scheme

  • Key: COMMONS-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is not expressible in OWL, easily. One option would be to create a boolean that indicates this is the case, which perhaps a rule engine for data quality, or sparql, or a SHACL shape could then test. What you really want to be able to say is that 'is classified by' can only have one value from a given classification scheme when applied to something.

    This is a change to the Classfiers ontology, which may impact that section of the specification.

  • Reported: Commons 1.0a1 — Fri, 5 Aug 2022 18:37 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Supporting this feature should be done in a user ontology, but we provide a flag for those that might need it

    The simplest way to say that only one member of a specific classification scheme can be used to classify something is to add a restriction to the concept in question. Something like

    ClassifiedItem isClassifiedBy max 1 SpecificClassifier

    where the classified item is the concept in a user ontology being classified, and specific classifier is the one from the scheme that applies. For example, suppose that the classification scheme / controlled vocabulary includes the individual paint colors that are available to customize a vehicle for purchase for some model/model year and manufacturer. A vehicle manufactured by that manufacturer that is of that model and model year can only have one color from that scheme, i.e.,

    Vehicle isClassifiedBy exactly 1 VehicleColor

    where the VehicleColor is a member of that specific scheme.

    We could complicate the classifiers ontology to add several new classes, such as ClassifiedThing, UniquelyClassifiedThing, SpecificClassificationScheme (or ExclusiveClassificationScheme) and SpecificClassifer, where the SpecificClassifier is a member of the ExclusiveClassificationScheme, where all members of the scheme are disjoint/different from one another, and where a UniquelyClassifiedThing can be classified by max 1 SpecificClassifier. The FTF agreed that this would overly complicate the ontology, though, and that commons users can add the restriction on the thing that they are classifying as needed without requiring the "clutter".

    We will provide a boolean flag, called isExclusive to allow users that need it to add such a flag to their classification scheme.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

The format of the tables throughout the specification needs improvement

  • Key: COMMONS-3
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    (1) Different fonts: I can understand why you are using a fixed-width font in the metadata tables to identify the right-hand columns as the actual values of the terms listed in the left column.
    In the Properties tables I suggest to use a sans-serif font (e.g. Ariel) for the Axioms column to clearly distinguish the Axioms from the Annotations
    (2) The Properties tables are too cramped. It is not clear what the purpose of the name repetitions in parentheses in the Name column is. However, these repetitions take up unnecessarily much horizontal space. This could be solved by always moving them in a line under the bold camel-case name. The recovered horizontal space should be then allocated to the Axioms column, which is way too narrow. Many axioms are mutilated by inappropriate line breaks.
    (3) Since you are not using vertical separators (which is ok), you should extend the gutter whitespace between columns to improve readability, in particular between Annotation and Axiom columns.
    (4) Clause 6 should contain good explanations regarding the fonts and the table layouts [and the parenthesis names].

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:45 GMT
  • Disposition: Closed; No Change — COMMONS 1.0
  • Disposition Summary:

    Most formatting issues raised in AB review were addressed via errata

    We added gutter space and separators to make the tables easier to read in a revision via errata prior to AB approval and final voting at the June meeting. Moving labels (which are the human-readable rather than camel case names) to the middle column is something that we can do once we agree on a format for ontology generation in LaTeX in a future version of this specification. The format we used for the Commons is the same as recent FIBO, LCC, and other ontology specifications until such time as we are able to automate generation of the material.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

There needs to be an additional usage note on Text in the TextDatatype ontology with a stronger warning

  • Key: COMMONS-18
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This datatype is quite useful but most free and some commercial OWL tools don't support (1) custom datatypes in OWL, and (2) rdf:langString. We need to provide a stronger warning to users who might want to extend Text with the inherent risk in doing so depending on their application and tool infrastructure.

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 22:51 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Add a note to Text that warns people not to use it under certain circumstances

    The current scope note doesn't go far enough to warn potential users of some of the issues with this datatype. A stronger usage note should be added in addition to the current scope note.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the abbreviation for the AboutCommons "make file

  • Key: COMMONS-16
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The AboutCommons.rdf file is a convenience file that can be used to load all of the ontologies into ontology editors such as Protege, triple stores, and other applications. The namespace prefix for this ontology does not conform to the others in terms of its structure, however. It is currently "abt-cmns" and should be "cmns-abt".

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 02:25 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Revise the namespace prefix for AboutCommons to be "cmns-abt"

    The namespace prefix in the beta 1 specification for this ontology is "abt-cmns", which is different in structure from all the others, which are of the form "cmns-"<ontology prefix>.

    Fixing this requires a 1 line change to the specification and a revision to the AboutCommons ontology, attached.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

CodeSet should be a subclass of arrangement

  • Key: COMMONS-19
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is a gap, as classification scheme and identification scheme are both already subclasses of arrangement.

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 23:10 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Make CodeSet a kind of Arrangement

    CodeSets are essentially controlled vocabularies that conform to some scheme and that are collections. Every code set is both an arrangement and a collection in other words. Thus, code set should be a subclass of arrangement.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the version IRI for all of the Commons ontologies to agree for finalization purposes

  • Key: COMMONS-14
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This issue involves updating the version IRIs for all of the ontologies to be 20220801 for finalization

  • Reported: Commons 1.0a1 — Sat, 20 Aug 2022 00:19 GMT
  • Disposition: Closed; No Change — COMMONS 1.0
  • Disposition Summary:

    The IRI changes can be made editorially thus no vote is required.

    After discussion within members of the FTF we determined that we can make the changes to the version IRIs editorially and a vote on this issue is not required.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

The constraint on a classifier that says it must classify something is too restrictive

  • Key: COMMONS-9
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Classification schemes should be able to be defined without necessarily referring to all of the things that they classify. For example, one should be able to encode industry classifiers without having to know exactly what those classifiers apply to. Thus, the constraint that a classifier classifies some thing should be loosened to be min 0, meaning 'may'.

    This issue affects the Classifiers ontology, only

  • Reported: Commons 1.0a1 — Thu, 14 Jul 2022 21:44 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Loosen the restriction on Classifier from at least one to min 0

    The original restriction on the property classifies on Classifier was too restrictive, i.e., it required all classifiers to reference at least one thing that they classify. For ontologies that represent things like industry classifiers such as NAICS, the "schema", or t-box, that represents those classifiers should not be required to include them. Typically such reference data would be in a separate controlled vocabulary, or a-box, i.e. a separate ontology that is only imported when in use.

    The solution is to change a someValuesFrom owl:Thing restriction to a minCardinality 0 restriction on the property classifies on the class, Classifier.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

The terms and definitions section of the Commons Ontology Library is incomplete

  • Key: COMMONS-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This section defines ontology, but none of the other key terms that are present in any of the ontologies. It should be revised to incorporate at least some of the basic definitions that are present in the ontology files.

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:40 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Augment the terms and definitions clause with a few additional high-level definitions

    Add definitions for several top-level terms used in the ontologies that may be useful for specification users.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

The use of rdfs:isDefinedBy is inconsistent in the annotation vocabulary

  • Key: COMMONS-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    In the annotation vocabulary machine-readable file, the use of rdfs:isDefinedBy is inconsistent. For reified elements for Dublin Core annotations, we use the Qname / abbreviated IRI to link to the source. For reified elements for the Simple Knowledge Organization System (SKOS), we use the full IRI. And, we have not included rdfs:isDefinedBy for any of our local annotation declarations.

    The latter is probably ok, but we should normalize the references for Dublin Core and SKOS to all use the same approach.

    This issue was raised by Richard Beatch in his AB review.

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:25 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Normalize the use of rdfs:isDefinedBy for Dublin Core and SKOS declarations

    In the case of Dublin Core annotations in the annotation vocabulary, we used rdfs:isDefinedBy to refer to the same property in the Dublin Core namespace using an abbreviated IRI followed by the local name. In the case of SKOS annotations we used rdfs:isDefinedBy to reference the entire ontology IRI for SKOS.

    The fix to this issue is to revise all of the rdfs:isDefinedBy annotations for the Dublin Core annotations to use the same approach as we did for SKOS, i.e., to refer to the ontology using the IRI for Dublin Core.

    This revision affects the machine-readable AnnotationVocabulary ontology only, and has no impact on the specification document.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the definition of designation to better align with the latest version of ISO 1087

  • Key: COMMONS-26
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The definitions of designation and name need some additional work and don't align with the ISO definitions as well as they should. The definition of designation needs clarification and the definition of name should state that it is not linguistically neutral per its usage in the standard. Also, even if we clarify name, we probably don't want it to be disjoint with identifier as it is now (needs further discussion).

  • Reported: Commons 1.0b1 — Thu, 1 Sep 2022 16:34 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Clarification of the distinctions between kinds of designators

    1. Clarified the definition of designation, denotes, and name, and better aligned them with ISO 704 / ISO 1087 in the Designations ontology
    2. Augmented the definition of a contextual name to require a context in the Contextual Designations ontology
    3. Further clarified the distinction between an identifier, contextual identifer and code / code set by adding notes, making identfies a functional property, and adding the notion of a contextual identification scheme in the Identifiers, Contextual Identifiers, and Codes and Code Sets ontologies

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Some of the diagrams in Clause 8 are difficult to read


Some of the commons ontologies include double spaces in annotations

  • Key: COMMONS-6
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    These double 'blanks' cause minor hygiene issues when using the EDM Council's test harness and should be addressed.

  • Reported: Commons 1.0a1 — Sun, 10 Jul 2022 00:16 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Eliminate double 'spaces' in several commons ontologies

    This is a trivial update but cleans up an issue identified through the EDM Council's hygiene test environment.

    Revisions impact the machine-readable files only, and include:

    1. Elimination of a double space in the scope note on CombinedDateTime in the Dates and Times ontology
    2. Elimination of double spaces in the abstract and a note on Designation in the Designators ontology
    3. Elimination of a double space in a note on ClassificationScheme in the Classifiers ontology
    4. Elimination of a double space in a note on ContextualName in the ContextualDesignators ontology

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Examples are needed to help explain to Commons users how to use the ontologies

  • Key: COMMONS-5
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    There are no examples in the specification itself, which are needed to assist both library implementers and users of the ontologies.

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 19:03 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Add examples

    The attached document includes an informative annex representing examples that we hope will be helpful to implementers of the Commons library.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:
    • Annex B.odt 25 kB (application/vnd.oasis.opendocument.text)

Ordering of user exception and return values

  • Legacy Issue Number: 16
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Standard uuid for interfaces (COM/CORBA Part A)

  • Legacy Issue Number: 680
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

CORBA section 11 struct PortableGroup::GroupInfo

  • Legacy Issue Number: 12512
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

What should Automation View accept in bounded sequences?

  • Legacy Issue Number: 683
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 4.1.12: DICORBA TypeCode::kind

  • Legacy Issue Number: 685
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Standard ProgramId

  • Legacy Issue Number: 684
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 4.1.18.5 enum should be named CORBA_CompletionStatus

  • Legacy Issue Number: 681
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

VB cannot handle array out-parameters

  • Legacy Issue Number: 682
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Add CORBATCKind to end of enum list

  • Legacy Issue Number: 687
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Return value type of DICORBATypeCode::member_type should be changed

  • Legacy Issue Number: 688
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 690
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

uuid for DForeignException has an extra 0

  • Legacy Issue Number: 689
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Remove EX_repositoryID readonly property from IForeignException

  • Legacy Issue Number: 686
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

boundary violations should cause View to propagate DISP_E_OVERFLOW

  • Legacy Issue Number: 695
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 697
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-129, section 4.1.17.1: retval attribute

  • Legacy Issue Number: 696
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

INSTANCE_Clone does not need an in-parameter

  • Legacy Issue Number: 698
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

ODL is erroneous

  • Legacy Issue Number: 691
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 692
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 2-30: There is a label "Examples", but no examples

  • Legacy Issue Number: 693
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-109, section 4.1.5.3: editorial

  • Legacy Issue Number: 694
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

"Safe" keyword identifier issue

  • Legacy Issue Number: 1251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Above rules seem to imply that the
    "safe" keyword identifier can only occur before the first scoped name in the
    <value_parent_spec>, whereas I think the actual intent is that it can only
    occur before a non-abstract value type, of which there is at most one in the
    list, although it need not be the first. Since this can"t be expressed in the
    rules exactly, I would simply amend the rule to be:

    <value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>

    { "," [ <safe_token> ] <scoped_name> }

    *

    and simply express the semantic restriction in the text. There already is a
    brief mention of the semantics of the "safe" keyword in section 5.3.2.5
    "Substitutability Issues". Perhaps another sentence or two would help clarify
    the intended usage.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Which TypeCode operations apply to Value and ValueBox?

  • Legacy Issue Number: 1140
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
    to Value and ValueBox types. For example, are id(), name(), member_name(),
    member_count(), member_type(), etc. valid for Value and ValueBox or should they
    raise BadKind exception?

    I don"t see why they should not be valid. Normative text should be added in
    CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
    the IDL should also be updated.

  • Reported: CORBA 2.2 — Thu, 9 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.5 Interface repository (02)

  • Legacy Issue Number: 1065
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Can Value type inherit from Value Box type?

  • Legacy Issue Number: 1252
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Can value type inherit from Value Box type

  • Legacy Issue Number: 1055
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
    described as been syntactic sugar for a Value type)? If so, what is the
    implicit name of the Value Box"s single data member?

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Automation View should generate HRESULT DISP_E_TYPEMISMATCH

  • Legacy Issue Number: 700
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.5 Interface repository (01)

  • Legacy Issue Number: 1064
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Dispatch versions of DCORBAObject and DORBObject

  • Legacy Issue Number: 699
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

describe_value() operation issue

  • Legacy Issue Number: 1258
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Missing member_kind and member_tc

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

    Summary: Missing member_kind and member_tc

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 1256
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

New lexical type - Keyword Identifie

  • Legacy Issue Number: 1253
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that
    "new keyword identifiers should only be added such that the resulting grammar is
    still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for
    the newly introduced keyword identifiers in many cases.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.3.3: can value inherit from a boxed value?

  • Legacy Issue Number: 1255
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Value type ansd Value Box"s single data member name

  • Legacy Issue Number: 1257
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Semantics of computing the hash code..

  • Legacy Issue Number: 1267
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Concrete value class

  • Legacy Issue Number: 1268
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.6.3 Hashing Algorythm

  • Legacy Issue Number: 1266
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Repository Id (02)

  • Legacy Issue Number: 1264
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.6.2 Repository Id

  • Legacy Issue Number: 1263
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Repository Id (03)

  • Legacy Issue Number: 1265
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Type code issue

  • Legacy Issue Number: 1261
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Clarify the hash code algorithm

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

    Summary: Clarify the hash code algorithm

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.10 Value Factories

  • Legacy Issue Number: 1273
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7 C++ Language mapping

  • Legacy Issue Number: 1271
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Java mapping example and C++ mapping example

  • Legacy Issue Number: 1272
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Why is ValueBase a value and not a native type?

  • Legacy Issue Number: 1274
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.6 Reference Counting Mix-in Classes

  • Legacy Issue Number: 1270
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.5 ValueBase and Reference Counting

  • Legacy Issue Number: 1269
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

p 5-50 2nd paragraph of 5.6.2.1

  • Legacy Issue Number: 1283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing
    ORBs, version inconsistencies between, eg, structs, may already corrupt
    memory. The difference now is that preservation of values sharing
    could make matters worse. It would be great to have this issue better
    explained.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Editorial: p 5-50

  • Legacy Issue Number: 1282
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Suggested changes (to section 5.4.1 of orbos/98-01-18) are

  • Legacy Issue Number: 1280
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:

    1. Remove the ``;"" from the end of the definition of <value>. (It"s
    in the modified <definition>.)

    2. Remove [ <supports_token> <scoped_name>

    { ``,"" <scoped_name> }

    * ]
    from the <value_inheritance_spec> non-terminal move it to a new
    non-terminal, <value_supports_spec>.

    3. Change the definitions of <value_abs_dcl> and <value_header>,
    replacing [ <value_inheritance_spec> ] by [ <value_inheritance
    _spec ] [ <value_supports_spec> ].

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 1275
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

p 5-24, first paragraph of 5.3.1.3

  • Legacy Issue Number: 1279
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Editorial page 8-107

  • Legacy Issue Number: 1277
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Keyword identifiers (01)

  • Legacy Issue Number: 1310
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.
    1) First and foremost, the addition of keyword identifiers changes
    the IDL grammar into a context-sensitive grammar, which are known to
    be notoriously difficult to parse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Can public modifier be applied to value operations?

  • Legacy Issue Number: 1284
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Reconcile RMI/IIOP upcall and helper class

  • Legacy Issue Number: 1286
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Reconcile RMI/IIOP upcall and helper class

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

No portable way to obtain list of type safe repository IDs

  • Legacy Issue Number: 1352
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real
    type, going up (the derivation hierarchy) to, and including if appropriate the formal type". Currently, there is no portable way to obtain the list of type safe repository ID"s
    from within the marshaling engine in order to be marshaled on-the-wire properly.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword Identifiers(03)

  • Legacy Issue Number: 1312
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    3) It allows IDL specifications that, while not unparseable, are
    highly ambiguous, especially to a human reader. For example, Jeff
    recently posted answers on how the following is to be parsed, but
    there is no way that someone reading the OBV spec would be able to
    figure out the rules he gave:

    interface public

    { ... };
    interface custom { ... }

    ;
    value safe

    { ... };

    value foo : safe { ... }

    ; // Is this legal or an error?
    value foo2 : safe safe

    { ... }

    ; // What about this?
    value foo3

    { public x; // Is this legal or an error? public public y; // What about this? custom value(); // Is this a valid operation or a syntax error? }

    ;

    While all of these constructs can all be parsed using the appropriate
    number of look-ahead tokens (by the way, the grammar is not LALR(1)
    as the OBV Spec suggests), it is hard to read and even harder to
    parse correctly. Many IDL compilers still fail to properly implement
    the name lookup rules in the existing CORBA specification, and adding
    keyword identifiers will only make that situation much worse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword identifiers (04)

  • Legacy Issue Number: 1313
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    4) Finally, the keyword identifier approach gives the impression that
    IDL extensions can be made at no cost, which is simply not true.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword identifiers (02)

  • Legacy Issue Number: 1311
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:

    interface ValueBase {};
    struct S

    { ValueBase v; }

    ;

    This is ambiguous because the compiler cannot know whether the type
    of struct member "v" refers to the ValueBase interface or the
    ValueBase keyword identifier.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV "chunking"

  • Legacy Issue Number: 1522
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 1419
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Can "public" mofifier be applied to value operations?

  • Legacy Issue Number: 1421
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Typo on page 8-107 of OBV specification

  • Legacy Issue Number: 1420
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Narrowing from abstract interfaces

  • Legacy Issue Number: 1382
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It has been pointed out to me that we have no way of narrowing
    from abstract interfaces to non-abstract interfaces and value
    classes. In Java, the helper"s narrow method has a signature of
    org.omg.CORBA.Object, so it cannot take an abstract interface
    type. In C++, the generated classes for abstract interfaces
    have an _narrow method with the right signature (taking an
    AbstractBase_ptr), but generated classes for values and regular
    interfaces don"t have such a method. It seems like we would
    need to add overloaded narrow methods in all these places to
    make this work as envisaged in (for example) numbered paragraph
    3 of section 8.3.

  • Reported: CORBA 2.2 — Mon, 18 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private

  • Legacy Issue Number: 1380
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.3.1.2 says that non-public data members should be mapped
    so that "the private part of the state is only accessible to the
    implementation code and the marshaling routines."

    Section 6.3.1 says that non-public data members are mapped to
    private instance variables.

    The problem is that the Java marshaling routines are in the Helper
    class, which cannot see private instance variables in the value class.

    The proposed solution is to modify the Java mapping to map the default
    IDL state to the default (package visibility) Java state instead of
    private.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Marshaling engine issue

  • Legacy Issue Number: 1353
  • Status: closed  
  • 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 it"s formal parameter. Now supposet we wish to pass a Derived value type. When marshaling the list of repository id"s, the marshaling engine has no notion of the formal type of the parameter , thus it
    does not know how many safe repository id"s it needs to marshal.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV spec inefficient for dending large number of small objects

  • Legacy Issue Number: 1614
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Some explicit semantics seem to be missing in section5.8.6

  • Legacy Issue Number: 1615
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Forward declaration of value boxes

  • Legacy Issue Number: 1624
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCodes for values

  • Legacy Issue Number: 1625
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV C++ problem with "supports"

  • Legacy Issue Number: 1539
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCodes defined in section 5.8.2

  • Legacy Issue Number: 1527
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 1528
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CDR Streams

  • Legacy Issue Number: 1523
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

P 5-44: use of base type

  • Legacy Issue Number: 1697
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type. (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind. However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value. This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this. The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase. An alternate could be to not go the PrimitiveDef route and use a different approach. Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase. This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface). This is less likely though because create_ValueBase would need to return a type. We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named. We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV TypeCode parameters wrong

  • Legacy Issue Number: 1676
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

No typecodes for abstract interfaces

  • Legacy Issue Number: 1719
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Abstract Interface issue (write_Abstract/read_Abstract)(01)

  • Legacy Issue Number: 1699
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. There are no write_Abstract and read_Abstract methods on
    DataInputCtream and DataInputStream. This looks like an oversight
    to me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Custom marshalling support for IDL fixed type

  • Legacy Issue Number: 1673
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Default constructor for Java values

  • Legacy Issue Number: 1654
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

C++ boxed value member clashes

  • Legacy Issue Number: 1674
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Boxed values need extension to write_Value call

  • Legacy Issue Number: 1650
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Status of hashed repository IDs

  • Legacy Issue Number: 1817
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

"Tool" issue for IDL compilers too complex

  • Legacy Issue Number: 1932
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The current language mapping mixes both generated code with user
    written code in the same source file. This poses a very complex "tool"
    issue for IDL compilers which is unnecessarily complex.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ValueHelper Interface issue

  • Legacy Issue Number: 1934
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCode complexity for value types

  • Legacy Issue Number: 1726
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Memory Management for Value Factories Unspecified

  • Legacy Issue Number: 1748
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV init

  • Legacy Issue Number: 1816
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeBase interface uses undefined type

  • Legacy Issue Number: 1771
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue for Firewall RTF - HTTP tunnelling.

  • Legacy Issue Number: 2455
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.3.4 and elsewhere

  • Legacy Issue Number: 2584
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Title does not cover the use of SS7 as signaling transpor

  • Legacy Issue Number: 2583
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: Title does not cover the use of SS7 as signaling transport. This case is
    not a TC interworking.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

passthrough connection

  • Legacy Issue Number: 2261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy
    issue.

    In page 4-45, the spec says "It is possible to support pass-through through
    multiple proxies. For example if in the above example there was another
    proxy B2 between B and C, during processing the new_target operation from A,
    B can try to establish a pass-through connection to C via a call to
    new_target on B2. If this fails, due to NO_PERMISSION for example, B should
    fall back to try to connect through B2 using the NORMAL mode.".

    If the connection (B - B2) is NORMAL, the whole connection is not a
    PASSTHROUGH since the client will see the B2"s identity in the SSL session.
    Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION
    from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is
    what spec says), does this mean that it is possible that the client request
    a PASSTHROUGH connection but actually get a NORMAL connection?

  • Reported: CORBA 2.2 — Wed, 16 Dec 1998 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

issue with TCPfirewallMechanism

  • Legacy Issue Number: 2304
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue for Firewall RTF - Chapter 5 needs clarification

  • Legacy Issue Number: 2240
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The values of these tags need to be assigned

  • Legacy Issue Number: 1996
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Minimum CORBA and POA

  • Legacy Issue Number: 2676
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 4.2.1

  • Legacy Issue Number: 2591
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2586
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.5.1.1, item 3

  • Legacy Issue Number: 2588
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2589
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

It should be possible to have negative invoke ids

  • Legacy Issue Number: 2590
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It should be possible to have negative invoke ids.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.3.4 make factory creation operations conform to the IDL

  • Legacy Issue Number: 2585
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: make factory creation operations conform to the IDL style guide

    Proposed solution: change the capitalization and put in underscores between
    words

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 4.3.2.1 Title and text should be changed

  • Legacy Issue Number: 2595
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 4.7.1: RelativeRoundTripPolicy

  • Legacy Issue Number: 2596
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problem: Why is AssociationId a string?

  • Legacy Issue Number: 2592
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is a difference between the responder and initiator interfaces

  • Legacy Issue Number: 2594
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The current text for DialogFlowCtr is for outgoing only

  • Legacy Issue Number: 2593
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5.4.1

  • Legacy Issue Number: 2599
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2600
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: Fig. 27

  • Legacy Issue Number: 2601
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2597
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5.2 and other sub-sections

  • Legacy Issue Number: 2598
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-Directional GIOP: which connections may be used?

  • Legacy Issue Number: 2633
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 2.3

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

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

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Should SIOP version number start with 1.2?

  • Legacy Issue Number: 2603
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2605
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 6.2.2

  • Legacy Issue Number: 2604
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5

  • Legacy Issue Number: 2606
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2602
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall POA Policy does not control access

  • Legacy Issue Number: 2639
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

new_target

  • Legacy Issue Number: 2648
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

new_callback

  • Legacy Issue Number: 2651
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Traversal algorithm

  • Legacy Issue Number: 2641
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2634
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Outgoing local port in Bi-directional IIOP

  • Legacy Issue Number: 2638
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proxified object references

  • Legacy Issue Number: 2865
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Clarification is needed on the passing of credentials

  • Legacy Issue Number: 2867
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Reusing PASSTHRU

  • Legacy Issue Number: 2866
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How to obtain initial reference to the GIOPProxy object

  • Legacy Issue Number: 2864
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TcPdu User and Provider interfaces

  • Legacy Issue Number: 2919
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2917
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Specification Translation from ASN to IDL issue

  • Legacy Issue Number: 2918
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Traversal algorithm not sufficient

  • Legacy Issue Number: 2869
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    There may be some network topologies where the traversal
    algorithm is not sufficient for a firewall to find a server. This is due to
    an unstated assumption that all addresses within the outermost inbound
    firewall are addressable from the outermost inbound firewall. Consider for
    example the following topology:

    -----*Firewall
    B*-----Network B
    Internet -----Firewall A---------
    -----*Firewall
    C*-----Network C

    Service Network (DMZ)

    Assume that the addresses on the service network are
    globally routable addresses, Network B uses RFC 1597 addresses and Network C
    uses RFC 1597 addresses. This topology could be possible, say for a
    government agency that has sub-agencies that share some resources (service
    network) but maintain separately administrated networks. In this case the
    outermost inbound firewall for a server on Network B or C is Firewall A.
    However, when new target is invoked on Firewall A, it won"t know from the
    host address whether to open a connection to Firewall B or Firewall C.

    Proposed Solution:
    There are several possible solutions to this problem:
    1) Explicitly state the assumption described in the
    description section
    2) Mandate that implementations allow for the
    configuration of the next inbound firewalls
    3) Mandate that servers on Network B or C in such
    configurations use Firewall B or C as the outermost inbound firewall.

    There may be other solutions to this problem. These were
    the ones that immediately presented themselves.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problems with routing and/or traversal of firewalls.

  • Legacy Issue Number: 2868
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2916
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2915
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

BiDir GIOP Policy Clarification

  • Legacy Issue Number: 4115
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of PolicyType id

  • Legacy Issue Number: 3363
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allow GIOP 1.3 messages to be transported.

  • Legacy Issue Number: 3184
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing definition on security tags in the SIOP

  • Legacy Issue Number: 3314
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is currently no valuetype support in SIOP.

  • Legacy Issue Number: 3313
  • Status: closed  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:
  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

use of the SSN number in the 1988 TCAP version

  • Legacy Issue Number: 2982
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Discrepancy in the changes proposed to CSIIOP and CSI modules

  • Legacy Issue Number: 7167
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

GIOP version 2.0 issue

  • Legacy Issue Number: 7168
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bidirectional Policy insufficient for persistent objects

  • Legacy Issue Number: 6313
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Server Authentication

  • Legacy Issue Number: 6312
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

MAIN_THREAD_MODEL questions

  • Legacy Issue Number: 4155
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiate Session Message Orientation

  • Legacy Issue Number: 6284
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiation Session message is unwieldy

  • Legacy Issue Number: 6311
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Implications about BiDirIds

  • Legacy Issue Number: 7225
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

paragraph limits use of BiDirOfferContext

  • Legacy Issue Number: 7224
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiate Session Message Issues

  • Legacy Issue Number: 7202
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (05)

  • Legacy Issue Number: 7201
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (02)

  • Legacy Issue Number: 7198
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (03)

  • Legacy Issue Number: 7199
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (01)

  • Legacy Issue Number: 7197
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (04)

  • Legacy Issue Number: 7200
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

What BiDirIds shall be sent over what bidirectional connections?

  • Legacy Issue Number: 7312
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Interplay of Contexts allowed in NegotiateSession messages too ill-defined

  • Legacy Issue Number: 7311
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall FTF Issue: No ene-to-end security for firewall traversal

  • Legacy Issue Number: 7313
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Random BiDirIds can't be used for persistent POAs

  • Legacy Issue Number: 7310
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Connection over which BiDir offers are sent is unspecified

  • Legacy Issue Number: 7309
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Response to failed BiDir challenge is unclear

  • Legacy Issue Number: 7308
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall issue - Number of BiDirIds in a BiDirOffer

  • Legacy Issue Number: 7307
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous

  • Legacy Issue Number: 7353
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY

  • Legacy Issue Number: 7351
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-directional connections considered volatile at connection acceptor side

  • Legacy Issue Number: 7352
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

connection_complete field of the FirewallPathRespContext is under specified

  • Legacy Issue Number: 7317
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How many BI_DIR_GIOP_OFFER service contexts are allowed

  • Legacy Issue Number: 7318
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Targets of Export and Offer Policies incompletely specified

  • Legacy Issue Number: 7315
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Expected behavior of a non-conformant implementation

  • Legacy Issue Number: 7316
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Processing of NegotiateSession messages at various stages of connection set

  • Legacy Issue Number: 7314
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Multiple objects on a stream

  • Legacy Issue Number: 22
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Definition of stream portability

  • Legacy Issue Number: 21
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Lifecycle Key type definition

  • Legacy Issue Number: 18
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Stream contexts and internalization

  • Legacy Issue Number: 19
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Start and end of context tags

  • Legacy Issue Number: 20
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 7356
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Coordinator remembering LockCoordinator

  • Legacy Issue Number: 59
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 60
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Freeing of locks at the end of a transaction

  • Legacy Issue Number: 58
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Getting the thread ID in a non-transactional lock request

  • Legacy Issue Number: 57
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Communication failure issue

  • Legacy Issue Number: 56
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Timeout while locking

  • Legacy Issue Number: 47
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service

  • Legacy Issue Number: 476
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 473
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 472
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosGraphs::deep

  • Legacy Issue Number: 469
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Common format on stream

  • Legacy Issue Number: 466
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

performing a compound copy of relationship

  • Legacy Issue Number: 470
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 471
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Thu, 9 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Using local thread identification for concurrency

  • Legacy Issue Number: 61
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Internalizing roles-IDL optimization

  • Legacy Issue Number: 706
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Who is responsible for releasing locks in transaction?

  • Legacy Issue Number: 578
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Purpose of related LockSet

  • Legacy Issue Number: 576
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service (3)

  • Legacy Issue Number: 478
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Which model should ConcurrencyControl support?

  • Legacy Issue Number: 577
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service (2)

  • Legacy Issue Number: 477
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- finding index

  • Legacy Issue Number: 6
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Query Collection::Collection -- Sharing State

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

    Summary: How do IteratorObjs and CollectionObjs share state?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Circular References in CosStream and CosCompoundExternalization

  • Legacy Issue Number: 1401
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- membership scoping

  • Legacy Issue Number: 3
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- Adding multiple elements

  • Legacy Issue Number: 4
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Questions on CosQuery::QueryableCollection interfaces

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

    Summary: Clarifications on interfaces which support QueryableCollection.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- reset() exceptions

  • Legacy Issue Number: 10
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- keyed collections

  • Legacy Issue Number: 12
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- next_n()

  • Legacy Issue Number: 11
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- destroy methods

  • Legacy Issue Number: 9
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- Iterator Position Invalid

  • Legacy Issue Number: 7
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- iterator updating

  • Legacy Issue Number: 8
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Query language for operations

  • Legacy Issue Number: 83
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Definition of NULL in datafiles without NULL as a concept

  • Legacy Issue Number: 80
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Delegating iterator functionality to the RDBMS

  • Legacy Issue Number: 82
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Clarification request for section 11.1.5

  • Legacy Issue Number: 79
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

retrieve_element

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

    Summary: How does this operation work?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 78
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of MD5 on arguments

  • Legacy Issue Number: 23
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Updating information via query iterators

  • Legacy Issue Number: 69
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Inconsisten IDL in the Minimum CORBA chapter

  • Legacy Issue Number: 4216
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypedConsumerAdmin interface (4.9.2))

  • Legacy Issue Number: 961
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Correction of CORBA specification (page 18-51)

  • Legacy Issue Number: 3342
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

WWW Form output

  • Legacy Issue Number: 535
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

interface QueryEvaluator {

  • Legacy Issue Number: 575
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Malformed PropertyName

  • Legacy Issue Number: 284
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OQS relation to POS

  • Legacy Issue Number: 84
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

COM/CORBA keywords

  • Legacy Issue Number: 2009
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosExternaliazation Service (bug?)

  • Legacy Issue Number: 4188
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ObjectCreationError and Nofactory exceptions in Externilazition

  • Legacy Issue Number: 1293
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosConsurrencyControl service bug or not?

  • Legacy Issue Number: 3522
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Compiler being able to translate from OMG-IDL into ANSI

  • Legacy Issue Number: 184
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Unclear and possibly harmful consequences of mandatory annotation definitions

  • Legacy Issue Number: 19738
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 15.4.5.1 struct has to be updated

  • Legacy Issue Number: 12858
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this section says: // GIOP 1.0 struct LocateRequestHeader_1_0

    { // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }

    ; Anonymous types are deprecated so this struct has to be updated

  • Reported: CORBA 3.0.3 — Tue, 23 Sep 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Fixed Types in COM

  • Legacy Issue Number: 4507
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How does DynValue handle derived valuetypes?

  • Legacy Issue Number: 5467
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 5624
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

messaging router issue

  • Legacy Issue Number: 5621
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is a messaging router supposed to do if it receives multiple
    requests from a client with more than one type of QueueOrderingPolicy
    value? (Is this legal? Is it legal to have more than one QueueOrdering
    bit set in a single request?) How can it sort on priority, FIFO, and
    deadline simultaneously?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

valuetypes and local interfaces

  • Legacy Issue Number: 6318
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy

  • Legacy Issue Number: 6424
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA 3.02, page 11-25, section 11.3.6

  • Legacy Issue Number: 6899
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

module SendingContext

  • Legacy Issue Number: 7340
  • Status: closed  
  • Source: MetroApp Entertainment ( Keith Allyn Baker)
  • Summary:

    The CORBA specification has module SendingContext { //... interface CodeBase

    { //... CORBA::FullValueDescription meta(in CORBA::RepositoryId x); //... }

    ; //... }; but there is no CORBA::FullValueDescription defined in the specification, yet the supplied <SendingContext.idl> file declares module SendingContext { //... interface CodeBase

    { //... CORBA::ValueDef::FullValueDescription meta(in CORBA::RepositoryId x); //... }

    ; //... };

  • Reported: CORBA 3.0.3 — Sat, 15 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

rules for marshalling ValueBoxes

  • Legacy Issue Number: 5899
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

BNF changes

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

    BTW I think the twiddle is incomplete because it is not reflected
    in the BNF for Identifier. I think it is better if the BNF always
    reflects the ultimate specification of a language's lexical
    definition. Otherwise compiler writers are apt to miss the
    subtleties.
    I'll propose some BNF changes if others agree

  • Reported: CORBA 3.0.2 — Wed, 25 Jun 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problem with ServerRequestInterceptor::receive_request and DSI

  • Legacy Issue Number: 5895
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

restriction of where a valuetype chunk can end

  • Legacy Issue Number: 5892
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bad text in 22.6 mandates Routing for sendc/sendp

  • Legacy Issue Number: 5856
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is a sentence in the first paragraph of 22.6 that should be fixed:

    "The implementation of these methods must generate a method invocation
    as described in Section 22.14, Message Routing, on page 22-50."

    However, 22.2.5.3 allows asynchronous invocations to be delivered via
    synchronous protocols if the RoutingPolicy is ROUTE_NONE.

    This sentence should be changed to:

    "The implementation of these methods may generate a method invocation as
    described in Section 22.14, Message Routing, on page 22-50, depending
    on the effective RoutingPolicy for the invocation."

  • Reported: CORBA 3.0.2 — Tue, 11 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

What is the RSC when using a PersistentPoller

  • Legacy Issue Number: 5781
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is the RSC when
    > using a PersistentPoller? Since it is a valuetype that can be passed
    > from one process to another, the RSC obviously can't be the same in the
    > other process as at the original invocation point.
    >
    > Anybody have any bright ideas for this one? Should it be empty? A copy
    > of the TSC at the poll point? Change MessageRouting:PersistentRequest
    > to have an attribute that provides access to a copy of the RSC, and
    > PersistentRequestRouter::create_persistent_request to have the RSC as an
    > "in" argument?

  • Reported: CORBA 3.0.1 — Mon, 25 Nov 2002 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Messaging Routing Protocol is broken for GIOP 1.0 & 1.1

  • Legacy Issue Number: 5662
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Codec Interface Deficiencies

  • Legacy Issue Number: 7730
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 3, chapter 13.8, defines the Codec interface to encode
    arbitrary data values into CORBA::OctetSeq "blobs" and vice
    versa. This interface can be used, e.g., to supply and retrieve
    ServiceContext data using the PortableInterceptor interfaces.

    In practice, the Codec interface is also being used for data
    serialization, i.e., to store and retrieve arbitrary values in
    files or other databases.

    However, the interface is deficient in that it does not consider
    all possible variables that are needed for interoperability.
    It supports setting the CDR version that is to be used, but
    neglects byteorder and codeset settings.

    Consequently, the encoded values are platform-specific. If a
    value was encoded on a little-endian system, it will not decode,
    or worse, decode erroneously, on a big-endian system. The same
    caveats apply to codesets, e.g., when an ISO-8859-1 encoded
    blob is decoded using UTF-8 or Windows-1252.

    To support interoperability, the Codec interface needs to be
    extended.

    My recommendation is to extend the CodecFactory interface,
    so that it supports creating CDR version-, byteorder-, and
    codeset-specific Codec instances, either supplying user-
    provided values for each, or informing the user about chosen
    defaults.

    Example:

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct EncodingExt

    { EncodingFormat format; octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingExt enc) raises (UnknownEncoding); }

    ;
    };

    The create_codec_ext operation would create an appropriate
    Codec instance, if available; it will then set all "default"
    members of the EncodingExt structure to their actual values,
    so that the application can store this information along
    with any encoded values.

    One potential criticism of the above is that the encoding
    format's parameters depend on the encoding format. For example,
    there may be encoding formats that are byteorder-independent,
    or that consistently use UTF-32 for strings, thus not needing
    codeset parameters. Also, they may use wildly different
    versioning. So a "better" solution might involve passing
    the EncodingFormat, and an Any with a format-specific data
    type.

    That could look like:

    module GIOP {
    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct CDREncodingParameters

    { octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;
    };

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingFormat format, inout Any parameters) raises (UnknownEncoding); }

    ;
    };

    Once we have consensus on the approach, I will gladly volunteer
    to come up with a full set of editing instructions

  • Reported: CORBA 3.0.3 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

methods on the POA

  • Legacy Issue Number: 7890
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A lot of the methods on the POA which have USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER as policies don't describe in detail what should happen when one of these policies is set, but no default servant/servant manager is set. For example reference_to_servant, when USE_DEFAULT_SERVANT is set and default servant is registered we return the default servant, but what when no default servant is set, is then the ObjectNotActive the correct exception? Shouldn't this be something like a system exception (bad inv order, obj adapter or something like that?)

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add a typedef for the POAManager id

  • Legacy Issue Number: 7892
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Add a typedef for the POAManager id and use this throughout the spec for POAManager, POAManagerFactory and IORInterceptor add typedef string POAManagerId change in POAManager string get_id(); to POAManagerId get_id(); Or better (see other issue). readonly attribute POAManagerId the_id;

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

An extension of IOR to protect target objects Nature

  • Legacy Issue Number: 7592
  • Status: closed  
  • Source: Computer Science Department, National University of Defence Technology ( jack_nudt)
  • Summary:

    Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. ------------ ----------- | Client | Abstract IORs | Service | | application ---------------+ Proxy | | | | | ----------- --+ BS1's IORs | | | ------------------------- | | | BS2's IORs | | + ------------ | -------+ + BS3's IORs | Background | --------+ + | Server 1 | | Background | -------+ ---------- | Server 2 | | Background | ---------- | Server 2 | ----------- The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: AIOR = SP's regular IOR + logical name Logical name is uniquely corresponding to an IOR of an object running on background server. So the SP should set up the mapping before corresponding request comes, and map the logical name in the AIOR to the regular IOR of the target object at background server for a coming request. The structure of AIOR is compatible to regular IOR. Firstly let's have a look at the structure of regular IOR defined at page 13-15. Then we will discuss how to support AIOR based on existing IOR data structures and what interfaces and methods will be defined. module IOP { // IDL // Standard Protocol Profile tag values typedef unsigned long ProfileId; struct TaggedProfile

    { ProfileId tag; sequence <octet> profile_data; }

    ; typedef sequence <TaggedProfile> TaggedProfileSeq ; // an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR

    { string type_id; sequence <TaggedProfile> profiles; }

    ; // Standard way of representing multicomponent profiles. // This would be encapsulated in a TaggedProfile. typedef unsigned long ComponentId; struct TaggedComponent

    { ComponentId tag; sequence <octet> component_data; }

    ; typedef sequence<TaggedComponent> TaggedComponentSeq; }; CORBA specification defines 3 standard IOR profiles (at page 13-17): module IOP

    { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef sequence <TaggedComponent> MultipleComponentProfile; }

    ; The following are standard IOR components that can be included in TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, ESIOPs, or other protocols. An ORB must not drop these components from an existing IOR (at page 13-19). module IOP

    { const ComponentId TAG_ORB_TYPE = 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES = 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = 20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = 32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY = 37; const ComponentId TAG_INET_SEC_TRANS = 123; }

    ; The following additional components that can be used by other protocols are specified in the DCE ESIOP chapter of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP section (at page 13-19, 13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The following is the description of our proposed supplement to CORBA core specification. We add one component into module IOP: const ComponentId TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The TAG_AIOR_LOGICALNAME component has an associated value of type string encoded as a CDR encapsulation. We have not defined the interface of mapping logical names to regular IOR because now this function is local and its interoperability is not necessary. But if two or more SPs want to exchange their mapping items to provide more intelegent services, we may need to define the coresponding interfaces.

  • Reported: CORBA 3.0.3 — Thu, 15 Jul 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Mapping from -ORBxxx to Java properties does not work for -ORBInitRef

  • Legacy Issue Number: 6007
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The CORBA 3.0 spec adds the following note in Section 4.5.1: ORB Initialization.

    "Whenever an ORB_init argument of the form -ORBxxx is specified, it is understood that the argument may be represented in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx."

    The approach stated in the above note does not work for -ORBInitRef. For example, if you have
    -ORBInitRef NameService=URL,
    you cannot translate the above arguments into a property named "org.omg.CORBA.ORBInitRef" because there can be only one property of this name and there may be many different services. This issue was slightly cover by Issue 3643 (java-rtf), which was not resolved. This issue becomes obvious and important because the note added in the CORBA 3.0 spec.

    Proposed solution: Arguments like "-ORBInitRef id=url" should be equivalent to a property named "org.omg.CORBA.ORBInitRef.id" with value "url".

  • Reported: CORBA 3.0.2 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The POA state inactive is not used consistent.

  • Legacy Issue Number: 7955
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The POA state inactive is not used consistent. On several places it is called deactivated instead of inactive. For example in 11.3.8.2, in the transient bullet, it mentions: "Once the POA's POAManager enters the dactivated state". Chapter 11.3.2.1 describes clearly the states are: active, inactive, holding and discarding. I would propose to scan the complete spec for these incorrect POA Manager state.

  • Reported: CORBA 3.0.3 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA 3.0.3 ch. 3.4 OMG IDL Grammar

  • Legacy Issue Number: 7978
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The grammar definition for valuetype <state_member> via the rule
    <declarators> includes <complex_declarator>.

    It should be clarified whether valuetype state members are intended
    to include <array_declarator>.

    IMHO clarification is needed as state members are usually mapped
    to accessor methods in programming languages. If permissible,
    the accessor methods would return a complex type.

  • Reported: CORBA 3.0.3 — Wed, 15 Dec 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

argument of the set_servant call has a small typo

  • Legacy Issue Number: 7896
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The argument of the set_servant call has a small typo, it must be p_servant to match the full IDL spec some pages further

  • Reported: CORBA 3.0.3 — Tue, 2 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.3.13

  • Legacy Issue Number: 8221
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec describes respository_id which should be repository_id. Is on two places, in 4.3.14 and 4.3

  • Reported: CORBA 3.0.3 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

change in the POAManager

  • Legacy Issue Number: 7893
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I would propose to change in the POAManager the following: State get_state(); string get_id(); to readonly attribute State the_state; readonly attribute string the_id; The get method just hide the fact that this are readonly attributes

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue: CSIv2 Identity Assertion

  • Legacy Issue Number: 3907
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Polymorphic Valuetypes and the DII

  • Legacy Issue Number: 3674
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

DynValue & custom valuetypes

  • Legacy Issue Number: 3459
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Code Set Conversion on Operations

  • Legacy Issue Number: 8244
  • Status: closed  
  • Source: Motorola ( Gary Duzan)
  • Summary:

    The "operation" field in the RequestHeader_1_2 struct is a string,
    which implies that it should be subject to code set conversion. However,
    existing practice seem to be that it is not converted, and there are other
    factors which could make it difficult for implementations to convert it.
    In addition, since the operation name is based on IDL/ASCII, conversion
    doesn't necessarily make sense.

    The easiest remedy would be to specify this as an exception in the
    text of the spec. The "correct" remedy would probably be to change the
    operation field from "string" to "sequence<octet>". This could cause
    problems at some point, but it might not break too much since the CDR
    encodings are the same.

  • Reported: CORBA 3.0.3 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Potential deadlock with POA::deactivate_object()

  • Legacy Issue Number: 2772
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Custom Value Marshaling Issue

  • Legacy Issue Number: 3097
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Appendix A

  • Legacy Issue Number: 8230
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The overview of all system exceptions is missing several ones which seem to be availalble in http://www.omg.org/docs/omg/03-01-04 For example NO_IMPLEMENT_TABLE minor code 8 is missing

  • Reported: CORBA 3.0.3 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ForwardRequest is impossible to detect in clients

  • Legacy Issue Number: 5266
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    REQUIREMENT

    To be able to use interceptors, and in particular ForwardRequest, in a client to perform active, per-request, load-balancing.

    PROBLEM

    It is not possible to detect in an interceptor whether ForwardRequest has previously been thrown for the same client request. Thus it is possible for a client to go into an infinite loop throwing ForwardRequest.

    DISCUSSION

    The basic problem is that although for a single client request the request-scoped PICurrent is shared across across interceptor invocations - even when ForwardRequest is thrown - it is not possible to modify this information in an interceptor to indicate to a future invocation that the invocation has been seen. The two relevant parts of the spec here are:

    21.3.6.5

    For retries, depending on the policies in effect, a new request may or may not follow
    when a retry has been indicated. If a new request does follow, while this request is a
    new request, with respect to Interceptors, there is one point of correlation between the
    original request and the retry: because control has not returned to the client, the request
    scoped PortableInterceptor::Current for both the original request and the retrying
    request is the same (see Chapter 21, Portable Interceptors on page 21-32).

    21.4.2

    Before an invocation is made, PICurrent is obtained via a call to
    ORB::resolve_initial_references ("PICurrent")
    From within the interception points, the data on PICurrent that has moved from the
    thread scope to the request scope is available via the get_slot operation on the
    RequestInfo object. A PICurrent can still be obtained via
    resolve_initial_references, but that is the Interceptor's thread scope PICurrent.
    See section 21.4.4.4, Request Scope vs Thread Scope on page 21-36 for a detailed
    discussion of the scope of PICurrent.

    Thus modifications to the thread's PICurrent are lost on retries and modifications to the request's PICurrent are not possible.

    PROPOSED RESOLUTION

    I have made several different attempts at coming up with a portable way of solving this problem without changing the spec, but have failed. It seems to me that it really should be possible for the interceptor to know that a retry is in effect and I can think of a number of different solutions to this:

    1. add:
    void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    to RequestInfo. This would allow interceptors to transfer information between invokes of the same client request and thus a retry could be detected.

    2. Add a new function to RequestInfo to indicate that a forward is in operation. The minimalist fix here would be to allow forward_reference() to be accessed in send_request() as well as in receive_other(). i.e. returning the object from the previous ForwardRequest if that has been thrown.

    I'm ambivalent about which of these is best but for the sake of simplicity I'm going to plump for (1) because this is already allowed in ServerRequestInfo.

    So:

    • Change the IDL in 21.3.12 to include
      void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    • After 21.3.12.12 move in the text from 21.3.14.6
    • Change the IDL in 21.3.14 to remove set_slot()
  • Reported: CORBA 2.6.1 — Thu, 2 May 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Avoiding RSC/TSC copy on server side

  • Legacy Issue Number: 4169
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    During the interceptor FTF we changed the server-side threading
    requirements such that all server-side points run in the same thread
    as the ServantManager and servant except receive_request_service_contexts.

    We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
    accordingly but knew we screwed the picture and wording up. So we
    punted to the RTF.

    The main problem with the current wording is that is forces a copy of
    of TSC/RSC before the servant manager and then receive_request are
    called. This is necessary because 21.4.4.5 item 5 says: "The
    receive_request points may modify the RSC, but this no longer affects
    the TSC."

    The only way to make RSC identical to TSC in receive_request with
    respect to reading but also have them be independent with respect to
    writing is to make a copy (which could be optimized to copy-on-write,
    but why?).

    I suggest we just state they are equivalent after
    receive_request_service_contexts.

    Here is a proposed revision to ptc/00-08-06 along these lines.

    Comments?
    Harold

    21.4.4.4 Request Scope vs Thread Scope

    ... On the server-side, the request scope PICurrent is attached to
    the ServerRequestInfo and follows the request processing. It is
    logically equivalent to the thread scope PICurrent after the list of
    receive_request_service_contexts interception points are processed.

    21.4.4.5 Flow of PICurrent between Scopes

    5. The ORB logically makes the RSC equivalent to the server-side TSC
    after the receive_request_service_contexts points are processed and
    before the servant manager is called. This TSC is within the context
    for both the receive_request points, the invocation of the servant
    manager, and the invocation of the target operation.

    The receive_request points are called. These points have access to the
    RSC. Modifying the RSC at this point makes corresponding
    modifications on the TSC. Since these points execute in the same
    thread as the target operation invocation, these points may modify the
    server-side TSC which makes corresponding modifications on the RSC.

    6. After the receive_request points are called, control transfers to
    the server threads which may also read and write this server-side TSC.
    Any modifications to the TSC makes corresponding modifications on the
    RSC.

    7. <No change>

    8. <DELETE THIS ITEM>

    9. The send interception points have access to the RSC (and the
    equivalent TSC) from which they may populate the reply service context
    list. After the invocation result is sent back to the client, the
    server-side RSC is logically destroyed.

    ...

    The picture would also need updating, but let's agree on wording first.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Implications of any/valuetype marshalling

  • Legacy Issue Number: 4137
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal for extension to CosNaming

  • Legacy Issue Number: 5214
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Since there doesn't appear to be a CosNaming mailing list this seems like as good a forum as any this discussion.

    It has long struck me that the use of CosNaming for JNDI in J2EE applications creates a significant outage in being able to bind and retrieve objects that are not remote (see the EJB 2.0 spec for details). In JNDI you can bind pretty much anything that is Remote (aka an Object reference) or Serializable (aka a valuetype), however CosNaming only allows you to do the former.

    One easy way to solve this would be to create a new NamingContext extension that allows one to bind and resolve Any's. This is in keeping with the Java-to-IDL spec's treatment of untyped Java objects and at the same time would not compromise non-java implementations. For JNDI it would only be necessary to support Any's containing:

    1. Object references
    2. valuetypes
    3. valueboxes

    An exception could be thrown for any other types. The candidate interface might look something like this:

    module CosNaming {
    interface NamingContextAny : NamingContextExt {
    exception TypeNotSupported {};

    void bind_any(in Name n, in any obj)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound, TypeNotSupported);

    void rebind_any(in Name n, in any obj)
    raises(NotFound, CannotProceed, InvalidName, TypeNotSupported);

    any resolve_any (in Name n)
    raises (NotFound, CannotProceed, InvalidName);

    any resolve_str_any(in StringName n)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound);
    };
    };

    The implementation of this interface in Java is trivial, although perhaps less so in other languages. Whether or not that matters is open to question.

  • Reported: CORBA 2.6 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

New issue: ForwardRequest()

  • Legacy Issue Number: 5231
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The Portable Object Adapter and Portable Interceptors both are able to
    raise a ForwardRequest exception to allow redirection to another
    object.

    What happens if the ForwardRequest is to a local object?

    Is this even possible?

    Should it be allowed?

    I suggest we change the specification to make this illegal.

  • Reported: CORBA 2.6 — Thu, 25 Apr 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How does an ORB implement Object::get_policy for PI defined policies?

  • Legacy Issue Number: 4065
  • Status: closed  
  • 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.

  • Reported: CORBA 2.4.1 — Sat, 18 Nov 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

rule (85) is misplaced

  • Legacy Issue Number: 15715
  • Status: closed  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    The rule number (85) is indented, the rule number is not aligned with other rule numbers.

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

processing TaggedComponents within an IOR

  • Legacy Issue Number: 5439
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    The overhead of processing TaggedComponents within an IOR becomes
    significant when done many times, as in the case of J2EE
    implementations where multiple interceptors are used.

    The definition of IORs in the IOP module is intended to support
    transmission and interoperability, rather than efficient access to the
    local, ORB specific, internal structure.

    I would like to propose that an abstract model of an IOR is introduced
    which recognises that many of the constituent parts of IOR profiles are
    identical for different objects, along the following lines:-

    • an IOR has a type ID string, and contains TaggedProfile instances
    • a TaggedProfile has an ID and data
    • an IIOPProfile is a TaggedProfile; it is composed of an
      IIOPProfileTemplate and an object ID.
    • an IIOPProfileTemplate has IIOP addressing information, and contains
      TaggedComponents.
    • a TaggedComponent has an ID and data
    • a TaggedComponentFactory creates a TaggedComponent
    • a TaggedProfileFactory creates a TaggedProfile

    with corresponding IDL definitions that allow the language bindings
    to optimise conversion between transmission and internal IOR formats
    to provide a performant and natural interface for IOR access.

    Rationale:
    In Java, for example, it should be possible to manipulate IOR
    TaggedProfiles and IIOPProfileTemplate TaggedComponents using the
    facilities of the Java collections framework, or at least some
    equivalent facility that is a natural Java idiom.

    Templates can be used to create IIOPProfiles because the basic object
    adapter model for object creation is to establish many of the properties
    of an IOR when the object adapter is created.

    • This has been present for the POA essentially from the beginning, since
      policies can only be passed to create_POA, and cannot be changed on an
      existing POA.
    • The Portable Interceptors work has also made this clear, since the IOR
      interceptor establish_components method, which is the only time that
      user code can add tagged components to an IOR, is only guaranteed to
      be called once for each distinct set of server policies i.e need only
      be run when an object adapter is created.
    • It is also likely that more than one object within an adapter will
      map to a TCP endpoint.

    TaggedProfile and TaggedComponent are intended as frameworks that may be
    extended to support application defined tagged profiles and components.
    To support this it is necessary to be able to register TaggedProfile and
    TaggedComponentFactory instances with an ORB, in which case any IOR
    unmarshalled by that ORB instance will use the registered factory
    to unmarshal the tagged profile or component.

    Since there has already been quite a bit of discussion about this in the
    Java RTF, here is a proposal for review:-

    Proposal:

    • add the following sections after the IOR Interceptor Overview:-

    21.5.2 An Abstract Model for IORs

    To support efficient access to IORs, avoiding repeated marshaling and
    demarshaling of IOR components, it is helpful to have an abstract model
    of the, ORB specific, local representation of an IOR.

    Recognising that many of the constituent parts of IOR profiles are
    identical for different objects allows the following model to be
    defined:-

    • an IOR has a type ID string, and contains TaggedProfile instances
    • a TaggedProfile has an ID and data
    • an IIOPProfile is a TaggedProfile; it is composed of an
      IIOPProfileTemplate and an object ID.
    • an IIOPProfileTemplate has IIOP addressing information, and contains
      TaggedComponents.
    • a TaggedComponent has an ID and data
    • a TaggedComponentFactory creates a TaggedComponent
    • a TaggedProfileFactory creates a TaggedProfile

    21.5.3 Local IOR Interfaces

    The following interfaces provide access to the data within a local IOR
    using this model.

    TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB
    may create implementations of them. Corresponding factories may be
    registered with the IORFactory.

    The IORFactory is obtained through a call to
    ORB::resolve_initial_references ("IORFactory") and may also be used to
    obtain an IOR for an Object.

    An ORB must return all tagged profiles in an IOR through the IOR
    getProfiles operations. The ProfileIterator interface allows a client
    to iterate through the TaggedProfiles using the next operation.
    Those profiles whose ids have a registered TaggedProfileFactory will
    be made available in the form returned by the registered factory's
    TaggedProfileFactory create operation, which must return a subtype of
    TaggedProfile.

    An ORB will provide a TaggedProfileFactory implementation for the
    IIOPProfile.

    Profiles with ids for which no TaggedProfileFactory has been registered
    will be made available as instances of a generic ORB implementation of
    TaggedProfile.

    Similarly, an ORB must return all tagged components in an IIOP profile
    through the IIOPProfile().getTemplate().getComponents() operations.
    The ComponentIterator interface allows a client to iterate through the
    TaggedComponents using the next operation.
    Those components whose ids have a registered TaggedComponentFactory
    will be made available in the form returned by the registered factory's
    TaggedComponentFactory create operation, which must return a subtype of
    TaggedComponent.
    Components with ids for which no TaggedComponentFactory has been
    registered will be made available as instances of a generic ORB
    implementation of TaggedComponent.

    module PortableInterceptor {

    local interface TaggedComponent

    { readonly attribute IOP::ComponentId component_id; readonly attribute CORBA::OctetSeq component_data; IOP::TaggedComponent convert(); }

    ;

    local interface ComponentIterator

    { TaggedComponent next(); boolean has_next(); }

    ;

    local interface TaggedProfile

    { readonly attribute IOP::ProfileId profile_id; readonly attribute CORBA::OctetSeq profile_data; IOP::TaggedProfile convert(); }

    ;

    local interface ProfileIterator

    { TaggedProfile next(); boolean has_next(); }

    ;

    local interface IOR

    { readonly attribute string type_id; ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); }

    ;

    local interface IIOPProfileTemplate

    { readonly attribute IIOP::Version iiop_version; readonly attribute string host; readonly attribute unsigned short port; ComponentIterator get_components(); ComponentIterator get_components_by_id (in IOP::ComponentId id); }

    ;

    local interface IIOPProfile:TaggedProfile

    { readonly attribute CORBA::OctetSeq object_key; readonly attribute IIOPProfileTemplate profile_template; }

    ;

    local interface TaggedComponentFactory

    { readonly attribute IOP::ComponentId factory_id; TaggedComponent create_tagged_component (in CORBA::OctetSeq component_data); }

    ;

    local interface TaggedProfileFactory

    { readonly attribute IOP::ProfileId factory_id; TaggedProfile create_tagged_profile (in CORBA::OctetSeq profile_data); }

    ;

    local interface IORFactory

    { IOR create_ior (in Object obj); void register_tagged_profile_factory (in TaggedProfileFactory tpf); void register_tagged_component_factory (in TaggedComponentFactory tcf); }

    ;

    };

    21.5.3.1 IOR Factory Interface

    create_ior
    Return an IOR relating to the given Object.

    If create_ior is invoked when the object reference is not bound,
    standard system exception BAD_INV_ORDER with minor code n will be
    raised.

    register_tagged_profile_factory
    Register a TaggedProfileFactory to create TaggedProfiles with the id
    returned by the given factory's getId method. If a TaggedProfileFactory
    already exists for the given id, standard system exception
    BAD_INV_ORDER is raised with a standard minor code of n+1.
    Instances of this interface may be defined by users to support custom
    tagged profiles.

    register_tagged_component_factory
    Register a TaggedComponentFactory to read TaggedComponents with the id
    returned by the given factory's getId method. If a
    TaggedComponentFactory already exists for the given id, standard system
    exception BAD_INV_ORDER is raised with a standard minor code of n+2.
    Instances of this interface may be defined by users to support custom
    tagged components.

    21.5.3.2 IOR Interface

    This interface gives access to a local representation of an
    IOP::IOR.

    type_id
    The type id string from the IOR.

    get_profiles
    Returns an iterator over the TaggedProfiles within the IOR.

    get_profiles_by_id
    Returns an iterator over the TaggedProfiles with the given
    Profileid.

    21.5.3.3 TaggedProfile Interface

    This interface gives access to a local representation of an
    IOP::TaggedProfile.

    profile_id
    This attribute is the identifier for this TaggedProfile.

    profile_data
    This attribute is the data from the TaggedProfile. It is
    normally a CDR encapsulation.

    convert
    Create an IOP representation of this TaggedProfile

    21.5.3.4 TaggedComponent Interface

    This interface gives access to a local representation of an
    IOP::TaggedComponent.

    component_id
    This attribute is the identifier for this TaggedComponent.

    component_data
    This attribute is the data from the TaggedComponent. It is
    normally a CDR encapsulation.

    convert
    Create an IOP representation of this TaggedComponent.

    21.5.3.5 TaggedProfileFactory Interface

    factory_id
    This attribute is the identifier of profiles created by this
    TaggedProfileFactory.

    create
    Create a TaggedProfile from the given profile_data.

    21.5.3.6 TaggedComponentFactory Interface

    factory_id
    This attribute is the identifier of components created by this
    TaggedComponentFactory.

    create
    Create a TaggedComponent from the given component_data.

    21.5.3.7 ProfileIterator Interface

    next
    Returns the next TaggedProfile in the iteration. If next is called
    after the last TaggedProfile has been returned, BAD_INV_ORDER will
    be raised with a standard minor code of n+3.

    If an IOR is modified in between calls to next, the behavior of
    further calls to next is implementation dependent.

    has_next
    Returns true if the iteration has more elements. In other words,
    returns true if next would return an element rather than throwing
    an exception.

    21.5.3.8 ComponentIterator Interface

    next
    Returns the next TaggedComponent in the iteration. If next is called
    after the last TaggedComponent has been returned, BAD_INV_ORDER will
    be raised with a standard minor code of n+3.

    If a profile is modified in between calls to next, the behavior of
    further calls to next is implementation dependent.

    has_next
    Returns true if the iteration has more elements. In other words,
    returns true if next would return an element rather than throwing
    an exception.

    21.5.3.9 IIOPProfile Interface

    object_key
    This attribute is the Object key contained in this IIOPProfile.

    profile_template
    This attribute is the IIOPProfileTemplate associated with this
    IIOPProfile.

    21.5.3.10 IIOPProfileTemplate Interface

    iiop_version
    This attribute is the GIOP version of this profile. If the major
    value is 1 and the minor value is 0, this profile cannot contain
    any TaggedComponents.

    host
    This attribute is the host name string of this IIOPProfileTemplate.

    port
    This attribute is the port number of this IIOPProfileTemplate.

    get_components
    Return an iterator over the TaggedComponents within the
    IIOPProfileTemplate.

    get_components_by_id
    Returns an iterator over the TaggedComponents with the given
    ComponentId.

    In current Section 21.5.3:

    • add the following after the ORBInfo Interface

    local interface IORInfo_3_n:IORInfo

    { ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); }

    ;

    • add the following sections:

    21.5.3.4 get_profiles
    Returns an iterator over the TaggedProfiles within the IOR.

    21.5.3.5 get_profiles_by_id
    Returns an iterator over the TaggedProfiles within the IOR with the
    given Profileid.

    Parameter Description
    profile_id The IOP::ProfileId of the profiles in the iteration
    to be returned.

    • add the IORFactory to the list of reserved ObjectIds for
      resolve_initial_references in section 4.5.2
  • Reported: CORBA 3.0 — Tue, 25 Jun 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bad quotes and imported dot

  • Legacy Issue Number: 15714
  • Status: closed  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    Is:
    A character literal is one or more characters enclosed in single quotes, as in ’x.’
    Should be:
    A character literal is one or more characters enclosed in single quotes, as in 'x'.

    (note that the present version uses curly quotes and the dot is probably misplaced)

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

missing document title

  • Legacy Issue Number: 15713
  • Status: closed  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    The document title in PDF metadata
    is "untitled",
    should be
    "Common Object Request Broker Architecture (CORBA)
    Specification"

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.8.1

  • Legacy Issue Number: 12551
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The corba spec defines a lot of policies. In 4.8.5 client exposed policies are listed. We do have several of them, also policies could be applied at several levels, but some of them can't be applied to each level. To our idea the scope at which policies can be applied should not only be in the possible, but also part of the policy itself. That way application code and the corba orb could check this. Maybe add this to policy typedef unsigned long PolicyScope; const PolicyScope POLICY_SCOPE_OBJECT = 0x01; const PolicyScope POLICY_SCOPE_CURRENT = 0x02; const PolicyScope POLICY_SCOPE_SCOPE = 0x04; const PolicyScope POLICY_SCOPE_POA = 0x08; const PolicyScore POLICY_SCOPE_CLIENT_EXPOSED = 0x10; Then add to the interface Policy readonly attribute PolicyScope policy_scope; This attribute can then be set in the policy with the values above as bitmask. This can be documented clearly in the documentation, orbs can check this, etc.

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

move struct to IOP module

  • Legacy Issue Number: 12550
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CORBA spec defines the following types to proposage messaging qos. This is really nothing more then propagating policies values. struct PolicyValue

    { CORBA::PolicyType ptype; sequence<octet> pvalue; }

    ; typedef sequence<PolicyValue> PolicyValueSeq; This is now in the Messaging module, but the propagation of policy values is something that we want to use for ZIOP but also seems usable for other libraries. Instead of duplicating this struct to different modules I propose to move this to the IOP module.

  • Reported: CORBA 3.0.3 — Tue, 24 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add create_policy with just the type as argument

  • Legacy Issue Number: 17208
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For several cases it would be helpful to have a:

    Policy create_policy(
    in PolicyType type) raises(PolicyError);

    The name of the method has to change, to not conflict with the existing method

  • Reported: CORBA 3.1 — Thu, 1 Mar 2012 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

context should be local interface

  • Legacy Issue Number: 16996
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The context has to be define as local interface instead of a regular interface

  • Reported: CORBA 3.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Make anonymous types illegal

  • Legacy Issue Number: 16047
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the specification already deprecated anonymous types, but to our idea it would be time to update the specification to say that anonymous types are illegal and remove all references to them

  • Reported: CORBA 3.0.3 — Wed, 2 Mar 2011 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Redundant bullet

  • Legacy Issue Number: 16942
  • Status: closed  
  • Source: Kestrel Institute ( Alessandro Coglio)
  • Summary:

    It seems that the last and 4th-to-last bullets both describe the Wstring type. Thus, one should suffice.

  • Reported: CORBA 3.2 — Fri, 30 Dec 2011 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

interface ORB should be local

  • Legacy Issue Number: 16315
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The ORB is intended to be a local object, it is not to be used outside of the process, so it should be a local interface

  • Reported: CORBA 3.0.3 — Tue, 7 Jun 2011 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle

  • Legacy Issue Number: 13105
  • Status: closed  
  • Source: cs.agh.edu.pl ( Jacek Cala)
  • Summary:

    There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle. Having multiplex publisher port it would be easier to connect with dynamically created event consumers such that each consumer would have its own private communication channel with the publisher. In case of dynamically created consumers it is not possible to foresee the number of publisher ports required. For synchronous communication the elegant solution is a component with a multiplex receptacle for which we have separate communication channels.

  • Reported: CORBA 3.1 — Mon, 24 Nov 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.3.13

  • Legacy Issue Number: 10817
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Table 21-1 has the following note: When ClientRequestInfo is passed to send_request, there is an entry in the list for every argument, whether in, inout, or out. But only the in and inout arguments will be available. What is the behaviour when I request an out value? It says only that in/inout are available, but when I have an argument that is of out and I do get the value, do I then get an empty value (which could lead to a crash when using it), do I get an exception? That must be clearly specified by the spec

  • Reported: CORBA 3.0.3 — Tue, 13 Mar 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

16.10 lists register_initial_reference

  • Legacy Issue Number: 13056
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    16.10 lists register_initial_reference. It would be usefull for dynamic systems to also have a unregister_initial_reference (in ObjectId id).

  • Reported: CORBA 3.1 — Mon, 3 Nov 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.7.3

  • Legacy Issue Number: 12555
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This chapter defines register_orb_initializer. This itself is ok, but at the moment we have a 24*7 system and we get a new ORBInitializer shipped in for example a DLL we maybe want to get rid of a certain orbinitializer that we registered earlier. This is currently not possible, we propose to add an unregister_orb_initializer which makes it possible to unregister an orbinitializer again

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add CORBA::ORB::arg_list

  • Legacy Issue Number: 12773
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For a 24x7 system that doesn't shutdown and gets reconfigured it would be useful if we could for example change "-ORBDefaultInitRef" after the ORB has been initialized. That then would be used for any objects resolved after that. Maybe we could add CORBA::ORB::arg_list (inout arg_list argv); Which would change the arglist

  • Reported: CORBA 3.0.3 — Mon, 11 Aug 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add interface ORB { Object string_to_object ( in wstring str ); };

  • Legacy Issue Number: 12857
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We see more and more use of unicode. It happens more and more that users have code that gets unicode (wchar) commandline arguments. In order to smoothen corba usage for these users we propose to add interface ORB

    { Object string_to_object ( in wstring str ); }

    ;

  • Reported: CORBA 3.0.3 — Sun, 21 Sep 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 13.7 ServiceContext

  • Legacy Issue Number: 12559
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ServiceContext is defined as: struct ServiceContext

    { ServiceId context_id; sequence <octet> context_data; }

    ; Anonymous types are deprecated, this should be struct ServiceContext

    { ServiceId context_id; CORBA::OctetSeq context_data; }

    ;

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Part 2, Chapter 11 - MIOP

  • Legacy Issue Number: 12376
  • Status: closed  
  • Source: Lockheed Martin ( Kenton Waller)
  • Summary:

    The MIOP does not provide an analogous operation to PortableServer::POA::create_POA() for the GOA (i.e. there is no PortableGroup::GOA::create_GOA). The lack of an operation of this nature prevents the ability for an interface (i.e. servant) to subscribe to multiple (i.e. more than one) multicast group. To specify to a POA to allow multiple entries in its Active Object Map, the POAs IdUniquenessPolicy would have to be set to MULTIPLE_ID. This can only be done via the POAs create_POA operation. Since there is no GOA create_GOA operation, a GOAs IdUniquenessPolicy cannot be set to MULTIPLE_ID, which prevents a servant from being able to be subscribed to more than one multicast group. I don't know if the OMG explicitly wants to prevent this capability, thus purposely leaving it out of the MIOP specification, or if this is simply an overlooked issue.

  • Reported: CORBA 3.1 — Tue, 8 Apr 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

definition of Invalid Policies changed

  • Legacy Issue Number: 12229
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    The CORBA/e FTF slightly changed the definition of Invalid Policies to: exception InvalidPolicies

    { UShortSeq indices; }

    ; since this avoids the use of an anonymous sequence type, consider changing it (also for consistency).

  • Reported: CORBA 3.1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

mention of (deprecated) function get_implementation removed from text

  • Legacy Issue Number: 12230
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    CORBA/e FTF (issue 11331): removed mention of (deprecated) function get_implementation from text. Consider making same change for consistency

  • Reported: CORBA 3.1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal to change PortableInterceptor::ReplyStatus to a real enum

  • Legacy Issue Number: 11514
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Proposal to change PortableInterceptor::ReplyStatus to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum ReplyStatus

    { SUCCESSFUL, SYSTEM_EXCEPTION, USER_EXCEPTION, LOCATION_FORWARD, TRANSPORT_RETRY, UNKNOWN }

    ; };

  • Reported: CORBA 3.0.3 — Tue, 25 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal to change PortableInterceptor::AdapterState to a real enum

  • Legacy Issue Number: 11515
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Proposal to change PortableInterceptor::AdapterState to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum AdapterState

    { HOLDING, ACTIVE, DISCARDING, INACTIVE, NON_EXISTENT }

    ; };

  • Reported: CORBA 3.0.3 — Tue, 25 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 15.4.2/16.4.1

  • Legacy Issue Number: 11332
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 15.4.2 and 16.4.1 get_implementation is mentioned, but this method is nowhere else in the spec. Should this method be there? So far as I can see this is deprecated and should be removed.

  • Reported: CORBA 3.0.3 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Third line of 23.1.3.4, ACTIVE must be bold

  • Legacy Issue Number: 11525
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Third line of 23.1.3.4, ACTIVE must be bold

  • Reported: CORBA 3.0.3 — Sun, 30 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 13.6.10.1

  • Legacy Issue Number: 11161
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    The use of the '/' character to identify the object key component of a corbaloc URL is ambiguous where a protocol address also contains the character. Example: corbaloc:uiop:/tmp/uiop/xx/steve This could represent either a uiop address '/tmp/uiop' and an object key 'xx/steve/ or a uiop address '/tmp/uiop/xx' and an object key 'steve'. Suggest removing the '/' character from the list of non excaped object key characters (bottom of page 13-26)to resolve this ambiguity. The corbaloc would then become: corbaloc:uiop:/tmp/uiop/xx%27steve

  • Reported: CORBA 3.0.3 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing PolicyValue encoding instructions

  • Legacy Issue Number: 18152
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Invalid IDL (2)

  • Legacy Issue Number: 18151
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Two typo's in Annex A.4

  • Legacy Issue Number: 17273
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    There are two typo's in section A.4 on page 495.
    1
    SERVENT_RETENTION_POLICY_ID should be SERVANT_RETENTION_POLICY_ID
    2
    PortableServer::ServentRetentionPolicy should be PortableServer::ServantRetentionPolicy

  • Reported: CORBA 3.1 — Tue, 27 Mar 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Invalid IDL

  • Legacy Issue Number: 18150
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

struct PolicyValue

  • Legacy Issue Number: 12549
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This section defines struct PolicyValue

    { CORBA::PolicyType ptype; sequence<octet> pvalue; }

    ; Which should be as below because anonymous types are deprecated struct PolicyValue

    { CORBA::PolicyType ptype; CORBA::OctetSeq pvalue; }

    ;

  • Reported: CORBA 3.0.3 — Tue, 24 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 7.4

  • Legacy Issue Number: 8630
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Minor formatting issue in: abstract valuetype Pollable

    { boolean is_ready( in unsigned long timeout ); PollableSet create_pollable_set( ); }

    ; boolean is_ready is in the wrong font in the idl overview

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Moving *Seq typedefs into ORB chapter

  • Legacy Issue Number: 8586
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In the CORBA specification, chapter 5 (Value Type
    Semantics), section 5.5 (Custom Marshalling), defines
    sequences of primitive types in the CORBA module,
    i.e., CORBA::StringSeq et al. Some of these types are
    then used by the DynamicAny and Portable Interceptor
    chapters.

    The presence of these typedefs in section 5.5 seems
    to imply that they only need to be defined if the ORB
    implements custom marshalling – a feature still
    lacking in some open-source and commercial ORBs.

    In my experience, having worked with multiple ORBs,
    many of them do not provide the complete set of
    typedefs in their "orb.idl" file. Many ORBs only
    provide a limited set, usually, the set that is
    exercised by the other ORB features (such as PI).
    This implies that most ORBs added these typedefs
    on an "as needed" basis instead of simply referring
    to section 5.5.

    I suggest to move these typedefs from section 5.5
    into chapter 4 (ORB interface), e.g., into section
    4.2 (ORB operations) to highlight that these types
    should be present even if custom marshalling is not
    implemented by the ORB.

    Proposed resolution:

    In section 5.5.2 (Marshalling Streams), cut the
    type definitions, starting with AnySeq, up to and
    including WStringSeq.

    In section 4.2, in the IDL code fragment, at the
    beginning of the CORBA module, paste the type
    definitions cut above.

  • Reported: CORBA 3.0.3 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Minor code ambiguity

  • Legacy Issue Number: 8618
  • Status: closed  
  • Source: International Business Machines ( Mr. Neil Richards)
  • Summary:

    In the CORBA specification dated 04-03-12, the last two paragraphs on page 15-33 (section 15.4.1) describe the use of MARSHAL minor codes 7 and 8.
    However, this use of these minor codes is not reflected in the table of minor codes on page A-11 (appendix A).

    Furthermore, MARSHAL minor code 7 has also been assigned (at an earlier date?) to an issue resolved in the Java to IDL specification dated 03-09-04 (see page 1-50 / end of section 1.5.1.5).
    This use of minor code 7 is reflected in the table in the CORBA specification.
    However minor code 10, which is also specified in the same section in the Java to IDL specification, is not documented in the CORBA specification.

    In summary, MARSHAL minor code 7 is double-booked, whilst minor codes 8 (used in the CORBA specification) and 10 (used by the Java to IDL specification) are not documented in the table of codes.

    Proposed solution:

    Change section 15.4.1 to define the use of MARSHAL minor code 9 (in addition to minor code 8), instead of MARSHAL minor code 7.

    Update the table of minor codes on page A-11 with the definitions of MARSHAL minor codes 8, 9 and 10.

  • Reported: CORBA 3.0.3 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing size information for decompress()

  • Legacy Issue Number: 18153
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Typo in sections 22.10.1.1 and 22.10.1.2

  • Legacy Issue Number: 8629
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 2.10.1.1, page 22-26 (my copy is formal/04-03-01),
    enumerated item 3, second bullet, the text reads "232-1 - the
    maximum value for unsigned long [...]". The "32" needs to be
    in superscript, i.e., to indicate "2 to the power of 32 minus
    1".

    The same typo exists in section 2.10.1.2, page 22-28, fourth
    paragraph, second bullet (at the top of the page).

  • Reported: CORBA 3.0.3 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.7

  • Legacy Issue Number: 8843
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the draft 3.1 spec chapter 21.7 says the following: An Interceptor's behaviour may itself be modified by one or more Interceptor Policies. These Policy objects are created using a call to ORB::create_policy and are associated with an Interceptor during registration (see Section 21.7.2, ORBInitInfo Interface). All Policy interfaces defined in this section are local. The ORB can be accesed via the implicit get_orb operation of ORBInitInfo. The ORBInitInfo is passed on the pre_init and post_init call of the ORBInitializer but what should be the orb in the pre_init call? The orb is not initialized at that moment? Shouldn't it say that calling get_orb on the ORBInitInfo in the pre_init call gives the default exception that is given when get_orb is called on a local object?

  • Reported: CORBA 3.0.3 — Wed, 1 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

update the spec to not used anonymous types

  • Legacy Issue Number: 8783
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec describes that anonymous types are deprecated and will be removed in the future (as below), but this is used throughout the spec. Before deprecating this fully, update the spec to not used anonymous types: >From 3.11.6 IDL currently permits the use of anonymous types in a number of places. For example: struct Foo

    { long value; sequence<Foo> chain; // Legal (but deprecated) }

    Anonymous types cause a number of problems for language mappings and are therefore deprecated by this specification. Anonymous types will be removed in a future version, so new IDL should avoid use of anonymous types and use a typedef to name such types instead. Compilers need not issue a warning if a deprecated construct is encountered.

  • Reported: CORBA 3.0.3 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.9.1

  • Legacy Issue Number: 8844
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The draft document says the following in 21.9.1. The description about the type of exceptions sounds very vague. Shouldn't the spec be more detailed, which type of exceptions should be ignored specifically? Any exceptional return from the invocation of any operation of the ORBInitializer interface other than those resulting from the failure to instantiate a portable interceptor object shall result in the abandonment of the ORB initialization and destruction of the ORB. Any ORBInitializer implementation that needs the ORB to ignore any thrown exceptions can simply catch and discard them itself.

  • Reported: CORBA 3.0.3 — Wed, 1 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.4.3.1

  • Legacy Issue Number: 8856
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In case get_slot is called from withing an ORB itializer chapter 21.4.3.1 says a BAD_INV_ORDER with minor code 10 is thrown, this should be 14 as mentioned also in 21.7.2.11

  • Reported: CORBA 3.0.3 — Mon, 6 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.2 (02)

  • Legacy Issue Number: 8633
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Struct ServiceInformation is wrong, the sequence<> lines should be removed. struct ServiceInformation

    { sequence <ServiceOption> service_options; ServiceOptionSeq service_options; sequence <ServiceDetail> service_details; ServiceDetailSeq service_details; }

    ;

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.2

  • Legacy Issue Number: 8632
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The is an error in the ServiceDetail struct. service_detail is listed twice, the first one should be removed. struct ServiceDetail

    { ServiceDetailType service_detail_type; sequence <octet> service_detail; ServiceDetailData service_detail; }

    ;

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 13.6.2

  • Legacy Issue Number: 8631
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Update: struct IOR

    { string type_id; sequence <TaggedProfile> profiles; }

    ; to struct IOR

    { string type_id; TaggedProfileSeq profiles; }

    ; And also use CORBA::OctectSeq instead of sequence<octet>

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

FullInterfaceDescription and base_interfaces question

  • Legacy Issue Number: 9140
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Regarding the base_interfaces attribute of the Interface Repository
    (IFR) InterfaceDef and the ExtInterfaceDef interfaces, the CORBA spec
    has only this to say:

    "The base_interfaces attribute lists all the interfaces from which
    this interface inherits."

    Does that sentence mean that the base_interfaces attribute lists only
    immediate base interfaces, or does it list all base interfaces,
    i.e., the transitive closure of the inheritance graph (minus the
    implied Object interface at the root)? I believe it is supposed to be
    a list of only immediate interfaces, as one can make further calls on
    the IFR to obtain more information about those bases, including
    their bases.

    However, both the FullInterfaceDescription and the
    ExtFullInterfaceDescription structures also have a base_interfaces
    member, which is specified as a sequence of repository IDs.
    Unfortunately, the specification contains no description whatsoever
    for this member. I argue that unlike the base_interfaces attribute
    described above, this member can't list only the immediate base
    interfaces.

    I believe that the base_interfaces member of the
    FullInterfaceDescription and the ExtFullInterfaceDescription
    structures should contain the transitive closure of all base
    interfaces. These structures are intended to supply full interface
    descriptions, after all. Specifying the base_interfaces as I suggest
    would match the operations and attributes fields of the same structs,
    which are already explicitly specified to contain all operations and
    attributes respectively from the transitive closure of the
    inheritance graph. Note also that if base_interfaces does not contain
    the transitive closure of all base interfaces, there's no way to
    obtain the information from TypeCodes, since names do not appear in
    TypeCodes in minimum CORBA.

    I therefore propose that the third paragraph of section 10.5.24.1 of
    CORBA 3.0.2 be changed from this:

    "The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes.
    The operations and attributes fields of the FullInterfaceDescription
    structure include descriptions of all of the operations and
    attributes in the transitive closure of the inheritance graph of the
    interface being described."

    to add a sentence defining the base_interfaces member, like this:

    "The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes.
    The operations and attributes fields of the FullInterfaceDescription
    structure include descriptions of all of the operations and
    attributes in the transitive closure of the inheritance graph of the
    interface being described. The base_interfaces field of the
    FullInterfaceDescription structure includes the repository IDs of all
    the base interfaces in the transitive closure of the inheritance
    graph of the interface being described, except for the repository ID
    of the implied Object base interface."

    Note that even if this change is made, the base_interfaces attribute
    of InterfaceDef and ExtInterfaceDef can (and should) remain as
    listing only immediate bases, assuming that's what the spec's
    original intent was.

  • Reported: CORBA 3.0.3 — Mon, 7 Nov 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing mutual recursion for IDL structs - clarification needed

  • Legacy Issue Number: 10558
  • Status: closed  
  • Source: Borland Software Corporation ( Naveed Shaikh)
  • Summary:

    There was an issue 8969 (Allowing mutual recursion for IDL structures) posted sometime back on CORBA RTF (www.omg.org/issues/issue8969.txt). I am looking for a clarification in the proposed resolution, which allows for the mutual recursion between non-nested structures (CORBA 3.0 specification, section 3.11.2.3). The proposal essentially extends the definition of incompleteness of a struct/union as follows:

    The original definition was:
    o A struct/union is termed incomplete until its full definition is provided; that is, until the scope of the struct/union definition is closed by a terminating "}"

    The introduced proposal added to the original definition:
    o If a sequence member of a structure or union refers to an incomplete type, the structure or union itself remains incomplete until the member's definition is completed

    Section 3.11.2.3 also says that "an incomplete type can only appear as the element type of a sequence definition".

    Question 1:
    Is following legal under the new scheme?

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ; // Bar remains incomplete since it is holding an incomplete sequence type

    struct FooX

    { Bar b; // Is this valid with Bar marked incomplete here? }

    ;

    struct Foo

    { Bar b; }

    ; // According to the proposal, Foo and Bar are complete now

    Use of Bar under FooX apparently conflicts with the condition that incomplete type can only appear in a sequence definition.

    Question 2:
    Also is it must that there is a mutual recursion between non-nested structures? Consider the following:

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ; // Bar remains incomplete

    struct Foo

    { long a; }

    ; // Is Bar also complete here when Foo is complete even though Foo doesn't recurse on Bar?

    Is the above IDL valid under the new proposal? There is no constraint in section 3.11.2.3, which doesn't allow for this so it stands valid as per spec. Was issue 8969 also intended to make such cases valid?

  • Reported: CORBA 3.0.3 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA Exceptions

  • Legacy Issue Number: 9618
  • Status: closed  
  • Source: condor networks ( ramesh babu boya)
  • Summary:

    I implemented CORBA functionality, in that implementation I got some exceptions. I am sending that exceptions list in the below. omniORB: ERROR – the application attempted to invoke an operation on a nil reference. terminate called after throwing an instance of 'CORBA::INV_OBJREF' Aborted (core dumped) I have some doubts on these exceptions. What is the cause for this exception? How can I solve this exception? Please clarify my doubts.

  • Reported: CORBA 3.0.3 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 11.3.9.16

  • Legacy Issue Number: 9460
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For activate_object_with_id it is described that when SYSTEM_ID has been set and the object id was not generated by this system or tis POA we throw a BAD_PARAM, but the minor code is not described. Shouldn't this have an unique minor code?

  • Reported: CORBA 3.0.3 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 11.3.9

  • Legacy Issue Number: 9016
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CORBA spec describes the following about the wait_for_completion parameter of the POA::destroy call: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA belonging to the same ORB as this POA, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA belonging to the same ORB as this POA, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur. We have a use case where we have an ORB with two POA's, A1 and B1, each POA again has a child A2 and B2. In case we get a request for a servant of A2 to destroy POA B2 and we specify TRUE for wait_for_completion then we get an exception back, but this doesn't seem locally. We understand that when we want to destroy A1 when handling a request using a servant of A2 that we get an exception at that moment. We propose the change the description as following: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA that is a child of this POA or from this POA itself, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA that is a child of this POA or from the POA itself, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur.

  • Reported: CORBA 3.0.3 — Mon, 26 Sep 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 22.16/

  • Legacy Issue Number: 9075
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There are some issues with the definition of ExceptionHolder. In 22.16 it is as below, see the raise_exception_with_list, this seems to have two arguments here, in 22.7 there is just one argument. The same problem also appears in the draft 3.1 spec. Also, there is no CORBA::ExceptionList defined in the spec at all, there is Dynamic::ExceptionList but no CORBA::ExceptionList. valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) in Dynamic::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order;

  • Reported: CORBA 3.0.3 — Wed, 5 Oct 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 21-43

  • Legacy Issue Number: 9112
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The following methods are not described in this chapter: Object make_object (in string repository_id, in ObjectId id); IOP::TaggedProfileSeq make_profiles (in string repository_id, in ObjectId id); These are mentioned in 21.10.3

  • Reported: CORBA 3.0.3 — Tue, 25 Oct 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 22.11.1

  • Legacy Issue Number: 9082
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the C++ example code of 22.11.3 Messaging::ExceptionHolder_ptr is used, for valuetypes there is no _ptr, the could should read Messaging::ExceptionHolder *

  • Reported: CORBA 3.0.3 — Mon, 17 Oct 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 7-7

  • Legacy Issue Number: 8881
  • Status: closed  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    CORBA3.0.2(formal/02-12-02), chapter 7.2.1, says "The implicit object reference operations non_existent, is_a, repository_id and get_interface may be invoked using DII. No other implicit object reference operations may be invoked via DII." However, I think we should add "get_component" to this list of allowable operations. Or else we can't use some features of CCM via DII, because the implementation of get_component resides on the server side.

  • Reported: CORBA 3.0.3 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 9-1

  • Legacy Issue Number: 8879
  • Status: closed  
  • Source: nudt ( cyberdb)
  • Summary:

    There are some inconsistent idl declarations in CORBA3.0.2 Chapter 9(with editorial update version) 1?page 9-10: the idl declaration of DynAnyFactory is not the same as the idl declared earlier(page 9-9). It seems that three new fuctions have been left out. 2?Page 9-5: DynUnion should have a member fuction is_set_to_default_member, which is declared on page 9-20

  • Reported: CORBA 3.0.3 — Mon, 27 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 21-5

  • Legacy Issue Number: 8874
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the Interceptor interface there is a destroy method which can throw a system exception just like all other corba calls. What is the behaviour when the orb shutdown is done and an Interceptor::destroy() call throws an exception? Should the ORB ignore this exception and continue the shutdown or should it return the exception to the caller. I would except ignore the exception and continue but the spec doesn't describe the behaviour.

  • Reported: CORBA 3.0.3 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.3.14.11

  • Legacy Issue Number: 8862
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The minor code for add_reply_service_context is not correct. The spec says: Indicates the behavior of this operation when a service context already exists with the given ID. If false, then BAD_INV_ORDER with a standard minor code of 11 is raised. If true, then the existing service context is replaced by the new one. The minor code should be 15.

  • Reported: CORBA 3.0.3 — Wed, 8 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.5.2

  • Legacy Issue Number: 8860
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This corba spec describes POAManagerFactory. I have been searching on the web and it seems for example Orbacus has the possibility to do a resolve_initial_references ("POAManager"). This seems not possible with the latest corba spec. This seems an usefull extension. The only option there is now is to get the RootPOA, get from there the POAManagerFactory and use that again.

  • Reported: CORBA 3.0.3 — Tue, 7 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Appendix A

  • Legacy Issue Number: 8864
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The tags for unreliable multicast are missing. // The following are defined in 03-01-11 const ProfileId TAG_UIPMC = 3; const ComponentId TAG_GROUP = 39; const ComponentId TAG_GROUP_IIOP = 40;

  • Reported: CORBA 3.0.3 — Wed, 8 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.8 The simple Element, page 69-538

  • Legacy Issue Number: 5508
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    2. 69.8.2.8 The simple Element, page 69-538
    Simple Extensions and Changes
    a) Enumerations - Add an optional enumerations element to the simple
    definition.
    This allows a simple enumeration property to be defined. Each enumeration
    label
    has an associated value. The values are all of the same simple type.

    Change simple element to:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , enumerations?
    , defaultvalue?
    ) >

    Define new enumerations element

    <!ELEMENT enumerations
    ( enumeration+
    )>
    <!ELEMENT enumeration EMPTY>
    <!ATTLIST enumeration
    label CDATA #REQUIRED
    value CDATA #IMPLIED>

    b) Short appears twice in the simple type attribute definition. Remove
    second
    occurrence.
    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >
    <!ATTLIST simple
    name CDATA #IMPLIED
    type ( boolean

    char
    double
    float
    short – 1st occurrence
    long
    objref
    octet
    short – 2nd occurrence
    string
    ulong
    ushort
    ) #REQUIRED >

    c) Units - add an optional units element to indicate the units of
    measurement for
    a simple property.

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , units?
    , defaultvalue?
    ) >

    <!ELEMENT units (#PCDATA)>

    d) Property Kind - The properties file for a component should not be
    restricted to
    only initial configuration properties. A component has many different types
    of
    properties and when defining a component one should be able to define these
    types of properties in a generic way. Add a kind element or attribute for a
    property definition. A component has readonly, writeonly, and readwrite
    properties. Simple properties can also be used for a component factory's
    create
    options parameter (home) or executable parameters/arguments. Only simple
    properties can be used for executable parameters.

    New simplekind element

    <!ELEMENT simplekind EMPTY>
    <!ATTLIST simplekind
    kindtype (configure_writeonly | configure_readwrite | execparam |
    query_readonly | factoryparam) "configure_readwrite">

    Change simple definition to:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , simplekind*
    , defaultvalue?
    ) >

    The propertykind can be an optional element or attribute for the stuct and
    sequence elements.

    New propertykind element

    <!ELEMENT propertykind EMPTY>
    <!ATTLIST propertykind
    kindtype (configure_writeonly | configure_readwrite |
    query_readonly | factoryparam) "configure">

    Change Struct and Sequence to

    <!ELEMENT struct
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )*
    , propertykind?
    ) >
    <!ATTLIST struct
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    <!ELEMENT sequence
    ( description?
    , ( simple*

    struct*
    sequence*
    valuetype*
    )
    , propertykind?
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 9, Chapter 5

  • Legacy Issue Number: 8986
  • Status: closed  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    Section 9.2.9 says "A reference to a DynValueCommon interface (and interfaces derived from it) exhibit the same sharing semantics as the underlying valuetype that it represents.", which defines the sharing semantics of DynAny. However, I think its precondition is that valuetype's sharing semantics can be preserved in Any. DynAny is usually used with Any, converted from or to Any. If Any can't preserve sharing semantics, there is no necessary for DynAny to keep them. Suppose we use a struct which consists of several valuetypes to store a graph. In order to ensure the correctness of an application based on DII/DSI, converting this struct to Any and then to DynAny should produce an identical graph. However, if Any can't preserve sharing semantics, this goal is impossible. Any's sharing semantics focuses on valuetype conversion, because we don't concern the concrete internal implementation of Any. It means that when we extracting valuetypes from an Any or converting an Any contains valuetypes into a DynAny, sharing semantics should be preserved. For example, different Anys contain same valuetype only produce one valuetype instance when their contents are extracted. We can implement this by the help of a global valuetype manager. To sum up, the sharing semantics of valuetype can be divided into three layers: valuetype itself, Any and DynAny. All of them constitute a complete hierarchy. Only after each layer has been implemented, we are able to ensure that applications that use the DII and DSI can correctly view and preserve the semantics of the valuetype graph. Because Any's sharing semantics is very fundamental, it is necessary for us to clarify it in the specification, though we haven't special chapter/section on Any. We can add it to Chapter 5 "Value Type Semantics". Section 5.2.4.2 only defined sharing semantics in the layer of valuetype itself. We should say something about sharing semantics in the other two layers at the end of this section.

  • Reported: CORBA 3.0.3 — Mon, 5 Sep 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 11

  • Legacy Issue Number: 8985
  • Status: closed  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    Section 11.3.1 "The Servant IDL Type" defines the default implementations of get_interface, is_a, and non_existent. However, we should define the default implementation of "get_component" as well because this fuction is also an ORB-mediated implicit object reference operation. By default, this function returns a nil reference. When the object is a component or a facet, as other default implementations, this operation can be overridden by the servant's implementation.

  • Reported: CORBA 3.0.3 — Sun, 4 Sep 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing Mutual Recursion for IDL Structures

  • Legacy Issue Number: 8969
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 2.4 introduced forward declarations for IDL structures
    and unions in support of recursive structures, deprecating the
    prior practice of anonymous types.

    Also allowed were sequences of forward-declared structures
    ("incomplete types"), which could then be used as members in
    defining the structure. Currently, it is only allowed to use
    incomplete types in the actual definition of the type itself.

    As an example in section 3.11.2.3 demonstrates, this does
    allow indirect recursion – but only if the incomplete types
    are nested, as in [first example]

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Foo {
    struct Bar

    { FooSeq fs; }

    b;
    };

    Specifically not allowed – and this is the point of this
    issue – is the seemingly more intuitive definition of
    [second example]

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ;

    struct Foo

    { Bar b; }

    ;

    Currently, the spec says that, "sequence members that are
    recursive must refer to an incomplete type currently under
    definition," and thus Bar is not allowed to use FooSeq as
    a member.

    However, the second example is, in effect, no different than
    the first. In the first example, "Foo::Bar" is a well-defined
    stand-alone type that can be used elsewhere (e.g., as a
    structure member or operation parameter).

    If a developer intends to use both structures, the second
    example makes this much clearer, as it syntactically elevates
    "Foo::Bar" from a mere sub-type to an "independent" structure.

    Therefore, I would like to change the current wording of
    section 3.11.2.3 to allow the second example. A proposed
    update is below.

    This issue is all the more urgent because another available
    specification, the "Deployment and Configuration of
    Component-based Distributed Applications," depends on it,
    by using two IDL structures that mutually and indirectly
    recurse, effectively using [third example]

    struct Package;
    typedef sequence<Package> PackageSeq;

    struct Assembly;
    typedef sequence<Assembly> AssemblySeq;

    struct Package

    { AssemblySeq as; }

    ;

    struct Assembly

    { PackageSeq ps; }

    ;

    In reality, the IDL in question is a bit more complicated,
    using some intermediate structures, which makes rewriting
    the IDL without this mutual recursion impractical and
    non-intuitive – also because both "Package" and "Assembly"
    are meant to be potentially top-level, stand-alone items.

    Some might argue that the IDL restriction existed before
    the "Deployment" specification was adopted, and that CORBA
    should not be changed just because some later spec
    willingly (or rather, naively) used buggy IDL.

    So let me make some more arguments in favor of my request.

    First, as explained above, IDL already allows for indirect
    recursion. It just requires nesting.

    Second, defining structures as a "side-effect" of a member
    declaration is ugly, only marginally better than anonymous
    types. Allowing the type definition of a member to stand
    by itself is, in my opinion, much cleaner.

    Third, indirect recursion between non-nested types is no
    more difficult to implement in an ORB than indirect recursion
    between nested types.

    In fact, some existing ORB products already have no problem
    with indirect recursion, and are able to compile the IDL
    from the third example, resulting in correct code. The code
    works fine with Mico, TAO, JacORB and Combat, all of which
    apparently neglect to implement the check that "sequence
    members that are recursive must refer to an incomplete type
    currently under definition."

    OmniORB does issue a diagnostic, but simply removing the
    check, and making another trivial change to its IDL compiler,
    results in correct C++ code.

    Four, the existing IDL syntax, TypeCodes, CDR marshalling
    rules, and Interface Repository all allow indirect recursion
    to exist. In fact, it is already possible to create the
    above data types using the Interface Repository and
    TypeCode interfaces – as well as to create instances
    using DynamicAny, and to marshal them.

    With this background, I suggest to remove the statement
    that prevents indirect recursion between non-nested
    structures and unions.

    Proposed resolution:

    In section 3.12.2.3, change paragraphs (counting each IDL
    code example as a single paragraph) 10 to 12 (page 3-42)
    from

    If a recursive structure or union member is used,
    sequence members that are recursive must refer to
    an incomplete type currently under definition. For
    example

    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar

    { long value; FooSeq chain; // Illegal, Foo is not an enclosing }

    ; // struct or union.

    Compilers shall issue a diagnostic if this rule is
    violated.

    to

    If a sequence member of a structure or union refers
    to an incomplete type, the structure or union itself
    remains incomplete until the member's definition is
    completed. For example

    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar

    { long value; FooSeq chain; // Use of incomplete type }

    ; // Bar itself remains incomplete
    struct Foo

    { // ... }

    ; // Foo and Bar are complete

    Thank you for listening. Also thanks to Jeff Parsons
    and Boris Kolpakov from Vanderbilt University for
    researching this issue.

    We, the submitters of the "Deployment" specification,
    genuinely believe that indirect recursion is useful,
    and its lack (and having to work around) would take
    considerable value from the specification.

    I am uncomfortable arguing to change another spec
    to fix ours. But one spec has to change, and I believe
    that indirect recursion is a useful feature that already
    (unwillingly) exists in many ORBs, that it is no more
    problematic to implement than the existing means of
    recursion, and that the resulting data types are already
    valid when obtained from the TypeCode or Interface
    Repository interfaces.

    Considering the conflict of available specifications,
    I am tempted to flag this issue as urgent. Andrew, is
    that even possible, given that there is no active Core
    RTF?

  • Reported: CORBA 3.0.3 — Wed, 17 Aug 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

NVList Section: 7.5

  • Legacy Issue Number: 8929
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The NVList has a count, which is defined as long, it would be better to make this an unsigned long. This has impact on ORB::create_list, change the type of argumetn count to unsigned long. Also update NVList::get_count to have an unsigned long argument.

  • Reported: CORBA 3.0.3 — Fri, 15 Jul 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Legacy Issue Number: 5515
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Implementation Element Cardinality. Why does it make sense to have an empty
    implementation or to allow multiple elements such as code, description,
    humanlanguage, or to have no code? Suggested changes are to place the
    correct
    cardinality on the implementation elements. The suggested elements
    cardinality
    changes will make parsing the XML much simpler and reduce code footprint,
    and the
    XML more understandable.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    Suggested New Format for implementation

    • Zero or one description, the CAD and CORBA Components DTDs define the
      description this way.
    • Zero or one property file reference. Why are multiple property files
      needed?
    • One code element is required for a given implementation
    • Zero or one complier element. A given source code element is compiled
      by a
      specific compiler. Specifying the compiler is optional.
    • Zero or one programminglanguage element. Specifying the
      programminglanguage is optional.
    • Zero or one humanlanguage element. Specifying the humanlanguage is
      optional.
    • Zero or more dependencies for a specific implementation.
    • Zero or more descriptors for a specific implementation. An
      implementation
      may contain multiple different components.
    • Zero or more runtimes. A given code element may be compatible with
      multiple runtime environments.
    • Zero or more os. A given code element may be compatible with multiple
      operating systems.
    • Zero or more processors. A given code element may be compatible with
      multiple processors.
    • Zero or more extensions.

    <!ELEMENT implementation
    ( description?
    , code
    , compiler?
    , humanlanguage?
    , programminglanguage?
    , propertyfile?
    , ( dependency

    descriptor
    extension
    os
    processor
    runtime
    usescomponent
    )*
    )>
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3 Software Package Descriptor

  • Legacy Issue Number: 5514
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    69.3.2.1 The softpkg Root Element, page 69-473
    Softpkg Element Cardinality. Why does it make sense to have an empty
    softpkg
    file or to allow multiple elements such as title, pkgtype, description,
    license, or to
    have no implementations? Suggested changes are to place the correct
    cardinality
    on the softpkg elements to be similar to the CORBA Component and Component
    Assembly Descriptor definitions. The suggested elements cardinality changes
    will
    make parsing the XML much simpler and reduce code footprint, and the XML
    more understandable.

    Current Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #OPTIONAL >

    Suggested New Format for Softpkg

    • Zero or one title ? for example, a book only has one title, not
      multiple titles.
    • One or more authors ? for example, a book can have multiple authors,
      but at
      least one.
    • Zero or one description, the CAD and CORBA Components DTDs define the
      description this way.
    • Zero or one package type.
    • Zero or one property file reference. Why are multiple property files
      needed?
    • One or more implementations, since the softpkg is an implementation
      for a
      component definition then it must have at least one implementation.
    • Zero or more dependencies for all implementations.
    • Zero or more descriptors for all implementations. An implementation
      may
      contain multiple different components.
    • Zero or more IDL files for all implementations.
    • Zero or more extensions.

    <!ELEMENT softpkg
    ( title?
    , author+
    , description?
    , propertyfile?
    , license?
    , pkgtype?
    , implementation+
    , ( idl

    dependency
    descriptor
    extension
    )*
    )>
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add the capability to define a component artifact property

  • Legacy Issue Number: 5513
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    7. Component Artifact - Add the capability to define a component artifact
    property. For
    example, a logical device component artifact could be used to specify the
    capacity for
    a device or the characteristic of a device. The artifacts for a component
    are referenced
    by a component's implementation dependency for using or deployed on
    relationships.
    The component artifact property could be defined in two ways: 1) a new
    element
    called artifact or modifying the simple definition with optional new
    artifact element.

    Artifacts are simple types. The action element defines the action that can
    be
    performed on an artifact. When a dependency references an artifact with a
    specified value this is the action that can be performed against a
    component's
    artifact. The ID is a DCE UUID to guarantee uniqueness of the artifact
    within the
    system; so 2 different artifacts, which are different, are not viewed to be
    the same
    artifact when they are not. The action denoted as external indicates the
    artifact is
    managed by the component. A referenced value for an artifact would have to
    be
    applied against the component.

    Example 1 of New Artifact Element

    <!ELEMENT artifact
    ( description?
    , simple
    , action
    )>
    <!ATTLIST artifact
    id ID #REQUIRED>

    <!ELEMENT action EMPTY>
    <!ATTLIST action
    type ( eq | ne | gt | lt | ge | le | external ) "external">

    Change properties element to

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    artifact
    valuetype
    )+
    ) >

    Example 2 of Modified Simple Element with new Artifact element

    <!ELEMENT simplekind EMPTY>
    <!ATTLIST simplekind
    kindtype (configure_writeonly | configure_readwrite | execparam |
    query_readonly | factoryparam | artifact) "configure_readwrite">

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , simplekind*
    , artifact?
    , defaultvalue?
    ) >

    <!ELEMENT artifact
    ( action
    )>
    <!ATTLIST artifact
    id ID #REQUIRED
    action ( eq | ne | gt | lt | ge | le | external ) "external">

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.9 The sequence Element

  • Legacy Issue Number: 5511
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Simple Sequence -The current definitions for sequence allow invalid
    definitions to be
    built but be syntactically correct. A better definition for a simple
    sequence would be as
    follows:

    Current sequence element

    <!ELEMENT sequence
    ( description?
    , ( simple*

    struct*
    sequence*
    valuetype*
    )
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    Change to

    Add a new simplesequence element:

    <!ELEMENT simplesequence
    ( description?,
    , values?
    , choices?
    , range?
    , enumerations?
    , units?
    )>
    <!ATTLIST simplesequence
    name CDATA #IMPLIED
    type ( boolean | char | double | float | short | long | objref |
    octet | string | ulong

    ushort ) #REQUIRED

    <!ELEMENT values
    ( value+
    )>

    Change sequence to:

    <!ELEMENT sequence
    ( description?
    , ( simplesequence

    struct*
    sequence*
    valuetype*
    )
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    One does not have to keep repeating the same simple definition. This
    definition
    then has the added advantage where simple name attribute can now be made
    mandatory.
    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >
    <!ATTLIST simple
    name CDATA #REQUIRED
    type ( boolean

    char
    double
    float
    short
    long
    objref
    octet
    string
    ulong
    ushort
    ) #REQUIRED >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Test Property - add a test property definition to the properties DTD

  • Legacy Issue Number: 5512
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    This allows one
    to define test properties for a component in a generic way. The Test
    property is based upon simple
    element.

    Add new test element

    <!ELEMENT test
    ( description
    , inputvalue?
    , resultvalue )>
    <!ATTLIST test
    name CDATA #REQUIRED>

    <!ELEMENT inputvalue
    ( simple+ )>

    <!ELEMENT resultvalue
    ( simple+ )>

    Change properties element to:

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    test
    valuetype
    )+
    ) >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.3 The choices Element, page 69-537

  • Legacy Issue Number: 5510
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Choices Element - It appears multiple ranges do not make sense for a simple
    definition. If so, then remove the range element from the choices element
    definition
    and make range an optional element for a simple.

    Current definition
    <!ELEMENT choices ( choice | range )+

    Change to

    <!ELEMENT choices ( choice )+

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , range?
    , defaultvalue?
    ) >

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The range Element, pages 69-537/538

  • Legacy Issue Number: 5509
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Range Element - why is the min and max order not specified?
    <!ELEMENT range (value, value) >

    I understand the software logic can do a compare to determine the min and
    max values, but it seems the following definition would be easier to
    understand from human reader.

    Change Range to

    <!ELEMENT range EMPTY>
    <!ATTLIST range
    min CDATA #REQUIRED
    max CDATA #REQUIRED>

  • Reported: CORBA 3.0 — Wed, 24 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Component Artifact Dependency

  • Key: CORBA34-96
  • Legacy Issue Number: 5522
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    An implementation may request a dependency on a specific component based
    upon
    its artifacts. Add artifactdependency to the dependency element.

    Current Format

    <!ELEMENT dependency
    ( softpkgref

    codebase
    fileinarchive
    localfile
    name
    valuetypefactory
    ) >
    <!ATTLIST dependency
    type CDATA #IMPLIED
    action (assert
    install)"assert">

    New Format

    <!ELEMENT dependency
    ( softpkgref

    codebase
    fileinarchive
    localfile
    name
    valuetypefactory
    )
    , artifactdependency*
    >
    <!ATTLIST dependency
    type CDATA #IMPLIED
    action (assert
    install)"assert">

    <!ELEMENT artifactdependency EMPTY>
    <!ATTLIST artifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested
    or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LWCCM issue - Section 1.5.3 Exclusion

  • Key: CORBA34-95
  • Legacy Issue Number: 6254
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    On page 11: The Normative Impact "Disable get_connections, get_all_receptacles, get_named_receptacles operations in the Receptacles interface" does not match the Document Impact: "Section 1.5.3: remove". Removal of section 1.5.3 removes the Receptacles interface in it entirety, including the description of the generic connect and disconnect operations, which are referred to by comment in the previous item. The Document Impact needs to be narrowed.

  • Reported: CORBA 3.0.2 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.25 The propertyfile Element, page 69-482

  • Legacy Issue Number: 5518
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Propertyfile clarification is needed for consistent behavior.
    The only statement made about propertyfile is that the implementation's
    propertyfile
    has precedence over the same propertyfile types at the softpkg level. Why
    are
    multiple property files needed at the softpkg and implementation levels? If
    more than
    one propertfile exist at any level, which property file has precedence in
    the list? If
    multiple property files exists are they merged together? Are the softpkg's
    descriptor
    element property files merge with the softpkg property files and which one
    has
    precedence? Are the implementation's descriptor property files merge with
    the
    implementation property files, and which one has precedence? Are
    implementation
    property files merge with the softpkg property files?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.2 The author Element, page 69-474

  • Key: CORBA34-97
  • Legacy Issue Number: 5521
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Change the format of author to group related authors together from a
    company. One
    does not need the capability to list multiple companies and web sites
    together in the
    author element, since there can be many authors listed in the softpkg
    element. The
    suggested elements cardinality changes will make parsing the XML much
    simpler
    and reduce code footprint, and the XML more understandable.
    Current format

    <!ELEMENT author
    ( name

    company
    webpage
    )* >

    New format

    <!ELEMENT author
    ( name*
    , company?
    , webpage?
    )>

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.14 The idl Element, page 69-478

  • Key: CORBA34-99
  • Legacy Issue Number: 5519
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    a) Add idl element to implementation element. Why is idl only at the
    softpkg level?
    This is saying that all implementations use the same IDL. This is
    inconsistent with
    descriptor element. An implementation can specify a descriptor, why not
    idl? Cannot
    an implementation use a specific IDL for its implementation?

    b) Why is IDL defined in the software package descriptor instead of the
    CORBA
    Component descriptor?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Descriptor

  • Key: CORBA34-98
  • Legacy Issue Number: 5520
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    How does the Assembly Descriptor support multiple components within an
    implementation?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The code Element, pages 69-474

  • Legacy Issue Number: 5516
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    a) Add the optional stacksize and priority elements to code element
    definition. The
    stack size and priority are options parameters for an operating system's
    execute()
    operation. The stack size is the memory space needed by the executable and
    the OS
    priority for the executable. Data types for the values of these options are
    unsigned
    long. Priority number should be based upon industry standard such as POSIX.

    Current Format

    <!ELEMENT code
    ( ( codebase

    fileinarchive
    link
    )
    , entrypoint?
    , usage?
    ) >
    <!ATTLIST code
    type CDATA #IMPLIED >

    New Format for code

    <!ELEMENT code
    ( ( codebase

    fileinarchive
    link
    )
    , entrypoint?
    , stacksize?
    , priority?
    , usage?
    ) >
    <!ATTLIST code
    type CDATA #IMPLIED >

    <!ELEMENT stacksize (#PCDATA)>

    <!ELEMENT priority (#PCDATA)>

    b) Other valid values for type attribute
    Additional valid values for the type attribute are: "KernelModule",
    "SharedLibrary", and "Driver".

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Legacy Issue Number: 5517
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Add license element to implementation element. Why is the license element
    restricted
    to the softpkg level only? This is saying all implementations have the same
    license.
    Cannot each implementation have its own different license? Suggest adding
    license
    element to implementation element.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    license
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - abstract storage type

  • Key: CORBA34-89
  • Legacy Issue Number: 7131
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 4;
    there are still references to abstract storage type in the following
    sections:
    3.2.2 (§2), 3.2.6, 3.2.9 (point 4)

    Proposed resolution:

    Row 4 in the table 4.1, add in the "Document Impact" column :
    Section 3.2.2, paragraph 2: remove references to abstract storage type
    Section 3.2.6: remove references to abstract storage type
    Section 3.2.9, point 4: remove references to abstract storage type

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - entity components

  • Key: CORBA34-91
  • Legacy Issue Number: 7129
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to entity components in the following sections:
    3.3.3.3, 4.5.1.3 (§1), 4.5.2.3 (point 3)

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column :
    Section 3.3.3.3: remove references to entity components
    Section 4.5.1.3, paragraph 1: remove references to entity components
    Section 4.5.2.3, point 3: remove references to entity components

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - persistence

  • Key: CORBA34-92
  • Legacy Issue Number: 7128
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; there
    are still references to persistence in the following sections:
    4.2 §1, 4.2.1 §1, 4.2.12

    Proposed resolution:

    Add a row in the table 4.1 with :
    "Normative Exclusion" column : Exclude support for persistence
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    persistence
    Section 4.2.1, paragraph 1: remove reference to persistence
    Section 4.2.12: remove reference to persistence

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - section 4.1.2

  • Key: CORBA34-90
  • Legacy Issue Number: 7130
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    the section 4.1.2 doesn't have to be fully removed. Only the references to
    entiy container have to.

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column, replace
    "Section 4.1.2: remove" by "Section 4.1.2: remove reference to entity
    container API types".

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - transaction

  • Key: CORBA34-94
  • Legacy Issue Number: 7126
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.4 "exluding support for transaction", there
    are still references to the transaction feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 (point 2), 4.5.1.4, 4.5.2.4

    Proposed resolution:

    Add a row in the table 4.4 with :
    "Normative Exclusion" column : Exclude support for transaction
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    transaction
    Section 4.2.1, paragraph 1: remove reference to transaction
    Section 4.2.12: remove reference to transaction
    Section 4.5.1.1, point 2: remove reference to transaction
    Section 4.5.1.4: remove reference to transaction
    Section 4.5.2.4: remove reference to transaction

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - security

  • Key: CORBA34-93
  • Legacy Issue Number: 7127
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.5 "exluding support for security", there are
    still references to the security feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 , 4.5.1.5, 4.5.2.5

    Proposed resolution:

    Add a row in the table 4.5 with :
    "Normative Exclusion" column : Exclude support for security
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    security
    Section 4.2.1, paragraph 1: remove reference to security
    Section 4.2.12: remove reference to security
    Section 4.5.1.1: remove reference to security
    Section 4.5.1.5: remove reference to security
    Section 4.5.2.5: remove reference to security

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - abstract storage home

  • Key: CORBA34-88
  • Legacy Issue Number: 7132
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 3;
    there are still references to abstract storage homes in the following
    sections:
    1.7.4, 3.2.5 (§4), 3.2.6

    Proposed resolution:

    Row 3 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.4: remove references to storage home
    Section 3.2.5, paragraph 4: remove references to abstract storage home
    Section 3.2.6: remove references to abstract storage home

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - CIDL

  • Key: CORBA34-87
  • Legacy Issue Number: 7133
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 2;
    and the table 4.3 "exluding support for segmentation", row 1: there are
    still references to CIDL in the following sections:
    1.5.2.1 (§1), 3.1 (§1)

    Proposed resolution:

    Row 2 in the table 4.1 and Row 1 in the table 4.3, add in the "Document
    Impact" column :
    Section 1.2.2.1, paragraph 1: remove references to CIDL
    Section 3.1, paragraph 1: remove references to CIDL

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - locator

  • Key: CORBA34-86
  • Legacy Issue Number: 7141
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", row
    3; there are still references to locator in the following sections:
    3.3.3.5, paragraph 4 and last paragraph

    Proposed resolution:

    Row 3 in the table 4.3, in the "Document Impact", add:
    Section 3.3.3.5, paragraph 4 and last paragraph: remove references to
    locator

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - segmentation

  • Key: CORBA34-85
  • Legacy Issue Number: 7142
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", there
    are still references to segmentation in the following sections:
    : 3.2.1.6 (§1), 3.2.11 (§1), 3.2.9 (point 2), 4.2.12 (extended)

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - home finders and finder operations

  • Key: CORBA34-79
  • Legacy Issue Number: 7148
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.8 "exluding support for home finders" there
    are still references to finder operations and home finders in the following
    sections:
    1.7.1 (§2), 1.7.1.1, 1.7.3, 1.7.3.3, 1.7.4 (§1), 1.7.5 (heterodox), 3.3.6
    (point 5), 4.3.2.1 (get_CCM_home), 4.5, 4.5.1 (point 4, last §), 4.5.1.1
    (last point), 4.5.1.2
    The following sections have to be removed:
    1.7.3.2, 4.5.1.3, 4.5.2.3

    Proposed resolution:

    Add a row in the table 4.8 with :
    "Normative Exclusion" column : Exclude support for home finders and finder
    operations
    "Document Impact" column :
    Section 1.7.1, paragraph 2: remove reference to home finders and
    finder operations.
    Section 1.7.1.1: remove reference to home finders and finder
    operations.
    Section 1.7.3: remove reference to home finders and finder
    operations.
    Section 1.7.3.3: remove reference to home finders and finder
    operations.
    Section 1.7.4 paragraph 1: remove reference to home finders and
    finder operations.
    Section 1.7.5 (heterodox): remove reference to home finders and
    finder operations.
    Section 3.3.6, point 5: remove reference to home finders and finder
    operations.
    Section 4.3.2.1 (get_CCM_home): remove reference to home finders and
    finder operations.
    Section 4.5: remove reference to home finders and finder operations.
    Section 4.5.1, point 4 and last paragraph: remove reference to home
    finders and finder operations.
    Section 4.5.1.1, last point: remove reference to home finders and
    finder operations.
    Section 4.5.1.2: remove reference to home finders and finder
    operations.
    Section 1.7.3.2: remove
    Section 4.5.1.3: remove
    Section 4.5.2.3: remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - proxy homes

  • Key: CORBA34-80
  • Legacy Issue Number: 7147
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 1;
    in section 3.2.5, the last paragraph should be removed.

    Proposed resolution:

    Row 1 in the table 4.7, in the "Document Impact", add:
    Section 3.2.5 last paragraph:remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - invalid rows

  • Key: CORBA34-78
  • Legacy Issue Number: 7149
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 2
    and 3 are not valid

    Proposed resolution:

    remove the rows 2 and 3 of the table 4.7

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - primary key

  • Key: CORBA34-83
  • Legacy Issue Number: 7144
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 1;
    there are still references to primary key in the following sections:
    1.7.1 (§1 & §3), 1.7.4, 1.7.5.1 (§1, §2), 1.7.5.2 (§1, §2)

    Proposed resolution:

    Row 1 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.1, paragraph 1 and 3: remove references to primary key
    Section 1.7.4: remove references to primary key
    Section 1.7.5.1, paragraph 1and 2: remove references to primary key
    Section 1.7.5.2, paragraph 1and 2: remove references to primary key

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - get_all_facet, ...

  • Key: CORBA34-84
  • Legacy Issue Number: 7143
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.2 "exluding support introspection,
    navigation, ...", row 2; there are still references to these operations in
    the following sections:
    1.4.3, point 3 and 4, section 1.4.3.4, paragraph 1

    Proposed resolution:

    Row 2 in the table 4.2, in the "Document Impact", add:
    Section 1.4.3, point 3 and 4: remove references to these operations
    Section 1.4.3.4, paragraph 1: remove references to these operations

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - Section 4.1

  • Key: CORBA34-82
  • Legacy Issue Number: 7145
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; in the
    "Document Impact" column, row 1, the § 3 doesn't exist in the section 1.1.4.

    Proposed resolution:
    Table 4.1, row 1, column "Document Impact": replace "Section 1.1.4,
    paragraph 3: remove" by "Section 1.1.4, paragraph 2: remove"

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - configurators

  • Key: CORBA34-81
  • Legacy Issue Number: 7146
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.6 "exluding support for configurators";
    there are still references to configurators in the following sections:
    1.10.2 (second point), 1.10.2.1 (§2), 1.11.1 (configuration_complete)

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Checking XML DTD elements related to the trader service

  • Key: CORBA34-71
  • Legacy Issue Number: 5590
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 69-533, there is the following note

    Issue The trader elements have to be reviewed to make
    sure that they serve the purpose intended.
    Also, consider using a property file.

    XML DTD elements related to the trader service would be checked

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Description for the impltype Element?

  • Key: CORBA34-72
  • Legacy Issue Number: 5589
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In formal/02-06-65, page 6-54, there is the following text

    Placeholder for future version.

    The section 6.7.2.33 would be written.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Uses Relationships

  • Key: CORBA34-74
  • Legacy Issue Number: 5524
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    The softpkg element only deals with deployed on and library load dependency
    relationships for implementations. Component implementations may also have
    specific using relationships with another component, such as a device
    within the
    system. This relationship can be stated at the softpkg or implementation
    level.

    Current Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    usescomponent
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    usescomponent
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    <!ELEMENT usescomponent
    ( artifactdependency+
    )>
    <!ATTLIST usescomponent
    id ID #REQUIRED
    type CDATA #REQUIRED>

    <!ELEMENT artifactdependency EMPTY>
    <!ATTLIST artifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3 AssemblyFactory Interface

  • Key: CORBA34-73
  • Legacy Issue Number: 5576
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Device Artifact Dependency

  • Key: CORBA34-75
  • Legacy Issue Number: 5523
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    A component's implementation may have additional dependencies on a device's
    artifacts (e.g., capacity and/or characteristics) to ensure the right type
    of device is
    chosen for deployment and/or the device has sufficient capacities for
    deployment. To
    allow for this capability add a deviceartifactdependency element to the
    implementation element.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    deviceartifactdependency
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    <!ELEMENT deviceartifactdependency EMPTY>
    <!ATTLIST deviceartifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Dependency on D+C FTF

  • Key: CORBA34-76
  • Legacy Issue Number: 7363
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Lightweight CCM replaces CCM's Packaging and Deployment chapter
    with the "Deployment and Configuration of Component-based Distributed
    Applications" (D+C) specification, and thus Lightweight CCM cannot be
    finalized before D+C.

    I propose to defer this issue to a second FTF, to be resolved by the
    availability of D+C.

  • Reported: CORBA 3.0.3 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - Entity2Context

  • Key: CORBA34-77
  • Legacy Issue Number: 7150
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to Entity2Context in the following sections:
    3.2.11 (§2)

    Proposed resolution:

    Row 7 in the table 4.1, in the "Document Impact", add:
    Section 3.2.11, paragraph 2:remove reference to the Entity2Context
    interface.

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

A new exception specification is needed for CCM2Context::req_passivate()

  • Key: CORBA34-68
  • Legacy Issue Number: 5639
  • Status: closed  
  • Source: THALES ( Hakim Souami)
  • Summary:

    Document ptc/2001-11-03, CORBA Component Model
    ----------------------------------------------
    62.4.1.1 The CCM2Context Interface
    ....
    local interface CCM2Context : CCMContext

    { HomeRegistration get_home_registration (); void req_passivate () raises (PolicyMismatch); CatalogBase get_persistence (in _TypeId catalog_type_id) raises (PersistenceNotAvailable); }

    ;

    ....
    req_passivate
    The req_passivate operation is used by the component to inform the container
    that it wishes to be passivated when its current operation completes. To be
    valid, the component must have a servant lifetime policy of component or
    container. If not, the PolicyMismatch exception shall be raised.
    ----------------------------------------------

    What happens if req_passivate() operation is not called in the scope of a
    callback operation?
    I think that req_passivate() can only make sense if called in the context of
    a callback operation. The IllegalState exception is appropriate for this
    case.

    The IDL might then look like this :
    void req_passivate () raises (IllegalState,PolicyMismatch);

    and the following sentence might be appended to the paragraph above:
    "If this operation is issued outside of the scope of a callback operation,
    the IllegalState exception is returned."

    This addition will ease implementation of CCM2Context objects based on
    POACurrent : implementing container and component servant lifetime policies
    on a POA with RETAIN servant retention policy and the other servant lifetime
    policies on a POA with NON_RETAIN servant retention policy can rely entirely
    on the POACurrent.

  • Reported: CORBA 3.0 — Fri, 6 Sep 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM IDL style inconsistency

  • Key: CORBA34-65
  • Legacy Issue Number: 5858
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Derived component supported interface restriction (formal/2002-06-65)

  • Key: CORBA34-66
  • Legacy Issue Number: 5688
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.

    Resolution:

    In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

    "A derived component type may not directly support an interface."

    with

    "If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

  • Reported: CORBA 3.0 — Thu, 10 Oct 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue on the description of the consumesidentifier element

  • Key: CORBA34-67
  • Legacy Issue Number: 5684
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Proposed resolution:

    In the Adopted CORBA Components Specification (formal/02-06-65),
    section 6.7.2.15, page 6-50, replace 'consumingcomponent' by
    'consumesport'.

    Proposed revised text:

    In formal/02-06-65 page 6-50, replace
    A child of consumingcomponent
    by
    A child of consumesport

  • Reported: CORBA 3.0 — Mon, 14 Oct 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Using Configurator on CCMHome or any CORBA objects?

  • Key: CORBA34-70
  • Legacy Issue Number: 5591
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 69-545, there is the following note

    Issue The Configurator interface takes an argument of type
    CCMObject and therefore cannot be used to configure component
    homes. I see no reason not to widen the type to CORBA::Object
    so that the Configurator can be used for objects other than
    CCMObjects. The StandardConfigurator is after all a basic name
    value pair configurator that simply executes calls on mutator
    operations resulting from attribute declarations. J.S.E.

    The Configurator interface could be updated to allow configuration
    of any CORBA objects.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

[CCM] Interface Repository Metamodel

  • Key: CORBA34-69
  • Legacy Issue Number: 5594
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3

  • Key: CORBA34-59
  • Legacy Issue Number: 5903
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    To maintain a consistent style and to provide a detailed
    description in an XML element's first appearance, Section 6.4.5.26
    and Section 6.4.5.30 should be moved under Section 6.3 and changed
    to referring them back to the corresponding subsections like
    Section 6.4.5.29 does.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.10 (page 6-26)

  • Key: CORBA34-60
  • Legacy Issue Number: 5902
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    Section 6.4.5.10 (page 6-26): one of the child elements of the
    "containermanagedpersistence" element is "psstransactionpolicy" where
    it should have been "psstransaction" instead (see Section 6.4.5.40
    on page 6-34 and Section 7.2 on page 7-6 and 7-7).

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM spec: insufficient examples of component attributes

  • Key: CORBA34-62
  • Legacy Issue Number: 5898
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

multiple lifetime policies declaration issue

  • Key: CORBA34-64
  • Legacy Issue Number: 5870
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

3.2.7 Compositions with Managed Storage

  • Key: CORBA34-63
  • Legacy Issue Number: 5871
  • Status: closed  
  • Source: Opus Software ( Alexandre Ricardo Nardi)
  • Summary:

    Need to reflect the change in the PSS specification, in which the catalog is not user-defined anymore. The example and the cidl syntax (chapter 2) need to be changed too.

  • Reported: CCM 3.0 — Tue, 25 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.52 (page 6-38)

  • Key: CORBA34-61
  • Legacy Issue Number: 5900
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    1. Section 6.4.5.52 (page 6-38): It says the the "storagehome" element
    is a child element of "segment" where it should really say it is a
    child element of "containermanagedpersistence" instead.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

'local executor mapping'

  • Key: CORBA34-56
  • Legacy Issue Number: 5937
  • Status: closed  
  • Source: Anonymous
  • Summary:

    @@ It seems to me that generating 'local executor mapping' for supported
    by a component interfaces is not needed. Even though spec doesn't say
    directly that it's needed or not there are plenty of examples where it is
    shown generated.

    @@ According to the spec the following IDL is valid

    interface I;
    component C

    { provides I i; };


    while this is not:


    interface I;
    component C
    { uses I i; };


    Any reason for that?


    @@ According to the spec Home cannot be forward-declared. Any reason
    for that?



    @@ The following CIDL is legal according to the spec:


    interface I;
    component C
    { provides I i; }

    ;

    home H manages C
    {
    };

    composition session Impl
    {
    home executor H_Exec

    { implements H; manages C_Exec; };
    };


    However there is no way to generate valid local executor mapping for this
    CIDL. The resolution would be to require all forward-declared interfaces
    used by component's provides declarations to be defined before composition
    for this component is seen. I.e. the following CIDL would be a corrected
    version:


    interface I;
    component C
    { provides I i; };


    home H manages C
    {
    };


    interface I {};


    composition session Impl
    {
    home executor H_Exec
    { implements H; manages C_Exec; }

    ;
    };

    @@ The following legal according to the spec IDL:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    would result in local executor mapping that looks something like this:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    module M
    {
    local interface C : Components::EnterpriseComponent {};
    };

    which is illegal IDL. The resolution would be to require names like
    Components::EnterpriseComponent to be fully qualified e.g.
    ::Components::EnterpriseComponent.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

portability of CCM descriptors

  • Key: CORBA34-55
  • Legacy Issue Number: 6286
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA34-54
  • Legacy Issue Number: 6672
  • Status: closed  
  • Source: National Lab. on Distributed Processing of P.R.China ( Deng Bo)
  • Summary:

    The EnterpriseComponent should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the EnterpriseComponent interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-39

    module Components { local interface EnterpriseComponent {}; };

    with

    module Components { local interface EnterpriseComponent

    { Servant get_servant() raises (CCMException); }

    ; };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CCM 3.0 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

issue on component supporting abstract interfaces

  • Key: CORBA34-58
  • Legacy Issue Number: 5910
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM Spec: attributes are listed in the ports section?

  • Key: CORBA34-57
  • Legacy Issue Number: 5918
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a set_persistent_object method

  • Key: CORBA34-48
  • Legacy Issue Number: 7732
  • Status: closed  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    There is no standard way for container to intercept component state management.
    By which container can implement O/R mapping and management component states.

    Resolution:

    Container can intercept state management by provide a storage object for executor segment.
    Replace the following text in formal/02-06-05 on page 3-39

    module Components
    {
    local interface EnterpriseComponent
    {

    };
    };

    with

    module Components
    {
    local interface EnterpriseComponent

    { void set_persistent_object(in StorageObjectBase); }

    ;
    };

    and add the operation description

    set_persistent_object

    Set context object for executors

  • Reported: CORBA 3.0.3 — Fri, 10 Sep 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a set_context method

  • Key: CORBA34-47
  • Legacy Issue Number: 7733
  • Status: closed  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    Home executor cann't access context object. Thus some features like SMP(Self-Management Persistence) are not enabled.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components {
    local interface HomeExecutorBase {};
    };

    with

    module Components {
    local interface HomeExecutorBase

    { void set_context(in CCMContext con); }

    ;
    };

    and add the operation description

    set_context

    Set context object for home executor.

  • Reported: CORBA 3.0.3 — Fri, 10 Sep 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Generic connectivity for Receptacles, Emitters, Publishers

  • Key: CORBA34-49
  • Legacy Issue Number: 7556
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The CCMObject interface contains numerous operations for generic
    connection management (in addition to the type-specific operations
    defined by equivalent IDL for a component).

    However, there's a separate set of "connect" and "disconnect"
    operations for each kind of port, i.e., receptacles, emitters and
    publishers. This is inconvenient for generic software that treats
    ports generically, such as the deployment infrastructure in an
    implementation of the Deployment and Configuration specification.

    The set of operations might even get larger in the future, when
    Streams for CCM becomes available.

    I thus propose to add generic "connect_feature" and "disconnect_
    feature" operations that is able to interconnect compatible ports
    regardless of the type of port.

    Proposed resolution:

    In section 1.11.1, "CCMObject Interface," add the following two
    operations to the CCMObject interface:

    module Components {
    interface CCMObject : Navigation, Receptacles, Events

    { Cookie connect_feature (in FeatureName name, in Object connection) raises (InvalidName, InvalidConnection, AlreadyConnected, ExceededConnectionLimit); void disconnect_feature (in FeatureName name, in Cookie ck) raises (InvalidName, InvalidConnection, CookieRequired, NoConnection); /* other operations as before */ }

    ;
    };

    Add the following explanation to the same section:

    connect_feature

    The connect_feature operation connects the object reference
    specified by the connection parameter to the component feature
    specified by the name parameter. The feature must be either a
    receptacle, emitter or publisher port.

    If the feature identified by the name parameter is a receptacle
    port, the connect_feature operation acts equivalent to calling
    the connect operation on the Receptacles interface.

    If the feature identified by the name parameter is an emitter
    port, the connect_feature operation acts equivalent to calling
    the connect_consumer operation on the Events interface. A nil
    "cookie" value is returned.

    If the feature identified by the name parameter is a publisher
    port, the connect_feature operation acts equivalent to calling
    the subscribe operation on the Events interface.

    If the feature identified by the name parameter is neither
    receptacle, emitter or publisher port, or if the component does
    not have any feature by that name, the InvalidName exception is
    raised.

    disconnect_feature

    The disconnect_feature operation dissolves the connection
    identified by the ck cookie to the component feature specified
    by the name parameter.

    If the feature identified by the name parameter is a receptacle
    port, the disconnect_feature operation acts equivalent to calling
    the disconnect operation on the Receptacles interface.

    If the feature identified by the name parameter is an emitter
    port, the disconnect_feature operation raises the InvalidConnection
    exception if a non-nil cookie is passed as the ck parameter;
    otherwise, it acts equivalent to calling the disconnect_consumer
    operation on the Events interface.

    If the feature identified by the name parameter is a publisher
    port, the disconnect_feature operation acts equivalent to calling
    the unsubscribe operation on the Events interface.

    If the feature identified by the name parameter is neither
    receptacle, emitter or publisher port, or if the component does
    not have any feature by that name, the InvalidName exception is
    raised.

  • Reported: CORBA 3.0.3 — Thu, 1 Jul 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-50
  • Legacy Issue Number: 6689
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This question is similar to the first one. When creating component or
    facet reference of service or session component, the first step is
    creating the object reference and associating its
    PortableServer::ObjectId with servant. Currently, the container manages
    executor, but the HomeExecutorBase interface does not provide a
    mechanism to get servant. The method would be very useful as it means
    the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components {
    local interface HomeExecutorBase {};
    };

    with

    module Components {
    local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA34-51
  • Legacy Issue Number: 6688
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When creating component or facet reference of service or session
    component, the first step is creating the object reference and
    associating its PortableServer::ObjectId with servant. Currently, the
    container manages executor, but the EnterpriseComponent interface does
    not provide a mechanism to get servant. The method would be very useful
    as it means the container can use executor to get servant, which is not
    possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-39

    module Components {
    local interface EnterpriseComponent {};
    };

    with

    module Components {
    local interface EnterpriseComponent

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The association of entity component primary key and PSS key is unclear

  • Key: CORBA34-52
  • Legacy Issue Number: 6684
  • Status: closed  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.

  • Reported: CORBA 3.0.2 — Sat, 6 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-53
  • Legacy Issue Number: 6673
  • Status: closed  
  • Source: National Lab. on Distributed Processing of P.R.China ( Deng Bo)
  • Summary:

    The HomeExecutorBase should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the HomeExecutorBase interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components { local interface HomeExecutorBase {}; };

    with

    module Components { local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ; };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Contradictory sections in the CCM and Lightweight CCM specifications

  • Key: CORBA34-44
  • Legacy Issue Number: 10142
  • Status: closed  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    I'd like to report an issue that exists in both the CORBA Component Model Specification (formal/06-04-01) and also the Lightweight CORBA Component Model specification (ptc/04-06-10) please.

    In section "6.11 Component Inheritance" of formal/06-04-01 there is the statement : "A derived component type may not directly support an interface."

    This same statement is made in "1.11 Component Inheritance" of ptc/04-06-10 and in "3.17.2.3 Component Inheritance" of the CORBA 3.0.3 spec (04-03-02).

    But, in both "6.3.2.4 Inheritance and supported interfaces" of formal/06-04-01 and "1.3.2.4 Inheritance and supported interfaces" of ptc/04-06-10 there is the following:

    "For a component declaration with the following form:

    component <component_name> : <base_name>
    supports <interface_name_1>, <interface_name_2>

    { … };


    the equivalent interface shall have the following form:
    interface <component_name>
    : <base_name>, <interface_name_1>, <interface_name_2> { … }

    ;"

    The above example is giving equivalent IDL for a declaration that the preceding statements regarding component inheritance say is not permitted. It should presumably be removed.

  • Reported: CORBA 3.0.3 — Fri, 25 Aug 2006 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

spec should define how the base class of an executor is generated by the framework

  • Key: CORBA34-41
  • Legacy Issue Number: 14026
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The LwCCM removes the usage of cidl from CCM, but this looses also the fixed name of the base class of the executor. The spec should define how the base class of an executor is generated by the framework, so that the implementor of the executor can write a portable executor

  • Reported: ZIOP 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The D&C IDL part doesn't match 06-04-02.

  • Key: CORBA34-43
  • Legacy Issue Number: 10582
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The D&C IDL part doesn't match 06-04-02. For example TargetManager is not correctly in 06-04-01 and has its errors in 06-04-02

  • Reported: CORBA 3.0.3 — Tue, 9 Jan 2007 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add a sequence of CCMHome typedef sequence CCMHomes;

  • Key: CORBA34-42
  • Legacy Issue Number: 13151
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We would like to add a request to add the following IDL type. Just add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;

  • Reported: CORBA 3.1 — Wed, 10 Dec 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add some feature to let an assembly look like a monolithic compoment

  • Key: CORBA34-46
  • Legacy Issue Number: 9173
  • Status: closed  
  • Source: nudt ( jhuang)
  • Summary:

    It is better to add some feature to let an assembly look like a monolithic compoment. For example, add some discriptions in CAD(compoment assembly discription) file to identify the external interface of an assembly. There exists an delegate compoment behaving like the assembly. It can navigate one external interface of an assembly to another. This delegate compoment can be created by main component server automatically according to the CAD file.

  • Reported: CORBA 3.0.3 — Fri, 18 Nov 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

"supports" keyword

  • Key: CORBA34-45
  • Legacy Issue Number: 9174
  • Status: closed  
  • Source: nudt ( jhuang)
  • Summary:

    Issue: It is good to let CCM component definition can have operations directly, but not indirectly by "supports" keyword. The "supports" adds too much complexity when defining a compoment and compiler implementation

  • Reported: CORBA 3.0.3 — Fri, 18 Nov 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

two not used and document exceptions listed

  • Key: CORBA34-36
  • Legacy Issue Number: 15052
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL file 07-02-01 related to CCM we have the following exceptions

    exception LastConfiguration {
    };

    exception InvalidReference {
    };

    LastCOnfiguration is not listed at all in 06-04-01 and 06-04-02

    InvalidReference is listed in 06-04-02 in text and diagrams, but not in idl at all

  • Reported: ZIOP 1.0 — Tue, 16 Feb 2010 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Event mechanism proposal

  • Key: CORBA34-38
  • Legacy Issue Number: 14087
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CCM spec describes the event mechanism default part of CCM. We want to propose to change this event machine to a connector based model as part of the DDS4CCM specification. Then there would be an event connector and the container then is much more light weight and easier to use. People that don't want to use CORBA event machinisms don't pull in all the dependent code

  • Reported: ZIOP 1.0b1 — Tue, 21 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

typedef CCMObjectSeq

  • Key: CORBA34-39
  • Legacy Issue Number: 14064
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 10.3.1.2 the typedef CCMObjectSeq is listed, we propose to move it to Section 6.11.1 just after the definition of CCMObject

  • Reported: ZIOP 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The spec mentions InvalidConfiguration as exception but there is no idl in this spec

  • Key: CORBA34-40
  • Legacy Issue Number: 14061
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec mentions InvalidConfiguration as exception but there is no idl in this spec that describes this exception and its members

  • Reported: ZIOP 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ResourceCommitmentManager lacking

  • Key: CORBA34-37
  • Legacy Issue Number: 15051
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL file 07-02-01 related to CCM is lacking ResourceCommitmentManager

  • Reported: ZIOP 1.0 — Tue, 16 Feb 2010 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCMHome should have a get_components method

  • Key: CORBA34-31
  • Legacy Issue Number: 6438
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed). The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs). Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    typedef sequence<CCMObject> CCMObjects;

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); CCMObjects get_components(); }

    ;

    and add the operation description

    get_components

    The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.

  • Reported: CORBA 3.0.2 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCMHome should have a get_container method

  • Key: CORBA34-32
  • Legacy Issue Number: 6001
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for locating the container that created a home. The lack of a method to get a home's container is inconsistent with the rest of the CCM model. Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); Container get_container(); }

    ;

    and add the operation description

    get_container

    The get_container operation returns a reference to the Container object that created this CCMHome

  • Reported: CORBA 3.0.2 — Thu, 17 Jul 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Incorrect statement that implies that connect_consumer returns a cookie

  • Key: CORBA34-33
  • Legacy Issue Number: 15960
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    In chapter 6.6.8, sub paragraph "connect_consumer" the following statement is given:

    The cookie return value can be used to disconnect from the source.

    I think that this sentence should be removed from the specification since connect_consumer is declared as follows:

    void connect_consumer (
    in FeatureName emitter_name,
    in EventConsumerBase consumer)
    raises (InvalidName, AlreadyConnected,
    InvalidConnection);

    Also, disconnect_consumer doesn't provide a cookie as input parameter.

  • Reported: ZIOP 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeConfiguration::set_configuration_values should document exception

  • Key: CORBA34-34
  • Legacy Issue Number: 15164
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    HomeConfiguration::set_configuration_values documentation should mention which exception to thrown when an any/name value pair has a not supported name or when the any can't be extracted

  • Reported: ZIOP 1.0 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Interface Introspection

  • Key: CORBA34-25
  • Legacy Issue Number: 6391
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Inspired by a recent paper by Doug Schmidt and Steve Vinoski
    and the resulting newsgroup discussion on comp.object.corba,
    I have a feature request to introduce a better reflection
    mechanism into CORBA.

    At the moment, there is the CORBA::Object::get_interface()
    operation to access a matching InterfaceDef entry in an
    Interface Repository. Since an Interface Repository is
    seldomly deployed, using this operation is pretty much
    futile and will either return a nil reference or throw
    an exception.

    Therefore, I propose to add a new get_interface_def()
    operation to the Object interface that returns a FullInter-
    faceDef structure, as defined by the Interface Repository.
    This structure contains all that a dynamic client (such as
    the ones proposed by Schmidt&Vinoski, or software like
    CorbaScript or Combat) needs to know about an interface.

    A new _interface_def pseudo-operation then needs to be added
    to GIOP. This could probably be done without a version change,
    as no marshalling changes or new messages are involved, it's
    just another operation.

    On the server side, the IDL compiler would generate a suitable
    implementation as part of the skeleton. This implementation
    could just contain a binary representation of the FullInterface-
    Description structure (just like a "precompiled" TypeCode) that
    is dumped to the GIOP stream. (So that you don't need the
    Interface Repository IDL around.)

    Proposed resolution:

    In chapter 4.3, "Object Reference Operations," add the following
    operation to the Object interface:

    module CORBA {
    interface Object

    { // PIDL ... other operations ... FullInterfaceDescription get_interface_def (); }

    ;
    };

    Add the following explanation to 4.3.1, "Determining the Object
    Interface"

    4.3.1.2 get_interface_def

    FullInterfaceDescription get_interface_def ();

    The get_interface_def operation returns a data structure
    describing the most derived type of the object addressed by
    the reference. The FullInterfaceDescription structure includes
    descriptions of all the operations and attributes in the
    transitive closure of the inheritance graph of the interface
    being described. See the Interface Repository chapter for the
    contents of the data structure. Note that if an Interface
    Repository is not available, object references contained in
    this structure may be nil or inaccessible.

    In chapter 15.4.2, "Request Message", update the text that
    reads

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers and _component.

    to read

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers, _component or _interface_def.

    In the C++ language mapping, section 1.37.1, "Mapping of
    PortableServer::Servant", add the following operation to
    class ServantBase:

    namespace PortableServer { // C++
    class ServantBase

    { ... other operations ... virtual CORBA::FullInterfaceDescription_ptr _get_interface_def (); }

    ;
    }

    Update the paragraph that reads,

    ServantBase provides default implementations of the
    _get_interface, _is_a and _non_existent object reference
    operations [...]

    to read

    ServantBase provides default implementations of the
    _get_interface, _is_a, _non_existent and _get_interface_def
    object reference operations [...]

    Add a new paragraph,

    For static skeletons, the default implementation of the
    _get_interface_def function returns information about the
    interface associated with the skeleton class. For dynamic
    skeletons, the default implementation uses the
    _get_interface function to determine its return value.

    Other language mappings might need similar updates.

    By the way, since FullInterfaceDescription is only used as
    a return value, only a pointer to FullInterfaceDescription
    is needed. Therefore, you don't need the full Interface
    Repository interface descriptions but only a pointer to an
    incomplete type.

    On the client side, you only need to pull in the Interface
    Repository IDL if you are actually calling _get_interface_def.

    On the server side, the skeleton can do some ORB-dependent
    magic to push a precompiled binary data structure into the
    result.

  • Reported: CORBA 3.0.2 — Mon, 27 Oct 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Generic port connections

  • Key: CORBA34-27
  • Legacy Issue Number: 5852
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I propose to introduce generic operations that allow
    interconnecting ports regardless of their type. This
    would ease generic programming.

    The first part of the proposal is to allow generic
    usage of the "connect" and "disconnect" operations
    that are (currently) in the Receptacles interface,
    i.e. to extend the functionality to not only work
    on receptacles, but also on event source ports
    (emits and publishes keywords).

    The names "connect" and "disconnect" are appropriate
    for any kind of port, and their signatures are the
    same as "subscribe" and "unsubscribe" in the Events
    interface.

    The second part of the proposal is to introduce a
    new operation "get_port" into the CCMObject interface.
    This operation would take a FeatureName parameter and
    return the object reference associated with that
    facet or event sink.

    So I propose the following steps:

    1.) Allow connect, disconnect and get_connections to
    operate on event source ports, and introduce a
    get_port operation.
    This change would be backwards compatible.

    2.) Move connect, disconnect and get_connections from
    the now inappropriate Receptacles interface into
    the CCMObject interface. This step might cause
    minor, easily fixable breakage for software that
    widens an object reference to Receptacles instead
    of CCMObject. (I don't think any such software
    exists, it's more of a theoretical issue.)

    3.) Discourage, then remove the "subscribe" and
    "unsubscribe" operations in the Events interface.
    They don't offer any more type safety than connect
    and disconnect.

    I believe that these changes would also be of interest
    for slimming down CCM for the Lightweight CCM RFP, and
    in light of the Streams for CCM RFP (which will likely
    add another port type that needs interconnecting).

    This change does not have any impact on component
    implementations. The change to CCM implementations
    (ORBs) is neglegible (I would expect a day to make
    these changes in MicoCCM, another day to test them).

    If there is general agreement on this issue, I will
    draft the text updates.

  • Reported: CORBA 3.0.2 — Thu, 6 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LwCCM issue - Section 1.4.3.3 Exclusion

  • Key: CORBA34-26
  • Legacy Issue Number: 7027
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Navigation
    interface.

    While the normative exclusion "disable get_all_facets, get_
    named_facets, same_component operations in Navigation
    interface" retains the generic provide_facet operation,
    removing section 1.4.3.3 would remove the entire Navigation
    interface.

    On the other hand, the still-present section 1.4.3.4 references
    the disabled operations.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the second
    row, replace the text

    1.4.3.3: remove

    with

    1.4.3.3: remove these operations from the Navigation
    interface. Also remove the PortDescription, FacetDescription
    and FacetDescriptions types.

    1.4.3.4: remove

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeConfigurator should not extend CCMHome

  • Key: CORBA34-29
  • Legacy Issue Number: 5769
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Document formal/02-06-05 on page 1-49 states the following:

    "The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly."

    The first statement does not offer a clear interpretation when considering the language mapping for homes. If the implementation of a component type's home optionally supports HomeConfigurator how is this information defined in IDL? Should the component type's home definition support HomeConfiguration? This would seem to be the proper interpretation but that leads to problems in the language mapping of the defined home. In section 3.3.3.6 on page 3-45

    Home Explicit Executor Interface

    The home explicit executor callback interface is defined by the following rules:

    1. For each home <home name>, a local explicit executor interface with the same
    name as the home, but with a prefix of "CCM_" and a postfix of "Explicit" is
    defined.

    2. The explicit executor interface contains all attributes and operations declared by the
    home.

    3. If the home has a base with a name of <base name>, the explicit executor
    interface inherits CCM_<base name>Explicit. If the home does not have a base,
    the explicit executor interface inherits Components::HomeExecutorBase.

    4. If the home has supported interfaces, they are inherited by the explicit executor
    interface.

    5. Additional operations are added to the explicit executor interface for factories and
    finders, see below.

    Item 4 would imply that the home explicit executor must include operations defined in both HomeConfigurator and CCMHome since HomeConfigurator extends CCMHome. This is clearly not the intended behavior of the home explicit executor since it specifically excludes any direct inheritance of CCMHome.

    Resolution

    The inheritance of CCMHome by HomeConfiguration should be removed since it is implied that every home will extend CCMHome and home definitions in IDL would then be able to explicitly support HomeConfiguration without the extra baggage of the CCMHome interface. Furthermore, the language mapping does not properly handle a component home that supports HomeConfiguration (if it extends CCMHome) since the component executor would include all CCMHome operations. The language mapping would work fine if HomeConfiguration did not extend CCMHome.

    Replace text in formal/02-06-05 on page 1-49

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    with

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    Replace IDL in formal/02-06-05 on page 1-49

    module Components {
    interface HomeConfiguration : CCMHome

    { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); };
    };


    with


    module Components {
    interface HomeConfiguration { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); }

    ;
    };

  • Reported: CORBA 3.0.2 — Mon, 2 Dec 2002 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Session2Context interface

  • Key: CORBA34-30
  • Legacy Issue Number: 5909
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The Session2Context interface allows developers to create an object reference from an octet sequence (object id). The the Entity2Context allows developers to create an object reference from a ComponentId. Neither the Session2Context nor the the Entity2Context allows the developer to infer the octet sequence or ComponentId that is associated with an operation invocation on a component. In other words, a developer may use a context to create multiple references that are subsequently invoked by a client. When the client invokes an operation on the reference the component code will be required to satisfy the operation invocation (either through the monolithic or the locator language mapping strategy). There is no information, however, as to which of the created references is being invoked by a client. To resolve the ambiguity the component developer must be able to use the context to provide the current octet sequence or ComponentId corresponding to the reference that is currently being invoked.

    Resolution:

    Replace the following text in formal/02-06-05 on page 4-37

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); }

    ;

    with

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); CORBA::OctetSeq get_current_oid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_oid

    The get_current_oid operation is used by the component to extract the oid
    associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

    Also, replace the following text in formal/02-06-05 on page 4-44

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); }

    ;

    with

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); ComponentId get_current_cid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_cid

    The get_current_cid operation is used by a persistent component to retrieve the
    ComponentId associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

  • Reported: CORBA 3.0.2 — Tue, 22 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LwCCM issue - Section 1.6.8 Exclusion

  • Key: CORBA34-28
  • Legacy Issue Number: 7028
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Events
    interface.

    While the normative exclusion "disable get_all_consumers
    [...]" (8th row of section 10.3) retains the generic
    get_consumer, subscribe, unsubscribe, connect_consumer
    and disconnect_consumer operations, removing section 1.6.8
    would remove the entire Events interface.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the
    8th row, replace the text

    Section 1.6.8: remove

    with

    Section 1.6.8: remove these operations from the Events
    interface. Also remove the ConsumerDescription,
    EmitterDescription, SubscriberDescription and
    PublisherDescription types.

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 and page 1-21 - editorial

  • Key: CORBA34-19
  • Legacy Issue Number: 5945
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    -page 1-20 and page 1-21 the names of the operations get_all_receptacles get_named_receptacles are written with italic font. This seems to be a mistake.

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Change new GIOP Negotiate Session Message to Firewall Specific

  • Key: CORBA34-23
  • Legacy Issue Number: 6285
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We
    would get rid of all the weird nasty service contexts and make it
    simplistic. The FireWall messages are only allowed before any other GIOP
    messages. BiDir messages can happen at any time according to their
    protocol.

    What do you think? Asside from some problems I see with BiDir
    offer/challenge/response correlation, it is essentially equivalent to the
    solution proposed in the adopted spec.

    module GIOP {
    enum MsgType_1_4

    { Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment, // GIOP 1.1 addition // GIOP 1.4 additions FirewallPathRequest, // 8 FirewallPathRepsonse, // 9 BiDirOffer, // 10 BiDirChallenge, // 11 BiDirResponse // 12 }

    ;

    // Firewall Traversal GIOP 1.4

    struct FirewallSpec

    { boolean is_intelligent; IOP::TaggedComponentSeq endpoints; }

    ;
    typedef sequence<FirewallSpec> FirewallPath;

    struct FirewallPathRequestHeader

    { unsigned long host_index; FirewallPath path; }

    ;
    // No body follows.

    enum FirewallPathResponseStatusType

    { NO_EXCEPTION, SYSTEM_EXCEPTION }

    ;

    struct FirewallPathResponseHeader

    { FirewallPathResponseStatusType status; boolean connection_complete; }

    ;
    // Marshalled body immediately follows

    // Bidirectional GIOP 1.4

    // To keep this file uncomplicated we can introduce the
    // headers and put the marshalled bodies in a separate BiDir module
    // Due due some issue about the challege/response protocol for this,
    // there may be a need of an offer_id to correlate them.

    struct BiDirOfferHeader

    { unsigned long offer_id; };
    // Marshalled body immediately follows.


    struct BiDirChallengeHeader { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.

    struct BiDirResponseHeader

    { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.
    };

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

GIOP Conformance and Interceptors

  • Key: CORBA34-22
  • Legacy Issue Number: 6314
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    GIOP Conformance and Interceptor don't play well together.

    GIOP minor version conformance mandates two things.

    1. That standard service contexts that are considered optional
    can be ignored should the implementation not understand them.

    2. That certain service contexts get processed according to the
    specification of where they are defined.

    This requirement works well for GIOP 1.2 where a lot of them are optional,
    since (1) will apply. An implementation can claim 1.2 conformance and not
    process any of them.

    However, 1.3 and upcoming 1.4 will mandate the processing of them
    according to their specification. In many cases, this means that some
    default response may be required, which means that a GIOP 1.3, or later
    engine must have a "default" response for these service contexts.

    In an ORB that uses interceptors and has a generic GIOP messaging engine
    there is no way for the engine to "know" when or not to process a
    particular service context. It requires strict processing by the GIOP
    engine, or it requires "default" interceptors to be installed to maintain
    the level of conformance.

    However, interceptors have no way of "declaring" which service contexts
    they handle, and whether they they are overriding already installed
    (default) interceptors for processing those particular service contexts.

    For example, an non-transactional ORB that is GIOP 1.2 compliant must
    process the Transaction Service Context by raising a
    TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the
    OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but
    by certain in implementations it ALWAYS is). A default interceptor is
    needed in the ORB implementation to do this. However, for an ORB
    configuration that wants to process this, there is no way for an
    interceptor to "override" default processing.

  • Reported: CORBA 3.0.2 — Wed, 8 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

context interface for home implementation

  • Key: CORBA34-21
  • Legacy Issue Number: 5936
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    The home interface could have freely defined operations or can support an
    interface with such operations. A home context interface may help to implement
    such operations. E.g. a home implementation needs this context interface to
    determine its own object reference.

    suggestion:

    Add a home context interface that is similar to the component context interface.
    Add a set_context operation at the HomeExecutorBase interface.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 the description of the get_connection operation

  • Key: CORBA34-20
  • Legacy Issue Number: 5944
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    page 1-20 the description of the get_connection operation refers to a ConnectionDescription struct. In fact it is a ConnectionDescription valuetype

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet and CSIv2 Negotitaion

  • Key: CORBA34-24
  • Legacy Issue Number: 6283
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    I believe that we send CSIv2 stuff in a GIOP Request until a corresponding
    GIOP reply has been containing corresponding CSIv2 context ids is sent.

    For Codeset, I think the policy is to send the service context in each
    GIOP request until a corresponding GIOP Reply is received, thereby saying
    that the "negotiation" is completed and excepted (otherwise an exception
    will be raised.

    We should probably look at the fact that multiple NSReq messages can be
    sent, and there are no corresponding reply messages depending on the
    service contexts.

    I think that these messages should be intercepted since they are
    delivering service contexts.

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

valuetype fragmentation ambiguous

  • Key: CORBA34-13
  • Legacy Issue Number: 5941
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.

    In particular 15.3.4.6:

    Bullet 1 says:

    "End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
    so that the unmarshaling code can tell after reading each chunk whether:
    • another chunk follows (positive tag).
    • one or multiple value types are ending at a given point in the stream (negative
    tag).
    • a nested value follows (special large positive tag)."

    Bullet 3 says:

    "• For the purposes of chunking, values encoded as indirections or null are treated as
    non-value data."

    And the pseudo-BNF says:

    "(1) <value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>

    <value_ref>
    (2) <value_ref> ::= <indirection_tag> <indirection>
    <null_tag>
    (3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (4) <type_info> ::= <rep_ids>
    <repository_id>
    (5) <state> ::= <octets>
    <value_data>* [ <end_tag> ]
    (6) <value_data> ::= <value_chunk>
    <value>"

    Now clearly the implication of bullet 1 is that an indirection or null must appear inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.

    So I propose that we change the 3rd bullet to say:

    "For the purposes of chunking, values encoded as indirections or null are treated as
    if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."

    and then change the BNF to say:

    "(1) <value> ::= <concrete_value> | <value_ref>
    (2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>
    (3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
    (4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (5) <type_info> ::= <rep_ids> | <repository_id>
    (6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
    (7) <value_data> ::= <value_chunk> | <concrete_value>"

    etc

  • Reported: CORBA 3.0.2 — Fri, 23 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Clarification on multi-threaded codeset negotiation

  • Key: CORBA34-14
  • Legacy Issue Number: 5880
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue.

    The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6):

    "Codeset negotiation is not performed on a per-request basis, but only when a client
    initially connects to a server. All text data communicated on a connection are encoded
    as defined by the TCSs selected when the connection is established."

    but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter.

    There are two possible approaches to solving this:

    a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests.

    b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information).

    CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen?

  • Reported: CORBA 3.0.2 — Tue, 11 Mar 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

15.3.3 - codesets must be "explicitly defined"

  • Key: CORBA34-15
  • Legacy Issue Number: 6050
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    For codesets in encapsulations we have:

    15.3.3 - codesets must be "explicitly defined"

    Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it"

    But in 13.8 there is no prescribed way of "explicitly defining" the codeset.

    Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it.

    Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8.

  • Reported: CORBA 3.0.2 — Tue, 26 Aug 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

[Components] Contradiction between IDL and Interface Repository concerning

  • Key: CORBA34-16
  • Legacy Issue Number: 6671
  • Status: closed  
  • Source: Humboldt-Universitaet ( Bertram Neubauer)
  • Summary:

    According to the IDL language it is allowed to define a facet/receptacle on a component with type of Object. The text says:

    A facet is declared with the following syntax:
    (120) <provides_dcl> ::= “provides” <interface_type> <identifier>
    (121) <interface_type> ::= <scoped_name>

    “Object”
    The interface type shall be either the keyword Object, or a scoped name that denotes
    a previously-declared interface type which is not a component interface, ...

    In contradiction to that the Interface Repository element for a component, the ComponentDef, does only allow the creation of facets/receptacles with type of InterfaceDef. The according operations are:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type,
    in boolean is_multiple
    );

    Thus the ComponentDef can not be used to create a facet/receptacle that is of type Object, since Object is no InterfaceDef but a PrimitiveDef.
    One solution would be to use IDLType instead of InterfaceDef since PrimitiveDef and InterfaceDef inherit from that interface. My proposal is to change the Interface Repository IDL in the following way.

    1) replace in ComponentDef:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type,
    in boolean is_multiple
    );

    2) replace ProvidesDef, ProvidesDecsription, UsesDef, UsesDescription with

    interface ProvidesDef : Contained

    { // read interface readonly attribute IDLType interface_type; }

    ;

    struct ProvidesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; }

    ;

    interface UsesDef : Contained

    { // read interface readonly attribute IDLType interface_type; readonly attribute boolean is_multiple; }

    ;

    struct UsesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; boolean is_multiple; }

    ;

  • Reported: CORBA 3.0.2 — Wed, 3 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Chapter/section: 15.4.2.2 "Request Body"

  • Key: CORBA34-17
  • Legacy Issue Number: 6287
  • Status: closed  
  • Source: 2AB ( Carol Burt)
  • Summary:

    Suppose you are sending a request (GIOP 1.2 or 1.3) and the request will
    be fragmented into two segments. The first segment is a Request message
    that has the GIOP Header and part of the Request Header. The second
    segment is a Fragment message that has a GIOP Header, a Fragment Header,
    and the body is the remainder of the Request Header and the Request Body.
    Section 15.4.2.2 of CORBA 3.0 states that the Request Body (in a Request
    Message) should always be aligned on an 8 octet boundary.

    My question is, in the above scenario, where the Request Body begins in
    the Fragment message, should the Request Body be aligned on an 8 octet
    boundary or not? I have not found anything in the specification that
    explicitly says what to do.

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

page 1-20 second bullet of the description of the disconnect operation

  • Key: CORBA34-18
  • Legacy Issue Number: 5943
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    I found some minor editorial issues in the spec (referring to the document 02-06-65).

    • page 1-20 second bullet of the description of the disconnect operation. An 'and' is missing. This bullet should look like: "If the receptacle is a simplex receptacle and there is no current connection, then the NoConnection exception is raised."
  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Duplicate union labels

  • Key: CORBA34-7
  • Legacy Issue Number: 704
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

COM Sequence changes

  • Key: CORBA34-6
  • Legacy Issue Number: 703
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Changes to ForeignComplexType

  • Key: CORBA34-8
  • Legacy Issue Number: 701
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13A.5.2: Editorial

  • Key: CORBA34-9
  • Legacy Issue Number: 708
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13A.2.3: editorial

  • Key: CORBA34-10
  • Legacy Issue Number: 707
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Capter 13C: Editorial

  • Key: CORBA34-11
  • Legacy Issue Number: 709
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Incorrect mappings for systems exceptions (part A)

  • Key: CORBA34-12
  • Legacy Issue Number: 679
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13C.1.3 Editorial

  • Key: CORBA34-5
  • Legacy Issue Number: 710
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Levels of Indirection for passing COM types

  • Key: CORBA34-4
  • Legacy Issue Number: 702
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Additions for convenience methods

  • Key: CSRM-14
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The following changes are proposed (note that there are some changes from the original proposal to make it more complete and correct):

    Changes to: 7.6.3 ExtRequirement
    1) add /validatedBy:ValidationActivity[0..*]
    Documentation: The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
    2) add getValidatedBy():ValidationActivity[0..*]
    documentation: The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
    specification: Validate.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier

    Changes to: 7.6.3 VerificationActivity
    add:
    verifies : AbstractRequirement[0..*] - The requirements that this VerificationActivity verifies.
    add to doc (was already part of profile):
    verificationMethod : VerificationMethodKind -The verificationMethod indicates the primary method that «VerificationActivity» uses to verify a Requirement.

    added

    getVerifies():AbstractRequirement[0..*]
    Specification: Verification.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
    Documentation: The query getVerifies() returns all AbstractRequirement that are suppliers ( "to" end of the concrete syntax ) of a «Verifies» relationship whose client is the element input parameter, ref. This is a static query.

    Change to: Figure 7 SysML Extensions Profile
    Update diagram to reflect the addition of /validatedBy:ValidationActivity[0..*] element on the ExtRequirement Stereotype.

    Change to: Figure 5 Validation and Verification Profile
    Update diagram to show the addition of /verifies:AbstractRequirement[0..*] on the VerificationActivity stereotype.

  • Reported: CSRM 1.0b2 — Fri, 22 Apr 2022 20:31 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add derived properties and methods to improve usability.

    Add elements and add a clarifying note to model and specification:

    Changes to ExtRequirement

    1) add /validatedBy:ValidationActivity[0..*]
    Documentation: The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
    2) add getValidatedBy():ValidationActivity[0..*]
    documentation: The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
    specification: Validate.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier

    Note about this change: First, this is intended to mirror the same pattern as SysML. Second, the verifies and verifiedBy already exists in abstractRequirement. Because Verifies is a kind of Verify, no change is required.

    Changes to VerificationActivity
    1) add /verifies:VerificationActivity[0..*]
    2) add getVerifies():VerificationActivity[0..*]
    Specification: Verification.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
    Documentation: The query getVerifies() returns all the NamedElements that are suppliers ( "to" end of the concrete syntax ) of a «Verifies» relationship whose client is the element input parameter, ref. This is a static query.

    Change to: Figure 7 SysML Extensions Profile
    Update diagram to reflect the addition of /validatedBy:ValidationActivity[0..*] element on the ExtRequirement Stereotype.

    Change to: Figure 5 Validation and Verification Profile
    Update diagram to show the addition of /verifies:AbstractRequirement[0..*] on the VerificationActivity stereotype.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Add comments to 7.6.3 ExtRequirement source/Risk elements

  • Key: CSRM-31
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    We are missing the comments to source and risk of ExtRequirement. The elements also need to be printed in the specification. Other tag definitions are also not printed and thus need to be displayed.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 21:53 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    *Add comments to 7.6.3 ExtRequirement *

    Add the following text to 7.6.3 after the Generalization section. To be clear, when complete with all changes we have for 7.6.3, paragraph should look like this:

    Description
    The «ExtRequirement» is a mix-in stereotype that contains generally useful attributes for requirements.
    Note: This stereotype should be used instead of the «extendedRequirement» in the SysML non-normative extension of SysML
    Generalization:
    • SysML::Requirements::Requirement
    Attributes
    • risk : RiskKind - Risk level of the requirement.
    • source : String - Source (originating person and/or organization) of the requirement.
    • /validatedBy : ValidationActivity[0..*] - The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
    Operations:
    • getValidatedBy - The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
    specification:
    Validate.allInstances()->select(base Abstraction.client=ref).base_Abstraction.supplier

  • Updated: Tue, 27 Sep 2022 12:48 GMT

MeasurementSpecification missing documentation

  • Key: CSRM-28
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Need to add documentation of MeasurementSpecification.summary (paragraph 7.28) and fix MeasurementSpecification.id missing documentation.

    The summary element is missing documentation.
    The id incorrectly indicates that it is the id of a requirement, rather than a MeasurementSpecification.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:38 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add documentation to summary and fix documentation in summary

    Add/change documentation as follows to the model and to the specification:

    MeasurementSpecification.summary
    add documentation: The summary is a textual description of constraints, and measurement activities used to provide insight into the progress made in the definition and development of the technical solution, risks, and issues.

    MeasurementSpecification.id
    From: The unique id of the requirement.
    to: The id of the MeasurementSpecification.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

VerificationActivity missing documentation on verificaionMethod

  • Key: CSRM-26
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    VerificationActivity.verificationMethod is missing documentation.

    Proposed fix: add documentation to
    The verificationMethod property indicates the primary method that VerificationActivity uses to verify a Requirement.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:13 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    add documentation to VerificationMethod and show attributes of VerificationActivity

    Change to: 7.4.3 VerificationActivity
    Add the following text to 7.4.3:
    In the profile, add documentation to the verifies attribute of <<VerificationActivity>>:

    The requirements that this VerificationActivity verifies.

    Add previously undocumented attributes (verificationMethod and verifies) of <<VerificationActivity>>: to the specification by adding the revised text to paragraph 7.4.3.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change 7.6 SysML Extentions

  • Key: CSRM-3
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Section 7.6 to be replaced with an official SysML extensions profile. Section 1.6 was a hack that allowed the specification to move forward.

    Unfortunately replacing this section with a SysML profile may not be easy because of issues with how vendors have implemented the SysML extensions. It may be simpler to replicate all or part of the extensions.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:51 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    No change to 7.6 SysML Extensions is required

    No change to 7.6 SysML Extensions is required.

    The creation of an official version of SysML Extensions seems unwise as all the vendors and lots of users would be affected. The current profile described in this section is adequate for our purposes.

    Note: We already voted on this, but having to recreate it because the result was lost.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Add relationship convenience attribute for Validated and other relationships

  • Key: CSRM-2
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    David Kaslow requested that derived properties be added to allow reporting.

    For example, a user of the profile should be able to add to a table a column that matches the Validated By or Validates concepts (and others) similar to how tables can display Verified By and Verifies.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:38 GMT
  • Disposition: Duplicate or Merged — CSRM 1.0
  • Disposition Summary:

    Issue resolved in CSRM-14

    CSRM-2 was re-opened to change the priority (I did not realize this could be modified), CSRM-14 essentially duplicates the issue and was already resolved. Best thing to do is to close this issue as a duplicate of CSRM-14.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Modify Paragraph 2 to remove redundant reference to the machine readable file.

  • Key: CSRM-41
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    As the spec already has a reference to the machine-readable file, this line is redundant.

    This line in paragraph 2 should be removed:

    dtc/22-04-06 - CSRM Profile - XMI File (see the description in Section 6)

    Reported by Pete Rivett during FTF review.

  • Reported: CSRM 1.0a1 — Fri, 17 Jun 2022 19:49 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Remove the following text in section 2 Conformance

    Remove the following text in section 2 Conformance

    dtc/22-04-06 - CSRM Profile - XMI File (see the description in Section 6)

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Clarify usage of Group stereotype

  • Key: CSRM-35
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Clarify the use of the Group stereotype.
    Pete Rivette wrote:
    7.1.12 says that <<Group>> groups related requirements but not which property is used to achieve that.

  • Reported: CSRM 1.0a1 — Thu, 16 Jun 2022 13:46 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add Clairifying info and paragraph to documentation of 7.1.12 Group

    Change the existing documentation of 7.1.12 Group to help understand how the element is used and examples of use.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change names from CubeSat to Satellite

  • Key: CSRM-11
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The original issue is perhaps incorrect as I misunderstood the intent. The name changes were to additions to the spec. I am proposing to close with no change as only CubeSatRequirement actually exists and a SatelliteRequirement is there if desired by a user of the profile.

  • Reported: CSRM 1.0b2 — Thu, 21 Apr 2022 20:06 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Incorrectly submitted issue was against a future plan

    JD complained that the priority was incorrect. Changed priority to trivial.
    This was originally written up as a bug of initial submission, but it is actually against a proposed plan, not the current version. It is therefore immaterial to the changes of the FTF, so Closed: No Change.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Remove Section 0 (zero)

  • Key: CSRM-17
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Remove section 0 (zero) from finalized specification.

  • Reported: CSRM 1.0b2 — Fri, 22 Apr 2022 20:47 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Change already made by OMG editor

    Added the task without realizing that taskj already performed by OMG editor. No change required

  • Updated: Tue, 27 Sep 2022 12:48 GMT

This issue created by mistake

  • Key: CSRM-8
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    This issue created by mistake

  • Reported: CSRM 1.0b2 — Thu, 21 Apr 2022 18:24 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Removal of incorrectly created subtask

    Parent task is closed; No Change, so doing the same with sub task.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Recommended Additions

  • Key: CSRM-12
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    To make the case for updating CSRM stereotypes. Once agreement is reached, updates to the CSRM Specification will be developed.
    This is a big deal and needs lots of discussion.

    Figures 1 lists CSRM element stereotypes. Black font denotes current baseline as captured in the normative CSRM Profile. Blue font denotes recommended additions.

    Figure 2 lists requirement elements related properties that are part of the SysML language.

    Figure 3 illustrates one of many ways to establish relationships between the mission stakeholders, requirements, technical measures, and use cases stereotypes. These stereotypes are denoted by italicized font in Figure 1.
    The relationships are captured in the element specifications and are displayed and maintained in diagrams and tables as shown in Figure 1.
    Object Constraint Language

    There has been discussion about codifying the allowable relationships using Object Constraint Language (OCL). OCL is a declarative language describing rules applying to Unified Modeling Language (UML) models. For example, a refine relationship can exist between a requirement. and any other model element, whereas a derive relationship can only exist between requirements.

    That could be done founded on the examples in Figure 3. This would be of limited benefit. A mission team will be using the stereotypes and relationships best suited to their mission and the stereotypes in Figure 3 are very limited as compared to Figure 1.

    A case could be made to established relationships for the stereotypes in Figure 1. But that is out-of-Scope for the SSWG CSRM effort.

    An Issue that Needs Resolution.

    The intent of defining addition stereotypes as shown in Figure 1 is to provide stereotypes for a variety of mission architectures. However, several of the stereotypes are identified as CubeSat stereotypes. But they are not unique to CubeSats. The only thing that makes a model a CubeSat model is the incorporation of a CubeSat form factor such as the Cal Poly CubeSat Design Specification.

    My recommendation is to rename the stereotypes as show in Table 1 below.

    Table 1. Renaming of Stereotypes (Proposed name changes from Figure 1)
    CubeSatRequirement SatelliteRequirement
    CubeSatSubsystemRequirement SatelliteSubsystemRequirement
    CubeSatComponentRequirement SatelliteComponentRequirement
    CubeSatUseCase SatelliteUseCase
    CubeSatSubsystemUseCase SatelliteSubsystemUseCase

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    Defer to RTF

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Add constraints to aid in correctness of profile useage

  • Key: CSRM-4
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Constraints should be added to aid in the creating of correct models. For example, an MoE needs to be related to a moeRequirement which in turn is refined by a moeSpecification.

    In addition, by categorization and content of warings and error of the constraints, we could add hints for new users of minimal and advanced concepts.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer adding constraints to RTF

    This is rather complex and our team does not have the resources to address. It is also better to address the constraints as people begin to use the profile and as RTF possibly expands the standard.

    Note: We already voted on this in Ballot #1, but the result was lost.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change names from CubeSat to Satellite.

  • Key: CSRM-9
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Dave Kaslow proposes the following changes to stereotypes:

    From: CubeSatRequirement to: SatelliteRequirement
    From: CubeSatSubsystemRequirement to: SatelliteSubsystemRequirement
    From: CubeSatComponentRequirement to: SatelliteComponentRequirement
    From: CubeSatUseCase to: SatelliteUseCase
    From: CubeSatSubsystemUseCase to: SatelliteSubsystemUseCase

    Document attached was where the issue was raised.

  • Reported: CSRM 1.0b1 — Thu, 21 Apr 2022 19:43 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Issue created by mistake

    This issue related to a proposal and this was mistakingly created against the FTF. Closing with no change required.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Create examples of use of the profile

  • Key: CSRM-5
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Originally the first versions of CSRM had examples. However, when the spec was reduced to a profile, the examples were removed. Because of some of the changes, not all examples are viable, so it is proposed we create new examples. Dave Kaslow also requested that the examples be categorized as a simplified and expert use of the profile to aid adoption by students.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    The profile is fairly straight forward with much of the vocabulary in MBSE and space domains. Deferring issue to RTF to reconsider for a later version.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Icons for profile

  • Key: CSRM-1
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The original icons used for stereotypes in the profile were drafts and need to be replaced with better versions. The icons also need to be delivered as SVG.

    The document does not currently show these icons, so diagrams need to be updated or an appendix added to the icons.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    Punting this issue to the next release.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Remove Section 0 from the document

  • Key: CSRM-16
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Per standard process, Section 0 (zero) is to be removed from the Finalized document.,

  • Reported: CSRM 1.0a1 — Fri, 22 Apr 2022 20:42 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Change already made by OMG editor

    Closing subtask that was created by mistake..

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Provide a simple sample application

  • Key: CORBARS_-1
  • Status: closed  
  • Source: OpenText Inc. ( Mr. Matteo Vescovi)
  • Summary:

    It would be good to show a sample simple application that shows use of the REST mapping as proof of concept of use of the spec.

    While there are fragments sprinkled in the specification document, a simple application would be useful and ease adoption.

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:47 GMT
  • Disposition: Resolved — CORBA-REST 1.0
  • Disposition Summary:

    Add sample application walkthrough in Appendix A

    Add non-normative appendix A.

    The appendix walks through the steps involved in exposing a REST API to a sample CORBA application using the IDL-RS annotations.

  • Updated: Tue, 27 Sep 2022 12:47 GMT
  • Attachments:

Provide example of authentication and security

  • Key: CORBARS_-2
  • Status: closed  
  • Source: OpenText Inc. ( Mr. Matteo Vescovi)
  • Summary:

    It would be nice to have some discussion/example in the document for REST authentication and security.

    I think this would help with adoption.

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:50 GMT
  • Disposition: Resolved — CORBA-REST 1.0
  • Disposition Summary:

    Add example showing how to secure an application in appendix B.

    Add non-normative appendix B.

    Appendix B illustrates how security might be added to the example REST for CORBA application described in Appendix A.

  • Updated: Tue, 27 Sep 2022 12:47 GMT
  • Attachments:

FTF-1 changes to be applied to GraphQL PSM

  • Key: C2INAV11-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Some but by now means all of the Issue Resolution from FTF-1 are applicable to the GraphQL PSM. These should be determined and applied as appropriate.

  • Reported: C2INAV 1.0a1 — Thu, 14 May 2020 20:13 GMT
  • Disposition: Resolved — C2INAV 1.1
  • Disposition Summary:

    Generate new GraphQL PSM Schema from the PIM

    The 1-1 FTF did not apply PIM changes to the GraphQL PSM. Furthermore the proposed schema mapping was in practice less than optimal for specialization-generalization relationships, leading to a complicated mapping in many GraphQL software language clients.
    This proposal uses an improved mapping where there is a base type for common attributes and union for the specialized attributes.

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Update GraphQL PSM Mapping

  • Key: C2INAV11-3
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The GraphQL mapping in the specification and defined in the schema files leads to an unnecessarily complicated implementation of the standard and should be simplified

  • Reported: C2INAV 1.0 — Sat, 29 Jan 2022 19:02 GMT
  • Disposition: Duplicate or Merged — C2INAV 1.1
  • Disposition Summary:

    Regenerate GraphQL PSM with updated mapping

    The updated mappings from PIM to GraphQL as incorporated into the TDAI beta spec should be used.

  • Updated: Wed, 13 Jul 2022 14:18 GMT

Add mapping for @optional

  • Key: CPP1116-19
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification should specify the mapping of @optional, maybe maybe to IDL::optional which could be an using of std::optional with C+17, only for C11/C+14 at that moment the API of IDL::optional should be specified

  • Reported: CPP11 1.5 — Thu, 19 Aug 2021 08:21 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Map optional struct members

    Unlike other standardized annotations that are impact the middleware platform, the IDL @optional annotation impacts the language mapping.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Impact of @final on union/struct mapping

  • Key: CPP1116-20
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The @extensibilty(FINAL) or @final annotation is one of the new annotations in IDL4.2, see 8.3.16 of IDL4.2. Should the generated class for a struct/union which is annotated with @final be generated as a C++11 final class or not? So

    struct Foo final {}

    or

    struct Foo {}

  • Reported: CPP11 1.5 — Fri, 3 Sep 2021 11:32 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    Extensibility annotations do not impact the language mapping

    The concept of type extensibility is defined in IDL4.2 as "specifying how
    the element is allowed to evolve." The language mappings determine how each IDL source file is mapped. In terms of this "evolution," the mapping is just capturing a single point in time. Neither of the IDL4-specific mappings (C# or Java) map extensibility to a programming language feature.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Add IDL::traits<>::bit_bound

  • Key: CPP1116-11
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For template programming it could be helpful to have a IDL::traits<>::bit_bound trait of type std::integral_constant which returns the bit_bound set in IDL for a bitmask

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:32 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Add traits member specification to Bit Masks section

    Specify the bit_bound member of IDL::traits for Bit Masks

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Invalid constructor in example code

  • Key: CPP1116-12
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The example code has

    OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type;

    But this is not correct, it should be

    OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type);

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 12:05 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Fix invalid example code

    A closing parenthesis was missing from the example code.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Use IDL::traits<>::make_reference instead of CORBA::make_reference

  • Key: CPP1116-18
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For creating a client side reference the specification uses currently CORBA::make_reference but this logic is not really CORBA specific and in a LwCCM system which only uses local interfaces the usage of CORBA is polluting user code. One of the key concepts of IDL to C++11 is that the user doesn't need to remember any special naming rules so we don't want to tie a factory function to some implementation name. The IDL to C++11 specification already uses the IDL::traits<> concept which is specialized based on the IDL type. We propose to extend the IDL::traits<> for interfaces/valuetypes for a make_reference factory method so that user code given an interface A can create an object reference using IDL::traits<A>::make_reference.

    In the specification we propose the following changes:
    6.7.1, replace CORBA::make_reference with IDL::traits<>::make_reference
    6.18.7.1 replace CORBA::make_reference <StringValue> with IDL::traits<StringValue>::make_reference
    6.18.10.2 replace CORBA::make_reference<> with IDL::traits<>::make_reference
    6.25 replace CORBA::make_reference<> with IDL::traits<>::make_reference and CORBA::make_reference <MyLocalIF> (); with IDL::traits<MyLocalIF>::make_reference ();

    The CORBA::make_reference() can be easily kept by an implementation for backwards compatibility but this proposal enables the user to write code that is more CORBA independent

  • Reported: CPP11 1.5 — Tue, 15 Jun 2021 09:24 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary: