Hello TAPS,

I posted an information draft a little bit ago that goes more into depth on the 
presentation I gave in Seoul about the requirements that protocol racing, etc, 
have on API design. It focuses on the ways in which API models can cause 
protocol ossification and stagnation, and how we can try to avoid this by 
making our APIs sufficiently flexible.

I see this mainly as an information document to use as a reference as we are 
working on Post-Sockets and other API efforts. Please take a read through it, 
and let me know your feedback! If the WG would like to adopt this, I'd be happy 
to continue working on it.

Best,
Tommy

> Begin forwarded message:
> 
> From: [email protected]
> Subject: New Version Notification for draft-pauly-taps-guidelines-00.txt
> Date: February 7, 2017 at 4:05:58 PM PST
> To: Tommy Pauly <[email protected]>
> 
> 
> A new version of I-D, draft-pauly-taps-guidelines-00.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
> 
> Name:         draft-pauly-taps-guidelines
> Revision:     00
> Title:                Software Guidelines for Protocol Evolution
> Document date:        2017-02-07
> Group:                Individual Submission
> Pages:                14
> URL:            
> https://www.ietf.org/internet-drafts/draft-pauly-taps-guidelines-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-pauly-taps-guidelines/
> Htmlized:       https://tools.ietf.org/html/draft-pauly-taps-guidelines-00
> 
> 
> Abstract:
>   This document outlines a set of recommendations and guidelines for
>   how networking software should be designed to enable the development,
>   testing, and deployment of new protocols and protocol features.  The
>   focus is primarily on the API contract that a client-side networking
>   library should present to applications using networking features, and
>   how that library can be architected to maximize flexibility and
>   longevity.
> 
>   Specific areas of protocol development that should be enabled
>   include:
> 
>   o  Making security and privacy easy to use
> 
>   o  Reducing latency with 0-RTT protocols
> 
>   o  Allowing wider use of multi-stream protocols
> 
>   o  Providing a simple interface for multi-path protocols
> 
> 
> 
> 
> 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
> 

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to