Different IM protocols use a variety of ways to name chat rooms. The simplest example is perhaps IRC, where chat rooms have short, persistent, human-readable string names, and are generally global across the network. Skype chat rooms have persistent string names, so you can leave and re-join a room, but these names are opaque unique identifiers. MSN chat rooms are unnamed, and you can only join one by being invited. And XMPP wins the coveted “most complicated chat rooms” prize: chat rooms may be hosted by different servers with different DNS names; normally they have human-readable names, except that all MUCs on Google Talk's conference server have UUIDs as names, and XEP-0045 §10.1.4 Requesting a Unique Room Name defines a protocol for requesting a unique, opaque room name on the server.

This interface intends to support and differentiate these mechanisms more clearly than the TargetHandleType and TargetID properties can alone. It initially contains a pair of properties used to represent the human-readable parts of a Room_Handle's identifier, if any. The above examples for different protocols are represented as follows:

• The IRC channel #telepathy on Freenode is represented by a channel with properties TargetHandleType = Room, TargetID = "#telepathy", RoomName = "#telepathy", Server = "", indicating that the room has a human-readable identifier, and is not confined to a particular server on the network.

  Rationale:

  Actually, IRC supports creating “local” channels specific to the server they are created on. These channels have identifiers starting with & rather than #. These could be represented by setting Server appropriately.
• A Skype group chat with opaque identifier 0xdeadbeef has TargetHandleType = Room, TargetID = "0xdeadbeef", RoomName = "", Server = "", indicating that the room has an identifier but no human-readable name.
• An MSN group chat has TargetHandleType = None, RoomName = "", Server = "", indicating that the room has neither an identifier (so it cannot be re-joined later) nor a human-readable name.
• A standard Jabber multi-user chat jdev@conference.jabber.org has TargetHandleType = Room, TargetID = "jdev@conference.jabber.org", RoomName = "jdev", Server = "conference.jabber.org".
• A Google Talk private MUC private-chat-11111x1x-11xx-111x-1111-111x1xx11x11@groupchat.google.com has TargetHandleType = Room, TargetID = "private-chat-11111x1x-11xx-111x-1111-111x1xx11x11@groupchat.google.com", RoomName = "", Server = "groupchat.google.com", indicating that the room has a persistent identifier (FIXME: can you rejoin PMUCs if you part them? The spec isn't clear. If you can't, these should have THT None.), no human-readable name, and is hosted by a particular server.
• Similarly, a XEP-0045 §10.1.4 uniquely-named room lrcgsnthzvwm@conference.jabber.org has TargetHandleType = Room, TargetID = "lrcgsnthzvwm@conference.jabber.org", RoomName = "", Server = "conference.jabber.org", indicating that the room has a persistent identifier, no human-readable name, and is hosted by a particular server.

Requestable channel classes

If the connection supports joining text chat rooms by unique identifier, like Skype, it should advertise a Requestable_Channel_Class matching:

( Fixed = { ...ChannelType: ...Text,
            ...TargetHandleType: Room,
          },
  Allowed = [ ...TargetID,
              ...TargetHandle,
            ]
)

Channel requests should specify either TargetID or TargetHandle.

If, like IRC, the room identifiers are also human-readable, the RCC should also include RoomName in the allowed properties:

( Fixed = { ...ChannelType: ...Text,
            ...TargetHandleType: Room,
          },
  Allowed = [ ...TargetID,
              ...TargetHandle,
              ...RoomName,
            ]
)

Requests may specify the RoomName in place of TargetID or TargetHandle. If rooms may be on different servers, Server should also be included in the allowed properties, but CMs MUST use a reasonable default if Server is not explicitly specified in a channel request. FIXME: how do we specify the default room? A separate channel class with Server fixed?

If the protocol supports unnamed rooms, RoomName should be fixed to the empty string, and TargetHandleType should be None:

( Fixed = { ...ChannelType: ...Text,
            ...TargetHandleType: None,
            ...RoomName: "",
          },
  Allowed = [ ]
)

TODO: actually the classes for properties on this interface should not include THT: Room in Fixed, they should be separate. Document joining ad-hoc MUCs on different XMPP servers.