What are you trying to achieve?

Generalize the http.url, http.scheme, and http.target attributes so they can be used by different semantic conventions.

See @reyang's #2489 (comment):

I will give an example which shows how we end up with if we call it http.url:

1. A vendor is building an anti-virus software which records all the outgoing networking access, and for L7 actions, the software supports both FTP and HTTP.
2. The vendor would want to have a table which looks like:

   | timestamp | user   | url.full              | blocked |
   | --------- | ------ | --------------------- | ------- |
   | T1        | reiley | http://wikipedia.org/ | no      |
   | T2        | reiley | http://microsoft.com/ | no      |
   | T3        | reiley | ftp://bad/malware     | yes     |
   

3. If we ask folks to use http.url and ftp.url, they will either end up with a sparse table that is hard to use, or they have to put things to different tables, or they will push for a new major version of semantic convention.

Additional context.

ECS already has url.* namespace: https://www.elastic.co/guide/en/ecs/current/ecs-url.html

If we want to follow ECS naming, we could rename:

• http.scheme -> url.scheme
• http.url -> url.full
• http.target -> split into url.path + url.query