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.)
Re GetContactListAttributes: I find it sad that special timeout has to be written for this method; is it a generally accepted practice across Telepathy? This will require special work for bindings and clients. Maybe a property/signal pair could be added so that clients could wait on the signal, and know that GCLA will return empty if called while contact list synchronization is pending?
(In reply to comment #1) > Re GetContactListAttributes: Oops, please ignore this misplaced comment.
> 3. CMs may set this header on messages; clients must not set it (e.g. > message-token¹) What was footnote 1 meant to be?
> 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) ... > [This] 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.) All(?) current implementations just ignore unrecognized headers, which is the behaviour I intended Messages to have. I think this subdivides further: 4a. "Unimportant" hints. CMs may support this header on messages; clients may set it. If the CM doesn't support it, it's ignored, and that's OK; the message was delvered in a best-effort way. If the CM indicates that it doesn't support it, the client MAY hide the UI for it, or just send it unconditionally. IMO, message-validity and sender-nickname are in this class, and probably supersedes too - if you don't understand how to supersede messages, the fallback behaviour of treating the new message as independent is ugly but legible. Whether subject is in this class is debatable. 4b. Important semantic differences. CMs may support this header on messages; clients may set it, but should not set it if unsupported, because the behaviour if it's not understood will differ significantly. I'd assumed that message-to, message-cc and message-bcc were in this class, but having read your branch again, I'm not so sure: the intention of the branch seems to be that the recipients are determined by the channel's members. If you set message-bcc:[Bob] and the CM doesn't understand it, then the fact that Bob is a recipient is leaked, but that's the best you can do on a protocol where recipients of multi-recipient messages are always revealed to other recipients.
(In reply to comment #4) > IMO, message-validity and sender-nickname are in this class, and probably > supersedes too - if you don't understand how to supersede messages, the > fallback behaviour of treating the new message as independent is ugly but > legible. For outgoing messages, the UI needs to know whether it should suggest to the user that it can edit messages. For incoming messages I agree.
-- 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-spec/issues/74.
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.