Issue 16955: Use the term "Encapsulation" consistently and precisely (ddsi-rtps-rtf) Source: OCI (Mr. Adam Mitz, mitza(at)objectcomputing.com) Nature: Uncategorized Issue Severity: Summary: Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. In general, encapsulation means adding specific prefix bytes to the on-the-wire representation of data. This prefix can be used by the receiver to understand the format of the following bytes. The majority of uses of “encapsulation” in the specification do not agree with this meaning. This issue seeks to fix that by using the simpler term of “encoding” in place of “encapsulation.” Section: 8.3.2, Table 8.13, Count_t row Page: 30 Change: replace “encapsulate” with “encode” Section: 8.3.3.2, Table 8.15, flags row Page: 34 Change: replace “encapsulate” with “encode” Section: 8.3.5.1 Page: 37 Change: replace “encapsulate” with “encode” Section: 8.3.5.9, Paragraph 1 Page: 41 Change: replace “encapsulate” with “encode”; replace “encapsulation” with “encoding” Section: 8.3.7.9.2, Table 8.41, protocolVersion and VendorId rows Page: 59 Change: replace “encapsulate” with “encode”; replace “encapsulated” with “encoded” Section: 8.4.10.3 Page: 105 Change: replace “encapsulated” with “represented” (this use has nothing to do with encoding) Section: 8.5.3.2, Table 8.73, expectesInlineQos row Page: 126 Change: replace “encapsulated” with “encoded” Section: 9.4.2.11, Paragraphs 5, 7, 9 Page: 165 Change: replace “encapsulation” with “encoding”. Note that ParameterList itself is not an encapsulation. When it is used as the data payload for Discovery, it is the encapsulated data. When it is used as inlineQos it is not encapsulated. Each data value in the ParameterList is certainly not a CDR encapsulation. Section: 9.6.2.2, Paragraphs 4-5 Page: 181 Change: replace “encapsulates” with “encodes”; replace “encapsulated” with “encoded” (twice) Section: 9.6.2.2.2 Page: 182 Change: replace “encapsulate” with “encode” Section: 9.6.3 Page: 187 Change: replace “encapsulated” with “encoded” Section: 8.6.3.3 Page: 190-191 Change: replace “encapsulated” with “encoded” (twice); replace “encapsulation” with “encoding” (six times) Section: 10 Page: 193 Change: The introduction to section 10 (before the 10.1 header) should be removed. It adds no useful information and only confuses things with ambiguous use of the "encapsulate" term and the concept of a "type-plugin" which is nowhere to be found in the DDS specification. Since there is no 10.2, the contents of 10.1 can become 10. Regarding just the first sentence, data encapsulation must be part of RTPS or it would not be here, and different DDS implementations would not be able to interoperate. Resolution: Revised Text: Actions taken: December 27, 2011: received issue Discussion: End of Annotations:===== s is issue # 16955 Issues submission for OMG formal/2010-11-01, The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification (DDS-RTPS) Version 2.1 December 27, 2011 Adam Mitz (mitza@ociweb.com) Senior Software Engineer Object Computing, Inc. (OMG Member Use the term "Encapsulation" consistently and precisely Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of .encapsulation. throughout the RTPS spec. In general, encapsulation means adding specific prefix bytes to the on-the-wire representation of data. This prefix can be used by the receiver to understand the format of the following bytes. The majority of uses of .encapsulation. in the specification do not agree with this meaning. This issue seeks to fix that by using the simpler term of .encoding. in place of .encapsulation.. Section: 8.3.2, Table 8.13, Count_t row Page: 30 Change: replace .encapsulate. with .encode. Section: 8.3.3.2, Table 8.15, flags row Page: 34 Change: replace .encapsulate. with .encode. Section: 8.3.5.1 Page: 37 Change: replace .encapsulate. with .encode. Section: 8.3.5.9, Paragraph 1 Page: 41 Change: replace .encapsulate. with .encode.; replace .encapsulation. with .encoding. Section: 8.3.7.9.2, Table 8.41, protocolVersion and VendorId rows Page: 59 Change: replace .encapsulate. with .encode.; replace .encapsulated. with .encoded. Section: 8.4.10.3 Page: 105 Change: replace .encapsulated. with .represented. (this use has nothing to do with encoding) Section: 8.5.3.2, Table 8.73, expectesInlineQos row Page: 126 Change: replace .encapsulated. with .encoded. Section: 9.4.2.11, Paragraphs 5, 7, 9 Page: 165 Change: replace .encapsulation. with .encoding.. Note that ParameterList itself is not an encapsulation. When it is used as the data payload for Discovery, it is the encapsulated data. When it is used as inlineQos it is not encapsulated. Each data value in the ParameterList is certainly not a CDR encapsulation. Section: 9.6.2.2, Paragraphs 4-5 Page: 181 Change: replace .encapsulates. with .encodes.; replace .encapsulated. with .encoded. (twice) Section: 9.6.2.2.2 Page: 182 Change: replace .encapsulate. with .encode. Section: 9.6.3 Page: 187 Change: replace .encapsulated. with .encoded. Section: 8.6.3.3 Page: 190-191 Change: replace .encapsulated. with .encoded. (twice); replace .encapsulation. with .encoding. (six times) Section: 10 Page: 193 Change: The introduction to section 10 (before the 10.1 header) should be removed. It adds no useful information and only confuses things with ambiguous use of the "encapsulate" term and the concept of a "type-plugin" which is nowhere to be found in the DDS specification. Since there is no 10.2, the contents of 10.1 can become 10. Regarding just the first sentence, data encapsulation must be part of RTPS or it would not be here, and different DDS implementations would not be able to interoperate.