[Bug 28740] Channel.I.Messages needs some way for clients to discover which headers are supported

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28740

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-06-29 02:48:36 PDT ---
> 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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.