On 1/5/2012 10:30 AM, Dave Cridland wrote:
I think the arguments will be found in the archives.
XEP-0280 version 0.1 was marked as deferred on Jun 27, 2011, and then it
was updated to version 0.2 on July 10, 2011, which introduced the
wrapping. Between these two dates, I don't see any discussion about it
on the standards mailing list, though there was some discussion about
version 0.2 which led to version 0.3 one day later.
However, RFC 6120 defined what the to and from attributes mean, and an
extension can't really change this - I think it breaks too many
assumptions with third-party software such as guards and other Layer-7
filtering devices. Such things do exist, and are deployed.
This would only apply to outbound messages. RFC 6120 allows inbound
messages where the bare JID for 'to' matches but the full JID does not
match.
For outbound messages, nothing explicitly says an extension MUST NOT do
self fan-out (w/o wrapping the message) in addition to following the
rules in RFCs 6120/1. But an implementation note in RFC 6120, 8.1.1.1
seems to imply that the recipient's bare JID must match the bare JID in
the stanza's 'to' attribute. It may not hurt to more explicitly spell
this restriction out in somewhere other than an implementation note,
since self fan-out is a legitimate use case (whereas sending the stanza
to a random person is probably not a legitimate use case).
---
This also leads back to why I don't think we need to take a dependency
on message forwarding. Forwarding is more "complex" because the
forwarded recipient can be anyone, and the message can be forwarded at
any time. Whereas with carbons, the only use case is for fan-out to
other resources of the sender (or recipient if we wrap those carbons,
too), and the carbons are delivered at the same time as the original
message. The only use case for carbons, sender(/recipient) fan-out, is
different than the expected use case for forwarding, forwarding to a 3rd
party other than the sender or recipient. The business rules for message
forwarding suggest that chat state notifications may be omitted, whereas
the business rules for carbons intentionally keep them.
Thus, for carbons, it may make sense to use a more targeted, simpler
solution. Not only would the UI experience be different for 3rd-party
forwarding compared to fanout, but it would be unfortunate if carbons
were stuck as an experimental XEP simply because the forwarding XEP was
still experimental due to points of contention or use cases which are
inapplicable to carbons.
As a client developer, of sorts, on occasion, I'd hate to have logic
that tried to guess whether this was a message for me, or a message
I'd sent to something else. I'd really hate it, actually.
I likely will concede the original point on a 'to' not matching your
bare JID anyway, but strictly for carbons this wouldn't be an issue.
Your filter would simply check both 'to' and 'from' for a matching bare
JID instead of just the 'to'.
