http://tools.ietf.org/html/rfc2812#section-5.1 specifies that RPL_WHOISUSER contains "<nick> <user> <host> * :<real name>". It would be useful for clients to have access to the user and host as well as the real name.
Created attachment 87831 [details] [review] patch
Comment on attachment 87831 [details] [review] patch Review of attachment 87831 [details] [review]: ----------------------------------------------------------------- ::: src/idle-contact-info.c @@ +455,5 @@ > + _insert_contact_field(request->contact_info, "x-client-username", NULL, field_values); > + > + name = g_value_get_string(g_value_array_get_nth(args, 2)); > + field_values[0] = name; > + _insert_contact_field(request->contact_info, "x-client-hostname", NULL, field_values); The x-client-hostname can also be a cloak on networks that have them. Given that we already have a x-host field, maybe we should choose a different name? I don't know.
I'd like to see a patch for telepathy-spec (more specifically spec/Connection_Interface_Contact_Info.xml) which adds these pseudo-fields to the <tp:docstring> of VCard_Field, perhaps something like this in a <dl> (but please note that I'm reverse-engineering these descriptions from telepathy-idle source code, so I might be wrong): In addition to standardized vCard fields, Telepathy defines several non-standard fields: x-irc-server A sequence of up to two strings, in which the first is the name of a specific server within the IRC network (e.g. irc1.eu.example.net) and the second, if present, is human-readable information about that server x-presence-type The ASCII decimal value of a Connection_Presence_Type, used on protocols such as IRC where presence information is not necessarily "pushed" to contacts, but must be polled infrequently <tp:rationale> IRC's "away messages" don't fit the SimplePresence interface well, because that interface assumes an XMPP-like "push" model. </tp:rationale> x-presence-status-identifier The well-known string identifier of a presence status, such as "away", on protocols where x-presence-type is used. This corresponds to the second element of a Simple_Presence. x-presence-status-message The human-readable part of a presence status, such as "Gone to lunch", on protocols where x-presence-type is used. This corresponds to the third element of a Simple_Presence. x-irc-operator The literal string "true" if the contact is an IRC operator as described in RFC 2812 §1.2.1.1, or the literal string "false" if they are not. Note that channel operators ("ops"), typically denoted by the @ prefix in IRC clients, are not usually IRC operators. x-irc-registered-nick The literal string "true" if the contact's nickname is registered with the IRC network's services (e.g. NickServ) or the literal string "false" if not. x-irc-secure-connection The literal string "true" if the contact is connected to their server via a secure connection (SSL/TLS), or the literal string "false" if not. x-irc-channel An channel in which this contact is present. This field takes an optional type-parameter "role" whose value is a prefix used to denote the contact's role in the channel. This field may be repeated. For instance, a contact who is a channel operator ("op") in #telepathy, a moderator ("voice") in #farstream and an ordinary user in #dbus and #chat might have this contact info: ("x-irc-channel", ["role=@"], ["#telepathy"]), ("x-irc-channel", ["role=+"], ["#farstream"]), ("x-irc-channel", [], ["#dbus"]) ("x-irc-channel", [], ["#chat"]) x-host [I'm not sure what this means, please fill it in] x-idle-time The ASCII decimal number of seconds for which this user has been idle. To put HTML in a <tp:docstring> you have to use <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> - see VCard_Field_Address_Map for an example of that.
(In reply to comment #2) > The x-client-hostname can also be a cloak on networks that have them. Given > that we already have a x-host field, maybe we should choose a different > name? I don't know. What's the difference between x-host and x-client-hostname? Is it just "how we got the information"? Concrete example: the Unix user jsmith at client45285.cablemodem.example.net sets his "real name" to "Joe Smith" and connects to irc2.eu.freenode.net, where he takes the nickname Joe. His IRC client sends "jsmith" in the USER message, and responds to identd to confirm that his username is jsmith. Am I right in thinking that he would have this? ("fn", [], ["Joe Smith"]), ("nickname", [], ["Joe"]), ("x-host", [], ["client45285.cablemodem.example.net"]), ("x-client-username", [], ["jsmith"]), ("x-client-hostname", [], ["client45285.cablemodem.example.net"]), ("x-irc-server", [], ["irc2.eu.freenode.net"]), Another concrete example: jjones connects from the same location to the same server, with real name "Jane Jones" and nick "Jane". Jane is a Red Hat employee and has been given the "cloak" redhat/janej. Her IRC client does not respond to identd, and her claimed identity in the USER message is "jj". Would she have this? ("fn", [], ["Jane Jones"]), ("nickname", [], ["Jane"]), ("x-host", [], ["redhat/janej"]), ("x-client-username", [], ["~jj"]), ("x-client-hostname", [], ["redhat/janej"]), ("x-irc-server", [], ["irc2.eu.freenode.net"]),
Attachment #46403 [details], which added x-host, says: > The RPL_WHOISHOST message indicates the host name and IP address from > which the nick is connected to the server. This message is received > only if the nick against which the WHOIS message was sent is the one > that sent the it. Please clarify? Do you mean "you only get this if you do a whois on yourself, not if you do a whois on other people"? If you do, then perhaps x-irc-hostname could be described in terms like "the hostname from which the client connected, or a "mask" or other pseudo-hostname if the client's real hostname has been hidden" and x-host could be described in terms of it being less likely to be available than x-irc-hostname, but more likely to be really a hostname if present?
(In reply to comment #4) > (In reply to comment #2) > > The x-client-hostname can also be a cloak on networks that have them. Given > > that we already have a x-host field, maybe we should choose a different > > name? I don't know. > > What's the difference between x-host and x-client-hostname? Is it just "how > we got the information"? x-host is only returned if you are doing a WHOIS on your own nick, and it is unaffected by any cloaks that you might have. x-client-hostname is always there, and might have a cloak if the target user has one. > Another concrete example: jjones connects from the same location to the same > server, with real name "Jane Jones" and nick "Jane". Jane is a Red Hat > employee and has been given the "cloak" redhat/janej. Her IRC client does > not respond to identd, and her claimed identity in the USER message is "jj". > Would she have this? > > ("fn", [], ["Jane Jones"]), > ("nickname", [], ["Jane"]), > ("x-host", [], ["redhat/janej"]), > ("x-client-username", [], ["~jj"]), > ("x-client-hostname", [], ["redhat/janej"]), > ("x-irc-server", [], ["irc2.eu.freenode.net"]), Assuming that Jane is WHOISing her own nick (otherwise she wouldn't have a x-host), her x-host might look like: ["*@client45285.cablemodem.example.net"], [2a01:4f8:191:2334::2]
(In reply to comment #5) > Attachment #46403 [details], which added x-host, says: > > > The RPL_WHOISHOST message indicates the host name and IP address from > > which the nick is connected to the server. This message is received > > only if the nick against which the WHOIS message was sent is the one > > that sent the it. > > Please clarify? Do you mean "you only get this if you do a whois on > yourself, not if you do a whois on other people"? Yes. > If you do, then perhaps x-irc-hostname could be described in terms like "the > hostname from which the client connected, or a "mask" or other > pseudo-hostname if the client's real hostname has been hidden" and x-host > could be described in terms of it being less likely to be available than > x-irc-hostname, but more likely to be really a hostname if present? Yes, sounds correct to me.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-idle/issues/47.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.