Alan,I view this differently. First, we don't have good deployment numbers for TEAP. If we bump the version and nobody is using TEAP, then nobody will care. If we don't bump the version and people ARE using TEAP, we'll get to hear from everyone who cares! From a code standpoint, I imagine that the incompabitibilies will be small in number, and so we're talking about a handful of conditionals.
Eliot On 22.12.22 15:43, Alan DeKok wrote:
On Dec 22, 2022, at 9:36 AM, Oleg Pekar <oleg.pekar.2...@gmail.com> wrote:I would like to provide comments as well. We should also bump the version of the protocol so as not to harm the existing implementations (yes, they implemented the spec with filed errata, the spec is sometimes ambiguous but those implementations are already on the market).What we have is a situation where no one has implemented RFC 7170, and there is no practical path to implementing it. As a result, the -bis revision is documenting the implementations. i.e. "this is what's going on" versus "what should be going on". It would be more relevant to update the version when there are incompatible changes to the protocol, *and* existing implementations which need to know which version they're negotiating. Since there is only one "TEAP version 1", I would argue that there's no need to change the version. Plus, if we change the version, then people have no idea what's currently implemented. TEAP version 1 becomes an undocumented mess of unknowns. As an implementor, I'm happy to declare RFC 7170 as irrelevant, and to issue a new standard which defines TEAP version 1 "as implemented". Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
