chore: phrasing, remove undefined term <host>

Author: arnoweiss

specifications/common/common.protocol.md

@@ -19,8 +19,8 @@ similar contexts that facilitate this approach to interoperability.
 
 [=Connectors=] implementing the [=Dataspace Protocol=] may operate on different versions and bindings. Therefore, it is
 necessary that they can discover such information reliably and unambiguously. Each [=Connector=]
-must provide a version metadata endpoint `<host>/.well-known/dspace-version`. The location of this endpoint should 
-adhere to the [[rfc8615]]. 
+must provide a version metadata endpoint ending with URI segments `/.well-known/dspace-version`. The location of this 
+endpoint should adhere to the [[rfc8615]].
 
 A [=Connector=] must respond to a respective HTTPS request by returning a [`VersionResponse`](#VersionResponse-table)
 with at least one item. The item connects the version tag (`version` attribute) with a path to the endpoint.
@@ -36,8 +36,8 @@ When using the DSP HTTPS binding, the `path` property is an absolute URL path se
 all endpoints of this version.
 
 The following example demonstrates that a [=Connector=] offers the HTTPS binding from version `2024-1` at
-`<host>/some/path/2024-1`, the `2025-1` endpoints at `<host>/some/path/2025-1` and another [=Connector=] on the same host
-under `<host>/<path-to-root>/different/path/2025-1` - some of which signal the relevant authentication protocol overlay, 
+`<base>/some/path/2024-1`, the `2025-1` endpoints at `<base>/some/path/2025-1` and another [=Connector=] on the same 
+base URL under `<base>/different/path/2025-1` - some of which signal the relevant authentication protocol overlay, 
 determined by `protocol`, `version` and the `profile` array.
 
 <aside class="example" title="Well-known Version Endpoint (HTTPS) at different root path">