Subject: [Taps] Fwd: New Version Notification for draft-duke-taps-transport-discovery-00.txt

From: Martin Duke <[email-masked]>
Date: Fri, 9 Apr 2021 14:05:21 -0700

Here 'tis.

---------- Forwarded message ---------
From: <[email-masked]>
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-masked]>

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-masked] or on the GitHub repository which contains
   the draft: https://github.com/martinduke/draft-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.

The IETF Secretariat

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 13 Apr 2021 15:30:09 +0000

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-masked]> on behalf of Martin Duke <[email-masked]>
Date: Friday, 9. April 2021 at 23:06
To: taps WG <[email-masked]>
Subject: [Taps] Fwd: New Version Notification for draft-duke-taps-transport-discovery-00.txt

Here 'tis.

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>>

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:

   Discussion of this work is encouraged to happen on the TAPS IETF
   mailing list [email-masked]<mailto:[email-masked]> 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

---

From: Martin Duke <[email-masked]>
Date: Mon, 19 Apr 2021 11:20:21 -0700

Hi Mirja!

On Tue, Apr 13, 2021 at 8:30 AM Mirja Kuehlewind <
[email-masked]> wrote:

>    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.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Apr 2021 21:10:05 -0700

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:
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Christian Huitema <[email-masked]>
Date: Fri, 23 Apr 2021 07:52:45 -0700

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"?
>