Hi Martin, hi all, I just had a quick glance at your draft and have two thoughts to offer:
1. How is the protocol API different then the taps API? If a new protocol already offers the taps API (without the actual flexibility to choose between more than one protocol of course), the mapping would be easy. 2. I guess you need something like MUD for protocol where capabilities of a protocol are described in a unified way. However, maybe the properties we have in taps is also more or less what you need…? Just some spontaneous thoughts. So please consume with care. I just thought they could yield some further ideas! Mirja From: Taps <[email protected]> on behalf of Martin Duke <[email protected]> Date: Friday, 9. April 2021 at 23:06 To: taps WG <[email protected]> Subject: [Taps] Fwd: New Version Notification for draft-duke-taps-transport-discovery-00.txt Here 'tis. ---------- Forwarded message --------- From: <[email protected]<mailto:[email protected]>> Date: Fri, Apr 9, 2021 at 1:50 PM Subject: New Version Notification for draft-duke-taps-transport-discovery-00.txt To: Martin Duke <[email protected]<mailto:[email protected]>> A new version of I-D, draft-duke-taps-transport-discovery-00.txt has been successfully submitted by Martin Duke and posted to the IETF repository. Name: draft-duke-taps-transport-discovery Revision: 00 Title: TAPS Transport Discovery Document date: 2021-04-09 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-duke-taps-transport-discovery-00.txt Status: https://datatracker.ietf.org/doc/draft-duke-taps-transport-discovery/ Html: https://www.ietf.org/archive/id/draft-duke-taps-transport-discovery-00.html Htmlized: https://tools.ietf.org/html/draft-duke-taps-transport-discovery-00 Abstract: The Transport Services architecture decouples applications from the protocol implementations that transport their data. While it is often straightforward to connect applications with transports that are present in the host operating system, providing a means of discovering user-installed implementations dramatically enlarges the use cases. This document discusses considerations for the design of a discovery mechanism and an example of such a design. Discussion of this work is encouraged to happen on the TAPS IETF mailing list [email protected]<mailto:[email protected]> or on the GitHub repository which contains the draft: https://github.com/martinduke/draft-duke-taps-transport-<https://protect2.fireeye.com/v1/url?k=01182b34-5e8313e6-01186baf-866132fe445e-4a7967b513112dd9&q=1&e=0a0e0d39-a2e9-4ff3-bfcf-048ae7181df8&u=https%3A%2F%2Fgithub.com%2Fmartinduke%2Fdraft-duke-taps-transport-> discovery. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. The IETF Secretariat
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
