A real dial-tone

The concept of “killer app” is a powerful driver of our collective psychology. We want to believe that our entire community can be propelled forward and our lives reshaped by the next must-have technology. A search on “VoIP killer app” will give you an idea of the extend of this belief...
It's hard to get people excited about new frontiers and possibilities. Painting vivid and exciting pictures is not enough. They need to be credible. I earlier hinted at some of the reasons for considering presence the “new dial-tone”. Alec Saunders also looked at the decreasing value of Skype presence. I believe that his post is characteristic of many misconceptions attached to presence (in short IM is not presence, and AOL is not IM), although he probably wrote it on purpose... That said, he re-stated the major flaws of today's combined IM/VoIP messaging

• Presence tells you nothing about the person using the device at the other end. For example, it doesn’t indicate that I am talking when I am in a call.
• Presence gives me little to no control over who can reach me.
• Presence does not express my willingness to communicate.

I agree when he says the word presence cannot properly express whether I am willing to engage in a conversation. Same when he says we really mean availability, i.e. the result of processing presence information according to rules about our reachability. But this is yesterday's news. This difference was entirely detailed by the PAM forum many years ago. On the other hand, I believe Saunders is wrong when he says presence is a broken idea. He should have said the implementation of presence in all the existing IM or VoIP applications is broken. Not the idea of presence.

Generating the “new dial-tone” requires a tight integration between the presence aggregation engine, the availability inference engine and the presence notification engine. I will quickly expose why I believe XMPP as a protocol have a more appropriate design to support this integration and produce an accurate and useful dial-tone. A dial-tone that would signal busy when you do not want to be disturbed, and be your voice mail's dial-tone when you are in a meeting.

When establishing a point to point a voice communication, presence does not appear necessary. And de-facto, many VoIP services are only mimicking the PSTN model with a different technology. So much for those trying to make you believe they are “re-inventing telephony”. In doing so, VoIP is a bit of a side show. Establishing a bidirectional audio stream over a network is also yesterday’s news. VoIP only gets all the attention because of the PSTN charges and the sustained rush to mine them. Nonetheless, attempts at combining multimedia communications with presence have been around, at least on paper, for some times. Some implementations, such as Skype, call presence the information derived from authenticating on their system. AOL, along with other legacy services, is coming at VoIP from the instant messaging side. By adding voice to a client, it can claim offering a presence enabled VoIP service. Another interesting implementation is the upcoming 3GPP mobile phone service. The most courageous amongst you may read their thousand of specification pages to have an idea of how the carriers' world wants to use SIP presence extensions.

