Sorry about that, I replied to the wrong message. Please ignore.
On 4/22/2021 9:10 PM, Christian Huitema wrote:
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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
