DDSI-RTPS 2.3 RTF Avatar
  1. OMG Issue

DDSIRTP23 — Use the term "Encapsulation" consistently and precisely

  • Key: DDSIRTP23-25
  • Legacy Issue Number: 16955
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • 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.

  • Reported: DDSI-RTPS 2.0b1 — Tue, 27 Dec 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 17:25 GMT