Design Considerations for Protocol Extensions

Abstract

This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.

Architectural Considerations in Smart Object Networking

“…Extending protocols to fulfill new uses and to add new functionality may range from very easy to difficult, as [RFC6709] RFC 1958 [RFC1958] considers this aspect and says "... the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network." This statement is challenged more than ever with the perceived need to develop intermediaries interacting with less intelligent end devices.…”

DNS-Based Service Discovery

“…This information in the TXT record can be useful to help clients maintain backwards compatibility with older implementations if it becomes necessary to change or update the specification over time. Even if the profile author doesn't anticipate the need for any future incompatible changes, having a version number in the TXT record provides useful insurance should incompatible changes become unavoidable [RFC6709]. Clients SHOULD ignore TXT records with a txtvers number higher (or lower) than the version(s) they know how to interpret.…”

Peer-to-Peer Streaming Peer Protocol (PPSPP)

“…This closing HANDSHAKE message MUST contain an all zeros channel ID and a list of protocol options. The list MUST either be empty or contain the maximum version number Peer P supports, following the min/max versioning scheme defined in [RFC6709], Section 4.1.…”

“…A datagram containing a HANDSHAKE message then looks as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 A peer SHOULD explicitly close a channel by sending a HANDSHAKE message that MUST contain an all zeros Source Channel ID and a list of protocol options. The list MUST either be empty or contain the maximum version number the sender supports, following the min/max versioning scheme defined in [RFC6709], Section 4.1.…”