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
