On Wed Mar 30 08:20:22 2011, Scott Brim wrote:
Right. You might add control boundaries. What's happening is that
the server is extending a pseudopod down into the user environment,
so
that the 'user agent' is within its control boundary. There will
still be other apps, other user agents, in the user environment that
are outside of service control -- they will need standardized
interfaces to services.
Please, Scott, Hannes, take the time to read this carefully.
The server/server protocol remains an open standard, indeed. But as
The Other Dave C says, there is still a client/server protocol, but
it's now (as clearly marked on Hannes's diagram) a proprietary one.
Any client/server interface that's forced into being an open standard
becomes a second-class citizen for legacy access.
You may believe this is not a big loss, but it is most unfortunate,
for two reasons:
- We [should] promote the use of open standards over proprietary ones.
There is more than mere pragmatism involved in standardization. We
don't merely want things to work, we want them to work well,
everywhere. By removing the ability to interoperate with full
features over the "last mile", we eliminate the ability to innovate
without operating a service provider, in effect, and unless that
service provider is particularly large, any innovation will simply be
duplicated by the larger ones, removing any incentive for smaller
outfits. Promoting innovation - and this is a much bandied-about term
which we can also phrase as "making things better faster" - needs to
occur by lowering barriers to entry.
The use of mobile code and (in effect) self-deploying clients does
indeed lower some barriers to entry, but it raises other ones.
- This model spells the death of end-to-end applications.
Hannes's diagram shows clearly that SIP is no longer spoken between
clients, in this brave new world, but only between servers. This
means that any intelligence - any interoperability - between services
has to now occur solely at the server/server link. In almost every
protocol which federates to any degree, this has proven to be a very
poor model.
It is unfortunate that every example chosen by Hannes et al provides
a clear example of both the above cases. To pick the two I'm most
familiar with:
1) Email - IMAP and POP - allows MUAs to send RFC 5321 formatted
emails to each other, and allows MUAs to independently adopt
end-to-end functionality signalled via this format. For example, iCal
(more specifically iMIP) operates without any support from the MTAs,
and indeed for certain points of view we can effectively ignore that
anything more than the MUA exists at all.
Similarly, innovation has continually occured at the edge -
Thunderbird, Opera Mail, and so on - all have innovated thanks to a
standards-based last mile.
2) Strophe.js - XMPP and BOSH. XMPP does have relatively smart
servers, as compared to other protocols, but it's very clear to
anyone who's paid much attention that innovation generally occurs
between endpoints on the XMPP network - even the XEP-0045 Multi User
Chat we're using in (almost?) every WG meeting this week - which we
cheerfully call "jabber" - occurs as a result of interactions between
and end-user client and the chat service directly, with the user's
own server actually playing the passive role of simply routing
stanzas from client to remote service with no knowledge of what the
stanzas might signify. Again, the end-to-end principle holds (where
appropriate), and allows us to ignore the servers' existence for much
of the use-cases.
BOSH provides a standardized interface to XMPP for web applications
(and in principle other applications too), and Strophe.js - and JsJAC
- both take advantage of this to provide both innovative and
standardized end-user services.
The majority of servers do not even ship with a standard client - I'm
only aware of two which do, and one of these (to my intense suprise)
actually uses a customized open-source client - which obviously
suggests that innovation occurs - at a fast pace, I'll add.
In my experience - and I can claim to have a fair amount in this area
- it is several orders of magnitude harder to get deployment of a XEP
which relies on both client support and every server in the path. In
fact, the only one I can think of is AMP (XEP-0079), which has zero
deployment. Even pure S2S protocols are hard - yet end-to-end
protocols such as XEP-0184 (which provides a simplified protocol for
one part covered by AMP) rapidly get wide deployment. It seems
inconceivable that the same pace of innovation could occur if the
client developers were cut out of the equation, especially given the
(necessarily) slow pace of the larger service providers.
The ability to embed XMPP functionality into a web page *is* very
useful, and very powerful. But this is nothing like the same as being
able to sling in some arbitrary javascript chat applet - the real
benefit of Strophe.js, BOSH, and XMPP is that you can provide a
direct gateway into the XMPP federation and access standardized
services directly from the browser.
And this is reliant on several open standards running over the last
mile.
Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf