I worry that a registry will somewhat heavyweight with unclear benefits.
I'm in favor of punting on this topic for the moment. Does anyone
feel sufficiently passionate about this topic to lead a discussion in
Bangkok? I'd prefer not to use interim meeting time and focus on the
docs.
For what it is worth: I think this is an attempt to standardise some
names... and avoid many variants of the same. That may work, or it may
fail horribly. which to me depends on the interests of TAPS developers
in standardising cross-platform support. I think I suggested anyway if
we go this
Hi, all,
I'd see the contents of the appropriate sections of taps-interface (7.3 and
12.3 in the current editor's copy at
https://taps-api.github.io/drafts/draft-ietf-taps-interface.html) as the
initial contents of these registries, and MTI as per the (normative) RFC
taps-interface will
That's a good point—if a registry were to be complete to include what all
various implementations and transport protocols supported, the list (I imagine)
would be quite long and include many fairly obscure and optional extensions.
From an application developer's point of view, just because
Hi all,
I like the idea too, but I also wonder: does this give us a risk that the whole
system could become super-flexible, obscure and non-implementable at some point?
But maybe that’s easily solved, by stating that only the transport properties
in RFCs are required to implement, and
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Services WG of the IETF.
Title : A Minimal Set of Transport Services for End Systems
Authors : Michael Welzl
