On Thu Jan 5 16:18:27 2012, Mike Wacker wrote:
I understand that you disagree, but I want to get a better
understanding of your disagreement, in particular the server
concerns. (Would I be right in assuming this decision is more
server-driven than client-driven?)
I think the arguments will be found in the archives.
First, I hope that we can agree that in the "ideal" world (though I
acknowledge no world is ideal and that things like scalability
don't grow on trees), the protocol should be designed around user
experiences and client use cases, not server implementation details.
Right, that's fine, but whether or not there is additional wrapping
is immaterial.
But it seems like we have two types of server implementations:
those which can easily handle the change and those which cannot.
For clients or servers which can easily handle the change, this
message wrapping logic serves no useful purpose and is extra
overhead. For servers which cannot easily handle the change, this
change will have a significant effect in terms of reducing the
implementation cost, but at a (smaller) cost expense to client and
servers which can easily handle the change.
Speaking as a server implementor, I can more or less drop any old
garbage down the pipe to a client.
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.
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.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
