From 8fa73c61845f1b1cca444a2adc01d773877e410f Mon Sep 17 00:00:00 2001 From: Marco Munizaga Date: Thu, 1 Jun 2023 11:11:50 -0700 Subject: [PATCH] reword section on HTTP version --- http/transport-component.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/http/transport-component.md b/http/transport-component.md index 8f844c9..4d8a932 100644 --- a/http/transport-component.md +++ b/http/transport-component.md @@ -34,14 +34,11 @@ An HTTP transport is simply a node that can speak some standardized version of HTTP. Intuitively if you can `curl` it with HTTP, then it speaks HTTP. Most environments will have a way to create an HTTP Client and Server, and the -specific HTTP version used will be opaque. The client will negotiate (or [learn -about](https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1.1)) the specific HTTP version to use when communicating -with the HTTP server. - -For this opaque case, we use the `/http` component at the end of the multidadr. -The end user agent decides on HTTP version to use, based on the multiaddr -prefix, application, server negotiation, and specific use case. This follows -what existing `http://` URL implementations do. +specific HTTP version used will be opaque. We use the `/http` component at the +end of the multidadr to signal that this server supports an HTTP transport. The +end user agent decides on HTTP version to use, based on the multiaddr prefix, +application, server negotiation, and specific use case. This follows what +existing `http://` URL implementations do. ## Multiaddr representation