Arguing the alternative history is probably not all that productive and may explain some of the disagreement in this discussion. (as in "Would protocol X have taken off twenty years ago if all implementations had been strict or if the spec had been less forgiving?") We do seem to have incurred a technical debt - and maybe that's a related concept that should be mentioned, as this is clearly not just a protocol or networking problem.
We now have better tools and a larger community of (more professional) developers. Sometimes good advice that worked in 1990 is no longer as good advice now.
Henning
On Tue, May 7, 2019 at 5:45 PM Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:
Hiya,
Just to clarify where I'm coming from...
On 07/05/2019 22:32, Christian Huitema wrote:
> The alternative is what I see in "modern" specifications, like e.g. QUIC.
ISTM taking the approach outlined in Martin's draft with QUIC
is a good plan. I also know that this approach has improved
TLS even though TLS didn't start out doing things this way.
And I can totally buy it being valuable to at least consider
taking this approach for any new work. So I do like the core
idea on which the draft is based.
I'm just not sure as to how generally it can be applied, nor
if we can really say that "if only protocol X had taken this
approach, things would have turned out better."
S.
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/architecture-discuss
