On 24/07/2018, 10:23, John Grant wrote:
On 23/07/2018 21:15, Tommy Pauly wrote:
Hello TAPS,
Migrating a thread from GitHub to the email list, since it needs
broad WG input. I've pasted the discussion so far below.
Essentially, the question is if we have a set of standard properties
for Transport Services APIs, should they have a formal registry or not?
Maybe call it an ontology, as in metadata libraries, rather than a
registry.
The API is an interface between the application and the network, so it
needs to provide an abstraction of the service the network provides
that can be understood by each side without having to know too much
about how the other side is implemented. There's been some debate
about that in the DetNet group recently, too. Anyway, the API should
allow the application to specify byte stream or packet, constant bit
rate or bursty, latency requirements, tolerance of packet loss or
corruption, etc, but not ask it to select a particular protocol such
as TCP. Similarly, it should provide more abstract ways for the
application to say what it wants to talk to, e.g. specify a URL
directly rather than having to make a separate call of gethostbyname().
Of course, it should also provide a way for an application to request
features that are specific to a particular network technology, but
recognise that doing so compromises portability of the application.
--
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
John, I think if you take a look at the TAPS WG drafts, you'll now find
that much of what you hope exists in the current work.
I think the discussion of byte stream v. packet may be at a lower level
that we now envisage in TAPS, but as the TAPS work moves forward I
expect you'll find anything that was possible in a byte or packet stream
will also be possible via the higher-level API. In most cases, we have
also found the new abstraction to be also much simpler for developers to
code against. Do let us know if you have further comments on the WG drafts.
Gorry
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
