Message framer clarifications

[mwelzl]

6. Implementing Message Framers

Of course, a Message Framer is just another protocol layered on top of
a protocol stack, and I think it would be helpful if that was stated
early in this section.

But there are a lot of details of the situation that I think you want
to be clearer about. Does the TAPS specification define and require
support of a particular set of Message Framers? Applications will
generally take the defensive stance of not using Message Framers that
aren't required to be present.

Also, it's not clear to me to what degree this discussion is connected
to the API. In particular, does the TAPS API define how a Message
Framer interacts with the rest of the implementation? In that case,
the details in this section are normative. But if the idea is that
TAPS does not define such an API but that a TAPS implementation would
want to provide an API for "user" Message Framers, then this section
is a generic discussion of implementation considerations. Either way,
the intention should be stated clearly at the beginning.

E.g.

[...] these are ways for
applications or application frameworks to define their own Message
parsing to be included within a Connection's Protocol Stack.

suggests that allowing applications to specify their own custom
Message Framers is a part of the TAPS API definition, whereas

This section describes one possible API for defining
Message Framers, as an example.

suggests that there is no definition of such a facility (and so it is
an optional, non-standardized, extension in any implementation that
does have it).

---

From the review by Dale Worley: https://mailarchive.ietf.org/arch/msg/last-call/bpBk8QxZMLksr3ZuROtf2_BXYdI/
Note that indentation was lost by copy+pasting here - look at the edited version or the version at the URL to get a clearer view of what is being quoted.