If we are serious about discussing a V2 in this group, we should have a
convention for allocating version numbers to drafts of V2. For V1, we
used a version numbering scheme of 0xFF0000NN, with NN the number of the
draft. What should we do for the V2 effort? Something like "FF0100NN"?
On 4/19/2021 11:20 AM, Martin Duke wrote:
Hi Mirja!
On Tue, Apr 13, 2021 at 8:30 AM Mirja Kuehlewind <
[email protected]> wrote:
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.
I have not completely thought this through, but I believe it will be very
similar, modulo various language issues (e.g. no support for objects)
1. 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…?
Yes, my initial intent for these to exactly map to the protocol properties
in taps-interface.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
