C Language Mapping Avatar
  1. OMG Specification

C Language Mapping — Closed Issues

  • Acronym: C
  • Issues Count: 2,708
  • 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
C2MS12-221 Adjust Description for Telemetry CCSDS Transfer Frame - PARSE-ERRORS C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-191 General Cleanup of the Subject Content of Subject Naming Tables C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-162 Some examples of Subject Subscriptions use Wrong Form C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-54 Consider buying back some messages created for some specific missions as a possible new message in C2MS. C2MS 1.2b1 C2MS 1.2b1 Resolved closed
C2MS12-48 Improve Example Text for Publish Rate C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-28 Rework "Introduction to Specification" into a Section Describing Expected Use C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-143 Create final version of all model diagrams that have more than one resolution C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-39 Need Review/Documented Explanation of NUM-OF-PROD-SUBTYPE-SUBCATEGORIES C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-212 Replay TLM Data Response Message text correction C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-190 Two incorrect Subject Naming Tables C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-144 The Model still has Optional Fields and Required Fields classes C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-201 Add subsection description for Generic Service RESP and DATA MSGs C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-79 Create a C2MS SM&C MAL Message C2MS 1.1b1 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-204 Adjust FINAL-MESSAGE Verbiage for Response Messages C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-181 Product Messages do not have Message Summary Tables C2MS 1.1b1 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-153 REQUEST-ID is Required in Product Message, but Shouldn't be C2MS 1.1b1 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-196 Rework 8.12 Product Messages Intro C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-150 Rework "Response" Semantics in Product Message C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-161 Cleanup of Message Summary Tables C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-192 Make ME1 Optional for all Request Messages C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-176 Deprecate 1=Acknowledgment for MVAL Response Message C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-15 Using REQ Messages for 'Publish' C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-164 Make SERVICE-NAME an Alternate way to Reach a Service C2MS 1.1b1 C2MS 1.2b1 Closed; No Change closed
C2MS12-22 Replace simple service REQ/RESP C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-5 Acknowledge Final Status inconsistency C2MS 1.0b1 C2MS 1.2b1 Resolved closed
C2MS12-167 Documentation Changes to Move Away from Pub/Sub Expectation C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-177 Improve Representation of Message Types C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-168 Allow SERVICE-GROUP/NAME/OP-NAME in lieu of or along side DESTINATION-COMPNENT C2MS 1.1b1 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-155 Should Typed Variable DATA-VALUE be String instead of binary C2MS 1.1b1 C2MS 1.2b1 Closed; No Change closed
C2MS12-160 Do we need to add the ability to include a Classification Level? C2MS 1.1b1 C2MS 1.2b1 Closed; No Change closed
C2MS12-165 Replace "Publish" with "Broadcast" C2MS 1.1b1 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-118 Allow custom message subtypes C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-109 Need to update references to NASA Goddard Docs C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-126 Recommend UTF-8 for Text Encoding in C2MS implementations/usage C2MS 1.1 C2MS 1.2b1 Resolved closed
C2MS12-156 in 8.1, we sometimes have table and section names that have wrong term C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-154 Fix change in Table 8-155 Product Request Message Add'l Info C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-142 Missing Type for MVAL Data and AMVAL Data Messages C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-50 use of brackets not consistent for Subject Elements C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-35 Non-sensical Description for PROD-MSGS-TO-SEND C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-20 Clarity and Usage Issues with Replay Telemetry Data Request (and Response) Message C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-17 Split ME1 in Simple Service Req/Resp C2MS 1.0 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-119 Correct Final Message Construct C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-139 Fix diagrams from C2MS12-8 Resolution C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-41 Lack of Required Fields in Sub-elements C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-89 Resource Message Additional Information is blank for NUM-OF-DISKS Type and Presence C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-117 sometimes incorrect 'nth' sample or 'first' sample text C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-116 Wrong Relationship in Model Diagrams - Simple Service C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-114 Consider a list of Metadata Items for Command Request Message C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-113 Verify FORMAT Options for some Navigation Data Messages C2MS 1.1b1 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-93 Remove 'Not used' Designators in "Properties of Miscellaneous" Tables C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-91 Standardize Table Cell Borders C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-108 Represent Time as UTC C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-10 In message tables, make use of an enum type to designate a discreet list C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-84 Fix Use of 'Severe' in Diagrams (Should be 'Critical') C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-87 Standardize Sections and Section Names for Message Subjects C2MS 1.1b1 C2MS 1.2b1 Resolved closed
C2MS12-43 Rework Log Message C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-67 Revisit Completion Status in Command Response Message C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-51 Refactor "Introduction to Specification" section in front matter of Document C2MS 1.0 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-46 What to do when Priority isn't Specified C2MS 1.0 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-53 Make C2MS Messages Extensible C2MS 1.2b1 C2MS 1.2b1 Resolved closed
C2MS12-42 Required or Optional for MNEMONIC Status on Data Messages C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-37 AMVAL Value Response Doesn't Mirror MVAL Value Response Message C2MS 1.0 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-31 Consider Deprecating and Later Removing Resource Message C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-16 Define a Way to Create Argument-based Commands for the Command Request Message C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-18 Command Echo Not Provided Message C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-66 Consider a Command Completed Publish Message C2MS 1.0 C2MS 1.2b1 Closed; No Change closed
C2MS12-8 Larger Data Types C2MS 1.0 C2MS 1.2b1 Resolved closed
C2MS12-47 Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message C2MS 1.0 C2MS 1.2b1 Closed; No Change closed
C2MS12-19 Replace Unsolicited Echo with a Separate Message C2MS 1.0 C2MS 1.2b1 Closed; No Change closed
C2MS12-11 Add a Message Exchange Pattern (MEP) for a component to forward requests/responses C2MS 1.0 C2MS 1.2b1 Closed; No Change closed
C2MS12-7 Add documentation within the model C2MS 1.0a1 C2MS 1.2b1 Closed; No Change closed
C2MS12-1 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 C2MS 1.2b1 Deferred closed
C2MS12-2 Data Dictionary Messages C2MS 1.0b1 C2MS 1.2b1 Duplicate or Merged closed
C2MS12-3 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 C2MS 1.2b1 Deferred closed
C2MS12-4 XML PSM recommended C2MS 1.0b1 C2MS 1.2b1 Deferred closed
C2MS12-6 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 C2MS 1.2b1 Deferred closed
C2MS12-13 Consider a mechanism to request archived Commands and Events C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-9 Harmonize Replay TLM and Archive Mnemonic Message Sets C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-14 C2MS Database Query (DBQUERY) messages C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-21 Reconsider Oneshot in MVAL Request/Response C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-12 C2MS: Optional Transfer Frame/Packet attributes should be described in schema C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-23 Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-24 At Next Major Revision: Order MEs and Fields Consistently C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-25 At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-26 Deprecate fields duplicated between C2MS Messages and the Message Envelope C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-27 Remove Superfluous Fields from Header and Envelope C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-29 Use Semantic Versioning for Version Number of Messages C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-32 Revisit Tracking Fields C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-30 Remove the Req/Resp/Pub MEP C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-34 Inconsistent Fields in AMVAL Response and AMVAL Data Messages C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-33 Re-evaluate Optional Boolean Fields C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-36 mnemonic.n.sample.m.quality seems to be wrong type C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-38 Normalize Headers and Text in the new DB Query Messages C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-44 Consolidate Navigation Data Messages C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-40 Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-74 Add SM&C MAL Message C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-45 Undo Addition of DB Query Messages in 1.1 C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-49 Align TLM Terms C2MS 1.0 C2MS 1.2b1 Deferred closed
C2MS12-52 Define GUID Format and Algorithm C2MS 1.2b1 C2MS 1.2b1 Deferred closed
C2MS12-127 Create PSMs for at least XML and REST/JSON C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-96 namespace support should be reflected in at least the telemetry and command related C2MS messages C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-122 There may be a need for a ranging (tracking) publish message C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-149 In Model Diagrams, mark constants with {readOnly} and possibly static, and final where appropriate C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-151 Create Service Registry/Lookup Messages C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-175 Service Lookup REQ/RESP C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-152 Make a class hierachy/diagrams for all the Tracking Data Messages C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-215 Support CCSDS SM&C Services in C2MS C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-166 Improve Some Subject Specifics C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2MS12-217 Create a PowerPoint Set of Slides with Further Guidance for C2MS C2MS 1.1b1 C2MS 1.2b1 Deferred closed
C2INAV13-3 Enumeration value ESTIMATED used twice in the same package C2INAV 1.2b1 C2INAV 1.3 Duplicate or Merged closed
C2INAV13-2 Enumeration value ESTIMATED used twice in the same package C2INAV 1.2b1 C2INAV 1.3 Resolved closed
C2INAV13-1 C2INav Model refers to an old OARIS Common Types package C2INAV 1.2 C2INAV 1.3 Resolved closed
COMMONS13-35 Locations is missing a hasState property Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-31 Additional taxonomic relations are needed in the classifiers ontology Commons 1.2b1 COMMONS 1.3b1 Closed; No Change closed
COMMONS13-34 Poor definition of ctxtdsg:isUsedBy Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-21 US-centric geopolitical terminology Commons 1.2b1 COMMONS 1.3b1 Closed; No Change closed
COMMONS13-25 Need the definition of capacity in organizations and to contrast it with capability Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-33 Awkward unions of RA and Registrar Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-13 Annotation Vocabulary missing discussion of labeling policy Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-11 The documents ontology is missing the notion of a document part Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-5 StructuredCollections ontology misnamed Commons 1.2b1 COMMONS 1.3b1 Closed; No Change closed
COMMONS13-32 Unnecessary description properties in Designators Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-38 Need the ability to describe the concept of authorization Commons 1.2 COMMONS 1.3b1 Resolved closed
COMMONS13-28 Locations ontology should reuse W3C WGS84 ontology Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-12 Annotation Vocabulary has incomplete definitions from SKOS Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-10 Need to augment the locations ontology to cover sites and facilities, or create a new ontology for these concepts Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-23 Constituent term has two issues Commons 1.2b1 COMMONS 1.3b1 Closed; No Change closed
COMMONS13-19 Could a "date period" be defined even without knowing the exact dates? Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-27 Need to add the definition of language to the Codes and Code Sets ontology Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-14 Commons silently changes the semantics of dct:description Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-22 Typeface issue (LogarihmicScale should be bold) Commons 1.2b1 COMMONS 1.3b1 Closed; No Change closed
COMMONS13-20 Reference to GMT should be to UTC instead Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-18 Missing word "Revision"? Commons 1.2b1 COMMONS 1.3b1 Closed; No Change closed
COMMONS13-1 Need an ontology representing multidimensional arrays COMMONS 1.0b2 COMMONS 1.3b1 Deferred closed
COMMONS13-8 Definition of List says it's a set Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-4 Wrong property used for collection members Commons 1.2b1 COMMONS 1.3b1 Resolved closed
COMMONS13-2 The quantities and units ontology does not allow representation of unitless quantity values Commons 1.1b1 COMMONS 1.3b1 Deferred closed
COMMONS13-7 Confusing properties added to Constituent by StructuredCollections Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS13-6 Ill-defined notion of "ordered by time" Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS13-3 Need for simple ordered List Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS13-17 The definition of constituent, and of the property hasConstituent needs additional refinement Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS13-26 Add additional metadata for external ontology registration Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS13-24 expressesTheMagnitudeOf seems wrong Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS13-49 The definition of geopolitical entity in the locations ontology needs refinement Commons 1.2 COMMONS 1.3b1 Deferred closed
COMMONS13-30 Certain ontologies would benefit from having a node id for ontology elements that supports searching Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS13-36 Unclear distinction between hasPart and hasMember Commons 1.2b1 COMMONS 1.3b1 Deferred closed
COMMONS12-13 Clean up a few issues with the Locations ontology Commons 1.1 COMMONS 1.2b1 Resolved closed
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-7 The definition of aspect needs refinement Commons 1.1 COMMONS 1.2b1 Resolved closed
COMMONS12-1 Need an ontology representing multidimensional arrays COMMONS 1.0b2 COMMONS 1.2b1 Deferred 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-2 The quantities and units ontology does not allow representation of unitless quantity values Commons 1.1b1 COMMONS 1.2b1 Deferred closed
COMMONS12-11 Certain OMG processes need additional structured collection definitions MVF 1.0b2 COMMONS 1.2b1 Resolved closed
COMMONS12-10 Several OMG and external processes need concepts for describing regulatory authorities MVF 1.0b2 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
C2MS11-254 Table Formatting for Value and Description Columns C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-249 Misc Post-ballot-13 Fixes C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-260 Rename Section 6 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-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-234 Rework some text for Archive Message Retrieval Request 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-187 Consolidate all "Additional Information" Table and Model Figure changes into one Issue 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-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-83 Consider forcing a limited subscription 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-169 Clarify Text Associated with Simple Service Req/Resp C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-191 Remove XSDs as Normative Documents C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-143 Header UNIQUE-ID is Type "Header String" 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-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-163 Align TLM Messages against Subject Elements and Fields 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-54 VCID and APID in Message Subject for TLMTDM Frame 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-115 Remove APID from TLMPROC C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-114 Remove APID from TLMFRAME C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-25 Make all subjects be buildable from fields in the message 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-16 REQUEST-ID field does not support usage as a GUID 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-141 Improve text related to ONESHOT in Mval Request Message 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-135 NUM-OF-[ITEMS] Should be Required C2MS 1.0 C2MS 1.1b1 Resolved 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-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-90 Real-world STREAM-MODE Issues C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-112 Align MESSAGE-CLASS with Usage 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-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-43 Deprecate Archive Message Retrieval Messages C2MS 1.0 C2MS 1.1b1 Resolved 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-14 Specify multiplicity for required and optional fields C2MS 1.0a1 C2MS 1.1b1 Resolved 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-107 TLMPKT Message needs field AP-ID C2MS 1.0 C2MS 1.1b1 Duplicate or Merged 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-30 Clarify the ".... Message Header Notes" tables re: being included in each message C2MS 1.0 C2MS 1.1b1 Closed; No Change 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-87 Missing Echo Request 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-55 REQUEST-ID as "Replacement" and related STOP C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-49 Consider Renaming "Header String" type to "Subject Token String" C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-48 Add Message-level Security Constructs C2MS 1.0 C2MS 1.1b1 Transfered closed
C2MS11-34 In message Archive Message Retrieval Response, fix Header field names C2MS 1.0 C2MS 1.1b1 Resolved 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-46 Using REQ Messages for 'Publish' C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-38 In the Control Message, the field CNTL-STRING should be required C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-37 Remove value for CNTL-STRING from CNTL message 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-32 Add field for USER to Message Header C2MS 1.0 C2MS 1.1b1 Transfered 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-18 All Messages Subclass Message Header C2MS 1.0 C2MS 1.1b1 Resolved closed
C2MS11-12 "Mnemonic" should be called "Parameter" C2MS 1.0b1 C2MS 1.1b1 Closed; No Change closed
C2MS11-10 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 C2MS 1.1b1 Transfered closed
C2MS11-9 Pub/Sub subscription status unknown 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-22 Message-level Security Credentials C2MS 1.0 C2MS 1.1b1 Transfered 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-21 Larger Data Types C2MS 1.0 C2MS 1.1b1 Duplicate or Merged closed
C2MS11-8 Acknowledge Final Status inconsistency C2MS 1.0b1 C2MS 1.1b1 Deferred closed
C2MS11-7 XML PSM recommended C2MS 1.0b1 C2MS 1.1b1 Deferred 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-3 Archive Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.1b1 Resolved closed
C2MS11-2 C2CX Heartbeat comments C2MS 1.0a1 C2MS 1.1b1 Resolved closed
C2MS11-1 Lack of a registry concept C2MS 1.0a1 C2MS 1.1b1 Transfered 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-45 C2MS Database Query (DBQUERY) messages 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-42 C2MS: Optional Transfer Frame/Packet attributes should be described in schema C2MS 1.0 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-13 Add documentation within the model C2MS 1.0a1 C2MS 1.1b1 Deferred closed
C2MS11-140 Replace Unsolicited Echo with a Separate Message 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-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-19 Larger Data Types 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-184 Remove Superfluous Fields from Header and Envelope 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-88 Create CMD-MNEMONIC Field in Command Request 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-138 Command Echo Not Provided Message 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-131 Split ME1 in Simple Service Req/Resp 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-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-170 Replace simple service REQ/RESP 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-189 Add a section describing expected use 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-221 Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model 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-242 Consolidate Navigation Data Messages 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-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
C2MS11-250 Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message 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-251 Improve Example Text for Publish Rate 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
CSRM11-3 Create examples of use of the 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-1 Icons for profile CSRM 1.0b1 CSRM 1.1b1 Resolved closed
CSRM11-4 Recommended Additions CSRM 1.0a1 CSRM 1.1b1 Closed; Out Of Scope closed
CPP1117-9 Typo CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-8 Incorrect constructor referenced in Fixed description CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-14 bit_bound CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-13 Missing annotation mapping 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
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-7 Missing description related to union member modifier CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-1 Add standardized annotation to override the IDL map to std::map mapping CPP11 1.7 CPP11 1.7 Deferred 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-2 Typo in example CPP11 1.7 CPP11 1.7 Closed; No Change 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-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-3 Need to add start and end time and explicit time period in Commons COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-2 Need an ontology representing multidimensional arrays COMMONS 1.0b2 $issue.fixedSpecification.name Deferred 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
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-3 The format of the tables throughout the specification needs improvement Commons 1.0a1 COMMONS 1.0 Closed; No Change 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-19 CodeSet should be a subclass of arrangement Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-12 The properties in the collections ontology are confusing to users 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-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-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-5 Examples are needed to help explain to Commons users how to use the ontologies Commons 1.0a1 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-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-9 The constraint on a classifier that says it must classify something is too restrictive Commons 1.0a1 COMMONS 1.0 Resolved closed
CORBA34-453 CORBA section 11 struct PortableGroup::GroupInfo CORBAe 1.0b1 CORBA 3.4 Deferred closed
CORBA34-450 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-451 Ordering of user exception and return values CORBA 1.2 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-447 What should Automation View accept in bounded sequences? 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-449 Section 4.1.18.5 enum should be named CORBA_CompletionStatus 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-442 Return value type of DICORBATypeCode::member_type should be changed 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-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-436 page 4-109, section 4.1.5.3: editorial 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-438 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-439 ODL is erroneous 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-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-430 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-431 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-424 Can Value type inherit from Value Box type? CORBA 2.2 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-428 Section 5.5 Interface repository (01) 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-419 describe_value() operation issue 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-421 p.6.68 boxed values of complex types map to same type 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-423 New lexical type - Keyword Identifie 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-410 Concrete value class 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-412 Section 5.6.3 Hashing Algorythm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-413 Repository Id (03) 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-416 Clarify the hash code algorithm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-417 Type code issue 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-405 Section 7.3.10 Value Factories 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-407 Section 7 C++ Language mapping 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-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-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-395 Keyword identifiers (01) 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-397 Can public modifier be applied to value operations? 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-392 Keyword identifiers (04) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-393 Keyword Identifiers(03) 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-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-387 "in". "out", and "inout" modifiers on value operation parameters 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-381 ValueMemberSeq: What is to be done with the RepositoryID parameter? 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-383 CDR Streams CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-376 TypeCodes for values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-377 Forward declaration of value boxes 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-379 OBV spec inefficient for dending large number of small objects CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-380 OBV C++ problem with "supports" 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-372 C++ boxed value member clashes 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-375 Boxed values need extension to write_Value call 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-361 ValueHelper Interface issue 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-363 Status of hashed repository IDs 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-366 Memory Management for Value Factories Unspecified CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-367 TypeCode complexity for value types 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-354 issue with TCPfirewallMechanism CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-355 passthrough connection 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-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-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-346 It should be possible to have negative invoke ids 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-348 Section number: 3.5.1.1, item 3 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-350 Section number: 3.3.4 make factory creation operations conform to the IDL CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-340 Section 4.7.1: RelativeRoundTripPolicy 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-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-344 Problem: Why is AssociationId a string? 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-339 Shouldn’t this section really be called TC Service Interface? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-335 Section number: Fig. 27 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-337 Section number: 5.4.1 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-330 Section number: 5 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-333 Should SIOP version number start with 1.2? 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-322 new_callback CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-323 new_target CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-324 Firewall Traversal algorithm 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-326 Outgoing local port in Bi-directional IIOP 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-319 Reusing PASSTHRU CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-320 Proxified object references 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-318 Clarification is needed on the passing of credentials 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-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-311 TcPdu User and Provider interfaces 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-313 Why one to one association between a TcPduUser and TcPduProvider interface? 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-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-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-309 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 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-302 Negotiation Session message is unwieldy CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-303 Negotiate Session Message Orientation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-298 GIOP version 2.0 issue CORBA 2.5 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-304 MAIN_THREAD_MODEL questions CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-297 CodeSet issue (01) 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-294 CodeSet issue (04) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-295 CodeSet issue (03) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-296 CodeSet issue (02) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-290 Implications about BiDirIds 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-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-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-276 Bi-directional connections considered volatile at connection acceptor side 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-282 Processing of NegotiateSession messages at various stages of connection set 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-279 connection_complete field of the FirewallPathRespContext is under 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-281 Targets of Export and Offer Policies incompletely specified 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-271 Start and end of context tags CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-272 Stream contexts and internalization CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-273 Lifecycle Key type definition 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-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-263 Input values for "which" arg of non-trans. LockCoordinator CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-264 Coordinator remembering LockCoordinator 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-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-262 Using local thread identification for concurrency 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-258 $issue.summary 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-251 Which model should ConcurrencyControl support? 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-254 CosCompoundExternalization Service (2) CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-247 QueryCollection::Collection -- membership scoping 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-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-246 QueryCollection::Collection -- Adding multiple elements CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-242 QueryCollection::Collection -- iterator updating CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-243 QueryCollection::Collection -- Iterator Position Invalid CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-237 Questions on CosQuery::QueryableCollection interfaces 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-240 QueryCollection::Collection -- reset() exceptions CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-241 QueryCollection::Collection -- destroy methods CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-229 Query language for operations 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-234 How do iterators handle changing of the data they are pointing at CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-235 Updating information via query iterators CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-236 Use of MD5 on arguments 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-231 retrieve_element 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-222 Correction of CORBA specification (page 18-51) CORBA 2.3.1 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-224 WWW Form output CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-225 Malformed PropertyName CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-227 interface QueryEvaluator { CORBA 2.0 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-216 Compiler being able to translate from OMG-IDL into ANSI CORBA 1.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-212 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 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-214 Fixed Types in COM CORBA 2.4.2 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-207 How does DynValue handle derived valuetypes? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-208 module SendingContext CORBA 3.0.3 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-210 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-211 valuetypes and local interfaces 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-198 BNF changes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-199 rules for marshalling ValueBoxes 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-194 methods on the POA CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-195 Codec Interface Deficiencies 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-193 Add a typedef for the POAManager id 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-188 CORBA 3.0.3 ch. 3.4 OMG IDL Grammar CORBA 3.0.3 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-191 argument of the set_servant call has a small typo 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-183 Custom Value Marshaling Issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-184 Potential deadlock with POA::deactivate_object() CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-185 Code Set Conversion on Operations CORBA 3.0.3 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-175 New issue: ForwardRequest() CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-176 Proposal for extension to CosNaming CORBA 2.6 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-179 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-172 missing document title CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-170 rule (85) is misplaced CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-171 Bad quotes and imported dot CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-173 processing TaggedComponents within an IOR CORBA 3.0 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-165 context should be local interface CORBA 3.1 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-169 Make anonymous types illegal 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-155 Section: 21.3.13 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-161 Section: 21.7.3 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-157 16.10 lists register_initial_reference CORBA 3.1 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-159 add CORBA::ORB::arg_list CORBA 3.0.3 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-153 Section: 15.4.2/16.4.1 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-147 Section: Part 2, Chapter 11 - MIOP 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-149 definition of Invalid Policies changed CORBA 3.1 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-151 Proposal to change PortableInterceptor::AdapterState to a real enum CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-146 struct PolicyValue CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-144 Invalid IDL 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-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-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-139 Minor code ambiguity 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-137 Section: 7.4 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-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-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-130 Section: 21.4.3.1 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-124 FullInterfaceDescription and base_interfaces question 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-121 Allowing mutual recursion for IDL structs - clarification needed CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-128 Section: 22.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-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-118 Section: Appendix A 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-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-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-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-106 Test Property - add a test property definition to the properties DTD 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-100 69.3.2.25 The propertyfile Element, page 69-482 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-102 69.8.2.7 The code Element, pages 69-474 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-96 Component Artifact Dependency 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-98 Descriptor 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-95 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-89 lwCCM issues - abstract storage type 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-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-93 lwCCM issues - security CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-94 lwCCM issues - transaction CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-85 lwCCM issues - segmentation CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-86 lwCCM issues - locator CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-87 lwCCM issues - CIDL 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-78 lwCCM issues - invalid rows 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-81 lwCCM issues - configurators 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-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-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-73 69.3 AssemblyFactory Interface CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-74 Uses Relationships 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-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-68 A new exception specification is needed for CCM2Context::req_passivate() CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-69 [CCM] Interface Repository Metamodel 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-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-61 Section 6.4.5.52 (page 6-38) 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-63 3.2.7 Compositions with Managed Storage CCM 3.0 CORBA 3.4 Deferred closed
CORBA34-64 multiple lifetime policies declaration issue 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-58 issue on component supporting abstract interfaces 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-48 EnterpriseComponent should have a set_persistent_object 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-47 HomeExecutorBase should have a set_context method 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-43 The D&C IDL part doesn't match 06-04-02. CORBA 3.0.3 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-45 "supports" keyword CORBA 3.0.3 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-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-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-36 two not used and document exceptions listed ZIOP 1.0 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-34 HomeConfiguration::set_configuration_values should document exception ZIOP 1.0 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-27 Generic port connections 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-26 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-25 Interface Introspection 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-19 page 1-20 and page 1-21 - editorial 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-23 Change new GIOP Negotiate Session Message to Firewall Specific 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-18 page 1-20 second bullet of the description of the disconnect operation 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-15 15.3.3 - codesets must be "explicitly defined" 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-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-11 Capter 13C: Editorial 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-12 Incorrect mappings for systems exceptions (part A) 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
CORBA34-5 Section 13C.1.3 Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CSRM-41 Modify Paragraph 2 to remove redundant reference to the machine readable file. CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-28 MeasurementSpecification missing documentation CSRM 1.0a1 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-26 VerificationActivity missing documentation on verificaionMethod CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-14 Additions for convenience methods CSRM 1.0b2 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-35 Clarify usage of Group stereotype CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-12 Recommended Additions CSRM 1.0a1 CSRM 1.0 Deferred closed
CSRM-16 Remove Section 0 from the document CSRM 1.0a1 CSRM 1.0 Closed; No Change 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-9 Change names from CubeSat to Satellite. CSRM 1.0b1 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-1 Icons for profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-5 Create examples of use of the profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-4 Add constraints to aid in correctness of profile useage CSRM 1.0b1 CSRM 1.0 Deferred closed
CORBARS_-2 Provide example of authentication and security CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
CORBARS_-1 Provide a simple sample application CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
C2INAV11-3 Update GraphQL PSM Mapping C2INAV 1.0 C2INAV 1.1 Duplicate or Merged closed
C2INAV11-1 FTF-1 changes to be applied to GraphQL PSM C2INAV 1.0a1 C2INAV 1.1 Resolved closed
CPP1116-19 Add mapping for @optional CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-12 Invalid constructor in example code CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-11 Add IDL::traits<>::bit_bound 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-18 Use IDL::traits<>::make_reference instead of CORBA::make_reference CPP11 1.5 CPP 1.6 Resolved 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-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-14 Missing override CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-13 Missing override 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-8 Remove std namespace from example code 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-4 Add mapping for IDL4.2 standardized annotations CPP11 1.4 CPP 1.6 Deferred closed
CPP1116-3 Annotation for union discriminator name CPP11 1.5 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-9 Example V_factory should list deleted assignment/copy CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-8 Missing deleted assignment/copy operators 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-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-4 Add support for int8 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-15 Reference from navigation_covariance_type to navigation_report_type needs a length 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-43 Placement of surge,sway and heave within the spec C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-45 No Depth Accuracy Information Available 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
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-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
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-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-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-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-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-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-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-84 Merge figures 8-1 and 8-2 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-83 Add (back) Simple Service request and response messages 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-57 Figure 7-1, C2MS Message Exchange Patterns Diagram, misspells RESPONSE C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-36 Fix C2CX Device message, field NUM-OF_DEVICES 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-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
C2MS-23 Flatten the message hierarchy re: C2CX, TLM, and NDM messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-43 Modifying a subscription is undefined C2MS 1.0b1 C2MS 1.0 Duplicate or Merged closed
CPP1114-13 Only single argument constructors have to be explicit CPP11 1.3 CPP11 1.4 Closed; No Change closed
CPP1114-31 Add Delegation-Based Interface Implementation CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-7 Typo fixes CPP11 1.3b1 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-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-3 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.4 Resolved closed
CPP1114-4 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.4 Closed; Out Of Scope 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
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
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-7 Make mapping of sequences more flexible CPP11 1.1 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-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-13 Only a namespace level swap should be provided 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-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-4 Handle possible exception what conflict and improve Exception introduction text 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-9 Fix assignment operator of ColorValue CPP11 1.2 CPP11 1.3 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-124 Need to add names to contributors 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-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-131 Need for annotations and comments in CMMN 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-143 Editorial to section 5.1.5 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-114 Missing authorizedRoleRefs in XSD for tUserEventListener 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-110 Missing "externalRef" in Process class CMMN 1.0 CMMN 1.1 Resolved closed
CR-90 Missing attribute “name” for Process 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-74 Missing notational element for discretionary Milestones and discretionary EventListeners CMMN 1.0 CMMN 1.1 Deferred closed
CR-76 Missing PlanningTable on the CasePlanModel of figure 6.63 CMMN 1.0 CMMN 1.1 Resolved 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-92 Inconsistency between XSD and meta-model for condition on IfPart 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-104 Some figure in chapter 6 do not use the new Discretionary Association CMMN 1.0 CMMN 1.1 Resolved closed
CR-94 Add a new discretionary association CMMN 1.0 CMMN 1.1 Resolved 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-23 Evaluation/Re-evaluation of RequiredRule unclear - what does "maintained" mean? 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-19 Incorrect Example image CMMN 1.0 CMMN 1.1 Resolved 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-14 Ambiguous OnPart references for cross-stage-boundary plan items CMMN 1.0 CMMN 1.1 Duplicate or Merged 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-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-78 EventListeners erroneously listed for RequiredRule 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-82 Unrequired “body” element in expression in the 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-20 CMMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions) 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-16 Two entry criteria cannot be connected CMMN 1.0 CMMN 1.1 Closed; No Change 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-1 Inconsistencies between class diagram figures and attribute tables 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-15 Timerevent based on data not possible CMMN 1.0 CMMN 1.1 Resolved closed
CR-5 Discretionary Items should also have a Name property 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-53 Table labeled as a figure in page 40 CMMN 1.0 CMMN 1.1 Resolved closed
CR-57 Future sentence in specification CMMN 1.0 CMMN 1.1 Resolved closed
CR-55 Reference missformated CMMN 1.0 CMMN 1.1 Resolved closed
CR-46 Mislabled table CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-22 Non-normative References do not include CMIS 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-25 Missing reference to XML Schema and XPath specification 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
CR-24 CaseRoles have ugly definition in the XSD 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-2 The scope does not clarifies the relationship between CMMN and BPMN 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-6 PlanItemControl of discretionaries should also allow repetitionrules CMMN 1.0 CMMN 1.1 Resolved closed
ITCR-54 Update normative reference to point to CORBA 3.3 CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-39 Missing public specifier CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-57 Fix unclarity in IDL Union description 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-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-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-12 Clarify valuetype factory mapping 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-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-11 Valuebox should also have swap support CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-10 Add missing default initialization for valuetypes CPP11 1.1 CPP11 1.2 Resolved 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-18 Destructor should just be virtual CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-1 In-place construction of structure types CPP11 1.0 CPP11 1.2 Deferred 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-9 wrong return type for Foo::some_function() CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-8 provide unique class name as mapping of PortableServer::Servant 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-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-13 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping 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-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-238 Clarify semantics CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-233 IDL Type Extensions: DATA_CONVERSION exception 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
CORBA24-202 Standard System Exception minor codes missing in Chapter 13 CORBA 2.3.1 CORBA 2.4 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-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-263 Fixed-point initialization CPP 1.0b2 CPP 1.0 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-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-112 Second bit of response_flags CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-113 RMI repository ID references to serial version UID 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-108 A Messaging related issue in GIOP 1.2 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-109 CODESET_INCOMPATIBLE exception 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-97 CDR encoding of TypeCodes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-100 Type code marshalling 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-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
CORBA21-91 GIOP Exception formatting description (12.4.2) 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-8 clarification about relationships of specifications needed 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-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-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-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-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-16 CORBA-WSDL/SOAP: Section 1.2.7.10 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-15 CORBA-WSDL/SOAP: section 1.2.4 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-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-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-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-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-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-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-19 The documents referenced in Rule 12 should appear in the normative references section 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-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-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-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-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-222 Proposal on floating point fixes CORBA 2.2 CORBA 2.3 Duplicate or Merged 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-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
CORBA24-186 Section 3.3.8.16:deactivate_object() operation CORBA 2.1 CORBA 2.4 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-2 context:delete_values has type CORBA 3.1.1 CORBA 3.2 Resolved closed
CORBA32-1 Typo in set_values 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-41 There is an incorrect page reference 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-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-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
CORBA24-180 DynUnion incomplete CORBA 2.4 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-26 Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping 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-24 Obsolete text in 1.40.3 CPP 1.1 CPP 1.2 Resolved closed
CPP12-23 C++ Value Type issue (02) 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
CPP11-250 Tie classes CPP 1.0b2 CPP 1.0 Closed; No Change closed
CORBA23-214 OMG VMCID CORBA 2.2 CORBA 2.3 Resolved 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-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-192 Typos in IR IDL in Specification (050 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-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-185 GIOP typo, section 4.2 (page 4.4) of CORBA 2.2 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-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-181 Indentation on page 4-4 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-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-174 Fixed point constants issue 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-169 CORBA 2.2 - "native" and the interface repository CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-170 #pragma prefix issue 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-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-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-6 Font issue CPP11 1.0b2 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-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
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-93 We only need one COBOL Data Division model CWM 1.0 CWM 1.1 Resolved closed
CURR11-46 IDL Changes to support date ranges on ExchangeRateValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-45 exception semantics for MoneyValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-44 MoneyValue init interface need information CURR 1.0 CURR 1.1 Resolved closed
CURR11-57 Correct Currency create method CURR 1.0 CURR 1.1 Resolved closed
CURR11-56 Change get Currency to retrieveCurrency 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-55 Clarify the areEquivelent interface of the CurrencyBook 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-60 Modify and specify the behavior of the insertExchangeRate interface 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-47 ExchangeRateValue init interface need information 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
CURR11-58 Correct interface symantics for createExchangeRate CURR 1.0 CURR 1.1 Resolved closed
CURR11-53 Add validity checkign for StateIdentifier 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-62 Proposed interface changes to ExchangeRateManager CURR 1.0 CURR 1.1 Resolved closed
CURR11-61 removeExchangeRate() interface issue CURR 1.0 CURR 1.1 Resolved closed
CWM11-90 Supplier and version underspecified CWM 1.0 CWM 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-81 taggedValue reference is missing from ModelElement 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
CWM11-82 stereotype 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
CWM-1 Specify meta-model & XMI parameters for CWM XMI formats CWM 1.0b1 CWM 1.0 Resolved closed
CURR11-64 Clarify legal values for the MoneyFormatter format strings 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-69 Create mechanism to modify what negative prefix is for formatting string 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-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-67 Typo on SetPatternMnemonicSymbol name 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-75 Add clarification on formatting string in MoneyFormatter CURR 1.0 CURR 1.1 Resolved closed
CURR11-74 Supplied Data for ISO Locales in MoneyFormatter needs to be discussed CURR 1.0 CURR 1.1 Resolved closed
CURR11-65 Clarify contradiction betw setFormatByLocale & setFormattingString CURR 1.0 CURR 1.1 Resolved closed
CURR11-76 Value types need state 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-72 Fix omitted precondition for MoneyCalculator 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-42 Add description of isCurrency Active CURR 1.0 CURR 1.1 Resolved closed
CORBA26-73 Incorrect syntax in Components::Enumeration CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-72 Component port introspection 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-81 minor IDL changes required in CCM 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-78 CCM: import and re-opening of modules CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-71 "supports" terminology issue for CCM CORBA 2.4.2 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-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-74 explicit definition of CCM exceptions mapped from EJB standard exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-80 Little problem with introspection API CORBA 2.5 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-82 Use of undefined "id" attribute CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-94 Changing VSCID prefix to 24 bits CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-91 Indirections with chunking & fragmentation CORBA 2.4.2 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-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-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-61 Component home interface inheritance CORBA 2.4.1 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-68 CCM: usage of the MOF profile CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-67 CCM : Session2Context naming CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-57 Inter-component type semantics unclear 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-69 IDL out parameters can't map to EJB? 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-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-84 Is GIOP 1.x sustainable any more? 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-55 New component issue: connection failure recovery 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-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-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-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
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-51 No user access to filterable body in CCM spec. 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-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-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-41 An assembly is always mono-vendor ??? 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
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-2 GSSUP Names are inconsistent other security mechanisms. CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-1 CSIv2 Protocol 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-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-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-12 OIDs CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-11 Module suggestions 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-17 No Tokens in EstablishContext Message 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
CSIV2-20 The encoding of GSSUP ICT's is not clearly specified 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-22 clarification of csiv2 stateful conformance requirements CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-21 CSIv2 TSS state machine lacks states to enforce target policy for 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
CURR11-35 vendor implementations can implement only parts and interoperate-Statement CURR 1.0 CURR 1.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-30 StateID Exception 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-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-37 missing description on the init method for CurrencyValue 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-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
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-11 Versioning needed for CORBA Core CORBA 2.2 CORBA 2.6.1 Resolved closed
CORBA25-45 Null termination of strings CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-49 tk_indirect 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
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
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
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-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-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-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-37 Missing TypeCode identity 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
CORBA26-23 Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping 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-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-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-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
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-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
CORBA31-111 Make a typedef for the POA id new CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-110 ValueMembersSeq CORBA 3.0.2 CORBA 3.1 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-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-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-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-19 What is the semantics of the DataInputStream::read_*_array() operations? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-18 #include issue 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-32 Ambiguity in non_existent 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-29 Minor code CORBA 2.4.2 CORBA 2.5 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-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-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-10 core issue: unchecked narrow 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-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-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-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
CORBA25-6 CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-14 ForwardRequest from normal operations CORBA 2.4.1 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-11 PortableServer::ObjectId 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-3 POAManager::deactivate should not mandate ORB::shutdown implementation CORBA 2.4.1 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-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-30 Issue on Assemblies and descriptors CPP 1.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
CORBA3-102 Generic operations for subscribing/unsubscribing at publishing ports 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-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-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-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-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-88 Local types allowed as valuetype state? CORBA 3.0 CORBA 3.0.2 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-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-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-56 IOR processing performance 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-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-51 Codeset negotiation requires clarification 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-53 discussion on the create_union_tc operation could use some clarifications 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-49 interaction of #pragma and typeid, typeprefix CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-52 IDL inheritance issue 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-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-121 Corrections in XML DTDs for packaging 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-26 Clarify that each interception point executes in a distinct logical thread CORBA 2.4.1 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
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-27 X/Open Codeset registry is obsolete needs to be replaced 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-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-64 Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent CORBA 2.6.1 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-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-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-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-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-80 potential name clash with Messaging type-specific poller timeout argument CORBA 3.0 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-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-74 determining TimeT or UtcT value CORBA 3.0 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-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-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-43 Issue with chunking CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-33 rep_id() operation on Object? 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-36 Detecting Recursion in Other Interceptors CORBA 2.5 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-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-115 paragraph 60.2.1 : There is two mistakes in keywords 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-113 Issues related to CCM's XML descriptors: chapter 695.4 CORBA 3.0 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-107 Issue regarding language mapping for keyless homes 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-116 Productions 140, 141, 142 and 143 must be removed 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-111 Issues related to CCM's XML descriptors: chapter 69.7.2.25 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-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
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-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-9 Section: 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-2 Section: 1.2.7.6 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-3 Section: 1.2.7.6 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
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-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-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-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-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-42 CORBA2.0, 1.2.2 Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-47 3.10.3 Raises Expressions 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-31 Page 13C-36: Editorials CORBA 2.0 CORBA 2.1 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-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-15 Portable Interceptors / register_initial_reference() 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
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-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-9 Servant_to_id clarification 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-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
CORBAE-8 Section: 11.2.3 CORBAe 1.0b1 CORBAe 1.0 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-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-73 Implementation of parameter passing for T_var types 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-78 Persistent Any values CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-74 RTTI vs. _narrow for exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-75 decompose Any into constituent primitives CPP 1.0b1 CORBA 2.1 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
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-69 Rethrowing exceptions 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
CORBA3-12 Portable Interceptors: 9.2.3 text describing `Arguments' CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-11 Detail lacking in when request interceptors are called CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-1 constant decls broken CORBA 2.2 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-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-3 issue with ForwardRequest exception in POA CORBA 2.2 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-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-14 Policy Management in Portable Interceptors CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-13 Overriding POA policies CPP 1.1 CORBA 3.0.3 Resolved closed
CORBA3-4 scheme name for IORs CORBA 2.3 CORBA 3.0.2 Resolved closed
CORBAE-16 Wrong references in chapter 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-15 Section: 11.4.1 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-18 Section: 8.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-17 More wrong references in chapetr 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-14 Section: 18.2.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBA24-140 GIOP encoding of nil Abstract Interface is unspecified 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-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-134 Compacting GIOP Messages by using templates CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-139 .Passing the interface repository ID of the method in IIOP 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-137 TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-113 Locality constrained objects + externalization CORBA 2.2 CORBA 2.4 Closed; No Change closed
CORBA24-114 Locality-constrained objects CORBA 2.2 CORBA 2.4 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-171 wchar alignment in GIOP 1.2 CORBA 2.4 CORBA 2.4.2 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-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-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-168 Small optimization for the GIOP header CPP 1.1 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-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-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-122 CCM Issue: Is CCMObject::remove intended to be available to the CCM client? 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-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-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-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-115 Policies not locality-constrained? CPP 1.0 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-67 Semantics for DynAny::equal underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-66 Inheritence table 3-10 wrong? 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-71 #pragma rules are too restrictive 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
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-68 Does a value in a valuebox make sense? 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-93 ORB::shutdown underspecified 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-88 Valuetypes with multiple interfaces 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-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-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-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-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-94 servant_to_id versus servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-97 AbstractBase not declared. 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-148 Should an ORB be allowed to drop non-standard profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-142 CDR Encapsulation Issue CORBA 2.3.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-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-141 Minor code allocation inconsistency CORBA 2.3.1 CORBA 2.4 Resolved 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-83 ORB mediation for servant managers, references for servant managers? 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-86 is_equivalent and policies 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-80 POA namespace and ORB ID 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-75 symbolic constants for minor exception codes CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-74 valuetype factory inheritence? 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-73 Definition of COMPLETED_NO needs to be clarified 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-158 Valuetype encoding grammar in 15.3.4.7 is wrong 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-160 Wrong minor code specified in Chapter 13 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-152 Preserving unencapsulated information CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-153 Transferring Java exception reason string across the wire 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-151 Indirection for value types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-161 ORB throwing exception if it finds unknown service context CPP 1.1 CORBA 2.4 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-103 incomplete rules for forward declaration of structs/unions 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-108 ORB ID accessor 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-104 Nested Recursive Structs Legal in 2.3.x? 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-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
CORBA23-166 LocateRequest and LocateReply messages CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-165 CDR encoding for fixed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-26 Need namespace for Policy Type 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-16 Which OBV initialiser to run is under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-18 Recursive IDL types 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-15 DynUnion::member() CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-14 Missing equality for DynAny CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-22 Exception for abstract interface inheritance 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-20 Recursive exceptions? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-21 long double problem? CORBA 2.2 CORBA 2.3 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-59 IDL scoping rules 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-3 mixing giop versions 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-8 chapter 3 and recursion CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-7 ambiguity in wstrings having a Unicode escape sequence CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-15 URLs interact poorly with code set selection CORBA 2.3.1 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-5 OBV interface support inconsistencies CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-4 $issue.summary CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-12 DataInputStream specification is inefficient for Java CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-6 POA: false placement of paragraph CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-9 CORBA 2.3: minor editorial issue CORBA 2.3 CORBA 2.4 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-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-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-51 Error in text describing TypeCode interface 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-48 Error in ValueDef IDL 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-52 Clarify text in section 15.3.7 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-43 Signature of unmarshal method is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-37 Problem with the "Special scoping" rules in 3.15.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-33 PIDL vs Local 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-36 Meaningless sentence on page 3-11? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-35 Preprocessing of IDL 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-42 Section 7.6: IDL context housecleaning 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-38 Codeset conversions and unions 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-40 Missing "abstract" in forward declaration 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-41 Question about IDL \uxxxx escape format CORBA 2.3.1 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
CORBA23-85 confusing rules for operations on Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-84 Incorrect IDL is section 5.5.3 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-92 UNIQUE_ID and ServantActivator issue 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-91 Clarification on IdUniquenessPolicy 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-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-27 create_policy specification needs to be completed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-31 uses of recursive_tc 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-28 Core uses both "standard" and "system" exception terminology CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-34 POA threading policies CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-33 Custom marshalling & AbstractBase CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-38 Names of Data*Stream methods CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-37 Custom Marshaling clarification 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-36 Missing minor code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-32 Sequences of recursive structs/unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-168 Need clarification on GIOP::TargetAddress CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-167 profile ids & component ids CORBA 2.3 CORBA 2.3.1 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-24 (CORBA Core) Data streams missing arrays of long double 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-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-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-30 Minor codes for Standard System Exceptions in Chapter 5 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-29 General Exception Question 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-21 formal/99-08-01.txt missing pragmas CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-28 Exception section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-25 Component ids in 13.6.2.2 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-20 CORBA::ORB::RequestSeq definition obsolete CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-59 Use UNICODE Character set 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-69 IR Changes in 2.3 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-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-57 Grammar section 3.9.2 missing "float" rules, and other problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-56 Calling get_response twice? CORBA 2.2 CORBA 2.3 Resolved 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-63 Interceptors broken 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-55 Forward-Declared Interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-60 Application Interface issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-57 null & void TCs and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-56 valuebox and DynAny CORBA 2.3.1 CORBA 2.4 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-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-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-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-49 Use of Principal in GIOP Module erroneous 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-55 OMG wchar <-> COM WCHAR in CORBA 2.3 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
CORBA23-77 omg.org prefix not well specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-76 Scope of SendingContextRunTime service context 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-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
CORBA23-81 LocateReply body alignment issue 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-70 Inconsistent spellings of "policy" related identifiers: 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-75 Need to specify exception for abstract interface error 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-7 DynStruct::get_members needs exception 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-13 set_servant_manager 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-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-5 Semantics of system exception completion_status CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-4 resolve_initial_references under-specified 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
CORBA23-8 Change to IDL for anonymous types 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
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
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-73 Missing documentation on StatementSubject 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-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-77 CTS2: Delta stereotype is opposite of isQuery 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
CORBA22-11 Repository IDs 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-8 Typecodes for recursive sequences 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-15 Recursive sequence TypeCodes 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-6 Interface Repository Error Handling 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-16 Portability and the #include directive CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-7 lookup() questions CORBA 1.2 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-126 Clarification on IIOP2.1 12.3.2 fixed point type representation needed CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-125 Issue with service context CORBA 2.0 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-122 1.0 backward compat (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-121 Fragment improvements (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-127 Additional Requirement for GIOP 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-128 Additional enumeration to the ReplyStatusType CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-123 1.0 backward compat (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-120 Fragment improvements (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-124 CloseConnection messages CORBA 2.0 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-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-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-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-96 union typecode (02) CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-23 4.3.1 sen3 - comment 23 - comment 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-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-21 4.2.2 add_arg Paragraph 5-comment 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-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-24 4.6.2 set_on_value Paragraph 2 - objection 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-32 6.5.2 IRObject Paragraph 3 - objection 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-138 C mapping for list_initial_services is incorrect CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-134 IIOP object pointer resetting 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-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-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-72 No defined value for OBJECT_NIL 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-71 Section 7.2: get_implementation function CORBA 2.0 CORBA 2.2 Closed; No Change 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-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-79 TypeCode equality 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-67 Section 16.7: only C++ mapping defines string_free and string_dup 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-75 Syntax for basic types must be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-5 CORBA::InterfaceDef name collision 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-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
CORBA22-3 Missing info about the semantics of ORB_init and OA_init CORBA 1.2 CORBA 2.2 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-116 Type Extensions and code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-115 Problem with GIOP CancelRequest when fragments are used CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-108 LOCATION_FORWARD byte alignment CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-107 Type ids in OBJECT_FORWARD return message CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-112 Callbacks in IIOP 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-114 Transport Level Bridge CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-113 IORs and identifying Object Keys CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-117 Type extensions char code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-109 Correct IIOP marshalling of union TypeCodes CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-106 CORBA::Contained::describe() underspecified CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-90 TypedefDef issue 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-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-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-89 CORBA 2.1 IR Structdef typo CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-91 Proposed IFR exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-86 Inclusion of standard exception 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-85 Issue with ObjectId_to_string and string_to_ObjectId CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-57 CORE spec reference 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-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-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-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-47 6.5.11 UnionDef Last Paragraph - 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-44 6.5.6 Repository Paragraph 4 - 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-41 6.5.4 Container Paragraph 11 - 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-63 What exactly is a request CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-62 inherit vs. include 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-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-59 Enums and enumerators CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-58 Internationalization CORBA 2.0 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-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
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-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-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-56 ConceptDomainCatalogHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-55 ConceptDomainCatalogQueryServices WSDL corrections 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-57 EntityDescriptionTransformService 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-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-2 CTS2: "entityType" description text incorrect - needs to be updated CTS2 1.0 CTS2 1.1 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-10 CTS2: "versiontag" has wrong type in MapVersion schema 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-6 CTS2: DocumentURI shouldn't be mandatory in ResourceVersionDescription CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-13 CodesystemCatalogEntry.usedOntologyEngineeringTool CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-12 UpdateCodesystemCatalogEntry.usedOntologyEngineeringTool optionality CTS2 1.0b1 CTS2 1.0 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-11 Core spec typos CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-10 BaseMaintenanceService.updateChangeableMetadata parameters 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-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-9 Changeable/ChangeDescription typo 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-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-16 CTS2: Documentation for value set resolution needs to be corrected. 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-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-18 CTS2: Map Entry "MapFrom" and "MapTo" need optional description element 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-21 CTS2: Make "associationID" optional 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-14 CTS2: REST language signature "referencelanguage" needs to be more REST compliant 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
CTS211-23 CTS2: URIAndEntityName XSD representation does not match UML CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-22 AssociationDirectory needs "associationID" 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-19 CTS2: CodeSystemCatalogEntry xml schema missing "hasOntologyLanguage" and "includes" elements CTS2 1.0 CTS2 1.1 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-44 CodeSystemVersionCatalogMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 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-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-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-51 AssociationTransformServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-43 CodeSystemVersionCatalogQueryServices WSDL corrections 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-71 CTS2: section 1.1.2.1 Class CodeSystemCatalogEntryDirectory typo CTS2 1.0b1 CTS2 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-33 CTS2: Cardinality of includesResolvedValueSet wrong on ResolvedValueSetHeader 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-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-38 CTS2: AssociationDirectory needs the derivation CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-37 CTS2: Resource content filtering for Query 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-34 CTS2: MapTargetList and MapTargetListList need a 'Message' wrapper for REST calls 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-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-31 CTS2: Complete binding operation missing from specification 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-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-22 NamedEntityDescription and AnonymousEntityDescription incorrectly defined in schema CTS2 1.0b1 CTS2 1.0 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-31 Statement needs an identifier CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-30 ConceptDomainbinding needs an identifier 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
CTS2F2-25 XML Schema for BaseService has wrong type for supported Profile 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-28 Changeable changeDescription cardinality constraint 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-17 EntityDescriptionReadService lacking local variables 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-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-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-14 Entity description services p20 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-2 All Defined Operations 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-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-5 Use of xs:any data type for payload 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-6 Use of "Exception" as a class name in the model CDSS 1.0b1 CDSS 1.0 Resolved closed
COAS-8 how to use HL7 data types 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-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-13 Pg. 91 Under section - 3.3.3.3 AccessComponent 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-10 Pg. 86 Under section - 3.3.2.8 Exceptions 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-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
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
COAS-36 typedefs for TimeStamp and TimeSpan that are never used COAS 1.0b1 COAS 1.0 Resolved closed
COAS-35 COAS operations that return ObservationData 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-23 Pg. 79 Under section - 3.3.2.4.9 TimeStamp 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-27 Pg. 133 Under section - 3.6.1 Genera 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-21 Pg. 71 Under section - 3.3.2.1 Include Files 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-37 GCPR issue: Exceptions 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-30 Pg. 153 Under section - 3.9 Conformance Classes 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-32 Pg. 193 Under section - D.3 Secure Interoperability Concerns COAS 1.0b1 COAS 1.0 Resolved closed
CMMN-6 Reference from Section 5.4.10.5 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-3 Error in description of Active state for a Stage or Task CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-2 Contradicting Definitions of Sentry 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-1 Expand TimeEventListener 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-13 Missing statement on compliance 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-15 Errors in XML-Schema for CMMN (CMMN-1,2,3) 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-8 Process and Case Task are inconsistent with BPMN call activity notation (CMMN-6) 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-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-17 Figure 72 (Example CMMN model) is wrong in spec 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-34 interface Parameter 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-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-20 EntityFactory and ModelInstanceFactory CAD 1.0 CAD 1.1 Resolved closed
CAD11-19 Model Instances vs. Top-Level Entities 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-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-18 Add some operations to CadFoundation module's interfaces 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
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-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-43 Incompletely specified operations - issue 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-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-34 Deletion of CadFourndation::Entity descendants CAD 1.0b1 CAD 1.0 Resolved closed
CAD-37 Entity Factory issue (Function 2) 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-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-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-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
CAD11-21 Euclidean Dimension CAD 1.0 CAD 1.1 Resolved closed
CAD11-28 Set color on Layer interface CAD 1.0 CAD 1.1 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-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-16 Model level parameters for geometry creation issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-15 What are units for 'angle' field in TessParametersStruct 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-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-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-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-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-25 how to add new topological entities to existing model with sharing of exist CAD 1.0b1 CAD 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-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-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-228 CORBA::Bounds and CORBA::TypeCode::Bounds CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-237 Fixed type (02) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-236 C++ Fixed type issue (01) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-232 macros for fixed arithmetic results 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-229 CORBA::ORB::InvalidName ambigious in C++ mapping 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-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-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-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-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-137 Missing Mappings for Object 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-139 Semantics of >>= operator in C++ mapping 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-146 void * functions for Any 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-221 Bounded strings 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-212 Interpretation of _narrow semantics 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-158 Extraction from Any by pointer 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-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-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-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-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-152 Object reference members, _var, and widening 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-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-180 Problem with Any::to_object memory management CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-179 Any string extractor CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-184 Names of anonymous types 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-185 get_principal () needs an environment parameter 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-178 Adding T_copy function CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-174 Union discriminators in C++ CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-175 Memory Management Clarification 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-208 Any release flag and operator<<= 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-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-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-199 A_ptr and A_var should be distinct types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-202 Access to sequence elements 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-209 TypeCode interpreter 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-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-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-124 IIOP server-initiated connection closure problem CORBA 2.0 CPP 1.0 Resolved closed
CPP11-125 How to handle unexpected exceptions? CORBA 2.2 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-240 Typo in orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-239 String member initialization CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-246 Signature of _narrow in exceptions 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-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-238 C++ Fixed Type (03) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-241 _out parameter typo CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-166 C++ keyword mapping ambiguous CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-165 Interface issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-163 ORB mapping re Policy CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-162 CustomMarshal mapping type CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-164 Transfer of C++ codes 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-173 In String Argument Passing Question CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-172 C++ classes for modules CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-170 T__alloc in C mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-169 Access to sequence buffers 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-171 Defining an operator for struct/union/sequence _var types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-168 Omission in union C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-194 Sequence lacks common features 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-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-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-198 _var types for fixed-length types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-197 Typo in table 3? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-195 Sequence buffer types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-189 C++ mapping complexity CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-192 Sequence maximum() call CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-196 Sequence creation 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-115 2 of4 issues with Abstract interfaces 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-120 allocbuf() for bounded sequences? CPP 1.0 CPP 1.1 Resolved closed
CPP11-119 Extraction operator for system exceptions? 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-110 Fixed::round and truncate issue 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-116 don't understand the last paragraph of 1.18.2: CPP 1.0 CPP 1.1 Resolved closed
CPP11-118 Need Any::to_value operation? 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-113 NamedValue not only an NVList element CPP 1.0 CPP 1.1 Resolved closed
CPP11-112 Standard object operations & DynamicImplementation CPP 1.0 CPP 1.1 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-123 Typographical problems CPP 1.0 CPP 1.1 Resolved closed
CPP11-100 Contents of string members (01) CPP 1.0 CPP 1.1 Resolved closed
CPP11-99 Union string member mapping defect? CPP 1.0 CPP 1.1 Resolved closed
CPP11-102 String extractor semantics undefined? CPP 1.0 CPP 1.1 Resolved closed
CPP11-101 Contents of string members (02) 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-105 Unary operators for Fixed class have wrong return types CPP 1.0 CPP 1.1 Resolved closed
CPP11-104 Exception constructors should be protected 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-103 Exception::_raise() should be const? CPP 1.0 CPP 1.1 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-73 Context PIDL mapping bug CPP 1.1 CPP 1.3 Resolved closed
CPP13-72 ORB interface destroy() operation issue CPP 1.1 CPP 1.3 Resolved closed
CPP13-74 Section 4.5.4: parameter to _narrow CPP 1.2 CPP 1.3 Resolved closed
CPP13-71 _ptr_type and _var_type typedefs CPP 1.0b1 CPP 1.3 Resolved closed
CPP13-77 C++ keywords should be updated CPP 1.2 CPP 1.3 Resolved closed
CPP13-80 get_policy should return Policy, not Policy_ptr 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
CPP11-89 generate concrete classes and factories for valuetypes without initializer 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-73 Spec does not mention the existance of an Any_out class 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-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-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-82 sequence allocbuf parameter != 0 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-79 Parameter passing rules for ValueFactory CPP 1.0b1 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-86 Misleading text for DSI invoke() and _primary_interface() CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-85 Any missing LongLong operators, etc? 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-77 Section 5.3.6.3 Value Factories CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-47 operator<< for ostreams and Exceptions 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-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-51 [q] intf name == op name 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-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-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-45 buffer classes for sequences 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-54 const method qualification should be removed 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-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-52 Double underscore identifier mapping 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-6 interface mapping 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-3 Passing of object reference in pointers 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-13 Levels of portability conformance requested 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-15 Assignment to T_var CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-14 example incorrect? 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
CPP11-8 Pseudo objects for DSI 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-2 Fixed structs CPP 1.0b1 CPP 1.1 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-93 Sequences and get_buffer() CPP 1.0 CPP 1.1 Resolved closed
CPP11-92 Valuetype argument passing CPP 1.0 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-63 Multiple inheritance of C++ Servants is ill-defined 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-72 _var & _out types problems (01) 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-60 sec. 18.1.2: explicit information on _this() is missing 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-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-68 C++ mapping for fixed is broken (02) 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-65 C and C++ Mapping question 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-57 IDL from Ennvironment has invalid attribute 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-64 inout strings modifiable? 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-35 C++ namespaces 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-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-23 Array_forany 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-39 Name field for SystemExceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-38 union accessors require temporaries 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-27 handling void* from Any CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-26 Pointers vs. values 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-33 accessor function on SystemException CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-32 Mapping for IDL context CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-29 anonymus types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-28 void* from Any for constructed types CPP 1.0b1 CPP 1.1 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-10 Dangling reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-9 Escaped keyword mapping? 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-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-11 Bug on _var references 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-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
CPP12-8 Local interfaces issue 1 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-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
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-84 Content of an Any is a pointer to the type -- Issue 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-75 Editorial 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-77 Wrong order of parameters 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-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-78 Reference to undefined term DIR (Section 14.24.1) 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-65 Contents of string literal exception identifier 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-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-72 Type declaration 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-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-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-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-63 Suggested optimization for string duplication 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-57 Problems with underscores C 1.0b1 C 1.1 Resolved closed
C11-56 C keywords C 1.0b1 C 1.1 Resolved closed

Issues Descriptions

Adjust Description for Telemetry CCSDS Transfer Frame - PARSE-ERRORS

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

    Eric O would like to add to the description for Telemetry CCSDS Transfer Frame - PARSE-ERRORS to account for other types of errors that could be conveyed here.

  • Reported: C2MS 1.1b1 — Thu, 30 Oct 2025 21:01 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add to the Telemetry CCSDS Transfer Frame - PARSE-ERRORS Description

    Change the description of PARSE-ERROS. Adjusted text supplied by Eric O.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

General Cleanup of the Subject Content of Subject Naming Tables

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

    All Response Messages have RESPONSE-STATUS in the ME2 position of the subject, but in the Suject Naming Table, this is represented inconsistently between different messages.

    Simple Service is the only one that has the proper "Subject Content", which should be "[RESPONSE-STATUS]". However, Simple Service also has incorrect values in that ME2 field.

    This issue is for the Subject Naming Tables to use [RESPONSE-STATUS] in ME2 for each Response Message and to confirm valid values in the examples.

    Additionally, many other Message Elements that represent a value of a Message Field also show possible values in the Subject Content, even though this is already described elsewhere. See Log Message as an specific example. All these should be reduced to [<FIELD-NAME>] instead of showing the incomplete list of possible values. Doing so will make this table more clear. This change needs to be done for each Subject Naming Table, so should be a directive to the Editor with an example or two, rather than enumerating each case.

    Additionally, when these MEs represent a specific named field of the message, they should list it in the brackets. For example, instead of "[request id]" it should be "[REQUEST-ID]"

  • Reported: C2MS 1.1b1 — Tue, 14 Oct 2025 14:56 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Standardize Subject Tables

    Fix any offending Message Subject Naming tables. This resolution provides permission to the editor to make all changes to these tables per the following rules and using the example attachments modifications as a guide:

    • All Response Messages have RESPONSE-STATUS in the ME2 position of the subject, but in the Subject Naming Table, this is represented inconsistently between different messages. Subject Naming Tables to use [RESPONSE-STATUS] in ME2 for each Response Message. This is illustrated per the example of Replay Telemetry Data Response Message which has a before and after attachment.
    • Additionally, many other Message Elements that represent a value of a Message Field also show possible values in the Subject Content, even though this is already described elsewhere. See Log Message as an specific example. All these should be reduced to [<FIELD-NAME>] instead of showing the incomplete list of possible values.
    • Also, when these MEs represent a specific named field of the message, they should list it in the brackets. For example, instead of "[request id]" it should be "[REQUEST-ID]". This is shown in the changes (via attachments) to the xxx xxx xxx Subject Naming table.

    Finally, Simple Service Response also has incorrect example values in the ME2 field, and is corrected here to contain proper values.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Some examples of Subject Subscriptions use Wrong Form

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

    An asterisk (*) can take the place of exactly one whole element

    According to Section "6.2.2 Format of C2MS Subject Names", particularly:

    • "Table 6-2 Asterisk, Greater Than, and Plus Sign Wildcard Syntax Examples" and
    • "Table 6-3. Subject Name Matching Examples"
      The trailing '>' character means one or more, while trailing '+' character means zero or more.

    However, in the subject subscription examples provided of subjects in each message's description, many examples use '>' when they should use '+'.

    One example is found Simple Service Messages.

    Additionally, some have an improper space character between the last period and the '>' '*' or '+' character, which is incorrect. See Log Message as an example.

    Need to review all these and then offer correction.

  • Reported: C2MS 1.1b1 — Mon, 15 Sep 2025 20:18 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix errors in subscription examples

    Fix errors in subscription examples, per the main issue.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Consider buying back some messages created for some specific missions as a possible new message in C2MS.


Improve Example Text for Publish Rate

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

    In section 8.9.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: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Update Example Text for Publish Rate in 1.2

    Remove the discussion of the corner case of not being able to keep up with the request publish rate. It is up to the service provider to decide what to do in that situation; no need to give this one specific detail here.

    Additionally there is no need for the PUBLISH-RATE section here. Taking away the detail of the corner case listed above, the only information left in these paragraphs is already described in the preceding table, so just delete the section to be cleaner.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Rework "Introduction to Specification" into a Section Describing Expected Use

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

    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 section titled: "Introduction to Specification" needs evaluation and at least some rework. This is largely written as a "how we got to here" section, but could use more C2MS-centric language. Also, this should be considered to be moved from the front matter to a numbered section, such as perhaps 5.1 (moving the existing 5.1 to 5.2), and perhaps called "System Architecture", "Guidance", "User Guide", or something like that.

    If moved to a numbered section, it needs to be marked "Informative".

    The idea is to communicate context for how C2MS has been created and how it is expected to be used.

    One concept to make clear is that it does not require a message bus, but that is one expected use. Also, that when using message bus architecture, that more than one bus is a probable solution for many issues. For example, raw TLM might flow on one bus, MVALs on another, Replay on another.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:36 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Rework into in 1.2

    This resolution completely rewrites the existing Introduction to Specification section, removing almost all prior text and all diagrams. New text is provided to introduce the reader to the overall nature of C2MS, which is fully described in details that following in the normative document.

    Guidelines used in the rewrite:

    • Remove the history of how we got C2MS
    • Eliminate the discussion of GMSEC, which is merely one PSM, and neither the purpose for nor the assumed implementation of C2MS.
    • Move away from Pub/Sub as the assumed transport mechanism... it is supported but not required nor emphasized.
    • Provide very high-level introduction to the three types of messages, but defer to the document for detail
    • Introduce the concept of Message Exchange Patterns for use of the three message types, but defer to the document for detail
    • Discuss the need, but not the method, for tailoring C2MS for the environment of use.
    • Emphasize the flexible nature of the message set that can be used in a way determined best by the enterprise/domain where it is employed.

    Rationale for the choices made in the rewrite:

    • No diagrams are included, rather the introduction is reduced to a simple 3/4-ish pages to promote it as a brief high-level explanation, more likely to be read. All prior (PowerPoint-built) diagrams existed only to illustrate the use of a message bus via GMSEC API as a means of communication, which is no longer to be emphasized. The concept of components communicating with each other over a non-defined transport mechanism does not warrant a picture.
    • The intro is kept in its current place in the document to be consistent with other Space Domain Task Force specification. Those that have one, have it in this location.
    • NASA/GMSEC are mentioned (outside the Introduction) as providing one PSM for possible use. This already exists, but is being cleaned up. Because NASA has provided the only known PSM, it makes sense to maintain this note.
  • Updated: Mon, 30 Mar 2026 14:00 GMT

Create final version of all model diagrams that have more than one resolution

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

    Some model diagrams are affected by more than one issue, and as such, all the changes need to be combined into one final SVG image in this issue to finalize the edits.

    Note, for example, that some messages (see Event and Log Message from C2MS12-43) have a 2025 date, but should be made 2026, because 1.2 has taken a bit longer than planned and will be finalized in 2026. It would be good to go through every model change and determine for sure if it needs to be content-version of 2026.

    Also, note that in C2MS12-53, all message diagrams are being updated, so really, this issue should capture all the final changes. Because of the same issue, all messages should have a CONTENT-VERSION of 2026 because of the addition of CUSTOM-FIELDs.

    Include the Request Data Stream MEP, which is slightly improved from the original issue (just better spacing of lines)

  • Reported: C2MS 1.1b1 — Sat, 12 Jul 2025 18:16 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Final versions of all message diagrams

    This issue is to provide the final SVG for each C2MS Message model diagram figure, named C2MS12-143x, but are all in alphabetical order by class name.

    This is due to the figures being changed in more than one JIRA issue. This is the final version of these diagrams which can be placed into the document.

    Other figures (non-C2MS-Message-figures) have not had to be consolidated across multiple Jira issues.

    This does not include the new messages being added in the concurrent C2MS12-54 which has five new message model images itself. They are final as represented in that other issue. Note that here we left space for them in the numbering of attachments (C2MS12-143_19 through 23 inclusive) as an indicator of their presence in the other issue. These attachment numbers are not included or used in this issue.

    Note that we don't include the originals here, because all these changes have already been approved. The purpose of this present issue is to to approve changes, but to produce the final version of these SVGs.

    All SVGs are included in a single zip file attachment.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Need Review/Documented Explanation of NUM-OF-PROD-SUBTYPE-SUBCATEGORIES

  • Key: C2MS12-39
  • 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. This is described in the table and notes for the table for (C2MS 1.1) "Table 8-163. Properties of the Miscellaneous Elements for the Product Message"

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 17:42 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    add additional explainer and short example to tables where field is defined

    the fields basically make a hierarchical name, albeit in a clunky and confusing manner. the fields are intended to be used in conjunction with the table in A2 as well.

    To address this issue in 1.2, we'll add brief explainer under each table the field is used.

    For he future we need a new issue for hierarchical naming.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Replay TLM Data Response Message text correction

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

    In the description of the Replay TLM Data Response, the text uses the term "requestor" when it should be "responder" leading to confusion.

  • Reported: C2MS 1.1b1 — Sun, 26 Oct 2025 16:01 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix the errant text

    Fixt text under Replay Telemetry Data Response Message.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Two incorrect Subject Naming Tables

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

    Table 8-75 Telemetry CCSDS CADU Frame Message Subject Naming is Incorrect. It has incorrect formatting and lists ME5 instead of ME3 as the third ME.

    Table 8-162 Product Message is missing Subject Content titles and FILL in ME5 and ME6. (see Telemetry Processed Frame for how to represent this)

  • Reported: C2MS 1.1b1 — Tue, 14 Oct 2025 14:52 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix these in 1.2

    Fix two diagrams. Note that these are shown as bitmap before and after images, because these tables are difficult to display in wiki markup.

    The 8-75 table changes ME5 to ME3 and fixes cell borders in the ME section.

    Table 8-16 adds "(see notes)" for the title in Subject Content. This is because the actual data there is "Product Subtype Subcategory 1" (or 2). This would overwhelm the available space in that cell and required extensive information in the notes, already, so we take that up there. This is not a recommended way to handle other fields, but makes sense only here because of the complicated nature of these MEs.

    Also, this table adds FILL values where appropriate. Finally, an additional record is added to give another example to help.

    Note, too, that text a bit after this table needs some correction as shown in Revised Text to account for the correct usage of the miscellaneous elements.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

The Model still has Optional Fields and Required Fields classes

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

    Telemetry CCSDS Transfer Frame Message still has Optional and Required elements as aggregators in the model.

    MNE Value Request Message still has Required element as aggregator in the model.

    In both cases, we need to make sure all the fields are migrated to the top level and still exist in the C2MS Spec, then remove the elements listed here.

  • Reported: C2MS 1.1b1 — Sat, 12 Jul 2025 20:15 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Remove extra fields in model

    There's nothing to show, as this doesn't change the document at all, but in the model, remove the following UML classes with all their properties (these aren't used anywhere, so it's not problem to do it). I have confirmed with Eric about the CCSDS Message to make sure we didn't miss something in 1.1, and we are OK): It was just an oversight to have left them in the model, though unused.

    MNE Value Request Message (these classes are empty, so truly no need for them):

    • Dependent Fields
    • Required Fields

    Telemetry CCSDS Transfer Frame Message (see attachment):

    • Optional Fields
    • Required Fields
  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Add subsection description for Generic Service RESP and DATA MSGs

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

    In the already-approved C2MS12-22, there was no description provided for OMG Generic Service Response Message or OMG Generic Service Data Message. Need to add these.

  • Reported: C2MS 1.1b1 — Tue, 21 Oct 2025 12:57 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add missing text for Generic Service Messages

    Add missing text into the text already provided in the already-approved C2MS12-22.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Create a C2MS SM&C MAL Message

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

    The SM&C defines a set of mission operations services. At the bottom of this we believe there's an SM&C MAL message.

    We believe that if we define a C2MS MAL message and appropriate delivery (addressing) – that any C2MS service could flow over a C2MS implementation.

  • Reported: C2MS 1.1b1 — Mon, 16 Sep 2024 19:45 GMT
  • Disposition: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    duplicate of C2MS12-74

    This is a duplicate of C2MS12-74.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Adjust FINAL-MESSAGE Verbiage for Response Messages


Product Messages do not have Message Summary Tables

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

    None of the Product Messages contain a Message Summary Table (see Table 8-146 Command Echo Message Summary).

    All the other messages except Navigation Data Messages have summary tables. These NDMs are represented somewhat differently in C2MS, so not too worrisome that they don't, but Product Message are clear outliers with the other message types.

    These tables typically are followed with examples, also missing for Product Messages.

  • Reported: C2MS 1.1b1 — Sun, 12 Oct 2025 21:23 GMT
  • Disposition: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Duplicate of C2MS12-196

    Duplicate of C2MS12-196

  • Updated: Mon, 30 Mar 2026 14:00 GMT

REQUEST-ID is Required in Product Message, but Shouldn't be

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

    Product Message, by its description, can be produced either 1) as the result of a Product Request Message or 2) unsolicited. The REQUEST-ID is used to match a Product Message to correlate the PM with the originating request, which would be case 1, above. However, in case 2, there would be no original request.

    REQUEST-ID should therefore be optional.

  • Reported: C2MS 1.1b1 — Tue, 19 Aug 2025 19:37 GMT
  • Disposition: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Dup of C2MS12-150

    The description of this issue has been included into the closely-related C2MS12-150, leaving this issue as a Dup of C2MS12-150.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Rework 8.12 Product Messages Intro

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

    Section 8.12 Product Messages is the only major section of that Chapter without an Intro. The intro should discuss the purpose and use of all product messages. See any other major section of chapter 8 for examples.

    Additionally, none of the Product Messages contain a Message Summary Table (see Table 8-146 Command Echo Message Summary).

    All the other messages except Navigation Data Messages have summary tables. These NDMs are represented somewhat differently in C2MS, so not too worrisome that they don't, but Product Message are clear outliers with the other message types.

    These tables typically are followed with examples, also missing for Product Messages.

  • Reported: C2MS 1.1b1 — Sat, 18 Oct 2025 21:50 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Rework Product Messages Intro

    Rework Introduction to Product Messages. A lot of this existed but was placed under Product Request. That section is being moved and a new paragraph is being supplied here for Request and Response text.

    Also add Summary tables and examples to each message type.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Rework "Response" Semantics in Product Message

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

    The Product Message has a lot of aspects that are tied to it being a "response" to a REQ rather than simply a message with data (that might have been produced as a result of a REQ, but that shouldn't be tied to a REQ or RESP).

    C2MS12-119 (already-approved) has deprecated FINAL-MESSAGE and RESPONSE-STATUS to try to get away from this, but the message is in need of more review/work in this regard. For example, it also contains a RETURN-VALUE which is a field related to the already-deprecated RESPONSE-STATUS. That would should probably be deprecated, too. Additionally, it has a TIME-COMPLETED which is a Response Message field, though in this case, it might make sense to keep it as it indicates when the product was created... in other words, it was put here along with the other Response fields, but has a different meaning here (ugh).

    But other fields could stand review. The goal should be to make this a data message without reference to a REQ. Yet some of the fields seem to be in it exactly for this reason (see PROD-MSG-TO-SEND, for example).

    A complete review of all the field should be done and deprecate those that should better be handled in the already-existing Product Response Message.

    Special note on REQUEST-ID: as with other data messages in a REQ-RESP-NOTIFY Triade, Product Message, by its description, can be produced either 1) as the result of a Product Request Message or 2) unsolicited. The REQUEST-ID is used to match a Product Message to correlate the PM with the originating request, which would be case in 1, above. However, in case 2, there would be no original request.

    REQUEST-ID should therefore be optional.

  • Reported: C2MS 1.1b1 — Mon, 11 Aug 2025 15:20 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Correct the Product Message by Removing Response Semantics

    Deprecate fields that are supposed to be (and are) present in the Product Response, but don't belong in the Product Message.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Cleanup of Message Summary Tables

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

    Table 8-15 Archive Message Retrieval Request Summary has the first column centered. It's the only one of this type, all others of this type use left-justified, so that needs to be corrected.

    Additionally all these tables throughout the document use "Senders Intended Usage" and "Receivers Intended Usage". These should be "Sender's" and "Receiver's" respectively. Or maybe Senders' or maybe we just say "Intended Usage for Senders" They all have to change anyway, so this might be the best form.

  • Reported: C2MS 1.1b1 — Mon, 15 Sep 2025 15:49 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix grammar in Tables

    In Message Summary Tables, use "Intended Usage of Sender" instead of "Senders Intended Usage" and "Intended Usage of Receiver" instead of "Receivers Intended Usage".

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Make ME1 Optional for all Request Messages

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

    Allow ME1 (DESTINATION-COMPONENT) to be optional in all request message subjects. Note that the Header field DESTINATION-COMPONENT is already optional in the message itself. This would be the same we do on the OMG Generic Service Request in C2MS12-22, and we don't need SERVICE-GROUP/NAME/OPERATION-NAME, because the rest of the C2MS Messages are typed and already carry what is being requested.

    This is backward compatible, because it's moving ME1 from Required to Optional (less stringent).

    Note, too, that there was already a sort of hint at this in section 6.2.3.5 Miscellaneous Elements of the C2MS Subject Name which in its final paragraph talks about possibly using ME1 not for DESTINATION-COMPONENT, but for "group names" as a way to indirectly reach a component that is part of a single grouping of services. That's a bit of a kludge, but just allowing it to be not-specified works great. As it turns out, "group name" isn't needed because the request message is already strongly typed (I need MVALS for domain1, domain2, mission, constellation, satellite). That's very specific already, and leaving ME1 blank allows requestors to put out this message with no known component name, but to get back a response of exactly what I asked for.

  • Reported: C2MS 1.1b1 — Tue, 14 Oct 2025 23:25 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Make ME1 optional in C2MS Request Messages

    Make ME1 optional in C2MS Request Messages to allow for sending a request out to no one in parricular and expecting some service to respond. This closely aligns with, but improves upon Simple Service Request, which allowed specifying either a DESTINATION-COMPONENT or a SERVICE-NAME in ME1. It also closely aligns with the better OMG Generic Service Message defined in C2MS12-22.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Deprecate 1=Acknowledgment for MVAL Response Message

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

    Since there can be only one response, not sure ack makes sense. The idea is to start a stream of MVALs. Possible return values could be constrained to success, failed, invalid.

  • Reported: C2MS 1.1b1 — Thu, 25 Sep 2025 14:20 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Remove 1=Ack from MVAL Response Since only One Response Returned

    Because only a single response is supposed to be returned from MVAL Request, it doesn't makes sense for ACK to be one of the response values... changing to be one of the remaining possible values: success/fail/invalid.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Using REQ Messages for 'Publish'

  • Key: C2MS12-15
  • 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: Resolved — C2MS 1.2b1
  • Disposition Summary:

    With Fixed MEPS to avoid using REQ for Publish, Fix Related Content

    The Publish (Notify) Message Exchange Pattern itself was already fixed in C2MS12-167, however, there is lingering text in the document that is being fixed and a RESPOSE boolean field in some Request Messages that were apparently added to support using REQ as Publish, so those are being deprecated. (Note that we aren't bothering to deprecated RESPONSE in Simple Service Request, because that message is already itself deprecated.)

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Make SERVICE-NAME an Alternate way to Reach a Service

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

    For Request Messages, ME1 is always the DESTINATION-NODE, currently.

    Add another ME value for SERVICE-NAME. Make it mutually-exclusive. You either specify DESTINATION-COMPONENT or SERVICE-NAME. If the former, it's like it is today. If the latter, it is a REQUEST that doesn't know which component will process it.

    We have to make ME1 optional for these request messages..

    Strengthen the discussion of "FILL" in 6.2.2. State that is is a reserved word in subjects and that not only can it be sent as FILL, but a subscriber can also subscribe to FILL to catch cases where the DESTINATION-COMPONENT is not specified.

    Add a subsection that talks about requests and their use of SERVICE-NAME. These services should subscribe to FILL for D/C so that they respond to any request with the SERVICE-NAME.

    Somewhere Describe sense of component registry and not allowing more than one component to subscribe. These would be implemented in the domain according to domain requirements. In other words, Explain the peril about multiple responders and guidelines of how to approach it. Maybe they create a registry/lookup. Could use C2MS-EXT messages. Maybe we adopt this at a future time.

  • Reported: C2MS 1.1b1 — Tue, 16 Sep 2025 22:10 GMT
  • Disposition: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    No need

    After consideration, this was deemed not necessary. A better approach is to have the ability to lookup a service DESTINATION-COMPONENT in some kind of registry, rather than change the way these messages are delivered.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Replace simple service REQ/RESP

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

    Replace simple service REQ/RESP and deprecate current simple service messages. Maybe call this "Generic Service".

    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.

    If we create a new replacement for Simple Service, need to account for the question raised in C2MS12-41.

    Text from C2MS12-17, which was marked a dup of this issue:
    = = =
    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 requests to do that same thing, matching the modification made by that major user.

    = = =

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

    Create Generic Service Messages

    Deprecate the Simple Service Req/Resp messages. Create OMG Generic Service Request, Response and Data (notification) messages all within C2MS-EXT.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Acknowledge Final Status inconsistency

  • Key: C2MS12-5
  • 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: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix MEPs WRT Final Status Inconsistencies

    With C2MS12-119 resolution, the MEPs 2, 4 and 5 can be greatly clarified to close earlier sequence ambiguities.

    Change those MEPs to lever the improvements made in that other issue resolution.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Documentation Changes to Move Away from Pub/Sub Expectation

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

    C2MS has constructs and language that make it seem like a pub/sub specification, though that is merely one possible architecture. C2MS message define a format for messages that could be used in a service-based architecture.

    To aid with this, we should not use the term 'publish', and we should be careful with 'subscribe'.

    This is in order to get away from the assumption of a pub/sub architecture. This will include renaming the MEPS that have "Publish".

    Note that some already-approved issues in this release might have used "Publish". Need to find and correct these.

    We should further state that the Subject is optional used to aid message delivery, most useful in a pub/sub setup, but the subject is derived from, rather than adding to the message itself.

    In the document, use terms like 'send' instead of 'publish'. Make the patterns refer to Notify rather than publish.

  • Reported: C2MS 1.1b1 — Thu, 18 Sep 2025 14:16 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Do this in 1.2

    As much as possible, rid C2MS of the concept of Publish/Subscribe. This issue resolution modifies text and diagrams in chapters 6 and 7 and describes a pattern for general text editing for one-off uses of publish or subscribe throughout the rest of the document.

    This issue assumes the Introduction to Specification will be entirely reconstructed at a future time, so does not address the heavy pub/sub description there. See C2MS12-28.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Improve Representation of Message Types


Allow SERVICE-GROUP/NAME/OP-NAME in lieu of or along side DESTINATION-COMPNENT

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

    On Request Messages, allow SERVICE-GROUP, SERVICE-NAME and/or OPERATION-NAME to be used to find a service rather than DESTINATION-COMPONENT.

    One case would also use a DESTINATION-COMPONENT, implying that the message conveys to that directly-named component the S/G-S/N-O/N.

  • Reported: C2MS 1.1b1 — Thu, 18 Sep 2025 14:29 GMT
  • Disposition: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Dup of C2MS12-164

    Duplicate

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Should Typed Variable DATA-VALUE be String instead of binary

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

    From C2MS12.53 (already approved), the Typed Variable has a DATA-VALUE of type Binary. Could we make this String instead?

  • Reported: C2MS 1.1b1 — Tue, 19 Aug 2025 22:00 GMT
  • Disposition: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    No change

    After discussion in RTF, this is not needed.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Do we need to add the ability to include a Classification Level?

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

    It would have to be optional, but could be useful. I'm thinking a String whose value is determined by the domain where it operates, as these could be different depending on the country and could include (or not) releasability tags.

  • Reported: C2MS 1.1b1 — Mon, 8 Sep 2025 13:06 GMT
  • Disposition: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    No need

    MESSAGE-CLASS from the Header does this. It's optional, but that seems appropriate.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Replace "Publish" with "Broadcast"

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

    This is in order to get away from the assumption of a pub/sub architecture. This will include renaming the MEPS that have "Publish".

    Note that some already-approved issues in this release might have used "Publish". Need to find and correct these.

    Other possible replacement terms include disseminate, Notify/Notification.

  • Reported: C2MS 1.1b1 — Tue, 16 Sep 2025 22:13 GMT
  • Disposition: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Duplicates C2MS12-167

    Duplicates C2MS12-167

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Allow custom message subtypes

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

    C2MS12-53 calls for a way to make C2MS-defined messages extensible. This issue is to allow new TYPES of messages to be defined, within the construct of C2MS. This is to avoid having new messages defined that are not really C2MS Messages.

    This could also alleviate C2MS12-22.

    If we do this, we should consider allowing the user to specify a MESSAGE-SUBTYPE that is custom (though the MESSAGE-TYPE would still be just MSG/REQ/RESP). A couple of ways this could be done would be to say it must always start with "CUSTOM-", such as "CUSTOM-MISSIONX-CALCULATE-ORBIT". Note that if we do this, we need to change the Description in Table 8-2 for MESSAGE-SUBTYPE.

    Alternatively, we could use "CUSTOM" as the MESSAGE-SUBTYPE, and use ME1 to designate the "Custom Message Subtype". In many ways, this is cleaner, but doesn't take advantage of SUBTYP being a part of the message subject directly and uses up one of the ME slots.

    Either way, we would describe that they should use naming that avoids conflicts as we said in the resolution for C2MS12-53.

    We should consider some kind of registry, perhaps... maybe maintained at the DOMAIN1 level.

    In C2MS 2.0, we could consider adding a SubSpecification to go along with the Specication (C2MS), but that wouldn't be possible in 1.x.

    If we do anyting in 1.x, we should add a clear descriptoin of how it works, perhaps near or in 6.2.3.4 Message Elements of the C2MS Subject Name.

  • Reported: C2MS 1.1b1 — Tue, 27 May 2025 16:31 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add New C2MS Extension Messages to Allow Custom Messages

    This resolution assumes the acceptance of the resolution for C2MS12-177.

    Add a new "specification" of C2MS-EXT to allow adding custom C2MS-based messages but that conform to a C2MS standard.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Need to update references to NASA Goddard Docs

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

    Current document references NASA Goddard docs in the front matter. These should be brought to current versions:

    3.2.1 NASA GMSEC Documents
    The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.
    • GMSEC Architecture Document, Release 2.8.1, February 2014
    • GMSEC API 4.3 User’s Guide, May 2017

  • Reported: C2MS 1.1b1 — Mon, 17 Feb 2025 16:09 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    update references to GMSEC documents

    BEFORE
    3.2.1 NASA GMSEC Documents
    The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.
    • GMSEC Architecture Document, Release 2.8.1, February 2014
    • GMSEC API 4.3 User’s Guide, May 2017

    AFTER

    3.2.1 NASA GMSEC Documents
    The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.
    • GMSEC Architecture Document, Release 3.0.0, February 2018
    • GMSEC API 5.2 User’s Guide, November 2023

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Recommend UTF-8 for Text Encoding in C2MS implementations/usage

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

    The spec does not mention anything about text encoding. Although the PIM doesn't have to specify it, and it should be designated by PSMs, it would make sense to 'recommend' UTF-8 as the standard to be used by implementations.

  • Reported: C2MS 1.1 — Wed, 11 Jun 2025 17:26 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Suggest UTF-8

    Specify UTF-8, but allow individual PSMs to override.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

in 8.1, we sometimes have table and section names that have wrong term

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

    In this section, anytime we have a table or subsection or diagram name it should always be C2MS Message Envelope, instead of simply Message Envelope. The type is the former.

  • Reported: C2MS 1.1b1 — Tue, 19 Aug 2025 22:03 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Use complete name for C2MS Message Envelope in Headers and Titles

    In Section 8.1, ensure "C2MS Message Envelope" is used instead of "Message Envelope" in section and table titles. Also do this when referring to the class name. When not referring to the full class name, soften Message Envelope to message envelope.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Fix change in Table 8-155 Product Request Message Add'l Info

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

    In C2MS12-115, already approved, there was an error in the text of one cell in Table 8-155 Product Request Message Add'l Info which needs to be fixed. Specifically, under URI, the Description says "Location where the requesting component is asking for the product file(s) to be stored. Could be a web address, directory, or folder specification . Required if DELIVER-VIA-INCLUDE is True. Not used otherwise." but should be DELIVER-VIA-REFERENCE.

  • Reported: C2MS 1.1b1 — Tue, 19 Aug 2025 20:32 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix text in table cell

    Make fix specified in reported issue.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Missing Type for MVAL Data and AMVAL Data Messages

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

    Mne Value Data Message AND Archive Mne Value Data Message have missing type for ALARM-STATE in diagram. Need an updated diagram for both of these.

  • Reported: C2MS 1.1b1 — Fri, 11 Jul 2025 20:15 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add Type to Diagrams where Missing

    Modify the diagrams for MVAL and AMVAL Data Message to include the type (which is I16) where it is currently missing. Note that the type is already defined in the text, just missing in the table.

    Also note that I'm not showing original and updated diagrams here, because both of those diagrams are being modified in other issues and will be consolidated in C2MS12-143. Showing them here would take undue time and could result in confusion.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

use of brackets not consistent for Subject Elements

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

    In the "... Subject Naming" tables, a "Subject Content" item is supposed to have brackets [] around variables and no brackets for literals. This is not always followed though. See Telemetry CCSDS Packet Message as an example.ME2-ME6 do not use brackets, but should. Several other tables are like this.

  • Reported: C2MS 1.0 — Mon, 13 May 2024 06:05 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add brackets to variables in subject fields

    Updated all "Subject Naming" tables to add brackets around variables in the Subject Content definition.

    A Word document with change tracking is attached to help clarify where changes have been made.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:
    • C2MS12-50.docx 29 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Non-sensical Description for PROD-MSGS-TO-SEND

  • Key: C2MS12-35
  • 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: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Clarify description for PROD-MSGS-TO-SEND field

    Update the notes for the PROD-MSGS-TO-SEND field of the Product Response Message to indicate that the field should not be included if the number of messages is unknown.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Clarity and Usage Issues with Replay Telemetry Data Request (and Response) Message

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

    There are some clarity issues with Replay Telemetry Data Request (and Response) Message:

    • There is a STREAM-MODE the fields of the Replay Telemetry Data Request 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.
    • There is no mention that the replayed TLM messages should be marked with STREAM-MODE of RPY (Replay), but I assume that would be true, because otherwise, there would be no way to have RPY messages. This should be discussed in the context of this message.
    • There is a lot of messiness that can come from replaying the telemetry messages back in an operational environment. I could pick messages to replay from two years ago. What processes are listening for those messages? Do MVAL messages also get produced from the replayed TLM? Note that these cannot be marked RPY. Are Event Messages produced from the limit checks? Note that these cannot be marked RPY. Blech. Probably need a discussion of all this and a warning, again, not to have RPY messages flow in an operational environment.
    • There is discussion in "8.8 Replay Telemetry Data Messages" regarding using the Replay Request Message to get "real-time" or even "a future flow of data". In other words, there has been consideration at some point about using these messages as a way to request TLM messages wholly apart from subscribing to the normal published TLM messages. The only apparent benefits of this are the ability to constrain the DATA-RATE, to affect the PLAYBACK-RATIO, or to allow pausing or stepping through the TLM stream of the current (or future) real-time data. Any other elements of the data stream, could simply be filtered out as part of normal pub-sub of the standard messages. This makes for a bit of a Frankenstein meaning to the Replay messages. Not sure what do do about this. I think it actually simply makes more sense to say, if you want to do this kind of stuff, get the messages replayed from the archive, rather than to use this as a mechanism to affect real-time data. In any case, this could use some attention and explanation. Bottom line, I feel like this is one of those cases where the power of infinite flexibility has been employed so say, "Sure this is a message about replay, but you can get it to do basically whatever you want related to telemetry streams."
    • Section "8.8 Replay Telemetry Data Messages" refers to "Replay Telemetry Data Messages". However, this is a category rather than a specific message type, so some rewording is probably worthwhile to avoid confusion. The term "Replay Telemetry Data Messages" refers to replayed messages related to telemetry, which are specifically and exclusively: Telemetry CCSDS Packet Message, Telemetry CCSDS Frame Message, Telemetry CCSDS CADU Frame Message, Telemetry CCSDS Transfer Frame Message, Telemetry TDM Frame Message, and Telemetry Processed Frame Message.
  • Reported: C2MS 1.0 — Sun, 19 Mar 2023 21:16 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Clear up Usage and Documentation with Replay Telemetry Data Request (and Response) Message

    Rework some of the text in section 8.8 Replay Telemetry Data Messages to clarify usage of the Replay Telemetry Data Request (and Response) Message as shown in Revised Text of this issue.

    The intention is to deconflict the confusing description about real-time and future data flows, the nature of the data as being from the "data archive" vs "simulator", "data generator" or "future flow", as well as to account for how the data is to be produced and handled.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Split ME1 in Simple Service Req/Resp

  • Key: C2MS12-17
  • 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: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Simple Service is being Replaced, so this will be done in that issue

    The issue in-hand will be taken care of in the 'replace' issue

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Correct Final Message Construct

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

    Some messages have a RESPONSE-STATUS that has a value of 6=Final Message. However, "Final Message" is not a response status, especially when compared to the other five possible values, but rather a qualifier about an individual response message. Further, there is no guarantee that a Final Message will be sent. For example, if a response message is marked with "Acknowledge", should there then be a separate "Final Message"? If a response message is marked with "Working / Keep Alive", should there then be a separate "Final Message"? In these cases, it is actually ambiguous. Table 6-11 Sequence of Response Status seems to indicate that a Final Message may follow an Acknowledge or Working/Keep Alive, but no others. Yet it seems possible to see an ACK followed by Working / Keep Alive, Followed by either Successful Completion or Failed Completion, and the concept of a Final Message is left hanging in those cases. It's just a bit strange.

    A better way would be to allow any response message that supports sequences to indicate in a Boolean that it is the last message that will be received in a response, allowing both sequencing and single messages. In fact, many messages (like product message) that can be sent as part of a sequence do have a FINAL-MESSAGE Boolean field.

    This RESPONSE-STATUS is described in section 6.4.2.2 C2MS RESP Message Type Details and is used in the following messages:

    • Directive Response Message
    • Replay Telemetry Data Response Message
    • Archive Mnemonic Value Response Message
    • Command Response Message
    • Product Response Message
    • Product Message (it is wholly unneeded here and likely caused by copy-paste from the wrong source... It should be deprecated)
    • Simple Service Response Message

    In all the response messages above, deprecate the use of 6=Final Message, add an optional Boolean (default to false) called FINAL-RESPONSE-MESSAGE. This allows FINAL-RESPONSE-MESSAGE to be set for all true statuses. Ensure that there is a FINAL-MESSAGE Boolean in all things that could be sent, like Product Message (which already has this Boolean).

    Show an improved MEP (via C2MS12-5) that includes product messages (or the like) flowing within a response set.

  • Reported: C2MS 1.1b1 — Tue, 27 May 2025 18:12 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Handle RESPONSE-STATUS Properly and Add FINAL-RESPONSE-MESSAGE Boolean

    Where appropriate correct the use of RESPONSE-STATUS to deprecate 6=FINAL-RESPONSE-MESSAGE usage. See Issue description for C2MS12-119.

    "Show an improved MEP that includes Product Messages flowing within the Response set. Deprecate response-status in product message, add FINAL-MESSAGE Boolean everywhere that there is a RESPONSE-STATUS, after the model of Product Message. Deprecate the use of 6=FINAL MESSAGE in all RESPONSE-MESSAGES." (although, note that the MEP will be reworked in a separate issue once the structure is approved).

    Fix section 6.4.2.2 C2MS RESP Message Type Details as shown in the revised text.

    Annotate Table 6-10 Response Status Substructure to show that the use of 6 is deprecated.

    Correct Table 6-11 Sequence of Response Status.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Fix diagrams from C2MS12-8 Resolution

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

    Four of the "revised" SVGs in the resolution for C2MS12-8 we from an earlier iteration and still used the term "CAL-VALUE" instead of just "VALUE". Correct these.

  • Reported: C2MS 1.1b1 — Mon, 23 Jun 2025 20:31 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix Some Diagrams from the Resolution to C2MS12-8

    Four of the "revised" SVGs in the resolution for C2MS12-8 we from an earlier iteration and still used the term "CAL-VALUE" instead of just "VALUE". Correct these.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Lack of Required Fields in Sub-elements

  • Key: C2MS12-41
  • 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.

    The complete list of messages/classes that exhibit this are:

    • C2MS Message Envelope
    • Telemetry Processed Frame Message
    • Mnemonic Value Response Message
    • Mnemonic Value Data Message
    • Archive Mnemonic Value Data Message
    • Device Message
    • Resource Message
    • Product Request Message
    • Product Response Message
    • Product Message
    • Simple Service Message
    • Archive Message Retrieval Request
  • Reported: C2MS 1.0 — Sun, 7 Apr 2024 22:57 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Make obviously required sub-element fields required in the documentation

    Update some fields from Optional to Dependent or Required for sub-elements. This is on a case-by-case basis. In some cases, there are no obvious patterns for what fields might be Required in a given sub-element, so we try to do it only where there is obvious clarity that can be expressed.

    NOTE: Changing a field from optional to required is technically not backward compatible. However in each of the instances below that are being changed, the change is being made because in practice the field is de facto required and this change is simply catching up with that need. For example, in Archive Message Retrieval Request, it is technically allowed in 1.1 to designate a FIELD with neither a NAME nor CONTENT, but it would have no meaning, and would therefore be incorrect to do so. Both are required in practice and are now being marked as required.

    The following changes (if any) are being made in support of each message type that has this situation:

    • C2MS Message Envelope - no change. The sub elements are constructed in this way to allow maximum flexibility to the user. It would be heavy-weight to mark every field as dependent and say that at least one must be present. Although it would be technically accurate to do so, it would be more messy than helpful. Here, we leave this the way it is and leave the user to (in practice) use the message in an assumed way that has at least one of the many possible values filled in.
    • Archive Message Retrieval Request - Here it is non-sensical to send a request with a "FIELD" that does not have both the NAME of the field and the CONTENT match for the field. Therefore, the table and diagram are being updated to make these both required for each FIELD.
    • Device Message - Again, it is non-sensical to have a Device Parameter that does not have at least both a NAME and a VALUE. Therefore, the table and diagram are being updated to make NAME required for each Device Parameter. However, PARAM-VALUE is new in C2MS12-8 Resolution, so can't be made required. VALUE is being deprecated, so no need to do anything with it.
    • Resource Message - Similar to C2MS Message Envelope, above, the fields in these sub elements are much more free-form, with the user able to use any combination of them. Technically, it is true that at least one in each sub-element should be present. However, this message is being deprecated in C2MS12-31, so no action will be taken on this one, here.
    • Telemetry Processed Frame Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this.
    • Mnemonic Value Response Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this.
    • Mnemonic Value Data Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this. This Message is an interesting case because in the closely-related MVAL Response Message Mnemonic.name and .status are required, but not in this message... which is obviously wrong, so correcting here to note it as required. In practice it already is, so though this is a technically breaking change, in practice there is no case when these fields aren't set.
    • Archive Mnemonic Value Data Message- Here the new VALUE (From C2MS12-8 resolution) should be required in Sample. However, because this field is being introduced in 1.2, it is completely backward-breaking to make it required, because it didn't exist in prior versions, so no change for this. This Message is an interesting case because in the closely-related AMVAL Response Message Mnemonic.name and .status are required, but not in this message... which is obviously wrong, so correcting here to note it as required. In practice it already is, so though this is a technically breaking change, in practice there is no case when these fields aren't set.
    • Product Request Message - Either INPUT-FILE.n.URI or INPUT-FILE.n.DATA must be present. There are several other fields in this message that needed clarification as shown in the table changes and there is new supporting text after the table to help make sense of the various fields. For example, there is a URI a the top level of the request message and also a URI in each input file, each with very distinct meaning.
    • Product Response Message - as messy as Product Request Message is for this issue, Product Response Message is very straight forward: For each File "DATA" is required. Although this is moving from an optional to a required field, note that the File in-practice, this is the de facto case.
    • Product Message -Same as Product Response Message, above.
    • Simple Service Message - Each Parameter must at least have a VALUE. NAME, is optional, because Parameters could be positional. However, in this case, no changes is being made because Simple Service messages are already being deprecated in C2MS12-22. Assuming that issue is accepted by the RTF, there is no reason to update Simple Service Request with this adjustment. Should that issue wind up not being accepted, we will need to come back here to make the adjustment here.
  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Resource Message Additional Information is blank for NUM-OF-DISKS Type and Presence

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

    Table 8-62 Resource Message Additional Information is blank for NUM-OF-DISKS Type and Presence, should be U16 and R.

  • Reported: C2MS 1.1b1 — Wed, 20 Nov 2024 16:24 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add missing designators for Resource Message

    Table 8-62 Resource Message Additional Information is blank for NUM-OF-DISKS Type and Presence, should be U16 and R. Add those.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

sometimes incorrect 'nth' sample or 'first' sample text

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

    Where there is a

    • MNEMONIC.n.SAMPLE.m.TIME-STAMP field,
    • MNEMONIC.n.SAMPLE.m.RAW-VALUE field,
    • MNEMONIC.n.SAMPLE.m.EU-VALUE field,
    • MNEMONIC.n.SAMPLE.m.TEXT-VALUE field, or
    • MNEMONIC.n.SAMPLE.m.LIMIT-ENABLE-DISABLE field

    There is frequently incorrect description text that either refers to the 'nth' data sample (should be 'mth') or 'first' data sample (probably should be 'mth'. These need to be individually evaluated and corrected. Be sure when chaning 'first' to 'mth' as I'm not sure the history of saying 'first'.

    Search the doc for 'nth' data sample or first data sample. Can search for a few 'mth' data sample for the correct usage.

  • Reported: C2MS 1.1b1 — Mon, 26 May 2025 23:32 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Correct 'nth' sample or 'first' sample text

    correct 'nth' sample or 'first' sample text

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Wrong Relationship in Model Diagrams - Simple Service

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

    The Simple Service Req and Resp have an association with C2MS Message. Should be generalization. This is in the model and model diagram in the spec document.

    Need to look through all others and make sure they are OK.

  • Reported: C2MS 1.1b1 — Thu, 3 Apr 2025 14:32 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Fix UML Relationship in Simple Service

    Change the Simple Service Req and Resp diagrams to fix the an association with C2MS Message. Should be generalization.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Consider a list of Metadata Items for Command Request Message

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

    In 1.2, we are adding a set of name-value pairs for Command Metadata Items to the new Command Creation Request Message. This is being done in the resolution for C2MS12-16.

    The question here is we should add this construct to the Command Request Message as well.

  • Reported: C2MS 1.1b1 — Sun, 16 Mar 2025 23:03 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add an Array of CMD Metadata Fields with Name-Value Pairs

    This is closely associated with and assumes the adoption of C2MS12-16.

    Add an Array of Metadata Fields with Name-Value Pairs to the Command Request Message.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Verify FORMAT Options for some Navigation Data Messages

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

    Among the "Navigation Data Messages", the following messages all have supported FORMATs of KVN, XML, RAW and BIN:

    • Attitude Parameter Message
    • Attitude Ephemeris Message
    • Orbit Parameter Message
    • Tracking Data Message

    However the following only support FORMATs of KVN and XML:

    • Orbital Mean-Elements Message
    • Orbit Ephemeris Message

    I don't know if this was what was intended or an oversight not to include RAW and BIN in these last two (or if the other Orbit Parameter Message perhaps shouldn't have them).

    I'm entering this issue to capture this question as it could stand investigation

  • Reported: C2MS 1.1b1 — Wed, 12 Mar 2025 00:38 GMT
  • Disposition: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Dup of another issue (C2MS12-10)

    This work is covered by the changes being made in the resolution for C2MS12-10.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Remove 'Not used' Designators in "Properties of Miscellaneous" Tables

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

    A minority (nine out of 60+) of "Properties of Miscellaneous" tables have lines for Miscellaneous Elements only to state that they are "not used". This is superfluous and inconsistent with most other tables of this type. The "not used" aspect is knowable by the ME not being listed either in this table or its preceding "Subject Naming" table.

    This does not apply to the following tables, since they have some not used MEs in between others that are used, so they do need to be specified:

    • Table 8-86. Properties of the Miscellaneous Elements for the Telemetry TDM Frame Message
    • Table 8-91. Properties of the Miscellaneous Elements for the Telemetry Processed Frame Message

    Additionally, "Table 8-182. Properties of the Miscellaneous Elements for the Navigation Data Message" lists ME6 but without any other information, including "not used". Upon review, though, it is not used, so the line should simply be removed to avoid confusion.

  • Reported: C2MS 1.1b1 — Fri, 22 Nov 2024 16:22 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Do this in 1.2

    Remove the extra information as shown in "Revised Text".

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Standardize Table Cell Borders

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

    In the spec PDF, there is a lot of inconsistency about how XX Message Additional Information tables appear in the document.

    Some have (mostly) heavy cell borders - ex: Table 8-36. Directive Response Message Additional Information

    Some have normal cell borders - ex: Table 8-140. Command Request Message Additional Information

    Some have both in the same table - ex: Table 8-31. Directive Request Message Additional Information

    Having heavy cell borders leads to a propensity to add cells with inconsistent cell borders, unless care is taken by the editor. Because of this, I recommend using normal cell borders on all these tables. Normal borders are used in many of them and they look fine.

    Similarly all the XX Message Header Field Values tables should be updated in the same way.

    Additionally, there are other similar tables that follow this basic construct and should also be updated:

    • Table 6-9. Ordinal Date and Time Field Type Definition
    • Table 6-10. Response Status Substructure
    • Table 8-3. Mapping of Message Header Fields to the C2MS Subject Name
    • Table 8-9. Pass-Related Occurrence Types
    • Table 8-10. Telemetry Limit Violation Occurrence Types
    • Table 8-11. Command Verification Occurrence Types
    • Table 8-12. Miscellaneous Occurrence Types
    • Table 8-13. Log Message to Echo a Directive Request Message
    • Table 8-14. Product Message to Echo a Directive Request Message
    • Table 8-20. Examples of Start and Stop Times
    • Table 8-26. Meaning of Response Status and Return Value with Recommended Actions
    • Table 8-37. Group Hierarchical Associations
    • Table 8-160. Meaning of RESPONSE-STATUS and RETURN-VALUE with Recommended Actions
    • Table A-1. Software Class and Subclass Categories

    Finally, - Table 8-161. Example Scenarios Using the Set of Product Messages should keep the format of the cells generally, but needs to be cleaned up.

    As a note, there are some tables where the structure of the table is easier to distinguish with some heavy borders and these should remain. These are related to the XX Message Subject Naming Tables.

  • Reported: C2MS 1.1b1 — Fri, 22 Nov 2024 15:25 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Do this in 1.2

    Change the following table to use normal cell borders:

    • All XX Message Additional Information tables
    • All XX Message Header Field Values tables
    • Table 6-9. Ordinal Date and Time Field Type Definition
    • Table 6-10. Response Status Substructure
    • Table 8-3. Mapping of Message Header Fields to the C2MS Subject Name
    • Table 8-9. Pass-Related Occurrence Types
    • Table 8-10. Telemetry Limit Violation Occurrence Types
    • Table 8-11. Command Verification Occurrence Types
    • Table 8-12. Miscellaneous Occurrence Types
    • Table 8-13. Log Message to Echo a Directive Request Message
    • Table 8-14. Product Message to Echo a Directive Request Message
    • Table 8-20. Examples of Start and Stop Times
    • Table 8-26. Meaning of Response Status and Return Value with Recommended Actions
    • Table 8-37. Group Hierarchical Associations
    • Table 8-160. Meaning of RESPONSE-STATUS and RETURN-VALUE with Recommended Actions
    • Table A-1. Software Class and Subclass Categories
    • Any new tables of this type added in C2MS 1.2.

    For Table 8-161. Example Scenarios Using the Set of Product Messages, keep the format of the cells generally, but clean it up.

    NOTE: "Normal cell borders" are as shown in the current (C2MS 1.1 document) in Table 8-140. Command Request Message Additional Information

    NOTE for Editor: While these borders look OK on first glance in the Word document, they don't have their borders set properly and when generating the PDF, these are greatly exaggerated. To "use normal cell borders" in Word, 1) select the table, 2) navigate to the "Table Design" tab, 3) under "Border Styles" be sure the top left (normal) is selected, 4) under "Borders" select "All Borders".

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Represent Time as UTC

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

    We need to make a general statement in C2MS that all times are considered to be UTC. Additionally, every "Additional Info" table that has a Time type should put UTC in the Description column.

  • Reported: C2MS 1.1b1 — Thu, 19 Dec 2024 17:41 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Annotate Time Fields as Being in UTC in Document and Tables

    Wherever Time type is used, note that it is in UTC throughout the document, including in Description columns for individual fields.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

In message tables, make use of an enum type to designate a discreet list


Fix Use of 'Severe' in Diagrams (Should be 'Critical')

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

    Late in C2MS 1.1, we aligned SDTF error levels across the specs. 1.1 initially used 'Severe' for the highest level of concern. Later, we changed this to 'Critical' as this was better alignment with XTCE. Although the document text was all changed, we had three model diagrams that referred to 'Severe' in notes: Log Message, Heartbeat Message and Device Message. The notes in these diagrams all need to be fixed to use 'Critical' instead of 'Severe'.

    Note that Log Message is already being fixed as part of the proposed resolution for C2MS12-43. Therefore, this issue only addresses Heartbeat and Device Messages.

  • Reported: C2MS 1.1b1 — Fri, 15 Nov 2024 18:19 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Do this in 1.2

    Two diagrams to be fixed as shown in the attachments, changing 'Severe' to 'Critical' in the note in each diagram. This aligns with the text already in the document.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Standardize Sections and Section Names for Message Subjects

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

    Some messages have an inconsistent layout or section naming for their "Message Subjects" section. These need to be brought into a standard from. Messages that have this issue:

    • Section 8.3.1.1 Log Message Subject Names does not start at the right spot. It should begin before Table 8-5. Log Message Subject Naming. Additionally it should be "8.3.1.1 Log Message Subjects" (this is being fixed in the resolution of C2MS12-43)
    • Directive Response and Requests Messages to do not have 'Message' in the section heading. (Instead of "Directive Response Subjects" it should be "Directive Response Message Subjects" to be consistent with others.
  • Reported: C2MS 1.1b1 — Wed, 20 Nov 2024 00:28 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Do this in 1.2

    Make changes to section headings per the "revised text"

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Rework Log Message

  • Key: C2MS12-43
  • 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.

    There also needs to be an Event that is to capture AWEs or state change... something to do with teh operational state of the system (Mission Data).

  • Reported: C2MS 1.0 — Sun, 14 Apr 2024 23:36 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add Event Message, Specify the Correct Use for Log Message

    Add Event Message, Specify the Correct Use for Log Message.

    The latter includes deprecating the SPACECRAFT-TIME in the current Log Message, and indicating that the use of Log Message for spacecraft or ground systems events is deprecated.

    We add SATOPS to the Acronyms and Abbreviations so as to use that term when discussing Events.

    Note that this is an isolated change to the model diagrams, showing only the changes for this issue. Other issues may change the same diagrams in different ways. Because of this, a consolidating issue will be created at the end of this C2MS 1.2 effort to combine changes from multiple issues where needed.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Revisit Completion Status in Command Response Message

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

    We have a command request message and a command response message.

    There can apparently be multiple responses, each as it progresses through the values of the XTCE-STATUS. These even can include if the command was accepted, is executing and if it was completed at the vehicle. But this would mean that the command service that intercepts the command request message must be able to determine from vehicle TLM each of these states.

    It would probably be worth while to revisit this and document more clearly the pattern of use of this item, including the multiple responses, and the expected statuses to produce by the command component service provider.

    Additionally, there may be a couple of statuses not covered by XTCE-STATUS, such as VCC checking, and TLM verification (verifying the effected change in the telemetry). The former could fall under either 'invalid' or 'failed', but these aren't really discreet enough. The latter doesn't have any status indicated in this message.

  • Reported: C2MS 1.0 — Mon, 22 Jul 2024 22:35 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Update Descriptive Text to Address this Situation

    Without any field or message level changes, add some descriptive text to account for the fact that multiple responses might come back indicating command processing on the SV.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Refactor "Introduction to Specification" section in front matter of Document

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

    The section titled: "Introduction to Specification" needs evaluation and at least some rework. This is largely written as a "how we got to here" section, but could use more C2MS-centric language. Also, this should be considered to be moved from the front matter to a numbered section, such as perhaps 5.1 (moving the existing 5.1 to 5.2).

    If moved to a numbered section, it needs to be marked "Informative".

    May be related to C2MS12-28.

  • Reported: C2MS 1.0 — Sat, 29 Jun 2024 20:14 GMT
  • Disposition: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Dup of C2MS12-28

    The intent of this issue is the same as C2MDS12-28. The text from both has been combined and this one can be closed as a Duplicate.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

What to do when Priority isn't Specified

  • Key: C2MS12-46
  • 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: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Dup of C2MS12-10

    Dup of C2MS12-10

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Make C2MS Messages Extensible

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

    Find a way to make messages extensible so that missions that tailor C2MS messages do not need to create new forms of C2MS-like messages, but can simply use the C2MS message and add content to it specific to their mission. What we have seen in C2MS 1.0 is numerous cases where SatOps programs have modified C2MS messages to add information they need, and in so doing, have created a specification of C2MS-like messages that are not themselves C2MS messages. An example would be to have a COMMAND REQUEST MESSAGE that adds a field called SOUND-TO-MAKE-WHEN-SENT, and because of this, they change the message to use a SPECIFICATION of MY-MISSION-SPEC and version numbers with their own versioning. Usually, the Message Type and Subtype are affected as well. Sometimes, they have added to the C2MS Message Header itself, making it diverge further.

    One possible approach, simply as an example, is to allow name-value pairs to be added to the message. This would likely need some kind of namespace-like designator to indicate it is for Mission ABC, and would also need a way to have a type specified (maybe it's a Name-Type-Value triplet.

    Example of Name-Value pair to add to Command Request Message: NAME[0]="MISSION-FOO.SOUND-TO-MAKE-WHEN-CMD-SENT" VALUE[0]="BLEEP-BLOOP".

    Example of Name-Value-Type triplet to add to Command Request Message: NAME[0]="MISSION-FOO.SOUND-TO-MAKE-WHEN-CMD-SENT" VALUE[0]=[some binary like a wav] TYPE=BINARY.

  • Reported: C2MS 1.2b1 — Sat, 29 Jun 2024 20:26 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add an Array of Custom Fields with Name-Value Pairs

    This array is part of the C2MS Message class, so that all C2MS messages have this facility.

    Add a new section "8.2 C2MS Message" and a new subsection "8.2.2 C2MS Message Custom Fields" with the text and diagrams of these sections described under "Revised Text" of this issue.

    Move the current section "8.2 C2MS Message Header" to a subsection of "8.2 C2MS Message" as "8.2.1 C2MS Message Header". All figure numbers, table numbers and subsection numbers need to be adjusted accordingly.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Required or Optional for MNEMONIC Status on Data Messages

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

    When Mnemonic data is returned in the Mnemonic Value Response Message (representing the initial state of mnemonics being requested), the fields MNEMONIC.n.NAME and MNEMONIC.n.STATUS are required. This makes sense, because of the nature of the mnemonic values. If a name and status can't be returned, nothing else would seem relevant. However, when the data is conveyed in subsequent Mnemonic Value Data Messages, MNEMONIC.n.NAME and MNEMONIC.n.STATUS are Optional. This, in contrast, seems to be in error.

    Note that via copy-paste, the Archive Mnemonic Value Request/Data Messages are exactly the same. The MNEMONIC.n.NAME and MNEMONIC.n.STATUS are required in the Response Message and optional in the Data Message.

    Normally, it would not be appropriate to apply required to a field that was previously optional in order to avoid backward compatibility. But in this case it is clearly an oversight and the assumption is that anyone sending mnemonics in the Data Messages is already providing the name and status of each. Therefore, the fields in both the MVAL Data and AMVAL Data Messages should be modified to make these required, following the lead of the MVAL and AVMAL Response Messages.

  • Reported: C2MS 1.0 — Wed, 10 Apr 2024 16:25 GMT
  • Disposition: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Make MNEMONIC.n.NAME and .STATUS Required in MVAL/AMVAL Data Messages

    Make the fields MNEMONIC.n.NAME and MNEMONIC.n.STATUS required in MVAL Data Message and AMVAL Data Message the way they already are in corresponding MVAL Response Message and AMVAL Response Message.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

AMVAL Value Response Doesn't Mirror MVAL Value Response Message

  • Key: C2MS12-37
  • 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: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Dup of C2MS12-34

    Dup of C2MS12-34

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Consider Deprecating and Later Removing Resource Message

  • Key: C2MS12-31
  • 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: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Do this in 1.2

    Deprecate the Resource Message with text indicating that the use of this message should be replaced with "industry-standard tools for performing resource monitoring."

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Define a Way to Create Argument-based Commands for the Command Request Message

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

    The Command Request Message designates one CMD-FORMAT type as MNEMONIC, but it seems impossible to use this type to send a mnemonic-based command using the message as is, because the formatted command is to be held in CMD-DATA (binary). We have explored modifying to this message to include arguments to fill in a looked up command, but as we have tried to go in that direction, we get further from the expected use of Command Request Message.

    Therefore, this issue calls out the need to create a new message request/response to 'create' a formatted command from a command name and list of command arguments. This formatted command can then be placed in the CMD-DATA of the Command Request message. (This was the solution we converged upon in Chicago, 2024).

    This "Command Creation Request Message" should indicate the CMD-FORMAT desired, include a CMD-NAME field of type STRING to hold the human-readable name for command lookup. It is also to contain a list of 0-n Command Arguments to hold the human-supplied arguments, along with a way to specify the argument type.

    The "Command Creation Response Message should include the binary field CMD-DATA to line up with the same field name/type in Command Request Message.

    As part of this effort, the MNEMONIC CMD-FORMAT should be deprecated in Command Request Message, since it turned out not to be useable as is.

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

    Add new Command Creation Message REQ/RESP in 1.2

    Create new messages for the request/response to generate a command from a CMD name and arguments.

    Deprecate the MNEMONIC CMD-TYPE in Command Request Message, since this capability in captured in this new command.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Command Echo Not Provided Message

  • Key: C2MS12-18
  • 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: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Provide clarifying text regarding CMD-ECHO

    Add a note that the command echo may not be produced if not supported or not configured.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Consider a Command Completed Publish Message

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

    The Command Response Message has in the XTCE-STATUS field the ability to convey if a message was executed and completed. However, this may be incomplete because it doesn't account for VCC checking or functional verification (the expected effect was attained after the command, as would be indicated in a changed TLM point).

    One possible solution is to add a new Command Completed Message that the command subsystem would send out after all checks to indicate that all the VCC Verification, Command Accept Verification and effected TLM (Functional Verification) were completed.

  • Reported: C2MS 1.0 — Tue, 16 Jul 2024 18:20 GMT
  • Disposition: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    Not necessary

    This was determined in Chicago '24 RTF not to be necessary, because of textual updates that will be performed in support of C2MS12-67.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Larger Data Types

  • Key: C2MS12-8
  • 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: Resolved — C2MS 1.2b1
  • Disposition Summary:

    Add Typed Variable, use it to address Spacecraft RAW, Ground RAW, Converted, EU and TEXT values

    Note that this issue is interdependent on the resolution C2MS12-10, assumes it is being voted on at the same time.

    Replace the Variable type with a new one: Typed Variable, that allows a type discriminator and value together so that the Typed Variable can house the value and its type together. This is then used to replace all the fields that are of type Variable as well as RAW fields (currently I32) and EU fields (currently F64). This updates both the Additional Information tables and the model diagrams.

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message

  • Key: C2MS12-47
  • 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: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    No change, normal use case

    According to Andre D, this is a normal (although somewhat rare) occurence, in which the processed values are provided even while searching for frame markers.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Replace Unsolicited Echo with a Separate Message

  • Key: C2MS12-19
  • 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: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    No change. This is a normal use case

    According to Eric O, this is a normal use case and currently processed this way by FEPs. Therefore, this isssue is to be closed with no change.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

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

  • Key: C2MS12-11
  • 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: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    Close as unnecessary

    Short of sending a new request message with a new Destination Component, any forward of a message would have to take place outside the middleware flow of messages. In the former case, this follows the already-exisitng request/response MEP. With the latter, there is no MEP necessary as functional delegation is a normal software concept that would be handled invisibly to C2MS messages.

    Additionally, in light of other MEP changes needed to fix broken MEPs, this seems very minor and superfluous.

    Therefore, closing this as no-change.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Add documentation within the model

  • Key: C2MS12-7
  • 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: Closed; No Change — C2MS 1.2b1
  • Disposition Summary:

    This will be OBE when we move to a model-based specification

    At present, the model is used only for diagrams and is otherwise non-normative. The specification document contains all the detail. In the future, we will move to a model-based specification. There is no need to add documentation to the model until that time and it would cause documentation duplication.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS12-1
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Data Dictionary Messages

  • Key: C2MS12-2
  • 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: Duplicate or Merged — C2MS 1.2b1
  • Disposition Summary:

    Close as duplicate of C2MS12-14

    This is a duplicate of C2MS12-14, meaning that that issue will resolve this one.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS12-3
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

XML PSM recommended

  • Key: C2MS12-4
  • 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.2b1
  • Disposition Summary:

    Defer to a later release

    Not urgent enough, given all the other work for 1.2...

  • Updated: Mon, 30 Mar 2026 14:00 GMT

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

  • Key: C2MS12-6
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done as part of a major release boundary: so, 2.0.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Consider a mechanism to request archived Commands and Events

  • Key: C2MS12-13
  • 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.2b1
  • Disposition Summary:

    Defer to a later release

    Do this in a later release.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Harmonize Replay TLM and Archive Mnemonic Message Sets

  • Key: C2MS12-9
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done as part of a major release boundary: so, 2.0.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

C2MS Database Query (DBQUERY) messages

  • Key: C2MS12-14
  • 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."

    NOTE: C2MS12-2 is being closed as a DUP of this message, so the intent of that issue needs to be addressed in the resolution of this one.

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

    Defer to 1.3

    this needs to be prototyped first

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Reconsider Oneshot in MVAL Request/Response

  • Key: C2MS12-21
  • 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 type of 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    Because this will change a primary use case for this message, it was determined in Chicago '24 RTF to defer to a major release.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

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

  • Key: C2MS12-12
  • 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.2b1
  • Disposition Summary:

    Defer to 1.3

    see comment but generally we can either add fields:

    • spid
    • vcid
    • apid
    • time-code-length and format and say epoch maybe?

    and place those as optional fields in frame and packet messages...
    but as it is typical missins to assign these, they are known ahead of time. so without the mission telemetry handbook for example. you wouldn't know much.
    packets do not have their vcid or spid associated with them. they are not in the header is it not typical to add that info in metadata with the packet. the timestamp format if present is assigned by the mission ahead of time, the
    epoch also.
    some of this is the mission db, such as xtce.
    but if you stay started with framed data, and essentially created a ccsds pipeline to spit out packets could you add fields to that message for the spid and vcid the packet was "on"... it seems one could do so.
    should we require it or just make it optional – not clear.
    i suggest we discuss in more detail in Q4 to maybe 'prototypey-candidate" level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages

  • Key: C2MS12-23
  • 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.2b1
  • Disposition Summary:

    document unrolling of arrays and aggregrates to individual scalars

    Two overall approaches are being considered – unroll all the arrays and aggregate to their scalars and supply the values one at a time. OR possibly use a novel syntax such as json to specify the values in some sort of bulk fashion...
    The most obvious approach is to unroll them and have each individual array or aggregate field to the scalar of interest, here's some examples below.
    But we might also want to provide some more efficient manner if we want to support some kind bulk request at the very least (& then decide if the response is a bulk response or an unrolled response)
    Given a database definition like this:

    FLOAT[4] BATV // ARRAY of 4 FLOAT

    Then each of these “unrolled” can be considered as individual mnemonic definitions:

    FLOAT BATV[0] // ARRAY INDEX 0
    FLOAT BATV[1] // ARRAY INDEX 1
    FLOAT BATV[2] // ARRAY INDEX 2
    FLOAT BATV[3] // ARRAY INDEX 3

    The above array syntax is common and aligns well with the flight software and/or makes the database definitions etc…

    Below is an example of another complex type that is a mixture of aggregate/array. We use quasi-C-like syntax to illustrate:

    Struct[4] BATV { // array of 4 of these
    INT A;
    INT B;
    INT[2] C; // array of 4 here also
    Struct D

    { FLOAT X; FLOAT Y; }

    }
    We intend this to mean and array of BATV (4), with fields/members A, B, array of C (2), and Struct D which itself has members X and Y;

    Unrolling this produces a lengthy set of paths to each scalar:

    BATV[0].A
    BATV[0].B
    BATV[0].C[0]
    BATV[0].C[1]
    BATV[0].D.X
    BATV[0].D.Y

    (And 3 more for indices 1,2 and 3).

    In essence then any complex type can be unrolled out to a list of all the "paths" through it which results in often lengthy list of individual scalars.

    The question then becomes how to handle a request from MVAL for say "BATV".

    There's two possibilities in the unroll scenario: the first one is that the receiver of the request rejects it because it doesn't support complex MVAL requests and this would with the right return error code prompt the requester to break the query up into BATV[0] to BATV[3] request PER individual array index. The second possibility is the receiver does support it, and breaks the response up itself something like this:

    REQUEST: MVAL BATV

    RESPONSE:

    NUM-OF-MNEMONICS : 4

    MNEMONIC.1.NAME : BATV[0]
    MNEMONIC.1.NUM-OF-SAMPLES : 1
    MNEMONIC.1.SAMPLE.1.FLOAT-VALUE : 1.0

    MNEMONIC.2.NAME : BATV[1]
    MNEMONIC.2.NUM-OF-SAMPLES : 1
    MNEMONIC.2.SAMPLE.1.FLOAT-VALUE : 2.0

    MNEMONIC.3.NAME : BATV[2]
    MNEMONIC.3.NUM-OF-SAMPLES : 1
    MNEMONIC.3.SAMPLE.1.FLOAT-VALUE : 3.0

    MNEMONIC.3.NAME : BATV[3]
    MNEMONIC.3.NUM-OF-SAMPLES : 1
    MNEMONIC.3.SAMPLE.1.FLOAT-VALUE : 4.0

    (And so on ... note that the complex type example is not shown but in either case we're exploding the size of the messages)

    Either of these approaches would seem to work – in both cases it's up the requestor to get the data it wants and to "re-roll" the complex types if it wants to present the information to the user in that manner – and we believe this is technically feasable.

    Still the shear explosive nature in terms of the number of fields needed to implement this for realistic sized telemetry mnemonic arrays or complex types we've seen is going to be large.

    So... let's consider another approach. We allow JSON strings in the SAMPLE result and we define THREE new fields to support it:

    DATA-TYPE-FORMAT – send in the REQUEST
    RAW-TEXT-VALUE – JSON like text RESULT
    EU-TEXT-VALUE – OR JSON like text RESULT

    Essentially the requester specifies the DATA-TYPE complex form of the requested data and specifies either RAW or EU, and the RESPONSE packages up this data in a JSON like indentation form. The various scalar DATA-TYPE text forms will have to be defined. Further to be clear this means for complex types any requester wishing for BOTH RAW and EU types will have to break the request into two individual requests.

    Here's an example of the BATV[4] array.

    REQUEST:

    NUM-OF-MNEMONICS = 1
    MNEMONIC.1.NAME = BATV[4] // all of the array
    MNEMONIC.1.DATA-TYPE = EU
    MNEMONIC.1.DATA-TYPE-FORMAT =

    { FLOAT[4] }

    RESPONSE:

    NUM-OF-MNEMONICS = 1
    MNEMONIC.1.NAME = BATV[4] // all of the array
    MNEMONIC.1.NUM-OF-SAMPLES = 1
    MNEMONIC.1.SAMPLE.1.EU-TEXT-VALUE =

    { [1.0, 2.0, 3.0, 4.0] }

    All for now... work up example of struct above.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

At Next Major Revision: Order MEs and Fields Consistently

  • Key: C2MS12-24
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency

  • Key: C2MS12-25
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Deprecate fields duplicated between C2MS Messages and the Message Envelope

  • Key: C2MS12-26
  • 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.2b1
  • Disposition Summary:

    Defer to a later release

    do this in a later release.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Remove Superfluous Fields from Header and Envelope

  • Key: C2MS12-27
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Use Semantic Versioning for Version Number of Messages

  • Key: C2MS12-29
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Revisit Tracking Fields

  • Key: C2MS12-32
  • 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.2b1
  • Disposition Summary:

    Defer to a later release

    Do this in a later release.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Remove the Req/Resp/Pub MEP

  • Key: C2MS12-30
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Inconsistent Fields in AMVAL Response and AMVAL Data Messages

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

    The AMVAL Response and AMVAL Data messages mostly line up with MVAL Response and MVAL Data messages, but not quite. There are some inconsistencies among these messages. One aspect of these is that there should only ever be one MVAL Response Message, but may be multiple AMVAL Response Messages. The documentation does state this, and I'm only relaying it how not to confuse this issue. That difference is expected and normal. The reason for this particular difference is that the AMVAL REQ/RESP has a finite end (see descr of STOP-TIME in AMVAL REQ: "Requested stop time of the mnemonic values to be retrieved from the telemetry archive. Defaults to the end of the telemetry archive") while MVAL can be no-end. This is also manifested in the concept of START and STOP request types in MVAL REQ, which don't exist in AMVAL REQ.

    However, there are some inconsistencies that do need analysis and probably correction in one form or another:

    • The AMVAL Response contains no samples, which are present for all of MVAL Response, MVAL Data and AMVAL Data. So, if requesting the data back in the AMVAL Response, not all the data is returned. It could also be seen that you might request the data to come back in AMVAL Data if you need this deeper detail, which would be fine, but maybe some explanation in text would be warranted if we keep that construct.
    • Also, AMVAL Response, contains a Product Subtype Category not found in any of the others. This needs analysis and convergence to align these messages better. Note, too that Product info is contained in AMVAL Request, as well. This seems out-of-place, almost like it was copied from the product message. Interestingly, the PRODCUT-TYPE is always AAA (Archive and Assessment) and the PROD-SUBTYPE is always DATA. Is that really necessary to say? I mean, it is a request for archived MVALs, it doesn't seem to add anything to say that that's a DATA product from AAA. Instead, this seems like it aligns more with the Product Request Message that has these fields that are to be searched generically. Note that this has a corollary in Archive Message Retrieval Request/Response, which also contain Product Info, so need to look into that at the same time. These are the only other messages than Product Messages that reference PROD-NAME.
  • Reported: C2MS 1.0 — Wed, 24 Jan 2024 21:51 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    I would like to have addressed this in C2MS1.2, but we have run out of time. This needs a little more analysis and talk in working sessions. so it seems best to defer to a future release and revisit it there. This issue has a corollary in Archive Message Retrieval Request/Response, which also contain Product Info.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Re-evaluate Optional Boolean Fields

  • Key: C2MS12-33
  • 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.2b1
  • Disposition Summary:

    Do this in a later release

    This needs to be done eventually, but out of time in 1.2

  • Updated: Mon, 30 Mar 2026 14:00 GMT

mnemonic.n.sample.m.quality seems to be wrong type

  • Key: C2MS12-36
  • 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.2b1
  • Disposition Summary:

    Defer to 1.3

    This proposal changes the data type to signed 16 bit. And redefines GOOD as any non-negative value. BAD then become any negative value. Although this breaks the original slightly (0 is GOOD, 1 is BAD) ... it also allows for an expansion by implementations on kinds of good quality and kinds of bad quality without requiring the basic implementation to do anything more than report GOOD >= 0, or BAD < 0 by default.at
    CAUTION: this is NOT backwards compatible. alternate approach would be BAD >= 1, and GOOD <= 0 – although this means some "goods" may be negative. this is not what is being proposed and is only a note.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Normalize Headers and Text in the new DB Query Messages

  • Key: C2MS12-38
  • 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.2b1
  • Disposition Summary:

    Defer to 1.3

    part of new db query effort. without an prototype implementation this addition is too large to incorporate.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Consolidate Navigation Data Messages

  • Key: C2MS12-44
  • 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.2b1
  • Disposition Summary:

    Defer to future 2.0 release

    This would be really convenient to do, but should be in a major release.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model

  • Key: C2MS12-40
  • 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.2b1
  • Disposition Summary:

    Defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Add SM&C MAL Message

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

    SM&C (Spacecraft Monitor & Control) is a CCSDS working area that defines a set of ground system services, it is mainly Parameter (Mnemonic) value based (low level info is largely gone except they've added a packet construct recently). At the bottom of SM&C is the MAL message. The MAL message is technically abstract and one is to map it to your transport technology of choice – but perhaps there's no reason to literally implement a MAL message on the GMSEC bus. Determining details like "how will this really work" and so on would be part of this effort.
    Once completed, we then say to SM&C folks that we could support an SM&C service. There's an additional facet related about tying into XTCE. The MAL is explained further here – https://en.wikipedia.org/wiki/Message_Abstraction_Layer ... Note that in essence the idea which may need refinement is to make a mapping of the MAL into a concrete C2MS message. Implementation an addressing scheme in the pub/sub environ is another aspect. at least some implementations by esa use tcp/ip and it may be that some hard address approach would work well enough for pub/sub (broadcast not being needed)

  • Reported: C2MS 1.1b1 — Thu, 12 Sep 2024 17:42 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    defer to 1.3

    note this is a duplicate issue

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Undo Addition of DB Query Messages in 1.1

  • Key: C2MS12-45
  • 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.2b1
  • Disposition Summary:

    Defer to 1.3

    defer all dbquery work to 1.3

  • Updated: Mon, 30 Mar 2026 14:00 GMT
  • Attachments:

Align TLM Terms

  • Key: C2MS12-49
  • 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.2b1
  • Disposition Summary:

    defer to a later 2.0 release

    This needs to be done at a major version level.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Define GUID Format and Algorithm

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

    This issue covers the reevaluation of the GUID type to consider specifying not only the format (RFC 4122), but also the algorithm for generating the guid.

  • Reported: C2MS 1.2b1 — Sat, 29 Jun 2024 20:19 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    We hope to do this, but out of time for 1.2, so we'll take this up in 1.3.

  • Updated: Mon, 30 Mar 2026 14:00 GMT

Create PSMs for at least XML and REST/JSON

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

    In C2MS 1.0, XSDs were provided by NASA Goddard and published as 'normative' along with the spec. However, these were somewhat incomplete and not maintained by OMG, so these were removed as part of C2MS in 1.1.

    The issue is that we do need to supply some PSMs to encourage C2MS usage in the space community. To address GMSEC, it makes sense to supply an XML PSM, but it also seems good to have a REST/JSON PSM to make it more modern and usable in modern architectures. Also consider PSM for Protobuf.

    The intent should be to stop using NASA Goddard as the point of contact for all things C2MS. In fact, OMG should supply these PSMs to Goddard as input, rather than Goddard supplying XSDs to OMG as happened in 1.0.

    Additionally, a REST/JSON and/or Protobuf PSM should focus on non-pub-sub usage... something that can exist and operate in a services-based architecture. In this case, it could be that the message subjects are ignored as these are used entirely for pub-sub subscriptions/delivery. If that turns out to be the case, we might make clear in the PIM that subjects are optional.

    Related to the above, we COULD make subjects part of a PSM rather than PIM???

    PSMs can be done as new chapters within the spec, perhaps in a C2MS 1.3 release.

  • Reported: C2MS 1.1b1 — Wed, 11 Jun 2025 17:36 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Move to 1.3

    This should be a primary emphasis for 1.3, which should follow soon after 1.2

  • Updated: Mon, 30 Mar 2026 14:00 GMT

namespace support should be reflected in at least the telemetry and command related C2MS messages

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

    Many t&c systems support some form of namespaces in their database definitions. For example a "parameter" might be associated with a certain namespace ("/myagency/mymission/mysystem/mysubsystem/batv1") or a command as well. XTCE supports a kind of namespace through the spacesystem tree. GSFC's ITOS supports namespaces in the database. (the other one, ASIST does not). And so forth.

  • Reported: C2MS 1.1b1 — Thu, 5 Dec 2024 16:50 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Add optional namespace field and optional ns format field with default

    Ns is a string. Nsf is default "xtce" but also a string. Both optional. xtce means it's in xtce form /which/is/like/this.

    The default can accommodate other implementation specific forms but the xtce must be supported.

    The namespace should be associated with parameters, packets and commands.

    The following C2MS messages are affected:

    • Telemetry CCSDS Packet Message
    • Command Request Message
    • Command Response Message (maybe)
    • Command Echo Message
    • Replay Telemetry Data Messages
    • Telemetry Processed Frame Message
    • Telemetry TDM Frame Message
    • Replay Telemetry Data Request Message
    • Replay Telemetry Data Response Message
    • Mnemonic Value Request Message
    • Mnemonic Value Response
    • Mnemonic Value Data Message
    • Archive Mnemonic Value
    • Archive Mnemonic Value Response Message
    • Archive Mnemonic Value Data Message
  • Updated: Mon, 30 Mar 2026 14:00 GMT

There may be a need for a ranging (tracking) publish message

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

    This might be a buy-back type of message. Need to see what there is and if we could use it. This may already be accomplished via Tracking Data Message. Need to identify the need and see if these satisfy it already.

  • Reported: C2MS 1.1b1 — Thu, 29 May 2025 23:17 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    Do this in a later release.

  • Updated: Mon, 30 Mar 2026 13:59 GMT

In Model Diagrams, mark constants with {readOnly} and possibly static, and final where appropriate

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

    In our model diagrams, we tend to use "default" values in UML to signify constants, which isn't correct UML. To resolve this, evaluate each item with a default value to decide if it is supposed to be constant and if so, check the "Is Read Only" flag in the attribute for that class. If it is also static, check the "Is Static" flag, too. The former adds "

    {readOnly}

    " to the display of the attribute, the latter underlines it. Note, though, that with C2MS12-118, CONTENT-VERSION and SPECIFICATION, two obvious cases, have been added to the Constraints section of classes, which enforces a specific value, so these are already OK.

    Also consider marking all final classes with "Final Specification" to indicate that they can't be subclassed.

  • Reported: C2MS 1.1b1 — Fri, 8 Aug 2025 13:42 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    This is going to take analysis on a field-by-field basis in each message, so out of time for 1.2 and will take it up later.

  • Updated: Mon, 30 Mar 2026 13:59 GMT

Create Service Registry/Lookup Messages

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

    From an implementation standpoint, C2MS (and C2MS-EXT) Messages should be registerable at some kind of "C2MSMessageDescriptionManagerService" which serves them up, possibly pushing them out? To all active nodes on a gmsec bus ...

    Perhaps a Register Service message that includes what 'services' and message types are provided, a Service Registered message published to all, a Lookup Service Request message that asks 'who can do what I need?' and a Service Lookup Response message.

    C2MS doesn't need to define how that registry is maintained or made resilient or how services stay in the list (heartbeat?) at all. That is up to the implmentor, if any.

  • Reported: C2MS 1.1b1 — Tue, 19 Aug 2025 15:21 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    Worth considering, but not in 1.2

  • Updated: Mon, 30 Mar 2026 13:59 GMT

Service Lookup REQ/RESP

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

    We could add a message called Service Lookup Request Message that asks "who is out there that can service this request?" Then the requestor will receive 0-many responses.

    The idea here is to help with the issue that all request messages today want a DESTINATION-COMPONENT, but we have no facility for the requestor to find one native to C2MS.

    Request would have all the standard subject elements, up to ME1, which instead of the DESTINATION-COMPONENT would be REQ-SUB-TYPE, so if I'm asking who serves MVALs for a given satellite, I'd have a topic of "Domain1.Domain2.Mission.Const.Sat.REQ.SVC-LOOKUP.MVAL" which means, who handles the specific satellite for the MVAL subtype (obviously, this would only be needed for request service providers, so the REQ is not needed as part of the query.

    The responses would (all) contain the name of the servicing component, that could then be used in an MVAL REQ for DESTINATION-COMPONENT.

    After the resolution to C2MS12-192, this may not be needed. However, capturing it for future consideration.

  • Reported: C2MS 1.1b1 — Wed, 24 Sep 2025 13:05 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    This may not be needed because of C2MS12-192.

  • Updated: Mon, 30 Mar 2026 13:59 GMT

Make a class hierachy/diagrams for all the Tracking Data Messages

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

    Similar to C2MS12-118, it would be nice to create a model hierarchy for the TDM messages. The are almost all nearly identical, so inheritance would be nice. Of course, this can't break the CONTENT in the tables, but can greatly improve the diagrams.

  • Reported: C2MS 1.1b1 — Tue, 19 Aug 2025 15:22 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    Do this in a later release.

  • Updated: Mon, 30 Mar 2026 13:59 GMT

Support CCSDS SM&C Services in C2MS

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

    (Note: This is a consolidated and cleaned-up issue for CCSDS SM&C and MAL, which exist in several other C2MS issues.
    This information has been collected from those sources and refined for clarity moving forward. Previous issues listed below.)

    The CCSDS (Spacecraft Monitor & Control) SM&C defines a set of mission operations services. At the bottom of these
    services is an abstract MAL message layer.

    It is possible that an abstract MAL message could be mapped to a C2MS version, along with an appropriate addressing
    scheme so that SM&C services could flow over a C2MS system, coexisting with C2MS message-based services. The following
    is a copy of the current MAL message. It has a header consisting of several fields; after these data fields, this will
    be (preliminarily) further discussed following the header section.

    Within the header, there are TO and FROM fields. The CCSDS MAL Blue Book states that these fields are “open” in the MAL
    abstract definition, although some form of reasonable quality-of-delivery service should also be provided for MAL message
    delivery. There is also a service model—this is described in a separate Blue Book—which suggests that each service has an
    associated URI.

    Finally, there are several MAL mappings defined in various Blue Books—TCP, HTTP, and Space Packets, to name three. These
    show how the MAL URI TO/FROM fields are mapped to specific protocol headers such as source/destination IP addresses, HTTP
    URLs, and APIDs, to align with the above references. Given that the C2MS message can define services using C2MS subjects,
    these can be used directly for the MAL TO/FROM fields or mapped from corresponding URI/URL values.

    The REFERENCES section at the end of this description points to several CCSDS reports and multiple implementations in
    different programming languages, using a variety of transport mechanisms.

    Abstract MAL Header

    Field Type Description
    From Identifier Message Source
    Authentication Id Blob Authentication Identifier of Message Originator
    To Identifier Message Destination
    Timestamp Time Message generation timestamp
    Interaction Type InteractionType Interaction Pattern Type
    Interaction Stage UOctet Interaction Pattern Stage
    Transaction Id Long Unique to consumer
    Service Area UShort Service Area
    Service UShort Service
    Operation UShort Service Operation
    Area version UOctet Area version
    Is Error Message Boolean ‘True’ if this is an error message; else ‘False’
    Supplements List<NamedValue> Optional supplementary fields

    URI MAL Header

    Field Type Description
    URI From Identifier Message Source
    Authentication Id Blob Authentication Identifier of Message Originator
    URI To Identifier Message Destination
    Timestamp Time Message generation timestamp
    Interaction Type InteractionType Interaction Pattern Type
    Interaction Stage UOctet Interaction Pattern Stage
    Transaction Id Long Unique to consumer
    Service Area UShort Service Area
    Service UShort Service
    Operation UShort Service Operation
    Area version UOctet Area version
    Is Error Message Boolean ‘True’ if this is an error message; else ‘False’
    Supplements List<NamedValue> Optional supplementary fields

    (possible and vague mapping of MAL as C2MS minus fixing up types and the List)

    C2MS MAL Header

    Field Type Description
    C2MS Subject Source Identifier Message Source
    Authentication Id Blob Authentication Identifier of Message Originator
    C2MS Subject Destination Identifier Message Destination
    Timestamp Time Message generation timestamp
    Interaction Type InteractionType Interaction Pattern Type
    Interaction Stage UOctet Interaction Pattern Stage
    Transaction Id Long Unique to consumer
    Service Area UShort Service Area
    Service UShort Service
    Operation UShort Service Operation
    Area version UOctet Area version
    Is Error Message Boolean ‘True’ if this is an error message; else ‘False’
    Supplements List<NamedValue> Optional supplementary fields

    For C2MS most of the fields can be mapped to C2MS types with exception List<NameType> which should follow the C2MS pattern:
    Field Type Description
    Supplement.n.Name Scalar Value Optional supplementary fields

    An "InteractionType" is:

    Interaction Types

    Name Value Description
    SEND 1 Used for SEND interactions.
    SUBMIT 2 Used for SUBMIT interactions.
    REQUEST 3 Used for REQUEST interactions.
    INVOKE 4 Used for INVOKE interactions.
    PROGRESS 5 Used for PROGRESS interactions.
    PUBSUB 6 Used for PUBLISH-SUBSCRIBE interactions.

    (PRELIMINARY)

    MAL MESSAGE BODY
    After these header items the MAL body appears to consist of a TYPE/VALUE pair that is aligned with a specific message specification from the service.
    In other words there is not a name associated with each field.

    This means there are 2 options to further map a MAL message to C2MS:
    1) bundle up any concrete MAL message's data body into a C2MS blob type and send it on, with the idea that the MAL service receiving it through C2MS
    layer will then know what to do with it, because it has its own service definitions.
    2) Let the mapper handle this because it's sophisticated and it will map each MAL field to a C2MS field using the appropriate service definition,
    (somehow) giving each field in that service (a type/value pair) a name as well.

    Alternative approaches?
    One alternative approach to all the above would be to take any concrete MAL message, and in total make it a blob-style part of C2MS message in the
    data body – and broadcast this message on the C2MS bus – and any particular node implementing SM&C services would receive that message - and
    then decode it enough to determine if it's recipient or not.

    This is a simpler approach overall but every node that receives such "broadcast" MAL messages will have to look at every
    one of them to determine if any particular one is for them or not.

    Other approaches considering essentially involved tunnelling a URL based MAL message through C2MS and then inserting/stuffing it into the http "stack" and so on and
    this seem messy and possibly a security horror.

    REFERENCES
    – there's a large number of related ccsds publication found here under the "Mission Operations..." title
    ---- https://ccsds.org/publications/moims/
    https://en.wikipedia.org/wiki/Message_Abstraction_Layer
    https://github.com/CNES/ccsdsmo-maljava
    https://github.com/CNES/ccsdsmo-malc (note: uses zeromq but not clear if c2ms subject/topics would be mappable to it)
    https://github.com/nasa/CCSDS-MAL-Http-Binding-Xml-Encoding
    https://github.com/CNES/ccsdsmo-malgo
    https://github.com/tanagraspace/ccsdsmo-malc-sepp-apps (fork may have updates)

    PREVIOUS or EXISTING ISSUES (Deferred)
    The following issues (& related proposals) have previously been submitted on this topic. They have in general been deferred (to 1.3 now). However the intent of this issue is to subsume them all into this one issue which will carry forward.

    They are as follows:
    C2MS12-79
    C2MS12-97
    C2MS12-74
    C2MS12-112

  • Reported: C2MS 1.1b1 — Mon, 27 Oct 2025 22:06 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to 1.3

    This is meant to become the new "support sm&c in c2ms" issue, subsuming the existing ones as listed in the description. these have also been deferred but we ended up with a couple done at different times in an immature state.

  • Updated: Mon, 30 Mar 2026 13:59 GMT

Improve Some Subject Specifics

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

    See 6.2.2 Format of C2MS Subject Names in the 1.1 document. “An asterisk (*) can take the place of exactly one whole element but not a substring of an element.”

    We want to allow asterisk to be used in a part of an element string, like:

    ".FO*-B*R-*AZ." matching to "FOO-BAR-BAZ"

    There doesn't seem to be any reason that this couldn't work... we simply don't currently allow it. because it is not currently allowed and we would be now allowing it, it is backward compatible.

    Also allow blank or empty subject elements and document the the use of FILL as only satisfying otherwise required elements. Make clear that you can't use blank for elements that are required. matching an empty would look like "foo..baz"... which would not match "foo.bar.baz".

    In the OMG Leeds Meeting, we talked about idenifying a special character, instead of the special word FILL. Possible suggestions were = % ^ which would look like any of the following:

    FOO.=.BAZ
    FOO.%.BAZ
    FOO.^.BAZ

    But as we discussed using a special character in a subject name could cause problems and if so, the implementing component might have to substitute it with some text... I don't know... something like FILL.

    So, for now, we are setting this aside, living with FILL and we can revisit at a time in the future.

  • Reported: C2MS 1.1b1 — Tue, 16 Sep 2025 22:26 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Defer to a later release

    See description for reasons for deferring.

  • Updated: Mon, 30 Mar 2026 13:59 GMT

Create a PowerPoint Set of Slides with Further Guidance for C2MS

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

    Create a PowerPoint Set of Slides with Further Guidance for C2MS which will be placed in the C2MS Spec site and referenced from the Non-normative References section.

    Attached is a powerpoint that contains the main topics to cover.

    Below is the set of modifications we had planned for 1.2, but then backed off:
    = = =
    (At the end of the Intro to Specification)
    In addition to this detailed specification, the Space Domain Task Force of the OMG has created supporting documents that may aid in the use of C2MS, which are listed in the "Non-Normative References" (see Section 3.2.1 OMG Space Domain Task Force Guidance Documents).

    (NOTE to Reviewers/Editor: OMG SDTF is to create two PowerPoints to be used to give additional guidance of a more free-form nature such as why and how to go about using these specs, best practices, etc that don't belong directly in the specs but that would be useful to people trying to figure these out. The documents haven't been created yet, but will be by the time this goes to BETA.)

    3.2 Non-Normative References
    3.2.1 OMG Space Domain Task Force Guidance Documents

    The following documents provide guidance for the usage of C2MS set forth by the OMG Space Domain Task Force.

    3.2.12 NASA GMSEC Documents

    Note that NASA has developed a Platform Specific Model (PSM) referred to as GMSEC. The GMSEC API software, selected components, and documentation are distributed by NASA. Others are free to develop alternative PSMs.

    The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.

    • GMSEC Architecture Document, Release 3.0.0, February 2018
    • GMSEC API 5.2 User’s Guide, November 2023
  • Reported: C2MS 1.1b1 — Wed, 29 Oct 2025 20:51 GMT
  • Disposition: Deferred — C2MS 1.2b1
  • Disposition Summary:

    Try to do this in 1.3

    Recommendation is to create the "users guide" type powerpoint on the OMG site as soon as practical, then add references under non-normative to this (or these) in the document (1.3) after they have been produced.

    In the interim, once produced we can point people toward them anytime we want.

    Below is the set of modifications we had planned for 1.2, but then backed off:
    = = =
    (At the end of the Intro to Specification)
    In addition to this detailed specification, the Space Domain Task Force of the OMG has created supporting documents that may aid in the use of C2MS, which are listed in the "Non-Normative References" (see Section 3.2.1 OMG Space Domain Task Force Guidance Documents).

    (NOTE to Reviewers/Editor: OMG SDTF is to create two PowerPoints to be used to give additional guidance of a more free-form nature such as why and how to go about using these specs, best practices, etc that don't belong directly in the specs but that would be useful to people trying to figure these out. The documents haven't been created yet, but will be by the time this goes to BETA.)

    3.2 Non-Normative References
    3.2.1 OMG Space Domain Task Force Guidance Documents

    The following documents provide guidance for the usage of C2MS set forth by the OMG Space Domain Task Force.

    3.2.12 NASA GMSEC Documents

    Note that NASA has developed a Platform Specific Model (PSM) referred to as GMSEC. The GMSEC API software, selected components, and documentation are distributed by NASA. Others are free to develop alternative PSMs.

    The following GMSEC documents set forth the NASA GMSEC Architecture and the GMSEC Applications Programming Interface User’s Guide. Documents for specific GMSEC-compliant software components should be consulted on an individual basis.

    • GMSEC Architecture Document, Release 3.0.0, February 2018
    • GMSEC API 5.2 User’s Guide, November 2023
  • Updated: Mon, 30 Mar 2026 13:59 GMT
  • Attachments:

Enumeration value ESTIMATED used twice in the same package

  • Key: C2INAV13-3
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Using the value ESTIMATED for both accuracy_derivation_type and navigation_derivation_kind_type causes problems in some programming languages; it is also better practice to be more descriptive.

  • Reported: C2INAV 1.2b1 — Mon, 24 Jul 2023 14:26 GMT
  • Disposition: Duplicate or Merged — C2INAV 1.3
  • Disposition Summary:

    Duplicate of C2INAV13-2

    This issue is a duplicate of C2INAV13-2

  • Updated: Mon, 15 Dec 2025 15:00 GMT

Enumeration value ESTIMATED used twice in the same package

  • Key: C2INAV13-2
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Using the value ESTIMATED in accuracy_derivation_type and navigation_derivation_kind_type causes problems when mapped to some programming languages; it is also better practice to be more descriptive.

  • Reported: C2INAV 1.2b1 — Mon, 24 Jul 2023 14:24 GMT
  • Disposition: Resolved — C2INAV 1.3
  • Disposition Summary:

    Modify enumeration values to be more descriptive

    Change the ESTIMATED enumeration values as follows:

    In accuracy_derivation_type change to ESTIMATED_ACCURACY
    In navigation_derivation_kind_type change to ESTIMATED_NAV_INFO

  • Updated: Mon, 15 Dec 2025 15:00 GMT
  • Attachments:

C2INav Model refers to an old OARIS Common Types package

  • Key: C2INAV13-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Ollie Newman)
  • Summary:

    The C2INav Model refers to a package defined by OARIS 1.1.
    OARIS 2.0 is about to be published and there are 2.1 RTF & 3.0 FTF in progress.

  • Reported: C2INAV 1.2 — Thu, 20 Jul 2023 09:09 GMT
  • Disposition: Resolved — C2INAV 1.3
  • Disposition Summary:

    Update references to be to OARIS 3.0

    Update the references and images throughout the document to refer to the common packages from OARIS 3.0

  • Updated: Mon, 15 Dec 2025 15:00 GMT
  • Attachments:

Locations is missing a hasState property

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It has hasCountry and hasCounty but not hasState. The examples use hasSubdivision which is the super property, but trying to get back the state via hasSubdivision will also return the County and the Country.

  • Reported: Commons 1.2b1 — Wed, 25 Jun 2025 09:56 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Locations is missing a hasState property

    Add a property called 'hasPrimarySubdivision' for use in querying in cases where RDF entailment or other reasoning is employed in order to reduce the results returned to only those that are considered primary.

    This resolution depends on the results of Ballot #4, including the resolution to COMMONS13-28.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Additional taxonomic relations are needed in the classifiers ontology

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

    Relationships between elements of a taxonomy are difficult to represent without adding properties for concepts such as broader / narrower classifiers.

  • Reported: Commons 1.2b1 — Tue, 17 Jun 2025 20:52 GMT
  • Disposition: Closed; No Change — COMMONS 1.3b1
  • Disposition Summary:

    Additional taxonomic relations are needed in the classifiers ontology

    Work to add some capabilities for taxonomic relationships is being done in the context of MVF. The MVF RTF could propose adding those concepts to the classifiers ontology, but there is no need to duplicate the work that they are doing, regardless of where these concepts land.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Poor definition of ctxtdsg:isUsedBy

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The phrase "is employed in the process of accomplishing something for" is poor English: specifically the final word "for".
    I'm not even sure why it's even in ContextualDesignators since it's not referenced anywhere.

    It's certainly not formally defined enough to be used to represent the notion of a restricted legal currency for a country.as in
    <owl:Class rdf:about="&fibo-fnd-acc-cur;Currency">
    ...
    <rdfs:subClassOf>
    <owl:Restriction>
    <owl:onProperty rdf:resource="&cmns-cxtdsg;isUsedBy"/>
    <owl:someValuesFrom rdf:resource="&cmns-loc;GeopoliticalEntity"/>
    </owl:Restriction>
    </rdfs:subClassOf>
    And this is nothing to do with the notion of context.

    There is also inconsistent usage - the above is use by a geopolitical entity; there is also fibo-fnd-acc-cur:CalculatedPrice uses PricingModel which is not an entity and has quite different semantics.

  • Reported: Commons 1.2b1 — Wed, 25 Jun 2025 09:19 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Poor definition of ctxtdsg:isUsedBy

    This resolution simplifies and clarifies the definition of isUsedBy and makes minor adjustments to the definition of uses.

    Note that any issues in consistency with respect to how these properties have been used by FIBO is outside the scope of Commons.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

US-centric geopolitical terminology

  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    This ontology defines "County" and "FederalState", which bias the ontology toward the administrative geography of the United States. Cantons and provinces are defined as synonyms or FederalState, but other countries have subdivisions that go by other names. The term "GeopoliticalEntity" could apply in that case (e.g., to a French "région" or "département", except that GeopoliticalEntity is defined as a subclass of GeographicRegion, which is "an area of land that has common features" which seems to be mostly about physical characteristic (a mountain, a plain, etc.) not a geopolitical entity.
    It would seem that more generic terms than "County" or "FederalState" should be used to better address the geopolitical subdivision of countries other than the U.S.

  • Reported: Commons 1.2b1 — Fri, 27 Dec 2024 02:50 GMT
  • Disposition: Closed; No Change — COMMONS 1.3b1
  • Disposition Summary:

    US-centric geopolitical terminology

    This issue raises two questions: (1) whether certain concepts are overly US centric, which is addressed by use of LCC, and (2) the definition of geopolitical entity, which we have raised COMMONS13-49 to address.

    With respect to US language, the concept of a county uses the same language used in other English speaking countries including the UK, Australia, etc. The concept of a federal state applies in a number of other countries including Mexico. LCC contains the names for all subdivisions world-wide that are reported to the UN in their native language(s), and so making these kinds of modifications to find more common terms, given that American English is the language of OMG specifications, is redundant.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Need the definition of capacity in organizations and to contrast it with capability

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

    The current definition of capability isn't sufficiently clear about skills and qualifications that an individual might have in addition to an organization (both are needed), and should better describe the concept of having the skills, expertise, and other qualifications in order to, for example, achieve business goals and objectives.

    Capacity on the other hand is about having the resources to execute. These two terms are used somewhat interchangeably in FIBO, for example, but in order to use them properly for other use cases they should be differentiated and disjoint.

  • Reported: Commons 1.2b1 — Sat, 22 Mar 2025 23:58 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Need the definition of capacity in organizations and to contrast it with capability

    This resolution adds the concept of 'capacity' to the organizations ontology as requested.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Awkward unions of RA and Registrar

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There are several places with restrictions such as the following. It would be preferable to just use Registrar, separating the concerns. In those cases where a RA also does registration then it could be multiply classified as a Registrar too. <owl:someValuesFrom> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <rdf:Description rdf:about="&cmns-ra;RegistrationAuthority"> </rdf:Description> <rdf:Description rdf:about="&cmns-ra;Registrar"> </rdf:Description> </owl:unionOf> </owl:Class> </owl:someValuesFrom>

  • Reported: Commons 1.2b1 — Mon, 23 Jun 2025 21:48 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Address Awkward unions of RA and Registrar

    This revision clarifies the distinction between a registrar and registration authority, enabling individuals playing both roles to be multiply classified as such and eliminating the unions that the issue raises.

    Note that the diagram in Clause 8.16, Figure 17, will be revised via the resolution to issue COMMONS13-38.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Annotation Vocabulary missing discussion of labeling policy

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Little best practice or guidance is given in either the spec or the ontology. By the fact that they're included it seems that skos:prefLabel and skos:altLabel are recommended. However they're not actually used in this or any of the other Commons ontologies.
    Commons itself provides an alternative with its Designations ontology. And OMG provides a strong capability in MVF.

    Users of Commons should be warned about the anti-pattern use of rdfs:label as the primary in conjunction with skos:altLabel which makes it impossible, with reasoning enabled, to return only the primary (since skos:altLabel; is a subProperty of rdfs:label)

  • Reported: Commons 1.2b1 — Sun, 10 Nov 2024 20:08 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Annotation Vocabulary missing discussion of labeling policy

    The RTF determined that adding notes to each of the subproperties of rdfs:labels to indicate the issue with queries that use entailment may return multiple labels was sufficient to address this issue.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

The documents ontology is missing the notion of a document part

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

    SBRM and other OMG processes need to be able to connect documents to the components therein. RTF members have requested that we add these terms to the documents ontology to facilitate mapping to other document ontologies as well as for extension purposes.

  • Reported: Commons 1.2b1 — Sat, 2 Nov 2024 19:26 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    The documents ontology is missing the notion of a document part

    This resolution adds the requested concept of a document part to the documents ontology.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

StructuredCollections ontology misnamed

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It's counterintuitive that the class StructuredCollection is not in the ontology StructuredCollections. It breaks the naming pattern that an ontology is named after its principle class.

  • Reported: Commons 1.2b1 — Fri, 27 Sep 2024 18:52 GMT
  • Disposition: Closed; No Change — COMMONS 1.3b1
  • Disposition Summary:

    StructuredCollections ontology misnamed

    The issue states that there is a requirement that an ontology in Commons must include a class that has the same name as the ontology, and that as a consequence, this ontology is misnamed.

    There are other cases where we have expanded on a concept and created a subordinate ontology that does not include the class of the same name, and we should be able to continue doing this without the constraint. If, for example, a particular community needs an expansion on some concept, we would add that new ontology expanding on the higher level, but not necessarily move the concept to the lower level. There are cases where people may need the notion of a structured collection but not the library of kinds of structured collections that might be useful for some use case.

    Ontology renaming is quite disruptive, in fact, for people already using it, and should be avoided to the degree possible. The same is true for naming of concepts, although one can argue for doing that if it is appropriate for modularization or to create a higher-level concept on which multiple lower level concepts depend for interoperability. This is not that case, howevere.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Unnecessary description properties in Designators

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    hasDescription, describes, and isDescribedBy:

    • are very vaguely defined
    • have unclear usage
    • are little to do with the declared scope of Designators (about naming)
    • duplicate the more broadly used dct:description
    • are only used in two other places (cls:classifies is subPropertyOf describes - which is not semantically valid since a classifier does not "describes the nature of" the thing it classifies) and (qtu;describesActualExpression subPropertyOf hasDescription - would be better as subPropertyOf cmns-doc;specifies)
  • Reported: Commons 1.2b1 — Thu, 19 Jun 2025 15:39 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Unnecessary description properties in Designators

    The properties in question come from the semiotic triangle (describes, defines, denotes), and were discussed at length when we first added them to the ontology. They are heavily used in IDMP, FIBO, API4KP, and elsewhere.

    They are: describes, isDescribedBy, and hasDescription. With respect to dct:description, which was mentioned in the issue description, that's an rdf:Property commonly used as an annotation property in OWL. hasDescription in the Designators ontology is a data property. A data property is required for use in mapping attributes, where use of an annotation doesn't work. Revising the semantics of Dublin Core in our Commons ontologies would violate best practices in reuse / FAIR use of the vocabulary.

    We agreed to add usage notes to the 3 properties in question, as provided in the body of this resolution.

    Note too that Dublin Core is not an OWL ontology - it is an RDF vocabulary, and as such cannot be imported in any OWL ontology, only referenced. This is a nuance that many people don't understand, but is really important for consistency across uses. There are many folks out there that incorrectly import Dublin Core unfortunately, but that can cause inconsistency errors for reasoning, among other issues.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Need the ability to describe the concept of authorization

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

    Concepts including authorization (as a situation), roles of authorizing party and authorized party, and related properties are needed by a number of task forces for describing the legal authority some party may have with respect to some organization or process, including delegated authority.

  • Reported: Commons 1.2 — Fri, 18 Jul 2025 18:38 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Need the ability to describe the concept of authority

    This revision adds a new business authorizations ontology, updates the relevant metadata files, and reuses the concept of an authorizing party in regulatory agencies and registration authorities.

    This resolution depends on the resolution of the issues included in Ballots #1-#3 in terms of the metadata changes made therein to various files, as well as on the resolutions of COMMONS13-10 and COMMONS13-27 in order to update the AboutCommons metadata file to include the new ontologies. This file does not add semantics, however – it is provided for ease of use only.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Locations ontology should reuse W3C WGS84 ontology

  • Status: closed   Implementation work Blocked
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    See https://www.w3.org/2003/01/geo/. This tiny ontology with representation of lat/long is widely supported by graph databases and allows use of GeoSPARQL. It makes little sense for OMG to define its own properties such as &cmns-loc;hasLongitude..
    Example:
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
    <geo:Point>
    <geo:lat>55.701</geo:lat>
    <geo:long>12.552</geo:long>
    </geo:Point>
    </rdf:RDF>

  • Reported: Commons 1.2b1 — Wed, 11 Jun 2025 20:47 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Locations ontology should reuse W3C WGS84 ontology

    Added references to the WGS84 ontology using rdfs:seeAlso, given that the properties in this vocabulary are RDF properties and not directly usable in OWL. Also revised links to ESRI according to their new dictionary, and added hasAltitude for the sake of completeness.

    Note that this revision depends on the resolution of Commons-1.3.20, which covers all changes made through Ballot #3.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Annotation Vocabulary has incomplete definitions from SKOS

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The definitions taken from SKOS seem altered and incomplete.
    For example here is the official definition from SKOS RDF file for altLabel. The Commons version changes the label (using "tag" instead of "label") and omits the comments, one of which is the important (informal) disjointness constraint, and example.

    <rdf:Description rdf:about="#altLabel">
    <rdfs:label xml:lang="en">alternative label</rdfs:label>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>
    <skos:definition xml:lang="en">An alternative lexical label for a resource.</skos:definition>
    <skos:example xml:lang="en">Acronyms, abbreviations, spelling variants, and irregular plural/singular forms may be included among the alternative labels for a concept. Mis-spelled terms are normally included as hidden labels (see skos:hiddenLabel).</skos:example>
    <!-- S10 -->
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AnnotationProperty"/>
    <!-- S11 -->
    <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#label"/>
    <!-- S12 (not formally stated) -->
    <rdfs:comment xml:lang="en">The range of skos:altLabel is the class of RDF plain literals.</rdfs:comment>
    <!-- S13 (not formally stated) -->
    <rdfs:comment xml:lang="en">skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.</rdfs:comment>
    <!-- For non-OWL aware applications -->
    <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
    </rdf:Description>

  • Reported: Commons 1.2b1 — Sun, 10 Nov 2024 19:56 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Annotation Vocabulary has incomplete definitions from SKOS

    Modified the Annotation Vocabulary to revert to the precise annotations used in SKOS and Dublin Core rather than avoid circular definitions and comply with ISO 704, (which is required by ISO and thus for all OMG ontologies). Original explanatory notes remain in the ontology, though.

    This change depends on the resolutions to issues in Commons 1.3, including revised metadata, through Ballot #3.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Need to augment the locations ontology to cover sites and facilities, or create a new ontology for these concepts

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

    Several OMG members have requested a general ontology that includes sites and facilities, which are currently modeled in FIBO, primarily for lending and asset management purposes, but they are also needed for retail and manufacturing. The relationship between a site and a facility is many to many, and modeling them for manufacturing as well as retail, energy, military, and other domain areas can be tricky. Having the general pattern that can be extended by any domain area would be very useful for extension purposes.

  • Reported: Commons 1.2b1 — Sat, 2 Nov 2024 19:21 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Need to augment the locations ontology to cover sites and facilities, or create a new ontology for these concepts

    This resolution adds a new Sites and Facilities ontology, per the request from several OMG task forces and members as well as external Commons users. The proposed ontology has been tested extensively by FIBO and IDMP-O users, among others.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Constituent term has two issues

  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    1. The first term is shown as "cmns-col;Constituent" – what does the prefix mean???

    2. The annotation starts with "An element is an object..." instead of "A constituent is an object..."

  • Reported: Commons 1.2b1 — Fri, 27 Dec 2024 03:06 GMT
  • Disposition: Closed; No Change — COMMONS 1.3b1
  • Disposition Summary:

    Constituent term has two issues

    The first 'issue' was with respect to the namespace prefix, asking what it means. The prefix, 'cmns-col' is defined in clause 7.2, Table 7.2. That table includes all of the namespace prefixes for all ontologies included in the Commons library.

    Secondly, the issue suggests a rephrasing of the explanatory note added to constituent in the structured collections ontology. The note comes from ISO 5127, which uses the term 'element' rather than 'constituent' in a synonymous way. We added the note and synonym in structured collections, with the thought that in the context of that note, the term 'element' was more appropriate (and was what the ISO standard used).

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Could a "date period" be defined even without knowing the exact dates?

  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    The specificaton of DatePeriod states: "A date period is unknown if either the start date or the end date has no value. If a date period
    is unknown, then the duration should either be omitted or unknown (have no value)."
    What about the situation in which the period is known but the dates are not yet known? For example, as I write this we know that OMG's Q2 meeting will be over 5 calendar days, but it may be June 12-16 or June 19-23. There could be a date period associated to such an entity (meeting) that don't have a start date or end date, but have a known duration, which should be recorded. "Duration" is not necessariiy a good substitute because it is not limited to a date range.

  • Reported: Commons 1.2b1 — Fri, 27 Dec 2024 02:24 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Could a "date period" be defined even without knowing the exact dates?

    Revised the comments on DatePeriod to indicate that a date period can be incomplete, i.e., one where the period is known but start and end dates are not, such as a 4-day work week or 5-day conference.

    The resolution of this issue depends on the resolution of Commons-1.3-20.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Need to add the definition of language to the Codes and Code Sets ontology

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

    The notion of a language is needed for DOL, API4KP, and MVF and LCC - which means that we should move it from LCC to Commons. The team agreed that it should be added to the codes and code sets ontology, including a language identifier and related properties.

  • Reported: Commons 1.2b1 — Fri, 23 May 2025 19:16 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Need to add the definition of language to the Codes and Code Sets ontology

    This resolution adds a new Languages ontology for use in aligning and simplifying API4KP, DOL, LCC and MVF.

    See the resolution to issue COMMONS13-32 for metadata and a revised overview diagram for the Designators ontology. This resolution adds a single property, hasTag, as covered in the attached revised Text, but the remainder of the details, including other changes needed to resolve COMMONS13-32 are covered under that issue resolution.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Commons silently changes the semantics of dct:description

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The definition in Commons Annotation Vocabulary is not a mere copy of what's in DCT with the documented addition of making it a owl:AnnotationProperty, but adds the triple :
    <rdfs:subPropertyOf rdf:resource="&skos;note"/>
    That may or may not be a good idea but it adds a dependency and it's a significant change that should be flagged.
    In fact, given that SKOS itself makes use of DCT, that makes for a somewhat undesirable circular dependency though not formally stated.

    If an aim is some sort of unification then maybe skos:definition should be made a subProperty of dct:description.

  • Reported: Commons 1.2b1 — Sun, 10 Nov 2024 20:28 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Refine annotation hierarchy for better alignment

    The issue makes a good point regarding normalizing the hierarchy among external annotation properties, despite the fact that OWL reasoners ignore these kinds of axioms.

    The RTF determined that we should not only improve that hierarchy in a few cases but make a statement about why we've done so in the ontology metadata.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Typeface issue (LogarihmicScale should be bold)

  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    The term LogarithmicScale (near top left of page 91) should be bold.

  • Reported: Commons 1.2b1 — Fri, 27 Dec 2024 02:59 GMT
  • Disposition: Closed; No Change — COMMONS 1.3b1
  • Disposition Summary:

    Typeface issue (LogarihmicScale should be bold)

    This issue was addressed editorially in the formal Commons 1.2 specification prior to publication (formal/25-02-03)

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Reference to GMT should be to UTC instead

  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    The annotation for the DateTime row states "The time zone is implicitly GMT." This time zone is now known as UTC, and this should be used rather than GMT because UTC is the legal reference, and UTC is measured from midnight while GMT was measured from midday. There are other distinctions, see https://www.timeanddate.com/time/gmt-utc-time.html.

  • Reported: Commons 1.2b1 — Fri, 27 Dec 2024 02:34 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Reference to GMT should be to UTC instead

    Revise the annotation related to the DateTime definition in the ontology and specification to replace GMT with UTC.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Missing word "Revision"?

  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    The sentence "Oversight for curation of the library will be managed by the Commons task force (RTF) via the normal
    OMG process" seems to be mssing the word "revision" before "task force".

  • Reported: Commons 1.2b1 — Fri, 27 Dec 2024 02:07 GMT
  • Disposition: Closed; No Change — COMMONS 1.3b1
  • Disposition Summary:

    Missing word "Revision"?

    This issue was addressed editorially prior to publication of the Commons 1.2 specification, formal/25-02-03.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

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.3b1
  • Disposition Summary:

    Need an ontology representing multidimensional arrays

    We agree that this is important, but have been waiting on adoption of SysML v2 and its new quantities and units library in order to complete the work. We plan to do so in Commons 1.4 now that SysML v2 has been adopted.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Definition of List says it's a set

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The definition of List includes "set of related items"

  • Reported: Commons 1.2b1 — Fri, 27 Sep 2024 18:55 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Revise the definition of list to eliminate the notion of 'set'

    The original definition required the elements in a list to be part of as set, which is not correct. The definition should be revised to be clearer and more in line with how it is commonly used at OMG and elsewhere.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

Wrong property used for collection members

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Wrong property used for collection members in restrictions on List and ChronologicallyOrderedCollection.
    These make use of hasConstituent but this is disjoint with hasMember and it says "This property is disjoint with hasMember, and should be used in cases where the constituents of something are not considered discrete elements of whatever they are included in, such as a substance or composite."

  • Reported: Commons 1.2b1 — Fri, 27 Sep 2024 18:51 GMT
  • Disposition: Resolved — COMMONS 1.3b1
  • Disposition Summary:

    Revised the structured collections ontology to use hasMember in place of hasConstituent

    The definition of hasMember reflects the notion of a discrete member rather than one that may not be distinguishable, and thus this change revises the ontology such that the correct property is used in a couple of restrictions.

  • Updated: Wed, 10 Dec 2025 23:18 GMT
  • Attachments:

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.3b1
  • Disposition Summary:

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

    We agree that this needs to be addressed. The RTF plans to work with the SysML v2 team to revise the quantities and units ontology to incorporate tensor and vector quantities, and review other related concepts in the course of doing so. SysML v2 has only recently become an adopted standard, however, and due to time constraints we need to defer this to Commons 1.4.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Confusing properties added to Constituent by StructuredCollections

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Ontology StructuredCollections adds properties to Constituent which tend to add confusion rather than value. Specifically it adds a synonym "element" with explanation "an element is part of a set..." yet a set is by definition unstructured - the opposite the whole purpose of the ontology which is structured collections

  • Reported: Commons 1.2b1 — Fri, 27 Sep 2024 18:54 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    Confusing properties added to Constituent by StructuredCollections

    Resolving this issue requires further discussion, and should be addressed in the context of other related issues, such as COMMONS13-36, which the RTF has deferred to Commons 1.4.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Ill-defined notion of "ordered by time"

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The class ChronologicallyOrderedCollection is unclear when it says "structured collection whose elements are ordered by time", since the elements are more than simple (time) values but individuals with potentially many properties which are time-related. Even for the example given of bank transactions there's often a difference between the time the transaction happened and when it was recorded: my credit card statement has both "Post Date" and "Trans Date" - with the statement ordered by Post Date. And in some cases the time-related property might be on a separate linked individual. For some cases it could get a lot more complex e.g. employment for a person - there might be period overlaps.
    Even ChronologicallyOrderedConstituent does not help - it seems to select only hasObservedDateTime which is both over-specific (how does it help with Employment?) and still under-specified (since hasObservedDateTime is itself pretty vague "indicates a date and time associated with an event, measurement, record, or observation" which does not discriminate the above examples or help with Employment).

  • Reported: Commons 1.2b1 — Fri, 27 Sep 2024 18:53 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    Ill-defined notion of "ordered by time"

    This needs much more discussion and use cases, as the concept included in the structured collections ontology is more about ordered records, not about richer concepts such as employment, for which FIBO, for example, uses the pattern expressed in the parties and situations model. That pattern is significantly richer with respect to the options for representation of a period of time for which the state of affairs holds.

    We are deferring this to allow for use cases to be presented to the RTF and contrasted with suggesting that users leverage the parties and situations model for more complex states of affairs.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Need for simple ordered List

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Commons is missing a class representing a simple ordered list of items. The class StructuredCollections:List is far too heavyweight for general use:
    Each member must be an IndexedConstituent which in turn must have a value for comprises which is an IndexValue defined in an IndexingScheme and only that actually refersTo a nonNegativeInteger.
          myList a :List ;
          :hasMember [
                a :IndexedConstituent ;
    :comprises [
    a :IndexValue ;
    :characterizes <member1> ;
    :isDefinedIn :myScheme ;
    :refersTo ??;
    :hasNumericValue 1
    ]
               ] ,    
               a :ListMember ;
                :refersTo <member3> ;   
                :hasSequence 3 ;
               ] ,    
               a :ListMember ;
                :refersTo <member2> ;   
                :hasSequence 2 ;
               ]    
    .
    That might represent a StructuredElementList but for a basic list one would only need one class and two properties - something like:
          myList a :List ;
          :hasMember [
                a :ListMember ;
                :refersTo <member1> ;   
                :hasSequence 1 ;
               ] ,    
               a :ListMember ;
                :refersTo <member3> ;   
                :hasSequence 3 ;
               ] ,    
               a :ListMember ;
                :refersTo <member2> ;   
                :hasSequence 2 ;
               ]    
    .

  • Reported: Commons 1.2b1 — Fri, 27 Sep 2024 18:50 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    Need for simple ordered List

    RDF provides the concept of an atomic list, similar to what is described in the request. This concept is rarely used in ontologies, where a richer notion such as the pattern provided in the structured collections ontology is often needed.

    The concept of a simple list needs more discussion and specific use cases, and explanation for potential users as to when this should be used over the built in list structure available in RDF.

    We are deferring this issue due to the need for use cases and more discussion.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

The definition of constituent, and of the property hasConstituent needs additional refinement

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

    We've said that hasMember is distinct from hasConstituent, but the actual definitions are not necessarily obviously different to users. The definition of hasConstituent changed after the original ontology was submitted, and the notion of Constituent as a class could be used to support either members or constituents, even though the properties in question are disjoint.

    It is likely that we need to find a different "word" or "phrase" to describe elements of a composite that are not necessarily distinguishable from one another, and revise the ontology accordingly.

  • Reported: Commons 1.2b1 — Fri, 3 Jan 2025 19:31 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    The definition of constituent, and of the property hasConstituent needs additional refinement

    This issue should be merged with COMMONS13-36 and the two addressed together, since they raise similar issues.

    We deferred COMMONS13-36 due to the need to test a potential change with example data, thus this companion issue is being deferred as well.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Add additional metadata for external ontology registration

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For visibility outside OMG I think we should be registering all our ontologies which I think may require a few extra items of metadata as here https://lov.linkeddata.es/Recommendations_Vocabulary_Design.pdf such as Dublin Core terms title and description (we have label and abstract), (date) issued and modified, and for elements, rdfs:comment (we have the more specific skos:definition). I think most of these could be added via automated script (e.g. Each skos:definition also becomes a rdfs:comment).

  • Reported: Commons 1.2b1 — Tue, 13 May 2025 18:30 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    Add additional metadata for external ontology registration

    Resolving this issue requires agreement on the list of additional annotations needed to support registration of our ontologies in external systems. The LOD community, for example, while widely used for a combination of ontology and vocabulary registration, suggests use of annotations that are in vocabularies that are no longer maintained or that include embedded, viral references to vocabularies that are either no longer maintained or that are not allowed for use on various government or commercial systems.

    In other words, more research is needed, and agreement on the set of annotations and criteria for determining such a list, as well as which target repos we want to propose inclusion of OMG ontologies in, should be determined with consensus of, for example, the OMG AB.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

expressesTheMagnitudeOf seems wrong

  • Status: closed  
  • Source: Graphwise (Ontotext) ( Vladimir Alexiev )
  • Summary:

    expressesTheMagnitudeOf
    Definition: indicates the subject or topic of something, such as
    a document
    Range: ScalarQuantity

    I'm pretty sure the definition is wrong.
    And the range seems wrong too.

  • Reported: Commons 1.2b1 — Sat, 15 Feb 2025 04:12 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    expressesTheMagnitudeOf seems wrong

    The current definition of 'expressesTheMagnitudeOf is, in fact, 'specifies the quantity that some quantity value reflects', not 'indicates the subject or topic of something, such as a document', as described in the issue.

    It may be the case that we need to refine this definition, and the RTF plans to review all of the definitions as we integrate additional quantities from SysML v2, but in this case, the person that filed the issue was looking at the wrong definition.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

The definition of geopolitical entity in the locations ontology needs refinement

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

    Currently, a geopolitical entity is a subclass of geographic region. But, a geopolitical entity can span regions, and in a handful of cases may not be associated with well-defined borders. A geopolitical entity would be better defined as a political entity associated with a geographic region, and loosen the relationship between the two concepts.

  • Reported: Commons 1.2 — Thu, 14 Aug 2025 18:30 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    The definition of geopolitical entity in the locations ontology needs refinement

    The RTF agrees that this is important to address, but changing the definition of geopolitical entity, adding political entity, and then testing this with a revision of LCC that leverages this change will take time.

    Thus we agreed to defer this to Commons 1.4.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Certain ontologies would benefit from having a node id for ontology elements that supports searching

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

    For generated ontologies such as BACM, and applications that need access to the blank nodes in an ontology, it is useful to have a UUID for every node, particularly blank nodes, which could be handled as an annotation. For alignment with XMI metamodels it may be quite useful.

    This request came from BMI. We could add it to either (1) the annotation vocabulary, or (2) one of the identifier ontologies in Commons

  • Reported: Commons 1.2b1 — Tue, 17 Jun 2025 18:09 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    Certain ontologies would benefit from having a node id for ontology elements that supports searching

    Resolving this issue requires a bit more research, and should take into account the changes that are coming in RDF 1.2, which simplifies reification among other things that may be relevant.

    We are deferring this to allow for more discussion and to await finalization of the RDF 1.2 specification.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

Unclear distinction between hasPart and hasMember

  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The definitions in Collections are terse or drawn from diverse sources, and the notes focus on technical aspects (such as transitivity) that don't help a modeler decide which to use.
    hasMember definition is overly terse, whereas hasPart is almost absurdly long and littered with disjunctions making it all-inclusive of anything.

    in FIBO for example hasPart is used to link from a PooledFund to its FundUnits, and a BondPool to its Bonds. And from a Judiciary to its Courts.
    But on the other hand hasMember is used to link a Program to its Projects and an InstrumentPool to its FinancialIstruments.

    Clearly there is some understanding of the distinction being deployed in FIBO, especially related to Pools, that is not clear in the Commons definitions. Especially because BondPool subclasses DebtPool which subclasses InstrumentPool which has a hasMember restriction, yet hasPart is used.
    Also it's unclear why hasPart has no relation to comprises.
    Generally I think there's too much in authors' heads and not enough written - which is essential for successful and consistent usage in ontologies, data and queries.

    Definitions follow:
    hasMember: includes, as a discrete element. Note that the domain of hasMember should be some sort of collection, aggregate, or group. In the Financial Industry Business Ontology (FIBO), hasMember is used in the case of parties (people and organizations), whereas comprises can have anything in its range.

    hasPart: indicates any portion of something, regardless of whether the portion itself is attached to the remainder or detached; cognitively salient or arbitrarily demarcated; self-connected or disconnected; homogeneous or gerrymandered; material or immaterial; extended or unextended; spatial or temporal

  • Reported: Commons 1.2b1 — Tue, 8 Jul 2025 19:03 GMT
  • Disposition: Deferred — COMMONS 1.3b1
  • Disposition Summary:

    Unclear distinction between hasPart and hasMember

    The RTF agrees that additional clarifying annotations would be helpful to users, but any inconsistency in FIBO in using these properties should be addressed there, not in Commons per se.

    In order to confirm whether or not we can make hasDirectPart a subproperty of both comprises and of hasPart, though, we need some additional time to create test cases. The RTF plans to do so in Commons 1.4.

  • Updated: Wed, 10 Dec 2025 23:18 GMT

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:

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:

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:

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

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:

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

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:

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:

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:

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

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:

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

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

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

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

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

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:

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

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

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:

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

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

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

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:

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:

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

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:

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

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

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

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

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

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:

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

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:

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:

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

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

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:

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

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

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:

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

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

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:

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:

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:

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:

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

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

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

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

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:

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:

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

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

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:

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

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:

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


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:

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:

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

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

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:

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:

"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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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:

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

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

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:

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

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

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

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

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

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

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

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

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

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

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:

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 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:

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

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:

xmi profile


Use @key instead of @Key


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

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:

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:

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:

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

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:

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:

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)

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:

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:

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:

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

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

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

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

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

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

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

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

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

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

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-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

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 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

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

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

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

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

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

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

"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

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

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

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

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

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

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

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

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

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

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

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 (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

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

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

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

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.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

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

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

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

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

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

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

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

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

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 (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(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 (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

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

"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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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

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

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

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

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

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

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

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 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

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

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

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

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

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

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.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.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

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

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

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

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

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: 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 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: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (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

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 (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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

${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

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

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

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

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 -- 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

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 -- 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

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

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

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

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 -- 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 -- 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 -- 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: