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?

Add list of terms

In section 4 (Terms and Definitions) add a list of terms that are not already described in the specification.

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?

Reword Conformance Clause

Reword the Conformance clause to be more clear.

Comments from Shelley Higgins:
Use the new OMG specification template located here:
https://www.omg.org/cgi-bin/doc?pas/2024-05-01

Update the spec to use the latest OMG template

Move the specification content to the current OMG template located here:
https://www.omg.org/cgi-bin/doc?pas/2024-05-01

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.

Change the encoded size of the "Total Length" field from 3 to 4 octets

During the GDDI FTF 1.0 session in San Francisco 2024, the group agreed that the size of the "Total Length" field should be changed from 3 to 4 octets. This allows standard CDR rules to be followed for all encoded fields. It also provides for a larger payload field size, i.e. for cases with a large number of Type Blocks and many TLVs per block.

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".

Reword Encoding PSM description

Reword the description of how encoded attributes are packed into the octet stream to be more clear in section 8.1.1.

Comments from Shelley Higgins:
It would be helpful to add a glossary/acronym list.

Add IDL, PIM, PSM, etc.

Add list of acronyms

In section 5 (Symbols) add a list of acronyms used in the specification.

In the specification, make any updates to organization names, as needed.

Change organization names

In the copyright on page ii and in the Acknowledgements section 6.1 on page 3 change the name of the organization.