All these implementations have in common a “loose coupling” at protocol level between presence and call management. Skype's presence is irrelevant. AOL use a mix of proprietary instant messaging protocol with SIP signaling for the media sessions. The 3GPP IMS is SIP based, but provides presence as an “added value” service through the SIMPLE extensions to SIP.
SIP is a respectable player when it comes to negotiating point to point call sessions. It carries the weight of some big industry names behind it. But this concerns only SIP, not the integration of its presence extensions. How many SIP phones on the market implement the SIMPLE extensions? How many phones implementing these extensions actually use presence as a way to indicate willingness to communicate? How many presence enabled phones actually change automatically the presence status to "on the phone" when the call is in progress (The same could be said from AOL's Triton client)? By offering presence as a service the telecom world is taking the wrong road.

You could say that it would be easy to integrate these different protocols in the client. I agree that setting a status to "on the phone" is easily implemented in a client (I actually wonder why current SIP phones or clients are not doing it, don't you?) On the other hand, deriving availability from the aggregated presence information requires a close collaboration at the protocol level between the presence and call management. This is where, in my opinion, XMPP has an advantage. XMPP is a presence based protocol. Not only do all IM client applications receive notification of presence state changes, but many non IM XMPP applications are natively presence enabled. These application will only provide their services to you when you express certain presence states. Such applications today range from IM federation gateways to news feed aggregators and generic publish-subscribe systems. Many XMPP clients already allow message to be filtered out against presence status, and either shown or buffered. Because presence is deeply rooted in the XMPP protocol, the usage of presence is natural to many developers. This alone provides a huge advantage over other protocols. Many SIP developers are still thinking like telecom developers, not focusing on what a user is trying to accomplish and what the other party is available for. In this context, Jingle, as a natural extension to XMPP, will also benefit from the same advantages. Very naturally, the upcoming Jingle clients can automatically change the presence status when a call is in progress (GTalk does not do it, but GTalk is not a Jingle client). Some Jingle clients offer call filtering and call re-routing derived from the actual presence set by the user. On the server side, XMPP enables granular routing between multiple client instances based on presence application priority, whereas SIP will fork calls to every registered instances of a SIP URI.

In all, XMPP has many natural constructs leveraging presence. The root integration of presence in the protocol has created a larger community of “presence aware” developers. In comparison, SIP implementations today treat presence as accessory. Those of you that have tried to integrate presence in SIP applications have certainly found out that it is a complex task. And everybody would agree that complexity is an “app killer”.

Technorati Tags: XMPP, Jabber, Jingle, SIP, VoIP, Skype, Presence, Antecipate

Skype's missing dial tone

I came across the lament of Steve Smith caused by the decline of Skype’s presence component usage. I believe this is the inevitable outcome for a company that never properly understood presence.

Let's go back in time to the origin of Skype. It was born as a clever technical workaround to remedy SIP's inability to properly negotiate NAT traversal. The Skype protocol relies on clients outside a NAT device to proxy for clients behind the NAT device. As a consequence, a client may be used without its user's knowledge or consent to relay Skype traffic. In effect, Skype has an approach similar to what mail spammers do when they use a compromised computer as a relay... For those interested in digging further, this post provides additional sources on this closed protocol hidden features and their consequences.

So, in the beginning was the word, and voice filled the Skype space. Skype users had to wait until October 2004 to discover presence. Fourteen months after Skype was presented to the world as the "arrival of P2P Telephony". In essence, Skype is one of these clever companies that perfectly masters the art of surfing the wave of existing and emerging technologies. Don’t you see how Skype rhymes with hype... Looking at Skype's press releases over the first year gives a pretty good idea of the company’s positioning as "the Global Internet Telephony Company". The press announcements provide all the mandatory ingredients to reinforce this positioning, including the community building, the minimal instant messaging features, and the phone peering agreement negotiations. It becomes easy to conclude that, from the start, Skype’s business model was to become a VoIP phone company. This is not very original, but in October 2004 they cleverly announced "one million simultaneous users globally connected to each other at the same time" and added they had "served more than two billion minutes of free Skype-to-Skype calling". With a technology entirely built on point-to-point communication, Skype own infrastructure had nothing to do but authenticate these users. How could they claimed "serving" anything with an overlay point-to-point network? The actual transport capacity was in fact provided entirely by the Internet without any Skype resource being involved. What a marketing mastery!

And presence in all this? I always refer to presence as the “glue” that improves users’ ability to communicate and interact in true real-time. It ties together applications that previously lived in isolation. Presence is a dynamic extension of an entity's digital representation on a network; it describes one or many states, exposing entities’ ability, means and overall willingness to engage in a transaction. Typically, a presence engine manages the connectivity status of users, their devices and their capabilities. In the case of Skype, as it implements a point-to-point overlay network, I believe presence state changes are processed locally by the clients. As a consequence, only online/offline state would really be used to determine the ability to communicate. Skype allows several clients to be logged in for the same entity. In this context, the client side logic makes it difficult to aggregate an entity’s multiple availability information and present it to a contact. In turn, it decreases the ability to leverage presence to re-direct or temporary divert a call according to certain states. In an enterprise context, the client side logic is not the best design to fully take advantage of collaboration indicators, such as calendar based presence.

Presence can have a tremendous impact when implemented and used as the new "dial tone" in a communication system. Let’s consider an example. Many business process delays result both from inadequate access to missing information, and from users’ inability to locate and briefly interact with peers regarding such information. By enhancing the ability to reach a colleague using the most appropriate communication channel, presence addresses this recurrent business challenge. With presence, we no longer request, we subscribe!

Granular presence states, coupled with the ability to inject collaboration indicators and use rules are powerful enhancements to a VoIP communication system. When on the contrary, presence is reduced to an online/offline binary information, it looses any advantage over the POTS dial tone. In Skype, presence is derived from the call management, not integrated as the nervous influx in the system architecture. A typical carrier approach, where the business model relies entirely on the peering agreements and associated traffic clearing houses, not on services. Skype cleverly rode the presence hype without harnessing its power. And Skype will go back to what it really is: a proprietary non-interoperable VoIP phone provider.

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Skype, Presence, Antecipate

Breaking free from topic names

In many ages, it has been of classification as of authority: men always favored hierarchy. The latest discussion surrounding the publication of JEP-0060, the XMPP publish-subscribe standard extension, unfortunately gives us another example of this tendency. We have learned many times in the past, when implementing publish-subscribe systems, that referencing object of interest by identifiers with embedded structural information make life exceptionally difficult. This is commonly found in "topic name" based systems. Such systems are extremely easy to design and implement, and usually appear to be useful early in their lives. Over time, however, the usefulness decreases, and the inconvenience grows...

In a distributed information organization such as the Internet, using a hierarchy becomes inappropriate as soon as

• the information has to be federated between multiple organizations,
• the information source classification structures change over time.

We all know how slowly hierarchical organizations change, and history has taught us many times they usually evolve by revolution rather than evolution. Bob Wyman, sums up very well the inadequacy of the "topic name" approach in publish-subscribe systems when saying:

Historically, pubsub systems that have embedded structural or classification information in their topic names have found that it is very, very difficult to implement reorganizations since either there is no mechanism to notify subscribers of the changes in structure or the protocols to do so are very expensive and unreliable.

We can avoid this problem with JEP-0060 by ensuring that everyone knows that the node identifiers associated with topics must remain opaque.

Hierarchical "topic names" are a residue of "topic-based" systems, which make up the mass of the incumbent form of publish-subscribe. In those systems, subscriptions expressiveness is limited to simply specifying a topic name. Users would subscribe to a topic and be notified of every change published to that topic. However, it often arises that subscribers are only interested by a subset of a topic's information and wish to avoid unnecessary notifications. In "topic-based" systems, the solution brought to this problem goes through creating a sub-topic that would only notify a subset of the changes published to the main topic. But, as other users will have a different point of view on the world, the system will end up using a classification best represented as a graph. Unfortunately, as understanding the areas of interest becomes better over time, it is likely that new topics will be created to map the wider concepts' understanding, and existing topics will be moved from one point of the graph to another. Several answers have been proposed by academic research to solving this issue, but everyone agree that it is more robust to use opaque topic names and provide a different mechanism for expressing the structure of the topic-space. Bob pointed to one such research areas done in ISO on "topic maps" and classification systems. He further explained

The names chosen by XTM are a bit confusing but, what we have in JEP-0060 as a nodeID for a topic should be treated as a "subject indicator". Thus, it should be an unambiguous identifier for a particular subject or topic. (In XTM systems, the "subject indicator" is often just a unique URI or URN). In XTM systems, the "structure" of the space of "subjects" is provided via the "topic". In such a system, the "topic" is meta-data for the subject.

RDF would also provide an appropriate answer in de-coupling an object of interest from its reference. RDF and topic maps are both identity-based technologies. That is, the key concept in both is "symbols" representing identifiable "things", which statements can be made about. This document explains how one could use either technology and still provide the expected separation of concerns. The author also presents a method to cross map one technology into the other. Those interested by the subject can find a exhaustive coverage at the W3C of RDF/Topic Maps interoperability.

Again, as in the case of addressing, the important point is that the reference of the object of interest is distinct from the meta-data that describes that object's relationship to other things. This identifiers can be reused in multiple places in the overall classification structure and it is even possible to share references across possibly incompatible systems. System would only have to agree on using the same "subject indicators" even though they use different classification structures and names for various levels in their structures.

Technorati Tags: XMPP, Jabber, Addressing, Identity, Publish subscribe, Topic maps, RDF, Antecipate

Jingle nostalgy

Kind of fun, some of the definitions of “jingle” on the web (define:jingle for search aficionados)

Jingles are memes constructed to stay in one's memory and people often nostalgically remember them decades after, even after the brand has ceased to exist.

And searching on “meme”, you will get to:

Just as genes propagate themselves in the gene pool by leaping from body to body via sperms or eggs, so memes propagate themselves in the meme pool by leaping from brain to brain via a process which, in the broad sense, can be called imitation. ...

So was the GTalk launch just a “me too”? I leave you to reflect on an answer…

In the meantime, I am waiting impatiently for the next Jingle specification version release. Peter, where have you been?

Hopefully, this version will incorporate some necessary enhancements such as

• the support for multiple media description,
• a better glossary,
• a clear disconnect from the GTalk inspired transport negotiation.
• …

Technorati Tags: XMPP, Jingle, Conversation spaces, Session signaling, Antecipate

Decreasing the prejudice

I have been venturing into the wide identity space for a very simple reason. Although I do not pretend being an expert in this field, I believe using a communication address as an identity GUID is detrimental to the identity system relying on this identifier, and to the communication system that is using this address for routing. Communication systems are more my cup of tea. While researching the subject, I came across the latest fashionable sub spaces on the subject of identity, namely “digital reputation”. In a previous post, I explained what makes me suspicious about this concept in the very wide sense. This definition of reputation in the context of blog comments may reconcile me with some of the possible applications of digital reputation. Actually I find the authors idea of “reputation system” interesting.

reputation is a 1 to 1 relation between the reputed party (the blog commenter) and a reputation-relying service (the blog)

This is a much narrower definition than the more generic, all contexts inclusive, definitions I have been exposed so far. I have no difficulties extending this functional definition to any “reputation system”.

reputation is a computed value, the computation is performed by a reputation-asserting authority (the reputation manager service) from a collection of transactional data (acceptances and rejections of previous comments to other blog posts) and identity data originated by past interactions of the reputed party with reputation-relying services (other blogs).

I find this second functional definition a little trickier. Obviously, as a critical human being, I understand the underlying expectations buried in such definition. I also understand its limitations:

• the reputation system relies on “identity data”. In effect, the reputation system will be entirely dependent on the unicity of this “identity data” in order to compute the “reputation value” and keep a record of the “past interactions”
• to comply with privacy protection, the reputation system would certainly have to work on opaque tokens, instead of more explicit tokens such as mail addresses. This is the only way to ensure a minimum level of “identity independence” in the calculation process.
• the entire system will be bound to the pre-requisite that the spammer would play by the rules of good behavior. More specifically, it implies the spammer will behave in such a way the “reputation system” will always recognize it as the owner of a previous “identity data”. The game may becomes slightly more difficult if the spammer keep changing identity data.
• the “identity data” correlation problem becomes rather complex once the “reputation system” would require access to “interactions” outside the boundaries of a single blog. This aggregation can be eased up by setting up the “reputation system” as an external party. In this case, the token must only be thought off as a reputation token, and not an identity token.

Approaching the problem from that angle would make me feel more comfortable. I believe the blog “reputation system” could be built upon presentation of this reputation token, as long as this token does not provide direct mapping to the owner’s identity. After all, the blog is only interested by a repetitivity and scaling quality index on the posted comments. Using an identifier, and not an identity, to reconcile and group together the collection of transactional data used to compute that index is a perfectly valid approach. But it has the invaluable advantage of protecting the privacy of the comments’ author.

I disagree on several counts with Dick Hardt when he tries to mush up identity and reputation. But what could I expect from a blog trying to describe a “next generation identity”? Identity is our essence. Outsiders will use multiple attributes to incompletely describe how they perceive our identity in their own ontology. Our identity may possess certain innate attributes that are more permanent than others, but we do not usually disclose them easily. As a matter of fact, in most cases, identity attributes are imposed on us. Defining identity broadly (identity == reputation, identity == transactions, etc.) infers that we lose the ability to do anything useful with it. In particular, privacy concerns gets much broader. So, when someone tries to over simplify, and come up with the blunt statement that reputation is identity, he earns a bad value in my “reputation system”.

With respect to comments on a blog. We envision the commenter needing to build up a reputation over time, and it would be associated with a particular persona. Since it takes a sequence of good behavior to build a positive reputation, there is a cost to that reputation, that good netizens will want to preserve if having a good reputation provides additional value.

Once again, another “good intent”. I understand the requirement, but I would only agree on a resulting system based on contextual reputation, and not identity. His position is pre-supposing that a contextual reputation can be extended to any ontology and/or context. Because every context and ontology pair define differently what a “good behavior” contains, they will definitively lead to several different contextual reputations. Each of these reputations may be useful in their own context. Quickly reducing all these contextual reputations into a single manichean net-wide reputation is a little far fetched…

Technorati Tags: Identity, Trust, Digital reputation, Digital identity, Antecipate

A lost battle?

Going through the explanation of why Java was being displaced by .NET in an organization, it struck me how many arguments used in the post could have been applied to XMPP. It is another demonstration that the KISS concept (in this case the Stupid probably refers to corporate America) always prevail…

If I want to design a website look-and-feel and page flow in .NET, I use ASP .NET. That’s it. If I do so in Java, I use JSP. Or I use JSP and JSF. Or Facelets and JSF. Or Echo2. Or Tapestry. Or Velocity. The number of choices can be intimidating. And that is just for web design. With persistence frameworks, .NET developers have ADO .NET. Java developers have entity beans and JDO as Sun standards or open-source options like Hibernate, Torque, Spring JDBC, and on and on.

I was earlier commenting on the difficulties facing an XMPP client developer when discovering the huge number of different libraries available. The parallel is really easy to draw with the finding about Java and .NET. I know the XMPP community is boiling with energy, and has achieved amazing results with the efforts of many brilliant, dedicated individuals. I am nevertheless under the impression what could have been an opportunity is turning into a detriment.

How many times have I heard the same story on how XMPP is “so much more adapted” at solving a business issue, and how the “management did not endorse the project”. When business is at stake, “management” will always look at minimizing risk and getting a solution quickly and cheaply out. To minimize the risk, the solution will be using HTTP, because they know it works. They will host it on an IIS, because as for Java against .NET:

… deployment to IIS is a simple matter for developers—as simple as copying the project to the wwwroot folder. Java developers must build WAR files or EAR files in order to deploy across servers. Not terribly difficult thanks to Ant, but still more work than a simple copy.

They would be right in doing so. Certainly not smart, but this is not why they are in this position. On the other hand, one does not fight gregarious ignorance through technology, because technology is frightening to herds of corporate creatures... Reduce the fear, increase the usability, and you are already a long way to push a technology into acceptance. When I see on the XMPP developers list yet another question on “what library for (add your favorite development language name here) should I use to create an XMPP client”, I cannot but think XMPP is not as easy as it should. But enough of this, I may just be in a bad mood

Technorati Tags: XMPP, Jabber, Antecipate

Adresses as identity sub-attributes

In a communication space, an address is an identifier assigned to networks, nodes and other entities so that each entity can be separately designated to receive and reply to messages. An address is expressed in a given namespace, which defines a context in which an address makes sense. An address is unique in its own addressing namespace, but is not a globally unique identifier. For example, the address romeo@montague.net represents both the mail address and the JID of a user. This identifier is unique in the mail addressing namespace, as well as in the XMPP addressing space, but cannot be used as a global identifier. An address can be converted into an URI by adding a scheme, extending its unicity as an identifier. The conversion to URI enhance the address globality, but in contrast, removes its ability to route message. In a communication space, URI are static resource identifiers, whereas addresses posses dynamic routing capabilities.

Three of the most fundamental requirements of addressing are the ability to:

• Provide an abstraction layer capable of representing any actor or entity in a given communication space,
• Enable this representation to persist for periods of time during which it can be used to reach the resource it represents, and
• Enable this abstraction layer to be federated across any number of communication spaces.

To meet these requirements, we will follows the architectural principle of semantic abstraction in the communication space: separate non-persistent semantic identifiers (addresses) from persistent abstract unique identifiers(UIDs). In most digital naming systems, a name is resolved directly to the physical location of a resource: a file on a disk, a host machine on a network, a record in a database. In a communication space an address is normally resolved to an identifier, which in turn resolves to the network location of the entity or a node within it.

• UIDs are persistent values intended primarily for machine use. UIDs are permanent identifiers that can be either local or global in scope, but which never change once they are assigned to an entity. An UID is a URN, i.e., it may expire, but it may never be assigned to another entity. Likewise, if the entity is deleted from the system, the UID used to identify it is removed and never reused.
• Address handles are non-persistent addressing values intended primarily for message routing use. Address handles typically represent semantic relationships that can change as real-world entity names and relationships change, so they do not have the same persistence requirements as UIDs. Address handles naming is implemented as an attribute abstraction layer on top of UIDs. An address can be directly used in a communication space to route messages, but an address handle also resolves to an UID from which other address handles can be derived for other addressing namespaces.

In a multi protocol communication system, this definition helps define many address handles as attribute of UIDs, and thus provide an efficient address mapping service to the federation gateways. At any time, one of these gateways may query the mapping service to obtain address handles for the target communication space they bridge to. In this context, the UIDs need not be globally unique, as they are only meaningful in the particular communication space providing the mapping service. These UIDs may be created in an ad-hoc way, or may be derived from some identity management system. From a communication space stand point, there only role is to be a unique reference to an attribute registry of address handles. No other semantic is attached to UIDs for communication purposes, although they may possess semantics when derived from an "identity system". But these semantics have no meaning for the communication space, and are not needed to perform the routing of messages. In the end, UIDs may be attributes of an identity reference created for a specific “identity system”. In that case, address handles may at most be sub-attribute of this limited identity representation for the communication space.

Technorati Tags: XMPP, Jabber, Addressing, Identity, Digital identity, Trust, Antecipate

What are his address handles?

I have described in a previous post a usage of JEP-0030 to discover my own address handles for different addressing spaces. Thinking further of it, and researching the JSF mailing list brought up a slightly different approach to the problem. It is based on the recent trend in using disco queries addressed to a bare JID to retrieve pieces of information about that particular JID. Doing so assumes that the home server is the unique trusted source of information regarding a given JID. This is a very common assumption in the XMPP community, which I believe limiting the case for distributed XMPP information services. Nonetheless, I will present a version of the address handles discovery using the bare JID approach, as it results in a faster discovery process.

The server’s address mapping support is achieved by by issuing a generic item discovery to one’s XMPP home server.

<iq type='get' from='romeo@montague.net/orchard'
      id='info1'>
     <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

The server will provide a response similar to:

<iq type='result'
      from='shakespeare.lit'
      to='romeo@montague.net/orchard'
      id='info1'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
           …
          <feature var='http://jabber.org/address#mapping'/>
          …
      </query>
</iq>

This (non normative) example illustrates how a client application would leverage service discovery to find if an XMPP server provides an address handle mapping service. The server includes the "http://jabber.org/address#mapping" namespace in its features set to indicates address mapping support. As explained earlier we leverage the existing JEP-0033 specification to further query for address mappings. The extended addressing schema supports non XMPP address namespaces through the use of an URI attribute instead of a JID. At this point, the client application will have to issue a query to a bare JID to discover the collection of address handles mapping to this JID. It is matter for JEP-0030 item discovery qualified by a node. The client will issue a query to the bare JID for which the mappings are requested. This example is for retrieving one’s own address handles:

<iq type='get'
      from='romeo@montague.net/orchard'
      to='romeo@montague.net'
      id='items1'>
      <query xmlns='http://jabber.org/protocol/disco#items' 
             node='http://jabber.org/address#mapping'/>
</iq>

<iq type='result'
      from='romeo@montague.net'
      to='romeo@montague.net/orchard'
      id='items1'>
      <query xmlns='http://jabber.org/protocol/disco#items' 
                 node='http://jabber.org/address#mapping'>
            <item jid='romeo@montague.net'>
                <addresses xmlns='http://jabber.org/protocol/address'>
                    <address type='to' uri='mailto:romeo@montague.net'/>
                    <address type='to' uri='sip:romeo@montague.net'/>
                    <address type='to' uri='iax2:shakespeare.lit/555'/>
                    <address type='to' uri='tel:+16135555555'/>
                </addresses>
            </item>
            ...
      </query>
</iq>

At this point, the client application has retrieved the mapping between its own JID and the address handles in different communication namespaces. The same approach can be used to retrieve all Juliet’s address handles, subject to existing ACLs provisioned on the Capulet home server… In the end, this alternative way of querying a bare JID leads to fewer packets exchanged. This alone provides a strong argument in its favor. I still believe it is narrower than the previous method I discussed by limiting the scope of the queries to a JID and assuming the service is provided by the JID owner’s home server.

Technorati Tags: XMPP, Jingle, Jabber, Addressing, Phone number, Service discovery, Session signaling, Antecipate

Questionable efficiency

Is re-inventing the wheel the pinnacle of efficiency, that any new bee XMPP client developer absolutely insists on re-writing yet a new XMPP stack from scratch? Or is XMPP is really lacking an efficient approach at quickly creating new client based features, as Robert is explaining in his post. No need to tell you that I agree with his analysis and proposed direction. I would love to have an XMPP client development environment for me to experiment quickly with new ideas, without having to learn a new development language or to rewrite a client from scratch every time.

Today’s client development tools landscape lacks well defined and agreed upon API layers to abstract XMPP client development. Some commercial SDKs offer a better approach to this abstraction than open source projects. But even in their case, they use incompatible APIs, and they are usually limited to a single OS. Nevertheless, beyond the apparent differences, their APIs provide very similar functionalities. It would make sense to harmonize these APIs into a common set of definitions. After all, it maybe time for standardizing a little more than just the XMPP protocol.

This statement will probably create roars in the XMPP client developer community. There a very valid issues arising from trying to bring together all these islands of programming languages, OS silos, an strong opinioned personalities. I believe higher abstraction and common APIs is a necessary evolution when a technology is maturing. This is necessary to change what is perceived as a varied, but in this case very inefficient, XMPP world and help create a greater value building platform… Value comes from wide adoption, ease of extension, and quick time to implementation. Value resides in the thousands new usages of an API a programmer never thought of when it created the API in the first place. Value is in building applications to solve somebody’s pain points, or to offer new services to a community, not in building XMPP clients. This is what Robert’s post is about.: how to evolve from XMPP client building to XMPP application building?

As a proof that this is the right way to address the problem, let’s quickly look at the existing landscape. An entire ecosystem is in the making that leverage the RTC APIs available on any Windows workstation. The built in messenger service provides all what is necessary to any developer for creating real time communicating applications through this API. You may not like it because it is from Microsoft, but this is a fact. Apple did something similar with iChat. For the very simple reason these two companies want developers to create applications on their platform as opposed to building clients.

I would really like and benefit from an XMPP agent when experimenting with new client applications. It would be even more interesting if an agent based architecture was available for the major workstations operating systems. Properly engineered, it would provide an open alternative to proprietary stacks already in place for some of these OS. I would welcome an initiative along these lines fostered by the JSF…

Technorati Tags: XMPP, Jabber, Antecipate

Dilbert on Google

Funny how Dilbert picked at Google in the past few days. The gag started about them being "not so evil" after all. Earlier, I was reading Robert Quattlebaum’s latest post where he hinted at “corporate greed” being an important factor in keeping IM users in closed community. This statement triggered a comment to the post on how Google had been clever, and the incumbent IM players “dumb”. All this reminded me of Dilbert…

Corporation are not philanthropists. They make money. Google is no different. It is just using different tactics to get to the same result, but the base rules remain the same: to rip off the benefit of a community, you have to make it large and docile. There are many ways to make it docile. You can use the “all inclusive, all  protected community” approach, such as AOL, where everything you always dreamed of is catered for. You can also create a “no evil, no fear, illusory freedom community”, which is the Google way. The difference is in the community membership, not in the business need for a community.

The next step is to build the community. In this business, obviously the legacy IM networks are the incumbent, and Google the last entrant. Business schools teach you that, when you cannot compete head to head with an incumbent, you can change the business landscape where the incumbent is strong. This is just what Google did. They have been clever is by moving the battleground from IM to VoIP. In short, they have displaced the context instead of being "yet another IM provider". The next frontier for communities is not in IM anymore, every community has IM (although some are still building new proprietary IM services). There is a much greater potential in VoIP services than in IM. Voice is such a well studied market, and people are talking so much on the phone… There is nothing smart, or new in making this analysis. Google had to build a community quickly to reach a large audience which is the other critical factor of a community. At the same time they had to stick to their “not so evil” corporate image to succeed. They could not bluntly tell the world they wanted to create “yet another captive community”, right?

For Google, the equation was simple. To achieve their goal, they also needed multimedia IM. They could have built it from the ground up. But instead they looked at the landscape and realized that using XMPP would instantaneously give them the IM community. And rightly so. Today, anybody using XMPP can IM a GTalk user. The second part of the plan was adding the VoIP part. So they came up with GTalk. And there they achieved the lock up of the community. This is the clever bit. Because, as I have said several times Gtalk is not Jingle.

This lock in is a two steps process. First GTalk is launched to see how the service is perceived. At the same time, they drive the Jingle specification at the JSF. The second step consists in negotiating the peering agreements for the next to come VoIP Google service. By the time this service is ready, there will be many open source clients out supporting GTalk (not Jingle) eager to use the newly created GTalk to public VoIP or PSTN gateways. And Google will start milking the cow...

The strength of Google is in leveraging to its own interest the inextinguishable goodwill of the open source community. They just did it again. And when Jingle (not GTalk) will become mainstream, they will still own the peering agreements. Google is neither better nor worth than its competitors. Just another corporation, but cleverly using the “not so evil” on the fear factor scale...

Technorati Tags: XMPP, Jabber, Jingle, VoIP, GoogleTalk, Antecipate

What are my address handles?

I am following on Simon's last post, where he mentioned how discovery of contact details was an essential piece in integrating multiple addressing namespaces through XMPP. This discussion originated from his work on integrating his XMPP server with an Asterisk PBX. Beyond the specific mapping needs we identified for his application, I believe XMPP must provide a standard way of querying a service entity to discover what address handles are related to a JID. The original question was "I need to know the PBX extension for each of my XMPP users. How can my client query a service to retrieve this information?". This kind of legitimate question is typical of any interface between XMPP and another protocol. The client could either be a typical GUI client, or simply a gateway service trying to access address mapping information from an identity repository.

From a functional design perspective, these requirements lead to using some sort of address handle registrar. This registrar could then be queried to return non XMPP address handles for any JID. The purpose of this post is not in defining the implementation of this registrar service, but rather explaining how we can leverage existing XMPP extensions to obtain the expected result. And when it comes to available services and features, the obvious answer in XMPP is to turn to service discovery. Discovery is always a two steps process at a minimum:

• discover the service identity and its JID
• query the service for detailed information

The service identity discovery is achieved by by issuing a generic item discovery to one’s XMPP home server.

<iq type='get' from='romeo@montague.net/orchard'>
      to='shakespeare.lit'
      id='items1'>
     <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

The server will provide a response similar to:

<iq type='result'
      from='shakespeare.lit'
     to='romeo@montague.net/orchard'
      id='items1'>
      <query xmlns='http://jabber.org/protocol/disco#items'>
          <item jid='registrar.shakespeare.lit'
                    name='Directory of Characters'/>
          <item jid='jingle.shakespeare.lit'
                   name='Play Media Gateway’/>
          …
      </query>
</iq>

In the second step, the client will go over the list of identities that was returned by the server, querying each of them in turn to obtain their supported features. To that effect, the client will issue targeted discovery information queries to each returned service JID. At some point the registrar service will receive:

<iq type='get' from='romeo@montague.net/orchard'
      to='registrar.shakespeare.lit'
      id='info1'>
      <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

And will return its information set in a response such as this one:

<iq type='result'
      from='registrar.shakespeare.lit'
      to='romeo@montague.net/orchard'
      id='info1'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
           <identity category='directory'
                         type='user'
                         name='Directory of Characters'/>
           <identity category='directory'
                         type='address'
                         name='Characters White Pages'/>
           …
          <feature var='jabber:iq:search'/>
          <feature var='http://jabber.org/address#mapping'/>
          …
      </query>
</iq>

This (non normative) example illustrate how a client application would leverage service discovery to find about an address handle mapping service on the XMPP network. You will note how the discovery uses the new identity type "address" in the existing "directory" category to indicate that if can provide address handle mapping information. The features set provide additional information by specifying that queries will be understood in the "http://jabber.org/address#mapping" namespace. Once again we leverage existing XMPP specifications. The "http://jabber.org/address" is already defined and one possible usage is described in JEP-0033. I explained in an earlier post how we can leverage this existing specification and extend it in the context of Jingle. I am presenting yet another extension to query address mappings. The extended addressing schema supports non XMPP address namespaces by the use of an URI attribute instead of a JID. This is what we are going to use here.

To progress further, the client application will have to discover what actual mapping the service provides. It is matter for item discovery. The client will issue a query to the service in the form of:

<iq type='get'
      from='romeo@montague.net/orchard'
      to='registrar.shakespeare.lit'
      id='items2'>
      <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

To this query, the service will answer with a list of nodes indicating the various addressing namespaces for which it can provide a translation.

<iq type='result'
      from='registrar.shakespeare.lit'
      to='romeo@montague.net/orchard'
      id='items2'>
      <query xmlns='http://jabber.org/protocol/disco#items'>
           <item jid='registrar.shakespeare.lit'
                    node='http://jabber.org/address/mailto'
                    name='Characters eMails'/>
           <item jid='registrar.shakespeare.lit'
                    node='http://jabber.org/address/sip'
                    name='Characters SIP address of record'/>
           <item jid='registrar.shakespeare.lit'
                    node='http://jabber.org/address/iax2'
                    name='Characters phone extensions'/>
           <item jid='registrar.shakespeare.lit'
                    node='http://jabber.org/address/tel'
                    name='Characters phone numbers'/>
          ...
      </query>
</iq>

The service indicates in its response is willing to provide address mappings in the mailto, sip, iax2 and tel URI namespaces. At this point the client application only needs to issue a query to one of the namespaces' node to discover the address mapping.

<iq type='get'
      from='romeo@montague.net/orchard'
      to='registrar.shakespeare.lit'
      id='items3'>
      <query xmlns='http://jabber.org/protocol/disco#items' 
                  node='http://jabber.org/address/tel'/>
</iq>
<iq type='result'
      from='registrar.shakespeare.lit'
      to='romeo@montague.net/orchard'
      id='items3'>
      <query xmlns='http://jabber.org/protocol/disco#items' 
                 node='http://jabber.org/address/tel'>
            <item jid='romeo@montague.net'>
                <addresses xmlns='http://jabber.org/protocol/address'>
                    <address type='to' uri='tel:+16135555555'/>
                </addresses>
            </item>
            ...
      </query>
</iq>

At this point, the client application has been able to retrieve the mapping between its own JID and and its address handle for the phone namespace. In the case of Simon's application, it will have to retrieve the mapping for the IAX namespace, and would then be able to populate its Jingle transport candidates with the appropriate information.

Technorati Tags: XMPP, Jingle, Jabber, Addressing, Phone number, Service discovery, Session signaling, Antecipate

Securing XMPP

I have to agree with Peter StAndre, the state of secure XMPP standards is a joke! I will immediately dismiss the actual RFC 3923, which is kind of trying to force a square plug into a circular socket. Look like there is a strong faction at IETF in the security working group knowing only one way to do end to end encryption. Take it or leave it…  As to the usage of PGP, I have always wondered why this had not taken up more. Maybe something to do with the disdain found in enterprise against this technology. And finally the proposal for encrypted sessions, which is a thorough work on the subject by several authors. This last proposal in my opinion suffers from its very wide scope.

You will notice that I did not say complexity. Encryption is a complex subject. I have myself taken up writing a encryption JEP that was published as JEP-0102. Probably too early, and the XML signature and XML encryption were not entirely finalized at W3C. I nevertheless based my proposal on these standard to come. In essence, the proposal was very similar to JEP-0116, without the added management of long term keys. Same use of Diffie-Helmann key negotiation, same reference to IKE, use of XMLsig and XMLenc to represent the encrypted stanza. The main difference was its simplicity. Instead of managing long term keys, keying material was created for each encrypted session, and discarded afterwards. This JEP has been implemented in commercial clients, and has been working flawlessly.  

This bring again the statement that we’re not earth to suffer from the use of technology, but to use technology at providing solutions. Encryption would be a worthy addition to XMPP if we could come up with an easy to implement standard, and above all a transparent usage. One click on the padlock of the user interface must be all is needed to toggle encryption on/off. Actually the GUI part is really the easy bit… We may be better off revisiting the requirements set forward when writing JEP-0116 and come up with something applicable in 80% of the cases. And I am certain we can do it without compromising any of the security requirements. I believe we would also gain better acceptance by using the W3C recommendations for the encryption and signature framework.

Using XMLsig and XMLenc will not lower the original security requirements described in the JEP-0116. XMLsig and XMLenc provide a framework to encrypt and sign XML documents. They do not impose the keying material, nor the algorithms to use. These have to be provided by another process, either through a Diffie-Helmann key exchange, or through the use of asymmetric PKI keys. When the parties have agreed on a particular security context (i.e. crypto material and algorithms) they will use it by following the process described in XMLsig to sign and in XMLenc to encrypt XML.

The perfect forward secrecy is not linked to the encryption or signature method. PFS is just the statement that the ephemeral key negotiated during the key agreement will not be compromised if the long term secret keying material is compromised. In short, it is the way you use your long term secret, your random parts and the way you derive your ephemeral session key which will define PFS. This is entirely done outside XMLsig and XMLenc, which are only “using” the key material.

The repudiability is the notion of denying that an action occurred. If the ephemeral session key is short lived and discarded at the end of the session, it becomes impossible to prove the stanza has been exchanged from a cryptographic standpoint, in the absence of a stanza’s signature. Enforcing stanza signature will on the contrary provide non-repudiability, i.e. a proof of the stanza having been sent.

A little trickier, the “canonicalization” is only a way to standardize how the XML must be prepped in order to provide a reproducible XML when verifying signatures. In XMLsig and XMLenc, you need to use a canonicalization method, so different parties agree that the XML has not been tampered with. The W3C has standardized generic canonicalization, but very much related to the development of the web services framework. XMLsig and XMLenc will work with any canonicalization method. We may have to provide an XMPP specific canonicalization method if we find difficult to use the standard W3C methods.

Technorati Tags: XMPP, Jabber, Security, Trust, Antecipate

GUID, identity and addresses

I have enjoyed reading the paper on petname systems. It helped me understand why I had feeling of unease for some DNS based systems. I also liked the part on buddy lists based systems. I believe one of the inherent shortcomings of many buddy list systems comes with their mixing addressing and naming.

I find the petname system concept promising, and I am interested in its usability within an XMPP implementation. From an architecture view point, truly scalable distributed communication systems, and more specifically real-time messaging, usually implements an overlay network of some sort over the Internet. This overlay network leverages an homogeneous addressing space and uses the associated protocol routing logic to ensure message delivery. In this category we would find SIP or XMPP based systems, but also email systems. Buddy list based applications have been built on top of these communication systems. One major drawback of all theses implementations is the use of the system provided id as a nickname, this unique id being a routing address. For SIP the id is your URI, but this URI holds a routing semantic. For XMPP, the id is your JID, but the JID also holds a routing semantic. Same exactly applies for email. As a matter of fact, I have always felt using email address in certificates an oddity...

I am strongly convinced naming and addressing must be kept separate in any distributed communication systems. As a matter of fact, this issue is not found in the HTPP world, where URLs and identity are separate during a given authenticated transaction. URLs may be used as identifiers, such as these trustless URL redirects in recent user centric identity developments. They must not have to. In an HTTP based system, the relationship between URL and identity does not survive the transaction. On the contrary, for email, the address is the identifier, and the relationship becomes very long lasting... Temptation is great to use an email address as an identity, but this is wrong. This address is just another attribute of an individual identity. We all have several email addresses, and several IM handles, but our identity lies in our own essence. And our identity will definitively survive our changing email address.

If there was a single ubiquitous communication system with a universal addressing space, I would not be bothering. But I am sustaining the idea that global identifier schemes don’t scale. So does this post. I believe it has laid out sensible arguments in its demonstration, and its conclusions can be extended to other contexts, including communication. If we take this bad scalability of GUID schemes as a real world’s fact, I can conclude that the real world will ultimately be relying on a complex mesh of separate GUID schemes. If the relationship between naming and addressing remains so tight in each namespace, then building a multi protocol communication system becomes more complex and difficult. And then we have to interface different addressing spaces. This is the role of communication systems. What is a bounded communication worth?

In conclusion, I believe scalable and inter-operable communication systems must completely decouple their identity management from their addressing scheme. The identity management must be pluggable. The addressing scheme must only be used for routing, and no authorization or identity semantic should be attached to the address itself. This proper separation of concerns provides for a scalable approach to building multi-protocol communication systems. From this point, it is possible to design a system where address mapping becomes the simple result of a dictionary lookup.

Technorati Tags: XMPP, SIP, Jabber, Addressing, Security, Identity, Digital identity, Trust, Antecipate

The VoIP fear factor

At VON Europe, experts from well known VoIP vendors have publicly admitted that many of their products were not inter-operable with those form other vendors. They also said these vendors were not implementing basic security technologies over their entire product range. What an interesting disclosure. I was under the impression VoIP was a communication enabler. Maybe incompatible VoIP technologies are just a way to protect the large investments made in legacy voice systems by the same vendors? Or is it just a way to lock potential customers in…

But what I find really unsettling is the use of the fear factor all throughout this article. No fact, no analysis, a clear un-understanding of the issues at stake. Just a un-intelligible blurb of words between unrelated “experts” quotes. Somebody will have to explain to me the role of TLS in an UDP based VoIP system, for example. But the keyword TLS will probably bring this page in good position in the results o a search engine when looking for VoIP security.

One thing is certain, though, deploying a SIP VoIP infrastructure is the kind of project that makes your entire security protection look like swiss cheese. And fingerpointing the other party for lack of security understanding will not change this result.

Technorati Tags: SIP, VoIP, Security, Antecipate

We must not transport Jingle!

XMPP has from the beginning build a reputation of inter-operability through its ability to communicate with disparate instant messaging systems. Just look at the number of public IM transports in service today.

There is no reason why this inter-operability could not be extended to the VoIP or multimedia communication as well. The XMPP community is working at making Jingle a robust signaling framework, with the same extensibility in mind as the rest of the protocol. That said, VoIP services comes in ever increasing flavors and numbers, each with its own way of providing its service. Bridging between Jingle and VoIP providers using the same transport design as for public IM transports will not scale. Not from a protocol view point, but from an identity and addressing perspective!

In a traditional XMPP transport, the end user usually goes through a registration phase, providing some sort of credentials, and above all, a valid address handle for the target communication system. Existing transports either store this information locally on the hosting machine, or use some non standard mechanisms (see <xdb/> packets in jabberd) to delegate the storage to the associated XMPP server.

Doing so creates a large number of “identity islands”. One such islands for every installed transport, holding in some not always secure store the association of an address handle and credentials. I do not believe this to be a good practice from a security stand point. Neither is it an efficient design because of the multiplication of sensitive information in different locations.

If you do not expose yourself much by “trusting” your public IM credentials to an XMPP transport (except if you use your public IM account as a trader of course), it becomes a different game when you start using paying services, such as PSTN voice gateways. You would not be happy to have some happy GTalker charging your credit card by calling its Grandma at the other side of the earth…

We must not apply the current monolithic self contained transport design to Jingle. The context has evolved to a larger communication space. We have a good opportunity to learn from experience here. There are numerous discussions going on in the Internet digital identity world on the subject of minimizing identity exposure. Everybody complains about the ever increasing need to provide identity related information for all sorts of service available on the Internet. These security trends include, but are not limited to, making sure the end user is in control of its identity, as well as using assertions to derive authorization. Trends also clearly indicate the limitations incurred by using address handles as identity identifiers. This is not exactly how the original Jabber transport were built. I believe it becomes important to incorporate these new trends, ready ourselves and rethink our existing implementations, and prepare better ways of handling identity and querying about addressing.

Technorati Tags: XMPP, Jingle, Jabber, Addressing, Identity, Digital identity, Trust, Antecipate

Opinionated tagging

Some fun and strong positions in the text and comments from the TechCrunch post about the Google Notebook service. Following the author’s remark that Google Notebook lack tags, strong comments were made saying tags are un-necessary when you have content because it can be searched.  For me, tagging is the active approach to bookmarking, whereas search is the passive approach to categorized bookmarking. After all, isn’t content indexing equivalent to tagging all the content’s significant words?

I for my part don’t see why the author “wonders about Google dedication to its own projects”. After all, how could there be a relationship between groups of wonder kids and project dedication? Product vision is certainly not the likely outcome of gathering bright individuals and letting them wild. Product vision is boring and requires enterprise spirit…

Technorati Tags: Antecipate

Jingling in conversation space

Being a good listener, I am always surprised when starting a conversation to realize how different meanings’ interpretations often lead to a lengthy preliminary exchanges before reaching a common context understanding. As explained by Seth Ladd,

I believe meaning is relative, and that the reader, with their unique experiences and perspectives, will always interpret things in their own way. The readers, or consumers, will always have more power with regards to information interpretation.

Communication is a paradox of a subject, and what he says about readers attitude can easily be extended to mailing lists’ participants. I particularly like Seth’s final statement

It’s very possible that conversations between semantic web agents will be required to come to a sort of shared understanding.

I don’t know if participating to a mailing list thread makes us “semantic web agents”, but we definitively need this “shared understanding”. This is why I am adding to my previous post to further build that shared understanding around Jingle. I was prompted to do so remembering the difficulty I had on the JSF mailing list to convey the difference between Jingle as a framework and its application in setting up multimedia sessions. In fact, the confusion came from this word: “session”. Every time I used this word, I was referring to a communication taking place between participants in a conversation space, whereas my interlocutor was referring to the underlying RTP sessions…

I believe Jingle has all the qualities to become a widely adopted way to manage sessions in conversation spaces. We must be careful not to let Jingle be positioned as “yet another signaling” protocol, or it will only be perceived as a SIP imitation. This would be the worth positioning. Jingle is larger than just P2P VoIP, in the same way presence is larger than just instant messaging. Referring to my previous definition of “conversation space”, from a protocol stand point Jingle should allow the complete management of conversations in a given space. From the simple one-to-one phone call, to the more complex collaborative meeting mixing MUC, document sharing and multimedia streams.

This is unfortunately not the case at present time, as the Jingle glossary is both inconsistent and very limiting. For example, sessions are defined in JEP-166 as “a negotiated transport method and media description format connecting two entities”. The use of singular points to a single media/transport relationship. It is obvious using this definition, that we must use several Jingle sessions to become participant of in video conference. At least one Jingle session for audio, and one for video. Even SIP is doing better than this. A Jingle negotiation must allow negotiating several media descriptions at the same time. I believe we could even negotiate several media/transport relationships in a single Jingle negotiation. As an illustration, imagine a multimedia mobile phone becoming part of the previous video conference while roaming. The user has joined the conference while sitting in its favorite Internet cafe, with an adequate network connectivity. The conversation space is provided by a Jingle a multimedia conference server, and the negotiation is taking place between the mobile client and the server. Remembering its next appointment, the user decides to drive to a meeting outside town. Being a careful driver, it will decide to mute its microphone, hold the video streams, and only leave the incoming audio on, so it can listen while driving. The user also updates its presence state and PEP profile to indicate it is driving and cannot be disturbed. At some point, during the conference, documents are shown. The user decides to stop and have a look. It does it by re-enabling the video stream. It may decide to intervene in the conversation after un-muting its microphone. I believe the user experience will be greatly enhanced if all these media are part of a single conversation space, presented and managed as such. From an implementation perspective, it is easy to understand how control operations are more efficient when all media negotiations have already been carried out and referenced by a single session ID. Adoption requires ease of use and low client complexity. Its better to maintain states on a server and only pass a reference to a client. It is easier to group media streams together if the have a common root session identifier.

From a protocol definition stand point, I believe Jingle purpose must be widened beyond “peer-to-peer sessions” to manage conversation spaces sessions. With this definition, we open the perception of Jingle to multi-peer and client server sessions. I also propose to rewrite the definition of session as “the relationship linking together a dynamic set of multimedia senders and receivers and the data streams flowing from senders to receivers”. A wider definition in the protocol will result in allowing real multimedia (i.e. several media) management capability for a single communication space session.

Technorati Tags: XMPP, Jingle, Jabber, VoIP, SIP, Session signaling, Conversation space, Antecipate

Digital prejudices

As I was researching to get a better understanding of current thoughts about digital identity, I came across a post on digital reputations. I had thought of looking into digital reputation earlier after having seen the words cropping in the XMPP blogosphere lately. The first time I came across the wording, I had the distinct impression digital reputation was somewhat subjective. Reading this definition just confirmed my impression: to put it bluntly digital reputation is an everlasting prejudice.

By prejudice, I mean digital reputation contains a partiality that prevents objective consideration of an issue or situation, and digital reputation encourages coming to a judgment on a subject before learning where the preponderance of the evidence actually lies. On both accounts I find it difficult to accept. 

Reputations are both deep and complex at the same time, in one instance serving to amplify reality ("…she was larger than life.") and in another instance oversimplify it, ("…he’s amazing."). Reputations are not limited to people, but can and do apply to groups, organizations, companies, countries, governments and even objects.

I really agree with the opening statement. Reputation has a way to amplify reality, and to oversimplify it, which in my opinion makes it appropriate for “cave men” but not for responsible beings. I thus have some difficulties agreeing with many of the author statements that follow in the document. From my reading his post, I understand that a reputation based system offers a way for an individual to replace a responsible decision making by a gossip based decision making. I don't know if you are like me, but I do not feel comfortable with the idea of letting anybody influence the way I make a decision. A decision may and usually engage my responsibility, and as such must not be left to other to decide. I am also very weary of others "outsourcing" their decision making in this way because it is easier. Especially when it comes to my reputation...

Every single statement in the document reinforce the inaccurate nature of a reputation based system. For example

While a reputation can be thought of as distinct, separate and external to us all, they are inextricably linked to us, and don’t exist outside of the context of their owner for which they refer.

It is true that reputation is distinct for each of us, and is certainly external to us. So where does this statement inaccuracy lies? In the fact that reputation does not exist per say. It is a perception by a third party. Reputation is the resulting impression that has been conveyed to the recipient person through a chain of inaccurate communication messages between persons. Oral or written communication all conveys a degree of uncertainty. Experience and history show how inaccurate the transmission through a given set of individuals of any form of message can be. When these messages reach their destination in a context of partial knowledge and passive acceptance surprising, they may create surprising collateral results. Bad spirits were inhabiting the trees at night not long ago. Different behaviors were definitively the indubitable proof of witchcraft very recently. Different beliefs or convictions are still considered heresy today. Nations go to war on reputation!

We certainly need to "take digital reputation seriously", as the author declares. Applying binary and long-lasting memory to reputations will in no way change their "vague and subjective" nature. If reputation is by nature inaccurate, why would a machine, which is by nature so inferior to the human brain, be better at establishing what an individual is worth? The machine will certainly decrease the level of inaccuracy incurred during message transmission, but it will in no way be able to convey neither analyse the inherent complexity of the associated context. An I agree with the author statement that "our reputation is contextual and it is quite possible for me to have a positive reputation in one area of my life with individual A and a negative reputation in another area of my life with individual B". When coupling this with the long lasting nature of digital memory, a number of questions are surfacing. Very simple questions starting with but not limited to: what rules need be applied be to weighting the recorded facts in building a reputation? In which way can a positive fact balance a negative fact? What authority will mediate for inaccuracies? (add to the list at will)

Digital reputations are a way of denying the subject of the reputation the simple right to change and evolve. Everyone must be accountable for his/her actions, no doubt. But we have to be very careful not sticking simplistic "reputation" labels on individuals that would be used out of context. We have to be careful not to rely on delegated "reputation" impression when making a decision process. Because this is what prejudice is all about.

Speaking of reputation, I found it rather interesting to see the effect of long lasting memories in a more recent post of the same author. What struck me in the post is that it took so long to this otherwise reputated author to realize what he could be subjected to when going through French customs. What he is missing though, is that French customs are today equipped with powerful automatic brain scanners and that mirroring laptops hard-drives is not necessary anymore. Funny how people leverage fear factor to drive their business ;)

Technorati Tags: Identity, Trust, Digital reputation, Digital identity, Antecipate

With the belief, knowledge, hope, etc...

For those of you wondering if this blog’s name is not misspelled, be re-assured, it is not.

This place is nevertheless about considering things beforehand or before their time. Grasp their meaning. Not just about commenting about events. Think of it as the push model (reflecting) as opposed to the pull model (reacting) applied to blogging. Since some parameters are not known, they have to be estimated and described. In hope everybody speaks the same language.

Some may also think of this name as a bet required to play a hand in the communication game…

Technorati Tags: Antecipate

In the Google Jingle jungle

I find the presentation of Libjingle on the Google coder page a typical example of misleading documentation. Anyone reading this presentation is bound to assume that Jingle is for peer-to-peer communication only. Many are also referring to Google’s proprietary implementation as Jingle audio, which is a second misnomer. How could we create credible communication protocol if we cannot agree on a common language to describe the protocol usage and implemented technologies. My visit to the Libjingle pages came the other day as I was trying to separate reality from fiction behind the recent Jingle support announcements made by Asterisk and FreeSwitch. In fact, they only relates to the support of GoogleTalk. And this is not Jingle, whatever Google may say on the subject.

Google Talk uses a proposed extension to XMPP known as Jingle which can traverse many types of NATs, to establish peer-to-peer connections. The Jingle protocol is based on Interactive Connectivity Establishment (ICE), which is very successful in bypassing NAT. The core idea behind ICE is that the only way to determine the best way to connect to another user is to try every way, and use whichever works best. In that vein, when a peer-to-peer session is initiated, each client creates a list of possible addresses for itself. Each potential address is called a "candidate." Then, each client creates connections using every permutation of local and remote candidates possible and transmits data using the highest-quality connection.

Let’s have a look at the Jingle framework as proposed by the JSF. To date the Jingle media stack look just like this:

It is comprised of the main session management framework, media descriptions such as audio and video, and of  several transport descriptors. Three different transport negotiations JEPs are available within the Jingle framework. All of them use datagrams over UDP at the network level. Two of them rely on RTP as the transport protocol, and one is based on the Asterisk inter-exchange protocol.

Interpreting the description available on Google’s coder site, I am inclined to believe that what they call “Jingle audio” is in fact the combination of Jingle, Audio and the RTP-ICE transport. If this is the case, then the “Jingle support” for Asterisk and FreeSwitch is just a particular subset of the Jingle specification as highlighted bellow:

In reality, what has been implemented in the two IPBX is the support of GTalk, or more specifically the support of the Libjingle signaling, as it seems to be the library of choice for other XMPP clients in the making. I am certain every XMPP client developer will be eager to implement the specification as defined by the JSF. But they will also be forced to implement the GTalk distortion of the specification. And this will be a long status-quo, Google not being a philanthropy driven organization. They benefit from the hype created around Jingle and their use of an ‘open’ protocol such as XMPP. Will they spend the money to update all the GTalk clients to support the real Jingle as they claim remains to be seen. In the meantime, Google will benefit greatly from these open source PBX supporting their subset of the Jingle specification. This company has been great at leveraging open source for its own benefit. They will certainly not miss this opportunity of having two platforms allowing them to bridge between GTalk and SIP based VOIP networks, or to terminate GTalk calls on the PSTN…

But what of the rest of the world? I will try to define the base of a truly inter-operable Jingle implementation should be. Google explains the choice of ICE to negotiate and modify the RTP streams by issues related to NAT traversal. This is mentioned several time in their description. This is certainly plague for many VoIP clients, and identified as such in the recent H325 workshop. When asked what could be done about it, clever geeks came up with the clever idea of using ICE in GTalk. With a single clever move they left out all the VoIP clients using RTP on raw UDP for the media transport. When you think of it, this is just the vast majority of the SIP soft phones, and probably all the IP hard phones out there! Is this showing consideration for inter-operability? I doubt it. The enterprise market will obviously want to leverage the huge investments they made in SIP as a result of their listening to all the big telco vendors. A growing population on the Internet is using SIP based soft-phones as an alternative to the proprietary Skype. I would have thought one of the ways to show how superior XMPP is, would have been to enable voice communication with these SIP soft phones. I do not consider it such a distant dream to have a Jingle client holding a voice conversation with one of those SIP soft-phones, or IP hard phones. But that requires the real support of raw UDP in the Jingle libraries. It would mark the beginning of the kind of media inter-operability I mentioned in a previous post. Jingle to remain a player as a standard must extend the GTalk only model to include RTP/UDP transport. And as good protocol standards must define minimum mandatory requirements, I believe the base Jingle audio stack must look like this:

Implementing this base Jingle stack in clients and servers will greatly facilitate the emergence of XMPP as a strong VoIP player. Just look at the Libjingle media components, they are used by a number of public IM clients, and several IP phones. At least there is already compatibility at this level. Let’s make sure we do not miss the media transport compatibility. Doing so, Jingle will appear both protecting the investment through its support for legacy UDP/RTP transport, and extensible by its early adoption of ICE. On the server and IPBX side, I believe this extended support will make it easier for the community to quickly develop simple proxies or gateway to SIP, the other prominent signaling protocol.

Technorati Tags: XMPP, Jingle, Jabber, VoIP, IPBX, SIP, Session signaling, Antecipate