Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]