Change:
I think the intro currently doesn't fit well the content of the document as any motivation for this work should be in the Arch doc. If we want to retain the text that I deleted we can maybe add it to the Intro or background section in the Arch doc...? Note that the second paragraph I've added is stolen from the intro of the Arch doc.
NAME I can't see how the existing text that NAME proposed to delete could reasonably be merged with the intro text of the architecture doc? and the text that's there now motivates TAPS just as nicely, IMO. I would be inclined to just delete the text and do the update exactly as NAME proposes here.
I agree with NAME , I like the new text much better and I do not think we should add the removed text to arch.
I think the text did its duty and it's time to let go...
I don't have a strong opinion on this, for me it's fine to have some motivation in this document as well. However, if we delete the motivation from this document, let's put it in the -architecture, please - I would really like us to keep this text URL so dies the last text from the original post sockets paper ;( lgtm :)I like this; I think it improves the flow of the text, and I agree that the prior text is too motivational in style for this document. Even stealing a paragraph from the arch draft won't matter, I think.I really like this new intro and would like to have it irrespectively of moving the text as proposed in

Discussion:
1. <del> The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing network sockets into the UNIX programming model, allowing anyone who knew how to write programs that dealt with sequential-access files to also write network applications, was a revolution in simplicity.  The simplicity of this API is a key reason the Internet won the protocol wars PROTOCOL-WARS of the 1980s.  SOCK_STREAM is tied to the Transmission Control Protocol (TCP), specified in 1981 RFC0793.  TCP has scaled remarkably well over the past three and a half decades, but its total ubiquity has hidden an uncomfortable fact: the network is not really a file, and stream abstractions are too simplistic for many modern application programming models. In the meantime, the nature of Internet access, and the variety of Internet transport protocols, is evolving.  The challenges that new protocols and access paradigms present to the sockets API and to programming models based on them inspire the design principles of a new approach, which we outline in principles. This document builds a modern abstract programming interface atop the high-level architecture for transport services defined in I-D.ietf- taps-arch.  It derives specific path and protocol selection properties and supported transport features from the analysis provided in RFC8095, I-D.ietf-taps-minset, and I-D.ietf-taps- transport-security.  The design encourages implementations underneath the interface to dynamically choose a transport protocol depending on an application's choices rather than statically binding applications to a protocol at compile time.  We note that transport system implementations SHOULD provide applications a way to override transport selection and instantiate a specific stack, e.g. to support servers wanting to listen to a specific protocol.  This specific transport stack choice is discouraged for general use, as it comes at the cost of reduced portability. </del> <ins> This document specifies a modern abstract programming interface atop the high-level architecture for transport services defined in I- D.ietf-taps-arch.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from. As applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the application requirements and network conditions, without requiring changes to the applications.  This flexibility enables faster deployment of new features and protocols.  It can also support applications by offering racing and fallback mechanisms, which otherwise need to be implemented in each application separately. It derives specific path and protocol selection properties and supported transport features from the analysis provided in RFC8095, I-D.ietf-taps-minset, and I-D.ietf-taps-transport-security.  The design encourages implementations underneath the interface to dynamically choose a transport protocol depending on an application's choices rather than statically binding applications to a protocol at compile time.  We note that transport system implementations SHOULD provide applications a way to override transport selection and instantiate a specific stack, e.g. to support servers wanting to listen to a specific protocol.  This specific transport stack choice is discouraged for general use, as it comes at the cost of reduced portability. </ins> 2.