On 1/4/2012 6:27 AM, Matthew Miller wrote:
On Jan 4, 2012, at 03:57, Kevin Smith wrote:
I've just been reading through the current version of
http://xmpp.org/extensions/xep-0280.html and have a couple of
comments:
In example 14, we have:
<message xmlns='jabber:client'
from='[email protected]'
to='[email protected]/home'
type='chat'>
<forwarded xmlns='urn:xmpp:forward:0'>
<received xmlns='urn:xmpp:carbons:1'/>
<message>...</message>
</forwarded>
</message>
I think it makes more sense to have the forwarded payload inside the
received payload, instead of the reverse. I think this because the
forwarded message is a feature of the carbon, rather than the reverse
(Carbons depends on Forwarding, Forwarding doesn't depend on Carbons).
See my comment in the other thread.
Second is regarding
"Upon receiving an inbound or outbound gone chat state (as a carbon
copy) for a given conversation, that conversation SHOULD be removed
from user display"
I think we should be avoiding mandating (at least non-security
critical) UI features - I think this is a simple tweak from normative
'SHOULD' to 'is suggested' or similar.
/K
That's a fair suggestion.
- m&m
<http://goo.gl/LK55L>
Let me suggest a bolder idea. Why do we need to wrap the carbons using
Message Forwarding at all instead of just delivering the message stanzas
as is? You will only receive these additional message carbons if your
client supports carbons and enables carbons. Thus, if a client has
carbons enabled, if it receives a message not sent to its bare JID or
full JID (either a message from one of its other resources to a buddy or
from a buddy to one of its other resources), it can reasonably infer
that the message is a carbon.
The standard use cases for message carbons is to ensure that a given
device will receive both sides of all conversations, and that use case
is covered regardless of whether we wrap carbons or not. I can't think
of any use case for the special wrapping logic, though.
This would greatly simplify the XEP (as well as eliminate a dependency
on an experimental XEP more complex than message carbons itself), as
servers would only have to route the messages and not modify them, and
clients won't need special parsing logic for carbons.
Mike
