Channel.I.Messages needs some way for clients to discover which headers are supported
Submitted by Will Thompson @wjt
Assigned to Telepathy bugs list
Description
So. Message headers (and to a lesser extent body fields) fall into various categories:
• CMs must set this header on messages; clients must not (e.g. scrollback, message-sent, message-received) • CMs must support this header; clients may set it (e.g. message-type) • CMs may set this header on messages; clients must not set it (e.g. message-token¹) • CMs may support this header on messages; clients may set it (currently just sender-nickname; this also applies to most of the headers I'm defining at the moment like message-subject, supersedes (bug 25636), message-validity (SMS), message-to/cc/bcc)
So the first two classes are unproblematic. CMs implement them, and clients can look for them (and set them in the second case) or ignore them.
The third class is also okay, I think: CMs can implement them, and clients can look for the header but just deal if it's missing, as with all headers.
The fourth class is a problem. How does the UI know that it's on MSN using Butterfly, and hence can set sender-nickname? Ditto XMPP and message-subject; Skype (and maybe ll-xmpp) and supersedes; etc.
I think the way to do this is to split the fourth set out in the spec, and have a property listing which extra properties clients can set on outgoing messages on this channel. (The property is immutable, but isn't requestable so doesn't really fit in RCCs, which is a bit annoying.)