Should domain name be allowed in client.address?

[trask]

          Either we need allow a domain name in the client.address as well, or we forbid it in the server address.

(I think mixing name and address is confusing and means potential information loss, as we can no longer report the name + address of the logical client/server at the same time, since both are stored in "address", but the HTTP conventions rely on this quirk already, and are in "Feature Freeze" -- you may call a potential split a bugfix though?)

Originally posted by @Oberon00 in #244 (comment)

[trask]

Adding the follow-up discussion from that comment:

@lmolkova:

is there a case when we know a client domain name and it's relevant on RPC calls?

At the same time changing this description and allowing domain name (if there is a tech that needs it) would not be a breaking change.

(and if we wanted to set client domain name on a client span, we'd probably prefer to do it on host.name resource attribute rather than client.address)

@Oberon00:

Host resource attribute is a good point. While a host can have multiple addresses & domain names and there could be a paricular one that is relevant for a particular operation, it definitely reduces the importance. Still, the difference should be called out & justified in the description.

[Oberon00]

Regarding my comment about the host resource attribute being helpful: I have to retract that. The confusing thing is that the resource still uses "host" from the host/peer concepts, while server is from the different server/client concept. So the host resource attribute could fit the client and server both equally well.

This makes me think that we should really consider adding a separate attribute for the name and forbidding/deprecating setting a name in address (both client & server side). Probably this asymmetry is also the reason for the domain asymmetry, #255.