C Language Mapping Avatar
  1. OMG Specification

C Language Mapping — Open Issues

  • Acronym: C
  • Issues Count: 847
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
C2MS12-5 Acknowledge Final Status inconsistency C2MS 1.0b1 open
C2MS12-28 Rework "Introduction to Specification" into a Section Describing Expected Use C2MS 1.0 open
C2MS12-42 Required or Optional for MNEMONIC Status on Data Messages C2MS 1.0 open
C2MS12-22 Replace simple service REQ/RESP C2MS 1.0 open
C2MS12-20 Clarity and Usage Issues with Replay Telemetry Data Request (and Response) Message C2MS 1.0 open
C2MS12-96 namespace support should be reflected in at least the telemetry and command related C2MS messages C2MS 1.1b1 open
C2MS12-23 Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages C2MS 1.0 open
C2MS12-36 mnemonic.n.sample.m.quality seems to be wrong type C2MS 1.0 open
C2MS12-79 Create a C2MS SM&C MAL Message C2MS 1.1b1 open
C2MS12-74 Add SM&C MAL Message C2MS 1.1b1 open
C2MS12-16 Define a Way to Create Argument-based Commands for the Command Request Message C2MS 1.0 open
CPP1117-41 Missing base_type IDL traits for base struct and bitset CPP11 1.7 open
C2MS12-91 Standardize Table Cell Borders C2MS 1.1b1 open
C2MS12-93 Remove 'Not used' Designators in "Properties of Miscellaneous" Tables C2MS 1.1b1 open
C2MS12-89 Miscellaneous Minor Document Formatting/Text Issues C2MS 1.1b1 open
C2MS12-87 Standardize Sections and Section Names for Message Subjects C2MS 1.1b1 open
COMMONS13-14 Commons silently changes the semantics of dct:description Commons 1.2b1 open
C2MS12-84 Fix Use of 'Severe' in Diagrams (Should be 'Critical') C2MS 1.1b1 open
COMMONS13-13 Annotation Vocabulary missing discussion of labeling policy Commons 1.2b1 open
COMMONS13-12 Annotation Vocabulary has incomplete definitions from SKOS Commons 1.2b1 open
COMMONS13-11 The documents ontology is missing the notion of a document part Commons 1.2b1 open
COMMONS13-10 Need to augment the locations ontology to cover sites and facilities, or create a new ontology for these concepts Commons 1.2b1 open
CPP1117-40 Add support for @cpp_mapping CPP11 1.7 open
CORBA35-75 lwCCM issues - home finders and finder operations CORBA 3.0.3 open
CORBA35-91 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 open
CORBA35-85 lwCCM issues - abstract storage type CORBA 3.0.3 open
CORBA35-84 lwCCM issues - abstract storage home CORBA 3.0.3 open
CORBA35-80 lwCCM issues - get_all_facet, ... CORBA 3.0.3 open
CORBA35-25 LwCCM issue - Section 1.6.8 Exclusion CORBA 3.0.2 open
CORBA35-23 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 open
CORBA35-89 lwCCM issues - security CORBA 3.0.3 open
CORBA35-90 lwCCM issues - transaction CORBA 3.0.3 open
CORBA35-86 lwCCM issues - section 4.1.2 CORBA 3.0.3 open
CORBA35-88 lwCCM issues - persistence CORBA 3.0.3 open
CORBA35-87 lwCCM issues - entity components CORBA 3.0.3 open
CORBA35-81 lwCCM issues - segmentation CORBA 3.0.3 open
CORBA35-82 lwCCM issues - locator CORBA 3.0.3 open
CORBA35-83 lwCCM issues - CIDL CORBA 3.0.3 open
CORBA35-77 lwCCM issues - configurators CORBA 3.0.3 open
CORBA35-78 lwCCM issues - Section 4.1 CORBA 3.0.3 open
CORBA35-79 lwCCM issues - primary key CORBA 3.0.3 open
CORBA35-74 lwCCM issues - invalid rows CORBA 3.0.3 open
CORBA35-76 lwCCM issues - proxy homes CORBA 3.0.3 open
CORBA35-73 lwCCM issues - Entity2Context CORBA 3.0.3 open
CORBA35-415 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 open
CORBA35-418 Can value type inherit from Value Box type CORBA 2.2 open
C2MS12-26 Deprecate fields duplicated between C2MS Messages and the Message Envelope C2MS 1.0 open
C2MS12-32 Revisit Tracking Fields C2MS 1.0 open
C2MS12-37 AMVAL Value Response Doesn't Mirror MVAL Value Response Message C2MS 1.0 open
C2MS12-46 What to do when Priority isn't Specified C2MS 1.0 open
C2MS12-41 Lack of Required Fields in Sub-elements C2MS 1.0 open
C2MS12-15 Using REQ Messages for 'Publish' C2MS 1.0 open
C2MS12-33 Re-evaluate Optional Boolean Fields C2MS 1.0 open
C2MS12-18 Command Echo Not Provided Message C2MS 1.0 open
C2MS12-67 Revisit Completion Status in Command Response Message C2MS 1.0 open
C2MS12-43 Rework Log Message C2MS 1.0 open
C2MS12-31 Consider Deprecating and Later Removing Resource Message C2MS 1.0 open
COMMONS13-2 The quantities and units ontology does not allow representation of unitless quantity values Commons 1.1b1 open
COMMONS12-2 The quantities and units ontology does not allow representation of unitless quantity values Commons 1.1b1 open
COMMONS13-1 Need an ontology representing multidimensional arrays COMMONS 1.0b2 open
COMMONS12-1 Need an ontology representing multidimensional arrays COMMONS 1.0b2 open
C2MS12-66 Consider a Command Completed Publish Message C2MS 1.0 open
C2MS12-21 Reconsider Oneshot in MVAL Request/Response C2MS 1.0 open
C2MS12-47 Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message C2MS 1.0 open
C2MS12-44 Consolidate Navigation Data Messages C2MS 1.0 open
C2MS12-19 Replace Unsolicited Echo with a Separate Message C2MS 1.0 open
C2MS12-11 Add a Message Exchange Pattern (MEP) for a component to forward requests/responses C2MS 1.0 open
C2MS12-2 Data Dictionary Messages C2MS 1.0b1 open
C2MS12-7 Add documentation within the model C2MS 1.0a1 open
C2MS12-4 XML PSM recommended C2MS 1.0b1 open
C2MS12-14 C2MS Database Query (DBQUERY) messages C2MS 1.0 open
COMMONS12-13 Clean up a few issues with the Locations ontology Commons 1.1 open
COMMONS12-7 The definition of aspect needs refinement Commons 1.1 open
OARIS3-17 C2INav Model refers to an old OARIS Common Types package C2INAV 1.0 open
CORBA35-191 BNF changes CORBA 3.0.2 open
CORBA35-195 Bad text in 22.6 mandates Routing for sendc/sendp CORBA 3.0.2 open
CORBA35-607 Add optional/map mapping (and other IDL4 special types) CORBA 3.4 open
C2MS12-51 Refactor "Introduction to Specification" section in front matter of Document C2MS 1.0 open
C2MS12-48 Improve Example Text for Publish Rate C2MS 1.0 open
C2MS12-12 C2MS: Optional Transfer Frame/Packet attributes should be described in schema C2MS 1.0 open
C2MS12-34 Inconsistent Optional/Required Fields C2MS 1.0 open
C2MS12-17 Split ME1 in Simple Service Req/Resp C2MS 1.0 open
C2MS12-10 In message tables, rework the "value" column to allow for fixed values vs. default values C2MS 1.0 open
C2MS12-8 Larger Data Types C2MS 1.0 open
C2MS12-38 Normalize Headers and Text in the new DB Query Messages C2MS 1.0 open
C2MS12-45 Undo Addition of DB Query Messages in 1.1 C2MS 1.0 open
C2MS12-39 Need Review/Documented Explanation of NUM-OF-PROD-SUBTYPE-SUBCATEGORIES C2MS 1.0 open
CPP1117-39 constexpr constructors missing CPP11 1.7 open
CPP1117-38 CORBA::CustomerMarshal, type CPP11 1.7 open
CPP1117-37 Typo CORBA::CustomerMarshal CPP11 1.7 open
C2MS12-49 Align TLM Terms C2MS 1.0 open
C2MS12-40 Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model C2MS 1.0 open
C2MS12-30 Remove the Req/Resp/Pub MEP C2MS 1.0 open
C2MS12-29 Use Semantic Versioning for Version Number of Messages C2MS 1.0 open
C2MS12-27 Remove Superfluous Fields from Header and Envelope C2MS 1.0 open
C2MS12-25 At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency C2MS 1.0 open
C2MS12-24 At Next Major Revision: Order MEs and Fields Consistently C2MS 1.0 open
C2MS12-6 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 open
C2MS12-3 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 open
C2MS12-9 Harmonize Replay TLM and Archive Mnemonic Message Sets C2MS 1.0 open
C2MS12-1 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 open
C2MS12-50 use of brackets not consistent for Subject Elements C2MS 1.0 open
C2MS12-35 Non-sensical Description for PROD-MSGS-TO-SEND C2MS 1.0 open
C2MS12-13 Consider a mechanism to request archived Commands and Events C2MS 1.0 open
CSRM12-3 Informational Update to CSRM Profile Specification CSRM 1.1b1 open
CSRM12-2 Informational Update to CSRM Profile Specification CSRM 1.0 open
CORBA35-441 CORBA section 11 struct PortableGroup::GroupInfo CORBAe 1.0b1 open
CORBA35-438 Section 4.1.18.5 enum should be named CORBA_CompletionStatus CORBA 2.0 open
CORBA35-432 Add CORBATCKind to end of enum list CORBA 2.0 open
CORBA35-428 ODL is erroneous CORBA 2.0 open
CORBA35-426 page 2-30: There is a label "Examples", but no examples CORBA 2.0 open
CORBA35-417 Section 5.5 Interface repository (01) CORBA 2.2 open
CORBA35-411 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 open
CORBA35-416 Section 5.5 Interface repository (02) CORBA 2.2 open
CORBA35-409 Value type ansd Value Box"s single data member name CORBA 2.2 open
CORBA35-404 Section 5.6.2 Repository Id CORBA 2.2 open
CORBA35-405 Clarify the hash code algorithm CORBA 2.2 open
CORBA35-403 Repository Id (02) CORBA 2.2 open
CORBA35-402 Repository Id (03) CORBA 2.2 open
CORBA35-401 Section 5.6.3 Hashing Algorythm CORBA 2.2 open
CORBA35-400 Semantics of computing the hash code.. CORBA 2.2 open
CORBA35-397 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 open
CORBA35-399 Concrete value class CORBA 2.2 open
CORBA35-395 Java mapping example and C++ mapping example CORBA 2.2 open
CORBA35-393 Why is ValueBase a value and not a native type? CORBA 2.2 open
CORBA35-391 Editorial page 8-107 CORBA 2.2 open
CORBA35-386 Can public modifier be applied to value operations? CORBA 2.2 open
CORBA35-374 Can "public" mofifier be applied to value operations? CORBA 2.2 open
CORBA35-349 Minimum CORBA and POA CORBA 2.3 open
CORBA35-357 No typecodes for abstract interfaces CORBA 2.2 open
CORBA35-345 issue with TCPfirewallMechanism CORBA 2.2 open
CORBA35-344 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 open
CORBA35-338 How can we bound the range of invoke ids in the IDL? CORBA 2.3 open
CORBA35-337 It should be possible to have negative invoke ids CORBA 2.3 open
CORBA35-335 Problem: Why is AssociationId a string? CORBA 2.3 open
CORBA35-336 Section number: 4.2.1 CORBA 2.3 open
CORBA35-334 The current text for DialogFlowCtr is for outgoing only CORBA 2.3 open
CORBA35-332 Section 4.3.2.1 Title and text should be changed CORBA 2.3 open
CORBA35-333 There is a difference between the responder and initiator interfaces CORBA 2.3 open
CORBA35-331 Section 4.7.1: RelativeRoundTripPolicy CORBA 2.3 open
CORBA35-329 Section number: 5.2 and other sub-sections CORBA 2.3 open
CORBA35-328 Section number: 5.4.1 CORBA 2.3 open
CORBA35-327 Shouldn't it be typedef string CORBA::ScopedName? CORBA 2.3 open
CORBA35-326 Section number: Fig. 27 CORBA 2.3 open
CORBA35-322 Problem: There is no way to send dialogue data in a continue confirm. CORBA 2.3 open
CORBA35-321 Section number: 5 CORBA 2.3 open
CORBA35-316 Firewall POA Policy does not control access CORBA 2.3 open
CORBA35-320 Section number: 2.3 CORBA 2.3 open
CORBA35-314 new_target CORBA 2.3 open
CORBA35-313 new_callback CORBA 2.3 open
CORBA35-311 Proxified object references CORBA 2.3.1 open
CORBA35-312 How to obtain initial reference to the GIOPProxy object CORBA 2.3.1 open
CORBA35-310 Reusing PASSTHRU CORBA 2.3.1 open
CORBA35-309 Clarification is needed on the passing of credentials CORBA 2.3.1 open
CORBA35-308 Problems with routing and/or traversal of firewalls. CORBA 2.3.1 open
CORBA35-306 Use of InvokeId as the type name for both invoke id and link id. CORBA 2.3.1 open
CORBA35-305 When does a multiassociation TcUse know that it has been finished with? CORBA 2.3.1 open
CORBA35-304 Why one to one association between a TcPduUser and TcPduProvider interface? CORBA 2.3.1 open
CORBA35-303 Specification Translation from ASN to IDL issue CORBA 2.3.1 open
CORBA35-302 TcPdu User and Provider interfaces CORBA 2.3.1 open
CORBA35-301 use of the SSN number in the 1988 TCAP version CORBA 2.3.1 open
CORBA35-274 Firewall FTF Issue: No ene-to-end security for firewall traversal CORBA 2.5 open
CORBA35-242 Which model should ConcurrencyControl support? CORBA 2.0 open
CORBA35-239 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 open
CORBA35-241 Who is responsible for releasing locks in transaction? CORBA 2.0 open
CORBA35-218 interface QueryEvaluator { CORBA 2.0 open
CORBA35-211 CosConsurrencyControl service bug or not? CORBA 2.3.1 open
CORBA35-215 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 open
CORBA35-210 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 open
CORBA35-174 Issue: CSIv2 Identity Assertion CORBA 2.3.1 open
CORBA35-130 Section: 4.2 CORBA 3.0.3 open
CORBA35-129 Section: 4.2 (02) CORBA 3.0.3 open
CORBA35-9 Incorrect mappings for systems exceptions (part A) CORBA 2.0 open
CORBA35-8 Capter 13C: Editorial CORBA 2.0 open
CORBA35-7 Section 13A.2.3: editorial CORBA 2.0 open
CORBA35-6 Section 13A.5.2: Editorial CORBA 2.0 open
CORBA35-4 Duplicate union labels CORBA 2.0 open
CORBA35-5 Changes to ForeignComplexType CORBA 2.0 open
CORBA35-213 Inconsisten IDL in the Minimum CORBA chapter CORBA 2.4.2 open
CORBA35-606 The CCM document component-formal-21-02-04 shall be removed from CORBA 3.4 to become a standalone CCM specification. CORBA 3.4 open
CORBA35-440 Ordering of user exception and return values CORBA 1.2 open
CORBA35-439 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 open
CORBA35-435 Standard ProgramId CORBA 2.0 open
CORBA35-437 VB cannot handle array out-parameters CORBA 2.0 open
CORBA35-434 Section 4.1.12: DICORBA TypeCode::kind CORBA 2.0 open
CORBA35-433 Remove EX_repositoryID readonly property from IForeignException CORBA 2.0 open
CORBA35-431 Return value type of DICORBATypeCode::member_type should be changed CORBA 2.0 open
CORBA35-340 Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation CORBA 2.3 open
CORBA35-420 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 open
CORBA35-214 Correction of CORBA specification (page 18-51) CORBA 2.3.1 open
CORBA35-339 Section number: 3.5.1.1, item 3 CORBA 2.3 open
CORBA35-208 COM/CORBA keywords CORBA 2.2 open
CORBA35-207 Fixed Types in COM CORBA 2.4.2 open
CORBA35-3 COM Sequence changes CORBA 2.0 open
CORBA35-1 Levels of Indirection for passing COM types seem to be missing CORBA 2.0 open
CORBA35-436 What should Automation View accept in bounded sequences? CORBA 2.0 open
CORBA35-430 uuid for DForeignException has an extra 0 CORBA 2.0 open
CORBA35-427 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 open
CORBA35-429 page 2-25 contradicts first sentence of 3rd full para on p 4-106 CORBA 2.0 open
CORBA35-424 boundary violations should cause View to propagate DISP_E_OVERFLOW CORBA 2.0 open
CORBA35-425 page 4-109, section 4.1.5.3: editorial CORBA 2.0 open
CORBA35-423 page 4-129, section 4.1.17.1: retval attribute CORBA 2.0 open
CORBA35-422 page 4-129, section 4.1.17: change term "CORBA proxy" CORBA 2.0 open
CORBA35-421 INSTANCE_Clone does not need an in-parameter CORBA 2.0 open
CORBA35-342 Section number: 3.3.4 and elsewhere CORBA 2.3 open
CORBA35-419 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 open
CORBA35-330 Shouldn't this section really be called TC Service Interface? CORBA 2.3 open
CORBA35-324 Should SIOP version number start with 1.2? CORBA 2.3 open
CORBA35-325 Could SIOP be changed to 7IOP, pronounced "seven-up"? CORBA 2.3 open
CORBA35-300 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 open
CORBA35-323 Section number: 6.2.2 CORBA 2.3 open
CORBA35-298 Missing definition on security tags in the SIOP CORBA 2.3.1 open
CORBA35-299 There is currently no valuetype support in SIOP. CORBA 2.3.1 open
CORBA35-297 Use of PolicyType id CORBA 2.3.1 open
CORBA35-264 Lifecycle Key type definition CORBA 1.2 open
CORBA35-263 Stream contexts and internalization CORBA 1.2 open
CORBA35-262 Start and end of context tags CORBA 1.2 open
CORBA35-261 Definition of stream portability CORBA 1.2 open
CORBA35-260 Multiple objects on a stream CORBA 1.2 open
CORBA35-259 Timeout while locking CORBA 1.2 open
CORBA35-258 Communication failure issue CORBA 1.2 open
CORBA35-257 Getting the thread ID in a non-transactional lock request CORBA 1.2 open
CORBA35-256 Freeing of locks at the end of a transaction CORBA 1.2 open
CORBA35-255 Coordinator remembering LockCoordinator CORBA 1.2 open
CORBA35-254 Input values for "which" arg of non-trans. LockCoordinator CORBA 1.2 open
CORBA35-253 Using local thread identification for concurrency CORBA 1.2 open
CORBA35-252 Common format on stream CORBA 1.2 open
CORBA35-251 CosGraphs::deep CORBA 1.2 open
CORBA35-250 performing a compound copy of relationship CORBA 1.2 open
CORBA35-246 CosCompoundExternalization Service CORBA 1.2 open
CORBA35-245 CosCompoundExternalization Service (2) CORBA 1.2 open
CORBA35-244 CosCompoundExternalization Service (3) CORBA 1.2 open
CORBA35-240 Internalizing roles-IDL optimization CORBA 2.1 open
CORBA35-243 Purpose of related LockSet CORBA 2.0 open
CORBA35-238 QueryCollection::Collection -- membership scoping CORBA 1.2 open
CORBA35-237 QueryCollection::Collection -- Adding multiple elements CORBA 1.2 open
CORBA35-235 QueryCollection::Collection -- finding index CORBA 1.2 open
CORBA35-236 Query Collection::Collection -- Sharing State CORBA 1.2 open
CORBA35-234 QueryCollection::Collection -- Iterator Position Invalid CORBA 1.2 open
CORBA35-233 QueryCollection::Collection -- iterator updating CORBA 1.2 open
CORBA35-231 QueryCollection::Collection -- reset() exceptions CORBA 1.2 open
CORBA35-232 QueryCollection::Collection -- destroy methods CORBA 1.2 open
CORBA35-230 QueryCollection::Collection -- next_n() CORBA 1.2 open
CORBA35-229 QueryCollection::Collection -- keyed collections CORBA 1.2 open
CORBA35-228 Questions on CosQuery::QueryableCollection interfaces CORBA 1.2 open
CORBA35-226 Updating information via query iterators CORBA 1.2 open
CORBA35-227 Use of MD5 on arguments CORBA 1.2 open
CORBA35-225 How do iterators handle changing of the data they are pointing at CORBA 1.2 open
CORBA35-224 Clarification request for section 11.1.5 CORBA 1.2 open
CORBA35-222 retrieve_element CORBA 1.2 open
CORBA35-223 Definition of NULL in datafiles without NULL as a concept CORBA 1.2 open
CORBA35-221 Delegating iterator functionality to the RDBMS CORBA 1.2 open
CORBA35-220 Query language for operations CORBA 1.2 open
CORBA35-219 OQS relation to POS CORBA 1.2 open
CORBA35-217 Malformed PropertyName CORBA 1.2 open
CORBA35-216 WWW Form output CORBA 1.2 open
CORBA35-209 Compiler being able to translate from OMG-IDL into ANSI CORBA 1.2 open
CPP1117-36 Change union API misuage exception CPP11 1.7 open
CORBA35-446 Add CDR marshaling support for new IDL4 types (e.g. maps, bitset, bitmask) CORBA 3.3 open
CORBA35-175 Polymorphic Valuetypes and the DII CORBA 2.3.1 open
CORBA35-176 DynValue & custom valuetypes CORBA 2.3.1 open
CORBA35-177 Custom Value Marshaling Issue CORBA 2.3.1 open
CORBA35-178 Potential deadlock with POA::deactivate_object() CORBA 2.3 open
CORBA35-296 BiDir GIOP Policy Clarification CORBA 2.4.1 open
CORBA35-315 Firewall Traversal algorithm CORBA 2.3 open
CORBA35-317 Outgoing local port in Bi-directional IIOP CORBA 2.3 open
CORBA35-318 Bi-Directional GIOP: Masquerade security issue needs to be more explicit CORBA 2.3 open
CORBA35-319 Bi-Directional GIOP: which connections may be used? CORBA 2.3 open
CORBA35-350 ValueHelper Interface issue CORBA 2.2 open
CORBA35-352 Status of hashed repository IDs CORBA 2.2 open
CORBA35-356 TypeCode complexity for value types CORBA 2.2 open
CORBA35-379 Marshaling engine issue CORBA 2.2 open
CPP1117-35 No external annotation mapping CPP11 1.7 open
CPP1117-34 No mapping for min/max/range annotations CPP11 1.7 open
CPP1117-33 Clarify implicit default CPP11 1.7 open
CORBA35-347 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 open
CORBA35-348 The values of these tags need to be assigned CORBA 2.2 open
CORBA35-353 OBV init CORBA 2.2 open
CORBA35-354 CodeBase interface uses undefined type CORBA 2.2 open
CORBA35-355 Memory Management for Value Factories Unspecified CORBA 2.2 open
CORBA35-360 OBV TypeCode parameters wrong CORBA 2.2 open
CORBA35-361 C++ boxed value member clashes CORBA 2.2 open
CORBA35-362 Custom marshalling support for IDL fixed type CORBA 2.2 open
CORBA35-363 Default constructor for Java values CORBA 2.2 open
CORBA35-364 Boxed values need extension to write_Value call CORBA 2.2 open
CORBA35-365 TypeCodes for values CORBA 2.2 open
CORBA35-366 Forward declaration of value boxes CORBA 2.2 open
CORBA35-367 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 open
CORBA35-368 OBV spec inefficient for dending large number of small objects CORBA 2.2 open
CORBA35-369 OBV C++ problem with "supports" CORBA 2.2 open
CORBA35-370 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 open
CORBA35-371 TypeCodes defined in section 5.8.2 CORBA 2.2 open
CORBA35-372 CDR Streams CORBA 2.2 open
CORBA35-373 OBV "chunking" CORBA 2.2 open
CORBA35-376 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 open
CORBA35-375 Typo on page 8-107 of OBV specification CORBA 2.2 open
CORBA35-390 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 open
CORBA35-392 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 open
CORBA35-394 Section 7.3.10 Value Factories CORBA 2.2 open
CORBA35-396 Section 7 C++ Language mapping CORBA 2.2 open
CORBA35-398 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 open
CORBA35-406 Type code issue CORBA 2.2 open
CORBA35-407 Missing member_kind and member_tc CORBA 2.2 open
CORBA35-408 describe_value() operation issue CORBA 2.2 open
CORBA35-410 p.6.68 boxed values of complex types map to same type CORBA 2.2 open
CORBA35-413 Can Value type inherit from Value Box type? CORBA 2.2 open
CORBA35-192 rules for marshalling ValueBoxes CORBA 3.0.2 open
CORBA35-193 Problem with ServerRequestInterceptor::receive_request and DSI CORBA 3.0.2 open
CORBA35-194 restriction of where a valuetype chunk can end CORBA 3.0.2 open
CPP1117-32 Default annotation CPP11 1.7 open
CORBA35-197 Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 CORBA 3.0 open
CORBA35-198 Spec doesn't make clear what is valid mix of policies and what is invalid CORBA 3.0 open
CORBA35-200 How does DynValue handle derived valuetypes? CORBA 3.0 open
CORBA35-202 CORBA 3.02, page 11-25, section 11.3.6 CORBA 3.0.2 open
CORBA35-203 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 open
CORBA35-204 valuetypes and local interfaces CORBA 3.0.2 open
CORBA35-206 Unclear and possibly harmful consequences of mandatory annotation definitions CORBA 3.1.1 open
CORBA35-212 CosExternaliazation Service (bug?) CORBA 2.4.2 open
CORBA35-266 use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous CORBA 2.5 open
CORBA35-267 Bi-directional connections considered volatile at connection acceptor side CORBA 2.5 open
CORBA35-268 Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY CORBA 2.5 open
CORBA35-269 How many BI_DIR_GIOP_OFFER service contexts are allowed CORBA 2.5 open
CORBA35-270 connection_complete field of the FirewallPathRespContext is under specified CORBA 2.5 open
CORBA35-271 Expected behavior of a non-conformant implementation CORBA 2.5 open
CORBA35-272 Targets of Export and Offer Policies incompletely specified CORBA 2.5 open
CORBA35-273 Processing of NegotiateSession messages at various stages of connection set CORBA 2.5 open
CORBA35-275 What BiDirIds shall be sent over what bidirectional connections? CORBA 2.5 open
CORBA35-276 Interplay of Contexts allowed in NegotiateSession messages too ill-defined CORBA 2.5 open
CORBA35-277 Firewall Issue: Random BiDirIds can't be used for persistent POAs CORBA 2.5 open
CORBA35-278 Firewall Issue: Connection over which BiDir offers are sent is unspecified CORBA 2.5 open
CORBA35-279 Firewall Issue: Response to failed BiDir challenge is unclear CORBA 2.5 open
CORBA35-280 Firewall issue - Number of BiDirIds in a BiDirOffer CORBA 2.5 open
CORBA35-281 Implications about BiDirIds CORBA 2.5 open
CORBA35-282 paragraph limits use of BiDirOfferContext CORBA 2.5 open
CORBA35-283 Negotiate Session Message Issues CORBA 2.5 open
CORBA35-284 CodeSet issue (05) CORBA 2.5 open
CORBA35-285 CodeSet issue (04) CORBA 2.5 open
CORBA35-286 CodeSet issue (03) CORBA 2.5 open
CORBA35-287 CodeSet issue (02) CORBA 2.5 open
CORBA35-288 CodeSet issue (01) CORBA 2.5 open
CORBA35-289 GIOP version 2.0 issue CORBA 2.5 open
CORBA35-290 Discrepancy in the changes proposed to CSIIOP and CSI modules CORBA 2.5 open
CORBA35-291 Bidirectional Policy insufficient for persistent objects CORBA 2.5 open
CORBA35-292 Server Authentication CORBA 2.5 open
CORBA35-293 Negotiation Session message is unwieldy CORBA 2.5 open
CORBA35-294 Negotiate Session Message Orientation CORBA 2.5 open
CORBA35-295 MAIN_THREAD_MODEL questions CORBA 2.4.1 open
CORBA35-442 The use of Full Services definitions in CORBA/e spec CORBAe 1.0b1 open
CPP1117-31 Apply IDL/C++ formatting to code in text CPP11 1.7 open
CPP1117-30 Remove semi colon after namespace closure CPP11 1.7 open
CPP1117-29 Destructors should be override CPP11 1.7 open
CSRM12-1 xmi profile CSRM 1.0b2 open
CORBA35-447 Add support for IDL4 int8/uint8/map/bitset/bitfield/bitmask CORBA 3.4 open
CORBA35-172 Implications of any/valuetype marshalling CORBA 2.4.1 open
CORBA35-69 69.3 AssemblyFactory Interface CORBA 3.0 open
CORBA35-65 [CCM] Interface Repository Metamodel CORBA 3.0 open
CORBA35-61 CCM IDL style inconsistency CORBA 3.0.2 open
CORBA35-60 multiple lifetime policies declaration issue CORBA 3.0.2 open
CORBA35-58 CCM spec: insufficient examples of component attributes CORBA 3.0.2 open
CORBA35-53 CCM Spec: attributes are listed in the ports section? CORBA 3.0.2 open
CORBA35-2 Section 13C.1.3 Editorial CORBA 2.0 open
CORBA35-54 issue on component supporting abstract interfaces CORBA 3.0.2 open
CORBA35-51 portability of CCM descriptors CORBA 3.0.2 open
CORBA35-173 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 open
CORBA35-48 The association of entity component primary key and PSS key is unclear CORBA 3.0.2 open
CORBA35-45 Generic connectivity for Receptacles, Emitters, Publishers CORBA 3.0.3 open
CORBA35-41 "supports" keyword CORBA 3.0.3 open
CORBA35-40 Contradictory sections in the CCM and Lightweight CCM specifications CORBA 3.0.3 open
CORBA35-29 CCMHome should have a get_container method CORBA 3.0.2 open
CORBA35-307 Traversal algorithm not sufficient CORBA 2.3.1 open
CORBA35-341 Section number: 3.3.4 make factory creation operations conform to the IDL CORBA 2.3 open
CORBA35-343 Title does not cover the use of SS7 as signaling transpor CORBA 2.3 open
CORBA35-346 passthrough connection CORBA 2.2 open
CORBA35-351 "Tool" issue for IDL compilers too complex CORBA 2.2 open
CORBA35-359 P 5-44: use of base type CORBA 2.2 open
CORBA35-358 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 open
CORBA35-377 Narrowing from abstract interfaces CORBA 2.2 open
CORBA35-378 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 open
CORBA35-380 No portable way to obtain list of type safe repository IDs CORBA 2.2 open
CORBA35-381 Keyword identifiers (04) CORBA 2.2 open
CORBA35-382 Keyword Identifiers(03) CORBA 2.2 open
CORBA35-383 Keyword identifiers (02) CORBA 2.2 open
CORBA35-384 Keyword identifiers (01) CORBA 2.2 open
CORBA35-385 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 open
CORBA35-387 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 open
CORBA35-388 Editorial: p 5-50 CORBA 2.2 open
CORBA35-389 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 open
CORBA35-412 New lexical type - Keyword Identifie CORBA 2.2 open
CORBA35-414 "Safe" keyword identifier issue CORBA 2.2 open
CORBA35-38 add a sequence of CCMHome typedef sequence CCMHomes; CORBA 3.1 open
CORBA35-39 The D&C IDL part doesn't match 06-04-02. CORBA 3.0.3 open
CORBA35-110 NVList Section: 7.5 CORBA 3.0.3 open
CORBA35-113 Page: 21-5 CORBA 3.0.3 open
CORBA35-114 Section: Appendix A CORBA 3.0.3 open
CORBA35-115 Section: 21.3.14.11 CORBA 3.0.3 open
CORBA35-116 Section: 4.5.2 CORBA 3.0.3 open
CORBA35-119 Section: 11.3.9.16 CORBA 3.0.3 open
CORBA35-121 Page: 21-43 CORBA 3.0.3 open
CORBA35-122 Section: 22.11.1 CORBA 3.0.3 open
CORBA35-123 Section: 22.16/ CORBA 3.0.3 open
CORBA35-124 Section: 11.3.9 CORBA 3.0.3 open
CORBA35-125 Section: 21.4.3.1 CORBA 3.0.3 open
CORBA35-126 Section: 21.9.1 CORBA 3.0.3 open
CORBA35-127 Section: 21.7 CORBA 3.0.3 open
CORBA35-128 update the spec to not used anonymous types CORBA 3.0.3 open
CORBA35-131 Section: 13.6.2 CORBA 3.0.3 open
CORBA35-132 Section: 7.4 CORBA 3.0.3 open
CORBA35-141 struct PolicyValue CORBA 3.0.3 open
CORBA35-145 Third line of 23.1.3.4, ACTIVE must be bold CORBA 3.0.3 open
CORBA35-146 Proposal to change PortableInterceptor::AdapterState to a real enum CORBA 3.0.3 open
CORBA35-147 Proposal to change PortableInterceptor::ReplyStatus to a real enum CORBA 3.0.3 open
CORBA35-148 Section: 15.4.2/16.4.1 CORBA 3.0.3 open
CORBA35-150 Section: 21.3.13 CORBA 3.0.3 open
CORBA35-152 16.10 lists register_initial_reference CORBA 3.1 open
CORBA35-153 add interface ORB { Object string_to_object ( in wstring str ); }; CORBA 3.0.3 open
CORBA35-154 add CORBA::ORB::arg_list CORBA 3.0.3 open
CORBA35-155 Section 13.7 ServiceContext CORBA 3.0.3 open
CORBA35-156 Section: 21.7.3 CORBA 3.0.3 open
CORBA35-157 Section: 4.8.1 CORBA 3.0.3 open
CORBA35-158 move struct to IOP module CORBA 3.0.3 open
CORBA35-159 Add create_policy with just the type as argument CORBA 3.1 open
CORBA35-160 context should be local interface CORBA 3.1 open
CORBA35-162 interface ORB should be local CORBA 3.0.3 open
CORBA35-163 Make anonymous types illegal CORBA 3.0.3 open
CORBA35-180 Appendix A CORBA 3.0.3 open
CORBA35-181 Section: 4.3.13 CORBA 3.0.3 open
CORBA35-183 The POA state inactive is not used consistent. CORBA 3.0.3 open
CORBA35-184 argument of the set_servant call has a small typo CORBA 3.0.3 open
CORBA35-185 change in the POAManager CORBA 3.0.3 open
CORBA35-186 Add a typedef for the POAManager id CORBA 3.0.3 open
CORBA35-187 methods on the POA CORBA 3.0.3 open
CORBA35-205 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 open
CORBA35-443 Add CompressorId for zstd CORBA 3.4 open
CORBA35-444 Extend InvalidName exception CORBA 3.4 open
CORBA35-445 Replace Cookie with a string and use IDL map CORBA 3.4 open
CORBA35-448 ConfigValues to a std map CORBA 3.4 open
CORBA35-28 CCMHome should have a get_components method CORBA 3.0.2 open
CORBA35-26 HomeConfigurator should not extend CCMHome CORBA 3.0.2 open
CORBA35-24 Generic port connections CORBA 3.0.2 open
CPP1117-28 Add && setter CPP11 1.6b1 open
CPP1117-27 std::optional should be passed as const& CPP11 1.6b1 open
CPP1117-26 Formatting c++/idl in text CPP11 1.6b1 open
CPP1117-24 Fix bitset mapping CPP11 1.6b1 open
C2INAV13-3 Enumeration value ESTIMATED used twice in the same package C2INAV 1.2b1 open
C2INAV13-2 Enumeration value ESTIMATED used twice in the same package C2INAV 1.2b1 open
C2INAV13-1 C2INav Model refers to an old OARIS Common Types package C2INAV 1.2 open
CPP13-82 Improve wording CPP 1.3 open
CPP1116-38 Improve wording CPP11 1.6b1 open
ABPSC-33 URLs, URIs and namespaces for CMMN 1.1 XSDs are not aligned CMMN 1.1 open
LCC13-6 LCC ontologies and reference data should be refactored to use the Commons library COMMONS 1.0 open
CORBA35-247 $issue.summary CORBA 1.2 open
CORBA35-248 $issue.summary CORBA 1.2 open
CORBA35-249 $issue.summary CORBA 1.2 open
CORBA35-199 messaging router issue CORBA 3.0 open
CORBA35-201 module SendingContext CORBA 3.0.3 open
CORBA35-196 What is the RSC when using a PersistentPoller CORBA 3.0.1 open
CORBA35-188 Codec Interface Deficiencies CORBA 3.0.3 open
CORBA35-189 An extension of IOR to protect target objects Nature CORBA 3.0.3 open
CORBA35-190 Mapping from -ORBxxx to Java properties does not work for -ORBInitRef CORBA 3.0.2 open
CORBA35-182 CORBA 3.0.3 ch. 3.4 OMG IDL Grammar CORBA 3.0.3 open
CORBA35-179 Code Set Conversion on Operations CORBA 3.0.3 open
CORBA35-168 ForwardRequest is impossible to detect in clients CORBA 2.6.1 open
CORBA35-171 Avoiding RSC/TSC copy on server side CORBA 2.4.1 open
CORBA35-170 Proposal for extension to CosNaming CORBA 2.6 open
CORBA35-169 New issue: ForwardRequest() CORBA 2.6 open
CORBA35-164 rule (85) is misplaced CORBA 3.1 open
CORBA35-167 processing TaggedComponents within an IOR CORBA 3.0 open
CORBA35-165 Bad quotes and imported dot CORBA 3.1 open
CORBA35-166 missing document title CORBA 3.1 open
CORBA35-161 Redundant bullet CORBA 3.2 open
CORBA35-151 There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle CORBA 3.1 open
CORBA35-142 Section: Part 2, Chapter 11 - MIOP CORBA 3.1 open
CORBA35-144 definition of Invalid Policies changed CORBA 3.1 open
CORBA35-143 mention of (deprecated) function get_implementation removed from text CORBA 3.1 open
CORBA35-149 Section: 13.6.10.1 CORBA 3.0.3 open
CORBA35-140 Two typo's in Annex A.4 CORBA 3.1 open
CORBA35-135 Moving *Seq typedefs into ORB chapter CORBA 3.0.3 open
CORBA35-134 Minor code ambiguity CORBA 3.0.3 open
CORBA35-133 Typo in sections 22.10.1.1 and 22.10.1.2 CORBA 3.0.3 open
CORBA35-120 FullInterfaceDescription and base_interfaces question CORBA 3.0.3 open
CORBA35-117 Allowing mutual recursion for IDL structs - clarification needed CORBA 3.0.3 open
CORBA35-118 CORBA Exceptions CORBA 3.0.3 open
CORBA35-111 Page: 7-7 CORBA 3.0.3 open
CORBA35-112 Page: 9-1 CORBA 3.0.3 open
CORBA35-106 69.8.2.8 The simple Element, page 69-538 CORBA 3.0 open
CORBA35-107 Section: Chapter 9, Chapter 5 CORBA 3.0.3 open
CORBA35-108 Section: Chapter 11 CORBA 3.0.3 open
CORBA35-109 Allowing Mutual Recursion for IDL Structures CORBA 3.0.3 open
CORBA35-99 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 open
CORBA35-100 69.3 Software Package Descriptor CORBA 3.0 open
CORBA35-101 Add the capability to define a component artifact property CORBA 3.0 open
CORBA35-103 69.8.2.9 The sequence Element CORBA 3.0 open
CORBA35-102 Test Property - add a test property definition to the properties DTD CORBA 3.0 open
CORBA35-104 69.8.2.3 The choices Element, page 69-537 CORBA 3.0 open
CORBA35-105 69.8.2.7 The range Element, pages 69-537/538 CORBA 3.0 open
CORBA35-92 Component Artifact Dependency CORBA 3.0 open
CORBA35-96 69.3.2.25 The propertyfile Element, page 69-482 CORBA 3.0 open
CORBA35-93 69.3.2.2 The author Element, page 69-474 CORBA 3.0 open
CORBA35-95 69.3.2.14 The idl Element, page 69-478 CORBA 3.0 open
CORBA35-94 Descriptor CORBA 3.0 open
CORBA35-98 69.8.2.7 The code Element, pages 69-474 CORBA 3.0 open
CORBA35-97 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 open
CORBA35-67 Checking XML DTD elements related to the trader service CORBA 3.0 open
CORBA35-68 Description for the impltype Element? CORBA 3.0 open
CORBA35-70 Uses Relationships CORBA 3.0 open
CORBA35-71 Device Artifact Dependency CORBA 3.0 open
CORBA35-72 Dependency on D+C FTF CORBA 3.0.3 open
CORBA35-64 A new exception specification is needed for CCM2Context::req_passivate() CORBA 3.0 open
CORBA35-62 Derived component supported interface restriction (formal/2002-06-65) CORBA 3.0 open
CORBA35-63 Issue on the description of the consumesidentifier element CORBA 3.0 open
CORBA35-66 Using Configurator on CCMHome or any CORBA objects? CORBA 3.0 open
CORBA35-55 Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3 CORBA 3.0.2 open
CORBA35-56 Section 6.4.5.10 (page 6-26) CORBA 3.0.2 open
CORBA35-59 3.2.7 Compositions with Managed Storage CCM 3.0 open
CORBA35-57 Section 6.4.5.52 (page 6-38) CORBA 3.0.2 open
CORBA35-52 'local executor mapping' CORBA 3.0.2 open
CORBA35-50 EnterpriseComponent should have a get_servant method CCM 3.0 open
CORBA35-44 EnterpriseComponent should have a set_persistent_object method CORBA 3.0.3 open
CORBA35-43 HomeExecutorBase should have a set_context method CORBA 3.0.3 open
CORBA35-46 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA35-47 EnterpriseComponent should have a get_servant method CORBA 3.0.2 open
CORBA35-49 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA35-42 add some feature to let an assembly look like a monolithic compoment CORBA 3.0.3 open
CORBA35-22 Interface Introspection CORBA 3.0.2 open
CORBA35-27 Session2Context interface CORBA 3.0.2 open
CORBA35-16 page 1-20 and page 1-21 - editorial CORBA 3.0.2 open
CORBA35-20 Change new GIOP Negotiate Session Message to Firewall Specific CORBA 3.0.2 open
CORBA35-19 GIOP Conformance and Interceptors CORBA 3.0.2 open
CORBA35-18 context interface for home implementation CORBA 3.0.2 open
CORBA35-17 page 1-20 the description of the get_connection operation CORBA 3.0.2 open
CORBA35-21 CodeSet and CSIv2 Negotitaion CORBA 3.0.2 open
CORBA35-10 valuetype fragmentation ambiguous CORBA 3.0.2 open
CORBA35-11 Clarification on multi-threaded codeset negotiation CORBA 3.0.2 open
CORBA35-12 15.3.3 - codesets must be "explicitly defined" CORBA 3.0.2 open
CORBA35-13 [Components] Contradiction between IDL and Interface Repository concerning CORBA 3.0.2 open
CORBA35-14 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 open
CORBA35-15 page 1-20 second bullet of the description of the disconnect operation CORBA 3.0.2 open
CPP11-267 Extend Union mapping CPP 1.3 open
DDS4CCM11-18 Editorial corrections CCCMP 1.0 open
DDS4CCM11-17 Use of symbolic constant as string or sequence bound CCCMP 1.0 open
DDS4CCM11-16 Typos at figure 8.6 Constant example CCCMP 1.0 open
CORP-10 Support alternative way of modeling single dimension CORBAArray CORP 1.0b1 open
CORP-9 Use of expression as sequence/array bound CORP 1.0b1 open
CORP-8 Missing support for IDL "native" CORP 1.0b1 open
CCCMP-16 Bounded string attribute of struct/union/valuetype/interface is not mapped CCCMP 1.0 open
CR-154 Clarify semantics of None Event Listeners CMMN 1.1 open
CCCMP-15 Extended UML metamodel derivations of <> CCCMP 1.0 open
CR-153 Inconsistent spelling of color attributes in text, MM and XSD CMMN 1.1 open
CR-152 An Initial transition can't contain any trigger/event CMMN 1.1 open
CR-151 autoComplete doesn't take into account the event listeners CMMN 1.1 open
CR-150 Figure 7.4 'CMMN Shape' shows attribute isExpanded instead of isCollapsed CMMN 1.1 open
CR-148 Wrong manual activation default and missing defaults for ManualActivationRules, RequiredRules and RepetitionRules without condition CMMN 1.1 open
CR-149 Name missmatch between Table 5.51 and MM/XSD for condition of RequiredRules CMMN 1.1 open
CR-146 Process Task and Case Task should have performer defined CMMN 1.1 open
CR-147 Allow the possibility to define multiple standard events for an onPart CMMN 1.1 open
CTS213-13 Faulty CTS2 1.1 wsdl files CTS2 1.2 open
COLL-16 semantics of boolean iterator.next(out thing) ... COLL 1.0b1 open
CWM12-17 21.5 SQL-99 Data Types CWM 1.1 open
CWM12-71 Review the semantics of existing attribute types that are also CWM classes CWM 1.0 open
CWM12-57 CWM should consider generating XML Schemas, in both XMI 1.x and XMI 2.0 CWM 1.0 open
CWM12-70 Add a representation for sequence to CWM relational package CWM 1.0 open
CWM12-56 Make ChangeRequest useful CWM 1.0 open
CWM12-22 Location: 12.1 Overview CWM 1.1 open
CWM12-76 CWM Object resource package does not provide support for exceptions CWM 1.0 open
CWM12-7 Location: 5.4 CWM 1.1 open
CWM12-11 Annex F: Acknowledgements CWM 1.1 open
CWM12-64 The XML package should be revised/extended to represent XML schema metadata CWM 1.0 open
CWM12-39 Location: 3 Normative References -- OCL CWM 1.1 open
CWM12-16 21.6 Type Mapping Examples CWM 1.1 open
CWM12-14 Annex A: References CWM 1.1 open
CWM12-5 Add features for 11404 aggregates CWM 1.1 open
CWM12-47 TaggedValue CWM 1.1 open
CWM12-53 Modeling and packaging guidelines CWM 1.0 open
CWM12-54 Rationalize 'Measurement' CWM 1.0 open
CWM12-50 SQLParameter CWM 1.1 open
CWM12-42 Introduction - references CWM 1.1 open
CWM12-26 Location: 10.3.16 SQLIndex CWM 1.1 open
CWM12-9 Introduction, Page XVII CWM 1.1 open
CWM12-2 The XML features should support current XML data structures CWM 1.1 open
CWM12-38 Location: 4 Abbreviations and Conventions - ODBC CWM 1.1 open
CWM12-1 Add support for flat and nested N-dimensional arrays CWM 1.1 open
CWM12-41 Location: 3 Normative References CWM 1.1 open
CWM12-24 10.3.18 SQLParameter CWM 1.1 open
CWM12-69 Inconsistencies caused by changing Expression etc from Data Types to Classe CWM 1.0 open
CWM12-52 Warehouse processes missing physical information CWM 1.0 open
CWM12-27 Location: 10.2.8 Procedures CWM 1.1 open
CWM12-61 Inadequate support for Organizational Structures CWM 1.0 open
CWM12-45 figure 6, page 212 CWM 1.1 open
CWM12-21 10.3.20 SQLStructuredType - referencingColumn CWM 1.1 open
CWM12-34 4 Abbreviations and Conventions - SQL-92 and SQL-99 CWM 1.1 open
CWM12-20 13.3.9 Schema CWM 1.1 open
CWM12-58 CWM should consider generating XMI 1.2 DTDs CWM 1.0 open
CWM12-48 Invalid explicit references for some 'association generalizations' in the CWM 1.1 open
CWM12-73 consider changing DeployedComponent from being subclass of Core::Package CWM 1.0 open
CWM12-65 Generic Data Mining metamodel issue CWM 1.0 open
CWM12-3 Support the full set of 11404 aggregates. CWM 1.1 open
CWM12-31 Location: 10.2.4 Structured Types and Object Extension , Figure 10.5 CWM 1.1 open
CWM12-12 Annex D: Legal Information CWM 1.1 open
CWM12-60 CWM should consider using MOF 1.4 for it's metamodel CWM 1.0 open
CWM12-66 The metamodel for DTD should be reviewed CWM 1.0 open
CWM12-51 We only need one COBOL Data Division metamodel. CWM 1.1 open
CWM12-33 Location: 10.1 Overview CWM 1.1 open
CWM12-30 Location: 10.2.6 Index CWM 1.1 open
CWM12-19 10.4.2 ColumnRefStructuredType CWM 1.1 open
CWM12-18 13.1 Overview CWM 1.1 open
CWM12-13 Annex C: Glossary CWM 1.1 open
CWM12-55 Predefined' values not defined in metamodel CWM 1.0 open
CWM12-59 Component Re-use unclear CWM 1.0 open
CWM12-62 Make it easier to interchange UML Models CWM 1.0 open
CWM12-46 Parameter CWM 1.1 open
CWM12-32 Location: 10.2.4 Structured Types and Object Extensions CWM 1.1 open
CWM12-29 Location: 10.3.15 SQLDistinctType CWM 1.1 open
CWM12-77 supplierDependency reference is missing from ModelElement CWM 1.0 open
CWM12-68 Description, Document, ResponsibleParty should be made subtypes of Comment CWM 1.0 open
CWM12-37 Location: 3 Normative References - ISO/IEC 9075:2003 Database language SQL CWM 1.1 open
CWM12-35 Location: 10.1 Overview CWM 1.1 open
CWM12-49 page 9-276/Section: 9.3.22 of ptc/2002-01-02 -- CWM issue CWM 1.1 open
CWM12-23 10.3.20 SQLStructuredType CWM 1.1 open
CWM12-74 package may fail to permit definition of transformations CWM 1.0 open
CWM12-75 XML Schema package issue CWM 1.0 open
CWM12-78 XML metamodel should be based on W3C XML Information Set CWM 1.0 open
CWM12-8 Add syntax type to the metamodel. CWM 1.1 open
CWM12-15 Annex B: Compatibility with other Standards CWM 1.1 open
CWM12-6 value "name" attribute of ModelElement CWM 1.1 open
CWM12-4 Add datatype generators CWM 1.1 open
CWM12-63 Practical changes to Contact metamodel CWM 1.0 open
CWM12-67 All OCL sections should be reviewed to ensure that they are complete CWM 1.0 open
CWM12-40 Location: 4 Abbreviations and Conventions CWM 1.1 open
CWM12-36 Location: 4 Abbreviations and Conventions - SQL CWM 1.1 open
CWM12-44 Foreword CWM 1.1 open
CWM12-43 formal/03-03-02 CWM 1.1 open
CPP13-1 1.16.3 Extraction from any CPP 1.1 open
CWM12-10 5.4 datatype attributes don't incorporate the features of 11404 datatype CWM 1.1 open
CWM12-72 Identify precise CWM definition to which interchange doc. conforms CWM 1.0 open
CWM12-28 Location: 10.3.14 SQLDataType CWM 1.1 open
CWM12-25 10.3.17 SQLIndexColumn CWM 1.1 open
COLL-15 IDL does not match COLL 1.0b1 open
COLL-14 Suggested changes to Collection spec. COLL 1.0b1 open
COLL-13 Failure behavior for iterator operations COLL 1.0b1 open
CPP13-81 Practical problem with DII using Request Pseudo Object CPP 1.0b1 open
COLL-9 Interface OrderedCollection COLL 1.0b1 open
COLL-8 Page 17-29: OrderedCollection.remove_element_at_position COLL 1.0b1 open
COLL-7 Page 17-26: Collection.all_elements_do COLL 1.0b1 open
COLL-6 page 17-23: Collection.remove_all COLL 1.0b1 open
COLL-5 Collection.add_element COLL 1.0b1 open
COLL-4 Map/SortedMap COLL 1.0b1 open
COLL-3 CORBAservices (editorial page 17-74, 17-75) COLL 1.0b1 open
COLL-2 CORBAservices (editorial page 17-71 to 17-73) COLL 1.0b1 open
COLL-1 Error in CosCollection information COLL 1.0b1 open
CORP-1 Section: 3.5.19 - 3.5.20 CORP 1.0b1 open
CCCMP-3 Section 9 of UML Profile for CORBA and CCM CCCMP 1.0 open
CCCMP-2 Section: 8.2.1 - 2 CCCMP 1.0 open
CCCMP-1 Section: 8.1.2 CCCMP 1.0 open
CCCMP-4 Inconsistent capitalization of <> CCCMP 1.0 open
CCMP-1 definition of the stereotype CORBAPrimaryKey CCMP 1.0b1 open
CCMP-3 Facet and Receptacles (ports) CCMP 1.0b1 open
CCMP-2 The (IDL) definition of the example is not correct CCMP 1.0b1 open
CCMP-4 Event ports CCMP 1.0b1 open
CCMP-6 Association needed CCMP 1.0b1 open
CCMP-5 Figure6: associations described Event ports have to be composite associatio CCMP 1.0b1 open
CSAR-1 Text and Java API differ on return value for seacrhChemicalElements method CSAR 1.0 open
CURR11-21 Place maximums on wstrings for interoperability CURR 1.0 open
CURR11-15 Add interfaces to DTime properly handle the DAmountOfTime difference inter CURR 1.0 open
CURR11-17 Improve text in specification of of DAmountOfTime CURR 1.0 open
CURR11-16 Support millisecond precision in DAmountOfTime CURR 1.0 open
CURR11-20 Changing RoundType.DONT_ROUND CURR 1.0 open
CURR11-19 Add ability to clone Money CURR 1.0 open
CURR11-23 Remove Depedence in FBCCurrency of CBO::DDecimal CURR 1.0 open
CURR11-22 Remove Dependence in FBCCurrency of CBO::DTime CURR 1.0 open
CURR11-18 Remove dependence on a specific version of the ISO 4217 standard CURR 1.0 open
CURR11-8 : Change name of interface to CBO::Decima CURR 1.0 open
CURR11-7 Corrections to the equals/setEquals interfaces of DTime CURR 1.0 open
CURR11-6 Improve DTime exception handling CURR 1.0 open
CURR11-14 Add interface to DTime CURR 1.0 open
CURR11-13 Clarification required on setYear of the DTime interface CURR 1.0 open
CURR11-12 support to set precision to something other than milliseconds CURR 1.0 open
CURR11-5 describe how the individual components should be accessed CURR 1.0 open
CURR11-4 Description of Exception handling semantics CURR 1.0 open
CURR11-3 Add text for DTime and DDecimal from CBO submission into Currency spec. CURR 1.0 open
CURR11-11 : Change name of interface to CBO::Time CURR 1.0 open
CURR11-10 Add interfaces to DDecimal CURR 1.0 open
CURR11-9 Clarify the equality method of DDecimal CURR 1.0 open
CURR11-2 The idl for CBO::DTime needs the method: long getYear() CURR 1.0 open
CURR11-1 Clairfy comparisons of two CBO::Ddecimal values on equality CURR 1.0 open
C2WSDL12-1 Section: 4.1.9 SOAP Binding C2WSDL 1.2 open
COAS-3 GCPR issue: Asynchronous COAS COAS 1.0 open
COAS-2 GCPR Project issue: Delivering Observation Data COAS 1.0 open
COAS-1 new conformance classes and the Naming Service COAS 1.0b1 open
COAS-6 GCPR issue: Updating IDL for Examples COAS 1.0 open
COAS-5 GCPR Issue: Using Relational Operators COAS 1.0 open
COAS-4 GCPR Issue: Event Interface Enhancements COAS 1.0 open
COBOL-2 COBOL Language Mapping Section: 1.2.1.2 COBOL 1.0 open
COBOL-1 anomaly in that unsigned integers are mapped to signed integers COBOL 1.0 open
COBOL-3 Mapping of short and long COBOL 1.0 open
CAD11-7 different tessellation structures for different kind of entities CAD 1.1 open
CAD11-6 CadFoundation::EntityPropsStruct CAD 1.0 open
CAD11-13 CadBrep::OrientedEdge interface issue CAD 1.1 open
CAD11-12 CadBrep module issue CAD 1.1 open
CAD11-17 Documentation for CadMain::Model::unique_entities() CAD 1.1 open
CAD11-16 CadMain::Model interface issue CAD 1.1 open
CAD11-15 Data in CadGeometry::EdgeTessellationStuct CAD 1.1 open
CAD11-14 CADServices 1.1 issue CAD 1.1 open
CAD11-9 exception CadConnection::BadParameter does not match the method anymore CAD 1.1 open
CAD11-8 return value of CadFoundation::Entity::cad_model() CAD 1.0 open
CAD11-11 method CadMain::Model::unique_ids_to_entities() CAD 1.1 open
CAD11-10 description for CadMain::Model::unique_ids_to_entities() is missing CAD 1.1 open
CAD11-5 Model creation parameters CAD 1.1 open
CAD11-4 File CadMain: Method add_child and remove_child CAD 1.0 open
CAD11-1 File CadGeometryExtens CAD 1.0 open
CAD11-3 struct OffsetCurveStruct CAD 1.0 open
CAD11-2 struct HyperbolaStruct should be moved from CadSurface to CadCurve CAD 1.0 open
CPP13-67 Section: 13.6 Server mapping CPP 1.1 open
CPP13-66 Concrete ValueType _init class problem CPP 1.1 open
CPP13-63 _var's and valuetypes CPP 1.2 open
CPP13-62 conversion algorithm not specified CPP 1.1 open
CPP13-58 Fixed and truncation/rounding? CPP 1.1 open
CPP13-57 ServantBase needs _get_domain_managers()? CPP 1.1 open
CPP13-65 Sequence _var needs const operator [] CPP 1.2 open
CPP13-64 No portable way to create a OUT argument for a DII request CPP 1.1 open
CPP13-61 Prohibit extracting from any into _out type? CPP 1.1 open
CPP13-60 Add set of typedefs that would facilitate template programming CPP 1.1 open
CPP13-70 need unchecked narrow CPP 1.2 open
CPP13-69 valuetype example has errors CPP 1.2 open
CPP13-59 UTF-8 and IDL character types in C++ CPP 1.1 open
CPP13-68 Describe operator != and == for all generated types CPP 1.2 open
CPP13-53 Optional parameters for _create_request? CPP 1.1 open
CPP13-52 ORB::destroy() missing CPP 1.1 open
CPP13-54 Passing two context lists to _create_request() CPP 1.1 open
CPP13-50 CORBA::RequestSeq or CORBA::ORB::RequestSeq? CPP 1.1 open
CPP13-49 _default_POA if no default ORB? CPP 1.1 open
CPP13-51 questions to IDL - C++ mapping ( CORBA 2.3, valuebox) CPP 1.1 open
CPP13-56 Inserters/extractors for boxed strings? CPP 1.1 open
CPP13-55 publication of messaging / unchecked_narrow CPP 1.1 open
CPP13-43 Supporting typedefs for _var types? CPP 1.1 open
CPP13-42 Variable-length out params and exceptions CPP 1.1 open
CPP13-41 Read-only parameter remnants CPP 1.1 open
CPP13-40 Sequence mapping & custom marshalling CPP 1.1 open
CPP13-35 set_servant and null servant CPP 1.1 open
CPP13-34 ref counting ambiguous? CPP 1.1 open
CPP13-30 Object Reference insertion/extration to Any CPP 1.1 open
CPP13-39 DSI and implicit activation CPP 1.1 open
CPP13-38 void * operations on Any? CPP 1.1 open
CPP13-32 Valuetype "copying" semantics underspecified? (C++ issue # 1) CPP 1.1 open
CPP13-31 ValueBase::_copy_value() function is underspecified CPP 1.1 open
CPP13-33 Valuetype "copying" semantics underspecified? (C++ Issue # 2) CPP 1.1 open
CPP13-36 Issue with valuetypes & inout/out parameters CPP 1.1 open
CPP13-37 Constructor for structures? CPP 1.1 open
CPP13-12 Value Box Mapping CPP 1.0b1 open
CPP13-11 portable includes CPP 1.0b1 open
CPP13-16 Setting the TypeCode of an Any without setting a value CPP 1.0 open
CPP13-15 Value boxes and sensible value issue CPP 1.0b1 open
CPP13-3 C++ _var type widening proposal CPP 1.0b1 open
CPP13-2 include files CPP 1.0b1 open
CPP13-10 Is public _ptr member mandatory? CPP 1.0b1 open
CPP13-9 Need more info for custom marshalled value in C++ CPP 1.0b1 open
CPP13-8 Generic extraction of Fixed CPP 1.0b1 open
CPP13-7 Extraction of Fixed from Any CPP 1.0b1 open
CPP13-5 struct containing Fixed type CPP 1.0b1 open
CPP13-4 Section 7.3.6: PortableServer::ValueRefCountBase CPP 1.0b1 open
CPP13-13 Valuetypes as operation arguments CPP 1.0b1 open
CPP13-14 Memory management of recursive value CPP 1.0b1 open
CPP13-6 Extraction of strings from an Any CPP 1.0b1 open
CPP13-45 unclear semantics for valuetype insertion into Any CPP 1.1 open
CPP13-44 Any insertion for Boolean/Octet/Char CPP 1.1 open
CPP13-47 CORBA::Environment for EH compilers CPP 1.1 open
CPP13-46 unspecified criterion for Any extraction CPP 1.1 open
CPP13-48 CORBA::release and CORBA::is_nil on POA_ptr CPP 1.1 open
CPP13-29 fixed-length _var assignment from pointer CPP 1.1 open
CPP13-28 UnknownUserException and stubs CPP 1.1 open
CPP13-22 Exceptions in servant constructors CPP 1.0 open
CPP13-21 Abstract interface and DSI issue with C++ CPP 1.0 open
CPP13-19 _default_POA CPP 1.0 open
CPP13-18 ValueBase::_copy_value clarification CPP 1.0 open
CPP13-27 Construction of _var types CPP 1.1 open
CPP13-26 C++ spec: Valuebase missing get_value_def CPP 1.1 open
CPP13-25 C++ ValueBox & Fixed question CPP 1.1 open
CPP13-20 Problem with AbstractBase definition CPP 1.0 open
CPP13-17 IDL that is not IDL! CPP 1.0 open
CPP13-23 _out types and nested calls CPP 1.0 open
CPP13-24 Any and UnknownUserException CPP 1.1 open
C11-55 OpaqueValue needs to be documented in the C Language mapping C 1.1 open
C11-54 Order of structure members C 1.1 open
C11-44 Bound seq buffer allocation C 1.0b1 open
C11-43 Seq buffer deallocation C 1.0b1 open
C11-42 Mapping for Aliases C 1.0b1 open
C11-41 Exception id name C 1.0b1 open
C11-38 Sequence buffer release C 1.0b1 open
C11-37 Sequence buffer initialization C 1.0b1 open
C11-34 Allocation and initialization C 1.0b1 open
C11-33 Exception initialization C 1.0b1 open
C11-40 Argument passing, cases 3 and 6 C 1.0b1 open
C11-39 Exception initialization and release C 1.0b1 open
C11-36 Sequence initialization C 1.0b1 open
C11-35 De-allocation and release C 1.0b1 open
C11-32 System Exception Type C 1.0b1 open
C11-7 implementation hints not specification (Section 14.24.2 last para) C 1.0b1 open
C11-6 Parameter memory freeing problem (Section 14.24.1.para 6) C 1.0b1 open
C11-11 C mapping for sequence (Section 14.11 CORBA 2.0) C 1.0b1 open
C11-10 inconsistent parameter name and order C 1.0b1 open
C11-15 vec10 and CORBA_sequence_long C 1.0b1 open
C11-14 Spec contains mutually inconsistent examples C 1.0b1 open
C11-18 sequence as anonymous type in struct C 1.0b1 open
C11-17 Declare and define Allocators for new sequence type C 1.0b1 open
C11-8 What happens when set_exception called more than once? C 1.0b1 open
C11-13 C mapping for Any C 1.0b1 open
C11-12 Representation of "string" values in an "any" C 1.0b1 open
C11-16 Allocation Functions for sequences of "T" C 1.0b1 open
C11-9 confusing presentation (Section 14.25.4) C 1.0b1 open
C11-53 Error in C language specification C 1.0b1 open
C11-52 Inconsistency in CORBA 2.0 C mapping C 1.0b1 open
C11-47 Example inconsistent with table 20 and table 21 C 1.0b1 open
C11-46 Seq buffer allocation C 1.0b1 open
C11-51 CORBA_string is not defined C 1.0b1 open
C11-50 No defined value for CORBA_OBJECT_NIL C 1.0b1 open
C11-49 Delete 14.17 para 1 C 1.0b1 open
C11-48 Initial state of out parameter pointers C 1.0b1 open
C11-45 release flag & returned data C 1.0b1 open
C11-4 Pseudo-Object underspecification C 1.0b1 open
C11-3 C Language header question C 1.0b1 open
C11-5 Inappropriate information (Sect. 14.23. last paragraph C 1.0b1 open
C11-1 Inout sequence/any behavior with oversized return values C 1.0b1 open
C11-2 Wrong placement of asterics in table C 1.0b1 open
C11-21 memory allocation functions C 1.0b1 open
C11-20 When MUST _buffer of sequence be allocated with _allocbuf C 1.0b1 open
C11-28 Exception release function C 1.0b1 open
C11-27 Exception stringification C 1.0b1 open
C11-25 Sequence buffer management C 1.0b1 open
C11-24 Sequence behavior C 1.0b1 open
C11-31 Minor field of system exceptions C 1.0b1 open
C11-30 Exception identification C 1.0b1 open
C11-26 Scoped sequence naming C 1.0b1 open
C11-22 memory release functions C 1.0b1 open
C11-23 mapping for sequences C 1.0b1 open
C11-29 CORBA_Environment initialization C 1.0b1 open
C11-19 CORBA_sequence_long C 1.0b1 open
CTS213-2 Usage Context Binding Inappropriately Expressed CTS2 1.0 open
CTS213-3 Using enumerations instead of using code systems CTS2 1.0 open
CTS213-1 CTS2: Documentation is incorrect in SpecificEntityList class CTS2 1.1 open
CTS213-11 CTS2: ConceptDomain Binding has no property attribute CTS2 1.1 open
CTS213-10 CTS2: Children/Descendants use inconsistent with Value Set CTS2 1.1 open
CTS213-9 CTS2: SpecificEntityList description is incorrect CTS2 1.1 open
CTS213-12 CTS2: EntityDescription lacks workflow status entry CTS2 1.1 open
CTS213-8 CTS2: "readContext" missing on ResolvedValueSetResolution functions CTS2 1.0 open
CTS213-4 AssociationQueryServices WSDL corrections CTS2 1.0b1 open
CTS213-5 CTS2: Wrong type in CompleteValueSetReference (ValueSetDefinition.xsd) CTS2 1.1 open
CTS213-6 CTS2: ValueSetDefinitionListEntry in ValueSetDefinition.xsd has wrong cardinality CTS2 1.1 open
CTS213-7 CTS2: ResourceList entries have double "entry" items CTS2 1.1 open

Issues Descriptions

Acknowledge Final Status inconsistency

  • Key: C2MS12-5
  • Status: open  
  • 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
  • Updated: Wed, 11 Dec 2024 00:01 GMT

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

  • Key: C2MS12-28
  • Status: open  
  • 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.
  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:36 GMT
  • Updated: Tue, 10 Dec 2024 23:57 GMT

Required or Optional for MNEMONIC Status on Data Messages

  • Key: C2MS12-42
  • Status: open  
  • 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 field MNEMONIC.n.STATUS is required. This makes sense, because of the nature of the mnemonic values. If a status can't be returned, nothing else would seem relevant. However, when the data is conveyed in subsequent Mnemonic Value Data Messages, MNEMONIC.n.STATUS is 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.STATUS is required in the Reponse 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 status of each. Therefore, the field 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
  • Updated: Tue, 10 Dec 2024 22:50 GMT

Replace simple service REQ/RESP

  • Key: C2MS12-22
  • Status: open  
  • 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.
  • Reported: C2MS 1.0 — Tue, 11 Jul 2023 14:51 GMT
  • Updated: Tue, 10 Dec 2024 16:12 GMT

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

  • Key: C2MS12-20
  • Status: open  
  • 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
  • Updated: Tue, 10 Dec 2024 16:00 GMT

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

  • Key: C2MS12-96
  • Status: open  
  • 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
  • Updated: Tue, 10 Dec 2024 02:20 GMT

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

  • Key: C2MS12-23
  • Status: open  
  • 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
  • Updated: Tue, 10 Dec 2024 01:38 GMT

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

  • Key: C2MS12-36
  • Status: open  
  • 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
  • Updated: Tue, 10 Dec 2024 01:20 GMT

Create a C2MS SM&C MAL Message

  • Key: C2MS12-79
  • Status: open  
  • 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
  • Updated: Tue, 10 Dec 2024 00:35 GMT

Add SM&C MAL Message

  • Key: C2MS12-74
  • Status: open  
  • 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
  • Updated: Tue, 10 Dec 2024 00:34 GMT

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

  • Key: C2MS12-16
  • Status: open  
  • 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
  • Updated: Mon, 9 Dec 2024 18:44 GMT

Missing base_type IDL traits for base struct and bitset

  • Key: CPP1117-41
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Both the IDL struct and bitset support inheritance in 6.31, at the moment the struct/bitset has a base, a IDL::traits<>::base_type should be make available for template meta programming
  • Reported: CPP11 1.7 — Fri, 22 Nov 2024 12:37 GMT
  • Updated: Mon, 2 Dec 2024 18:32 GMT

Standardize Table Cell Borders

  • Key: C2MS12-91
  • Status: open  
  • 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
  • Updated: Fri, 22 Nov 2024 16:51 GMT

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

  • Key: C2MS12-93
  • Status: open  
  • 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
  • Updated: Fri, 22 Nov 2024 16:49 GMT

Miscellaneous Minor Document Formatting/Text Issues

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

    Item 1 - 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
  • Updated: Wed, 20 Nov 2024 16:24 GMT

Standardize Sections and Section Names for Message Subjects

  • Key: C2MS12-87
  • Status: open  
  • 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
  • Updated: Wed, 20 Nov 2024 00:55 GMT

Commons silently changes the semantics of dct:description

  • Key: COMMONS13-14
  • Status: open  
  • 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
  • Updated: Fri, 15 Nov 2024 19:49 GMT

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

  • Key: C2MS12-84
  • Status: open  
  • 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
  • Updated: Fri, 15 Nov 2024 18:19 GMT

Annotation Vocabulary missing discussion of labeling policy

  • Key: COMMONS13-13
  • Status: open  
  • 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
  • Updated: Sun, 10 Nov 2024 20:42 GMT

Annotation Vocabulary has incomplete definitions from SKOS

  • Key: COMMONS13-12
  • Status: open  
  • 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
  • Updated: Sun, 10 Nov 2024 20:09 GMT

The documents ontology is missing the notion of a document part

  • Key: COMMONS13-11
  • Status: open  
  • 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
  • Updated: Sat, 2 Nov 2024 19:26 GMT

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

  • Key: COMMONS13-10
  • Status: open  
  • 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
  • Updated: Sat, 2 Nov 2024 19:21 GMT

Add support for @cpp_mapping

  • Key: CPP1117-40
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Proposal is to add a @cpp_mapping as IDL4toC++ has, to enable users to select a mapping of IDL struct to a C++ struct (that mapping itself has to be added here also)
  • Reported: CPP11 1.7 — Wed, 23 Oct 2024 13:23 GMT
  • Updated: Mon, 28 Oct 2024 14:52 GMT

lwCCM issues - home finders and finder operations

  • Key: CORBA35-75
  • Legacy Issue Number: 7148
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.8 "exluding support for home finders" there
    are still references to finder operations and home finders in the following
    sections:
    1.7.1 (§2), 1.7.1.1, 1.7.3, 1.7.3.3, 1.7.4 (§1), 1.7.5 (heterodox), 3.3.6
    (point 5), 4.3.2.1 (get_CCM_home), 4.5, 4.5.1 (point 4, last §), 4.5.1.1
    (last point), 4.5.1.2
    The following sections have to be removed:
    1.7.3.2, 4.5.1.3, 4.5.2.3

    Proposed resolution:

    Add a row in the table 4.8 with :
    "Normative Exclusion" column : Exclude support for home finders and finder
    operations
    "Document Impact" column :
    Section 1.7.1, paragraph 2: remove reference to home finders and
    finder operations.
    Section 1.7.1.1: remove reference to home finders and finder
    operations.
    Section 1.7.3: remove reference to home finders and finder
    operations.
    Section 1.7.3.3: remove reference to home finders and finder
    operations.
    Section 1.7.4 paragraph 1: remove reference to home finders and
    finder operations.
    Section 1.7.5 (heterodox): remove reference to home finders and
    finder operations.
    Section 3.3.6, point 5: remove reference to home finders and finder
    operations.
    Section 4.3.2.1 (get_CCM_home): remove reference to home finders and
    finder operations.
    Section 4.5: remove reference to home finders and finder operations.
    Section 4.5.1, point 4 and last paragraph: remove reference to home
    finders and finder operations.
    Section 4.5.1.1, last point: remove reference to home finders and
    finder operations.
    Section 4.5.1.2: remove reference to home finders and finder
    operations.
    Section 1.7.3.2: remove
    Section 4.5.1.3: remove
    Section 4.5.2.3: remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:02 GMT

LWCCM issue - Section 1.5.3 Exclusion

  • Key: CORBA35-91
  • Legacy Issue Number: 6254
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    On page 11: The Normative Impact "Disable get_connections, get_all_receptacles, get_named_receptacles operations in the Receptacles interface" does not match the Document Impact: "Section 1.5.3: remove". Removal of section 1.5.3 removes the Receptacles interface in it entirety, including the description of the generic connect and disconnect operations, which are referred to by comment in the previous item. The Document Impact needs to be narrowed.
  • Reported: CORBA 3.0.2 — Tue, 16 Sep 2003 04:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - abstract storage type

  • Key: CORBA35-85
  • Legacy Issue Number: 7131
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 4;
    there are still references to abstract storage type in the following
    sections:
    3.2.2 (§2), 3.2.6, 3.2.9 (point 4)

    Proposed resolution:

    Row 4 in the table 4.1, add in the "Document Impact" column :
    Section 3.2.2, paragraph 2: remove references to abstract storage type
    Section 3.2.6: remove references to abstract storage type
    Section 3.2.9, point 4: remove references to abstract storage type
  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - abstract storage home

  • Key: CORBA35-84
  • Legacy Issue Number: 7132
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 3;
    there are still references to abstract storage homes in the following
    sections:
    1.7.4, 3.2.5 (§4), 3.2.6

    Proposed resolution:

    Row 3 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.4: remove references to storage home
    Section 3.2.5, paragraph 4: remove references to abstract storage home
    Section 3.2.6: remove references to abstract storage home
  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - get_all_facet, ...

  • Key: CORBA35-80
  • Legacy Issue Number: 7143
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.2 "exluding support introspection,
    navigation, ...", row 2; there are still references to these operations in
    the following sections:
    1.4.3, point 3 and 4, section 1.4.3.4, paragraph 1

    Proposed resolution:

    Row 2 in the table 4.2, in the "Document Impact", add:
    Section 1.4.3, point 3 and 4: remove references to these operations
    Section 1.4.3.4, paragraph 1: remove references to these operations

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

LwCCM issue - Section 1.6.8 Exclusion

  • Key: CORBA35-25
  • Legacy Issue Number: 7028
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Events
    interface.

    While the normative exclusion "disable get_all_consumers
    [...]" (8th row of section 10.3) retains the generic
    get_consumer, subscribe, unsubscribe, connect_consumer
    and disconnect_consumer operations, removing section 1.6.8
    would remove the entire Events interface.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the
    8th row, replace the text

    Section 1.6.8: remove

    with

    Section 1.6.8: remove these operations from the Events
    interface. Also remove the ConsumerDescription,
    EmitterDescription, SubscriberDescription and
    PublisherDescription types.

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

LwCCM issue - Section 1.4.3.3 Exclusion

  • Key: CORBA35-23
  • Legacy Issue Number: 7027
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Navigation
    interface.

    While the normative exclusion "disable get_all_facets, get_
    named_facets, same_component operations in Navigation
    interface" retains the generic provide_facet operation,
    removing section 1.4.3.3 would remove the entire Navigation
    interface.

    On the other hand, the still-present section 1.4.3.4 references
    the disabled operations.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the second
    row, replace the text

    1.4.3.3: remove

    with

    1.4.3.3: remove these operations from the Navigation
    interface. Also remove the PortDescription, FacetDescription
    and FacetDescriptions types.

    1.4.3.4: remove

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - security

  • Key: CORBA35-89
  • Legacy Issue Number: 7127
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.5 "exluding support for security", there are
    still references to the security feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 , 4.5.1.5, 4.5.2.5

    Proposed resolution:

    Add a row in the table 4.5 with :
    "Normative Exclusion" column : Exclude support for security
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    security
    Section 4.2.1, paragraph 1: remove reference to security
    Section 4.2.12: remove reference to security
    Section 4.5.1.1: remove reference to security
    Section 4.5.1.5: remove reference to security
    Section 4.5.2.5: remove reference to security
  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - transaction

  • Key: CORBA35-90
  • Legacy Issue Number: 7126
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.4 "exluding support for transaction", there
    are still references to the transaction feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 (point 2), 4.5.1.4, 4.5.2.4

    Proposed resolution:

    Add a row in the table 4.4 with :
    "Normative Exclusion" column : Exclude support for transaction
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    transaction
    Section 4.2.1, paragraph 1: remove reference to transaction
    Section 4.2.12: remove reference to transaction
    Section 4.5.1.1, point 2: remove reference to transaction
    Section 4.5.1.4: remove reference to transaction
    Section 4.5.2.4: remove reference to transaction
  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - section 4.1.2

  • Key: CORBA35-86
  • Legacy Issue Number: 7130
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    the section 4.1.2 doesn't have to be fully removed. Only the references to
    entiy container have to.

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column, replace
    "Section 4.1.2: remove" by "Section 4.1.2: remove reference to entity
    container API types".

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - persistence

  • Key: CORBA35-88
  • Legacy Issue Number: 7128
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; there
    are still references to persistence in the following sections:
    4.2 §1, 4.2.1 §1, 4.2.12

    Proposed resolution:

    Add a row in the table 4.1 with :
    "Normative Exclusion" column : Exclude support for persistence
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    persistence
    Section 4.2.1, paragraph 1: remove reference to persistence
    Section 4.2.12: remove reference to persistence
  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - entity components

  • Key: CORBA35-87
  • Legacy Issue Number: 7129
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to entity components in the following sections:
    3.3.3.3, 4.5.1.3 (§1), 4.5.2.3 (point 3)

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column :
    Section 3.3.3.3: remove references to entity components
    Section 4.5.1.3, paragraph 1: remove references to entity components
    Section 4.5.2.3, point 3: remove references to entity components
  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - segmentation

  • Key: CORBA35-81
  • Legacy Issue Number: 7142
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", there
    are still references to segmentation in the following sections:
    : 3.2.1.6 (§1), 3.2.11 (§1), 3.2.9 (point 2), 4.2.12 (extended)
  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - locator

  • Key: CORBA35-82
  • Legacy Issue Number: 7141
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", row
    3; there are still references to locator in the following sections:
    3.3.3.5, paragraph 4 and last paragraph

    Proposed resolution:

    Row 3 in the table 4.3, in the "Document Impact", add:
    Section 3.3.3.5, paragraph 4 and last paragraph: remove references to
    locator

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - CIDL

  • Key: CORBA35-83
  • Legacy Issue Number: 7133
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 2;
    and the table 4.3 "exluding support for segmentation", row 1: there are
    still references to CIDL in the following sections:
    1.5.2.1 (§1), 3.1 (§1)

    Proposed resolution:

    Row 2 in the table 4.1 and Row 1 in the table 4.3, add in the "Document
    Impact" column :
    Section 1.2.2.1, paragraph 1: remove references to CIDL
    Section 3.1, paragraph 1: remove references to CIDL
  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - configurators

  • Key: CORBA35-77
  • Legacy Issue Number: 7146
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.6 "exluding support for configurators";
    there are still references to configurators in the following sections:
    1.10.2 (second point), 1.10.2.1 (§2), 1.11.1 (configuration_complete)

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - Section 4.1

  • Key: CORBA35-78
  • Legacy Issue Number: 7145
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; in the
    "Document Impact" column, row 1, the § 3 doesn't exist in the section 1.1.4.

    Proposed resolution:
    Table 4.1, row 1, column "Document Impact": replace "Section 1.1.4,
    paragraph 3: remove" by "Section 1.1.4, paragraph 2: remove"

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - primary key

  • Key: CORBA35-79
  • Legacy Issue Number: 7144
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 1;
    there are still references to primary key in the following sections:
    1.7.1 (§1 & §3), 1.7.4, 1.7.5.1 (§1, §2), 1.7.5.2 (§1, §2)

    Proposed resolution:

    Row 1 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.1, paragraph 1 and 3: remove references to primary key
    Section 1.7.4: remove references to primary key
    Section 1.7.5.1, paragraph 1and 2: remove references to primary key
    Section 1.7.5.2, paragraph 1and 2: remove references to primary key
  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - invalid rows

  • Key: CORBA35-74
  • Legacy Issue Number: 7149
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 2
    and 3 are not valid

    Proposed resolution:

    remove the rows 2 and 3 of the table 4.7

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - proxy homes

  • Key: CORBA35-76
  • Legacy Issue Number: 7147
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 1;
    in section 3.2.5, the last paragraph should be removed.

    Proposed resolution:

    Row 1 in the table 4.7, in the "Document Impact", add:
    Section 3.2.5 last paragraph:remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - Entity2Context

  • Key: CORBA35-73
  • Legacy Issue Number: 7150
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to Entity2Context in the following sections:
    3.2.11 (§2)

    Proposed resolution:

    Row 7 in the table 4.1, in the "Document Impact", add:
    Section 3.2.11, paragraph 2:remove reference to the Entity2Context
    interface.

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

Which TypeCode operations apply to Value and ValueBox?

  • Key: CORBA35-415
  • Legacy Issue Number: 1140
  • Status: open  
  • 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
  • Updated: Thu, 17 Oct 2024 15:51 GMT

Can value type inherit from Value Box type

  • Key: CORBA35-418
  • Legacy Issue Number: 1055
  • Status: open  
  • 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
  • Updated: Thu, 17 Oct 2024 15:50 GMT

Deprecate fields duplicated between C2MS Messages and the Message Envelope

  • Key: C2MS12-26
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:32 GMT

Revisit Tracking Fields

  • Key: C2MS12-32
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:31 GMT

AMVAL Value Response Doesn't Mirror MVAL Value Response Message

  • Key: C2MS12-37
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:30 GMT

What to do when Priority isn't Specified

  • Key: C2MS12-46
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:29 GMT

Lack of Required Fields in Sub-elements

  • Key: C2MS12-41
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:28 GMT

Using REQ Messages for 'Publish'

  • Key: C2MS12-15
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:27 GMT
  • Attachments:

Re-evaluate Optional Boolean Fields

  • Key: C2MS12-33
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:24 GMT

Command Echo Not Provided Message

  • Key: C2MS12-18
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:23 GMT

Revisit Completion Status in Command Response Message

  • Key: C2MS12-67
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:20 GMT

Rework Log Message

  • Key: C2MS12-43
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:09 GMT

Consider Deprecating and Later Removing Resource Message

  • Key: C2MS12-31
  • Status: open  
  • 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
  • Updated: Thu, 26 Sep 2024 22:08 GMT

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

  • Key: COMMONS13-2
  • Status: open  
  • 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
  • Updated: Wed, 25 Sep 2024 22:59 GMT

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

  • Key: COMMONS12-2
  • Status: open  
  • 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
  • Updated: Wed, 25 Sep 2024 22:59 GMT

Need an ontology representing multidimensional arrays

  • Key: COMMONS13-1
  • Status: open  
  • 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
  • Updated: Wed, 25 Sep 2024 22:59 GMT

Need an ontology representing multidimensional arrays

  • Key: COMMONS12-1
  • Status: open  
  • 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
  • Updated: Wed, 25 Sep 2024 22:59 GMT

Consider a Command Completed Publish Message

  • Key: C2MS12-66
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Reconsider Oneshot in MVAL Request/Response

  • Key: C2MS12-21
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

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

  • Key: C2MS12-47
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Consolidate Navigation Data Messages

  • Key: C2MS12-44
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Replace Unsolicited Echo with a Separate Message

  • Key: C2MS12-19
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

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

  • Key: C2MS12-11
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Data Dictionary Messages

  • Key: C2MS12-2
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Add documentation within the model

  • Key: C2MS12-7
  • Status: open  
  • Source: Braxton Technologies, LLC ( 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

XML PSM recommended

  • Key: C2MS12-4
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

C2MS Database Query (DBQUERY) messages

  • Key: C2MS12-14
  • Status: open  
  • 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
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Clean up a few issues with the Locations ontology

  • Key: COMMONS12-13
  • Status: open  
  • 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
  • Updated: Mon, 16 Sep 2024 14:39 GMT
  • Attachments:

The definition of aspect needs refinement

  • Key: COMMONS12-7
  • Status: open  
  • 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
  • Updated: Mon, 16 Sep 2024 14:39 GMT
  • Attachments:

C2INav Model refers to an old OARIS Common Types package

  • Key: OARIS3-17
  • Status: open  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • 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.0 — Wed, 21 Jun 2023 10:00 GMT
  • Updated: Mon, 16 Sep 2024 14:35 GMT

BNF changes

  • Key: CORBA35-191
  • Legacy Issue Number: 5952
  • Status: open  
  • 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
  • Updated: Thu, 12 Sep 2024 21:34 GMT

Bad text in 22.6 mandates Routing for sendc/sendp

  • Key: CORBA35-195
  • Legacy Issue Number: 5856
  • Status: open  
  • 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
  • Updated: Thu, 12 Sep 2024 21:31 GMT

Add optional/map mapping (and other IDL4 special types)

  • Key: CORBA35-607
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For IDl4 the CDR marshaling should be described, optional could be described as a union with a boolean discriminant, with TRUE containing the value, map as a sequence of structs containing each key/value, other IDL4 extensions can also be described using IDL base types marshaling. That also enables interoperability of optional/map/others with an old implementation without IDL4 support, the IDL has to be rewritten to work, but at that moment an IDL3 app can talk with a IDL4 app (at least for CDR)
  • Reported: CORBA 3.4 — Mon, 27 May 2024 06:22 GMT
  • Updated: Thu, 12 Sep 2024 21:22 GMT

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

  • Key: C2MS12-51
  • Status: open  
  • 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
  • Updated: Thu, 12 Sep 2024 19:14 GMT

Improve Example Text for Publish Rate

  • Key: C2MS12-48
  • Status: open  
  • 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
  • Updated: Thu, 12 Sep 2024 18:49 GMT

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

  • Key: C2MS12-12
  • Status: open  
  • 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
  • Updated: Thu, 12 Sep 2024 18:12 GMT

Inconsistent Optional/Required Fields

  • Key: C2MS12-34
  • Status: open  
  • 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
  • Updated: Wed, 11 Sep 2024 21:06 GMT

Split ME1 in Simple Service Req/Resp

  • Key: C2MS12-17
  • Status: open  
  • 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
  • Updated: Wed, 11 Sep 2024 21:06 GMT

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

  • Key: C2MS12-10
  • Status: open  
  • 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
  • Updated: Wed, 11 Sep 2024 16:14 GMT

Larger Data Types

  • Key: C2MS12-8
  • Status: open  
  • 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
  • Updated: Wed, 11 Sep 2024 16:13 GMT

Normalize Headers and Text in the new DB Query Messages

  • Key: C2MS12-38
  • Status: open  
  • 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
  • Updated: Wed, 11 Sep 2024 16:08 GMT

Undo Addition of DB Query Messages in 1.1

  • Key: C2MS12-45
  • Status: open  
  • 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
  • Updated: Wed, 11 Sep 2024 16:08 GMT
  • Attachments:

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

  • Key: C2MS12-39
  • Status: open  
  • 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
  • Updated: Tue, 10 Sep 2024 03:15 GMT

constexpr constructors missing

  • Key: CPP1117-39
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In user code I want to use constexpr for IDL fixed values, for example

    constexr F pi

    {3.142857}

    ;

    But in order for that to work a constexpr constructor has to be available, the spec should define that
  • Reported: CPP11 1.7 — Wed, 4 Sep 2024 07:19 GMT
  • Updated: Wed, 4 Sep 2024 14:18 GMT

CORBA::CustomerMarshal, type

  • Key: CPP1117-38
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    CORBA::CustomerMarshal, should be CORBA::CustomMarshal,
  • Reported: CPP11 1.7 — Mon, 19 Aug 2024 07:10 GMT
  • Updated: Wed, 4 Sep 2024 14:10 GMT

Typo CORBA::CustomerMarshal

  • Key: CPP1117-37
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    CORBA::CustomerMarshal should be CORBA::CustomMarshal
  • Reported: CPP11 1.7 — Mon, 19 Aug 2024 07:08 GMT
  • Updated: Wed, 4 Sep 2024 14:07 GMT

Align TLM Terms

  • Key: C2MS12-49
  • Status: open  
  • 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
  • Updated: Thu, 8 Aug 2024 00:02 GMT

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

  • Key: C2MS12-40
  • Status: open  
  • 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 "Mnem