Issue #18 URI path processing

Define URI transport as description list with HTTP/1.0 and HTTP/3 included.

spec/src/main/asciidoc/servlet-spec-body.adoc

@@ -1306,14 +1306,17 @@ The process described here adapts and extends the URI canonicalization process d
 Servlet containers may implement the standard Servlet URI path canonicalization in any manner they see fit as long as the end result is identical to the end result of the process described here. Servlet containers may provide container specific configuration options to vary the standard canonicalization process. Any such variations may have security implications and both Servlet container implementors and users are advised to be sure that they understand the implications of any such container specific canonicalization options.
 
 ==== URI Transport
-===== HTTP/1.1
-The URI is extracted from the `request-target` as defined by [RFC 7230](https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.1). URIs in `origin-form` or `asterisk-form` are passed unchanged to stage 2. URIs in `absolute-form` have the protocol and authority removed to convert them to `origin-form` and are then passed to stage 2. URIs in `authority-form` are outside of the scope of this specification.
+HTTP/0.9:: The URI is the `document address` as defined by the W3C [Original HTTP](https://www.w3.org/Protocols/HTTP/AsImplemented.html) document.
 
-===== HTTP/2
-The URI is the `:path` pseudo header as defined by [RFC 7540](https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.3) and is passed unchanged to stage 2.
+HTTP/1.0:: The URI is extracted from the `Request-URI` in the `Request-Line` as defined by [RFC 1945](https://datatracker.ietf.org/doc/html/rfc1945#section-5.1). URIs in `abs_path` form are passed unchanged to subsequent steps. URIs in `absoluteURI` have the protocol and authority removed to convert them to `origin-form` and are then passed the subsequent steps.
 
-===== Other protocols
-Containers may support other protocols. Containers should extract an appropriate URI for the request from the protocol and pass it to stage 2.
+HTTP/1.1:: The URI is extracted from the `request-target` as defined by [RFC 7230](https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.1). URIs in `origin-form` are passed unchanged to subsequent steps. URIs in `absolute-form` have the protocol and authority removed to convert them to `origin-form` and are then passed the subsequent steps. URIs in `authority-form` or `asterisk-form` are outside of the scope of this specification.
+
+HTTP/2:: The URI is the `:path` pseudo header as defined by [RFC 7540](https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.3) and is passed unchanged to stage 2.
+
+HTTP/3:: The URI is the `:path` pseudo header as currently defined by the [draft RFC](https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34).
+
+Other protocols:: Containers may support other protocols. Containers should extract an appropriate URI for the request from the protocol and pass it to stage 2.
 
 ==== Separation of path and query
 The URI is split by the first occurrence of any '?' character to path and query.  The query is preserved for later handling and the following steps applied to the path.