| Key | Issue | Reported | Fixed | Disposition | Status | |
|---|---|---|---|---|---|---|
| GDDI-11 | Update any Organization Names | GDDI 1.0a1 | open | |||
| GDDI-6 | Use the latest OMG Specification Template | GDDI 1.0a1 | open | |||
| GDDI-5 | Add Symbols/Acronyms | GDDI 1.0a1 | open | |||
| GDDI-4 | Consider changing Total Length from 3 to 4 octets or add "trimmed" wording | GDDI 1.0a1 | open | |||
| GDDI-3 | Clarify Encoding PSM wording | GDDI 1.0a1 | open | |||
| GDDI-2 | Add Terms and Definitions | GDDI 1.0a1 | open | |||
| GDDI-1 | Clarify Conformance clause | GDDI 1.0a1 | open |
In the specification, make any updates to organization names, as needed.
Comments from Shelley Higgins:
Use the new OMG specification template located here:
https://www.omg.org/cgi-bin/doc?pas/2024-05-01
Comments from Shelley Higgins:
It would be helpful to add a glossary/acronym list.
Add IDL, PIM, PSM, etc.
Comment from Matteo Vescovi:
8.1.2.4 Total Length
"This integer PIM attribute maps to a CORBA unsigned long whose most significant 8-bits are unused, resulting in a 24-bit (3 octet) field as shown in the above figure."
I'm curious why the standard CDR rules were not followed, and it was decided to encode an unsigned long as 3 octets instead of 4? To save one octet? To limit max message size?
Also, figure 17 has "CORBA unsigned long" next to the Total Length field, which might be misleading. Perhaps it should say "CORBA unsigned long (trimmed)" or similar, to alert the reader to the fact that the usual CORBA unsigned long CDR marshalling does not apply to this field.
Comment from Matteo Vescovi:
8.1.1 Attributes
"Since GDDI provides an interface that carries data and metadata over an octet stream, GDDI Message attributes with the above types shall be adjacently packed on octet boundaries within the octet stream and aligned on boundaries as described in Section 9.3.1.1 and Table 9.1 of [CORBAINTEROP]."
Not sure I understand what the above is saying: is it requiring that the alignment rules of CDR are followed, or requiring that the data types are "adjacently packed" (i.e. aligned on octet boundaries)?
Clarification here would help.
I note that it appears from the examples in section 8.2 that data types are "adjacently packed".
Comment from Matteo Vescovi:
It would be nice to have some terms and definitions to help a reader understand the specification. For example, shouldn't the "endpoint" be defined in the Terms?
Comment from Matteo Vescovi:
I'm not sure I understand the Conformance clause. Is it saying that a conformant implementation shall comply with the requirements defined in the PSM-CORBA Encoding section and the PSM-TCP/IP Network Transport section? Is it leaving the door open to complying with encoding PSMs and networking PSMs that might be added in future submission revisions?
Perhaps this section could be improved and made a bit clearer?
