Subject: [Taps] Draft-ietf-taps-arch-08 review

From: Martin Duke <[email-masked]>
Date: Tue, 4 Aug 2020 15:26:35 -0700

I have read this document and believe it is ready for publication.

However, is it worthwhile to include something here about extensibility? If
new transports introduce new concepts, should we any requirements of the
api to have extension points for those concepts?

---

From: Martin Duke <[email-masked]>
Date: Wed, 5 Aug 2020 08:31:41 -0700

Also the authors should nominate a handful of editors to limit the byline.

On Tue, Aug 4, 2020 at 3:26 PM Martin Duke <[email-masked]> wrote:

> However, is it worthwhile to include something here about extensibility?
> If new transports introduce new concepts, should we any requirements of the

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 05 Aug 2020 08:48:04 -0700

Hi Martin,

On the author/editor side, please note that Brian and myself are already the editors for this document. The API and implementation documents also have two editors each.

For background see: https://github.com/ietf-tapswg/api-drafts/issues/184 <https://github.com/ietf-tapswg/api-drafts/issues/184>

I have been arguing for just having the editors being on the byline, with the rest of the authors in the document. It’s gotten to the point where we need to do manual submission of metadata since the data tracker doesn’t correctly parse dates when there are this many authors. But I was unable to gain agreement on this issue previously.

Regarding your comment about extensibility, I think we could add a sentence or two to Sections 3.1 and 3.2. The main extensibility point describe is in having transport-specific features that are impementation-specific. If there are entirely new functionalities that should become part of the standard/common API across implementations, then I imagine that would need to be an extension/bis to TAPS. 

Thanks,
Tommy

> On Aug 5, 2020, at 8:31 AM, Martin Duke <[email-masked]> wrote:
> 
> On Tue, Aug 4, 2020 at 3:26 PM Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
> However, is it worthwhile to include something here about extensibility? If new transports introduce new concepts, should we any requirements of the api to have extension points for those concepts?
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps