Wow! The robot can write long messages, too. Good work, everyone! Cheers,
Brian > On 22 Nov 2019, at 16:00, TAPS WG status robot <[email protected]> > wrote: > > Friday November 22, 2019 > > Issues > > ietf-tapswg/api-drafts (+12/-25/💬38) > 12 issues created: > > • #384 Experimental cost property: cost preference (by mwelzl) API > discuss > • #382 Multicast impact on architecture? (by abrunstrom) Architecture > • #375 Multiple receives convenience feature (by MaxF12) > • #374 Protocols in Figure 2 (by abrunstrom) Architecture > • #373 Transport Properties are not Connection Objects (by abrunstrom) > • #371 Do we need an example for an HTTP/1, HTTP/2, HTTP/3 agnostic > connection? (by philsbln) > • #367 Implementation - PMTU text is broken (by gorryfair) > Implementation ready for text > • #366 Some editorial (I hope) comments on implementation (by > gorryfair) > • #365 Architecture: Editorial comments (by theri) > • #364 Update wording where interface to security protocol implies > racing/abstraction (by squarooticus) > • #363 "Access to Specialized Features" example: Security protocols (by > theri) Architecture > • #362 -impl should say more about use of ALPN (by mirjak) Architecture > 21 issues received 38 new comments: > > • #375 Multiple receives convenience feature (6 by britram, mwelzl, > philsbln, tfpauly, MaxF12) API discuss > • #384 Experimental cost property: cost preference (5 by philsbln, > mwelzl, gorryfair, tfpauly) API discuss > • #362 -impl should say more about use of ALPN (3 by philsbln, > gorryfair, theri) Implementation > • #363 "Access to Specialized Features" example: Security protocols (3 > by philsbln, abrunstrom, squarooticus) Architecture > • #382 Multicast impact on architecture? (3 by tfpauly) Architecture > • #305 Protocol stacks that are not equivalent (2 by britram, theri) > Architecture > • #374 Protocols in Figure 2 (2 by mwelzl, tfpauly) Architecture > • #258 Do we need a terminology section in arch? (1 by britram) > Architecture discuss > • #145 Draft should point at implementations somewhere (1 by tfpauly) > Implementation ready for text > • #150 Add Unidirectional Streams for Multicast / Source and Sink > support (1 by MaxF12) API Implementation ready for text > • #154 Structure of implementation draft (1 by tfpauly) Implementation > • #177 Privacy considerations section (1 by tfpauly) API Implementation > ready for text > • #299 TAPS ARCH - Textual review to notes (1 by tfpauly) Architecture > • #45 Do we need to make state storage explicit in the architecture and > API? (1 by britram) API Architecture ready for text > • #312 Detailed author review of Arch text for -03 to prepare -04 (1 by > tfpauly) Architecture ready for text > • #324 Add explicit protocol selection. (1 by britram) API ready for > text > • #334 Consider message send API that takes padding policy as input (1 > by britram) API future work > • #357 Default values (1 by britram) API discuss ready for text > • #364 Update wording where interface to security protocol implies > racing/abstraction (1 by theri) > • #365 Architecture: Editorial comments (1 by britram) Architecture > • #249 API needs a way to handle "STARTTLS" (1 by britram) API > Architecture discuss > 25 issues closed: > > • #384 Experimental cost property: cost preference API discuss > • #150 Add Unidirectional Streams for Multicast / Source and Sink > support API Implementation ready for text > • #154 Structure of implementation draft Implementation > • #145 Draft should point at implementations somewhere Implementation > ready for text > • #382 Multicast impact on architecture? Architecture > • #365 Architecture: Editorial comments Architecture ready for text > • #374 Protocols in Figure 2 Architecture > • #324 Add explicit protocol selection. API ready for text > • #206 Define the server-side equivalent of racing API Architecture > ready for text > • #309 Clarification on queued receives API ready for text > • #178 Architecture privacy and security considerations Architecture > ready for text > • #347 "Events" versus "Callbacks" for security-relevant asynchrony API > Architecture ready for text > • #300 Add property for address privacy API ready for text > • #303 More expressive multipath transport property API ready for text > • #334 Consider message send API that takes padding policy as input API > future work > • #375 Multiple receives convenience feature API discuss > • #299 TAPS ARCH - Textual review to notes Architecture > • #45 Do we need to make state storage explicit in the architecture and > API? API Architecture ready for text > • #282 Implementation should describe how to handle proxies/TOR > Implementation discuss help wanted > • #357 Default values API discuss ready for text > • #306 Failure of unsatisfiable configurations API > • #270 Add re-initiate() call for voluntary connection migration API > future work > • #258 Do we need a terminology section in arch? Architecture discuss > • #249 API needs a way to handle "STARTTLS" API Architecture discuss > • #312 Detailed author review of Arch text for -03 to prepare -04 > Architecture ready for text > Pull requests > > ietf-tapswg/api-drafts (+13/-11/💬11) > 13 pull requests submitted: > > • #383 Editorial comments, fixes #365 (by theri) > • #381 Move Transport Properties text and close #373 (by philsbln) > • #380 Add clarification on Multicast receive to API (by MaxF12) > • #379 TAPS allows you to dynamically choose protocol stacks, we should > say so. (by britram) > • #378 closes #324 (by mwelzl) > • #377 Partial receives are not reordering preferences; fix #309 (by > britram) > • #376 Add text for server-side "racing" (by tfpauly) > • #372 Address privacy property, #300 (by tfpauly) > • #370 Add multipath property enumeration (by tfpauly) > • #369 add dates to references, and clean up spurious ones (by britram) > • #368 be explicit and careful about callbacks vs events; fix #347 (by > britram) > • #361 fixes for a few nits (by GrumpyOldTroll) > • #360 udp multicast receive (#150) (by GrumpyOldTroll) > 3 pull requests received 11 new comments: > > • #360 udp multicast receive (#150) (9 by MaxF12, philsbln, mwelzl, > theri) > • #378 closes #324 (1 by britram) > • #380 Add clarification on Multicast receive to API (1 by philsbln) > 11 pull requests merged: > > • #380 Add clarification on Multicast receive to API > • #383 Editorial comments, fixes #365 > • #379 TAPS allows you to dynamically choose protocol stacks, we should > say so. > • #376 Add text for server-side "racing" > • #377 Partial receives are not reordering preferences; fix #309 > • #368 be explicit and careful about callbacks vs events; fix #347 > • #370 Add multipath property enumeration > • #372 Address privacy property, #300 > • #369 add dates to references, and clean up spurious ones > • #360 udp multicast receive (#150) > • #361 fixes for a few nits > Repositories tracked by this digest: > > • https://github.com/ietf-tapswg/api-drafts > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
