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