• JWGC: http://www.blathersource.org/projects/jwgc/changefeed
• PyAIM-t: http://www.blathersource.org/projects/pyaim-t/changefeed
• PyICQ-t: http://www.blathersource.org/projects/pyicq-t/changefeed

There are also links on the project info pages. Enjoy!

Incoming search terms:

• rss to xmpp (1)

Currently it partially supports ad-hoc commands which are specified in XEP-0133 Service Administration and implemented by Tigase XMPP Server. As for it contains support for:

read more

Several companies already have an intranet authentication backend, like LDAP, Active Directory or an Ad-Hoc database. On the other hand our experience with large sized companies is that is not a good idea to expose LDAP or Active Directory to the internet.

To overcome this problematic scenario we have added a new authentication method, which consists on delegating the authentication to an external REST API, acting as a façade to your own intranet database.

The behaviour expected by hosted.IM is fairly straightforward. Your API must answer a GET query with details about the user that is trying to authenticate to your IM domain with 'true' or 'false' depending on whether the user is authorized or not.

In the image below we see how mydomain.com administrator sets https://mydomain.com/auth as the REST URL and clicks on the highlighted Verify your service link to ensure hosted.IM is able to contact it:

The next step would be to click on the 'Switch' button and that's all!. Now hosted.IM will authenticate users against your company data source.

Below is the specification of the authorization API: URLConfigured on hosted.IM user administration form. Could be HTTPS (recommended) or HTTP MethodGET ParametersusernameUsername part of the user ID to be validated passwordPassword sent by the user to be validated domainDomain part of the user ID to be validated secretArbitrary string defined on hosted.IM user administration form Expected replyCode200 OK Content-typeapplication/json Bodytrue if authorized; otherwise false ErrorCodeAny HTTP code, according to the error type. It will deny user access.

This release also includes other improvements suggested by our users. It contains also bug fixes.

As we continue improving daily our service, we will greatly welcome your feedback. There is already much more to come soon. Thank you!

Links:

after some more weeks of testing, debugging and developing, we would like to ask for your support and publish the first beta of Spark 2.7.0. Ultimately, we would like to move Spark to Java 7, but that is currently not implemented via the installers.

You can find the nightly build for Windows here:  http://bamboo.igniterealtime.org/browse/SPARK-INSTALL4J-520/artifact/Install4j

About Java 7: Spark 2.7.0 will run with Java 7. Please interchange the bundled JRE (located at Spark-install-folder\JRE) against a Java 7 JRE or use the installer named spark_2_6_3_12555_online.exe and install Java 7 as default on Windows. Using Java 7 will stop Spark from stealing the focus, when a new message is received.

Important Note: Oracle has introduced a bug in Java 1.6.0 u 25-27 that prevents Spark from closing automatically during the log-off on the Windows plattform. This is not Spark related.

About file transfer: Spark 2.7.0 is fixing issues with file transfer. It will move to a standard implementation for IBB file transfer. As a result of moving to the standard IBB implementation, you may have issues with transfer between Spark 2.7.0 and Spark 2.5.8 on IBB. This is an unavoidable result of obeying the standard. IBB is the fall back implementation, if Bytestream is not an option. Hence IBB is not the regular transfer method as it is much slower than Bytestream.

About plugins: There were large scale changes in the way Spark is dealing internally with plugins/extensions. All Plugin developers are kindly ask to review, if their plugins are still working. This applies also to Fastpath. Feedback regarding issues with this are highly appreciated.

About GUI: The Spark debelopers are only supporting JTattoo Luna. There are several reports that other skins are not working properly. This applies especially to Substance. If you are experiencing any GUI bug, please check if JTattoo Luna is also having this issue and report it.

About Mac and Windows7 64 bit: The next Mac release is NOT secured. We are looking for a developer who can provide a Mac beta release. The integration to Windows7 64 bit is ok, but the flashing notification in the tray may or may not work. A tester and developer (MS C++ Code)  for this is also needed.

The change log for this alpha are:

SparkToaster showing avatars in real size

Bug in PrivacyManager that can break smack communication

Selecting 'Start a chat' in a group chat room opens an incomplete chat window

Update build.xml to check for Java 7

Bug in ConferenceUtils.java that can break smack communication

Update simplified Chinese translation

Chat room configuration shows wrong roles for which presence is broadcast

typo error in LayoutSettings.java

ContactItem in shared group - right click popup menu performs copy when move is selected

Plugins are loaded in random order - plugins with no dependency has to be loaded first

Default Appearance/Colors cannot be overwritten through plugin;Group-Chat colors are hard-coded

Group Chat - Actions/Start a conference menu: propose bookmarked room (if any) instead of adhoc (random) room name

SPARK-1311 Enhance ability to overwrite spark properties values through plugin

Privacy plugins cannot be accessed if we log into Spark through the IP address of the server

SPARK-1311 Make tabs position optional: TOP or BOTTOM; make search input appearance optional

Subscription dialog shows the id value instead of the nickname

When network connection is lost, chat window cannot be closed

SPARK-1311 Enhance ability to extend core classes like ContactItem, ContactGroup, etc through plugin

Improved last activity recognition

Log out doesn't log out, it shuts down spark

Avatars are not scaled in user login/logout notification dialog

The messages in the set status message window is not getting deleted

JabberVersion.java uses hardcoded value "Spark IM Client" for version name

Application version and application name are hardcoded

Remove "#" character next to Accounts button on the login screen

persist vcard may throw file not found exception when jid is empty

Expect a beta in 2 weeks time that will include the latest final release of Smack (to be done in the next 2 weeks)

Please report issues in the Developer Forum

This presentation explains what is the use of XMPP in those solutions and how XMPP can be use to do much more that chat systems.

You will also learn how can ProcessOne help making realtime notifications, alerting and push a part of your business?

Wednesday, November 9, 2011

06:00 PM - 07:00 PM - CET - Paris, Brussels, Berlin 12:00 AM - 01:00 PM - EDT - New York, Montreal 09:00 AM - 10:00 AM - PDT - San Francisco, Los Angeles

You need to register now in order to attend the webinar: Registration URL: https://www2.gotomeeting.com/register/439179866

We hope to see you in great numbers!

Looking at the given mentioned problems (OTP and binary support), one of them is already in ejabberd 3.0 alpha (binaries), but what got my attention is that finally they might not be problems. It always depends ultimately on what you want to achieve. Some optimisations might be relevant in a few cases, but in a generic situation I still think that optimisations we made for ejabberd project for our customers on a case by case have a much larger impact. Some of the mentioned improvements would also stand on your scaling path for different use cases.

Let me take a specific example. OTP compliance is a controversial topic. Erlang OTP stands for Open Telecom Platform and is essentially a set of good practices and pattern to build Erlang applications. OTP provides a convenient help to get started but it is no silver bullet for all Erlang applications design. Sometimes, they fit in your problem and sometimes you have to do it differently.

One of the typical OTP pattern is supervision. You are supposed to link Erlang workers (the process doing actual work) to a supervisor that can trigger actions when the worker terminates.

However, for extremely large systems, with lots of worker creation and destruction, the supervisor comes with a performance penalty that you cannot afford. You thus have to disable the transient supervisors. In that case, OTP approach can limit your performance and become a bottleneck.

My view is that to get the best performance, you have to know and observe how the system behave in real world situation, for the specific use case. XMPP is a large protocol, especially with tens of XMPP Extension Protocols that have been added over time. If you want to scale you have to have a perfect knowledge of Erlang inside / out, but also a perfect knowledge of the XMPP protocol itself. Some requirements or suggested approach in the protocol do not scale out of the specification, and you have to take into account a full solution design, from the client behaviour itself to the cluster architecture and code optimizations.

Micro optimisations at the code level are doomed to be very limited. However, optimizing the full stack, from client (both desktop and mobile) to server, including specific code level optimisations, is a sure win. From experience, we can squeeze from 2 to 3 times more concurrent users on a single node. Your mileage might vary, but it clearly demonstrate that multiple levels of knowledge are involved in designing a scalable XMPP messaging solution.

I understand it is frustrating to hear that from a customer perspective: they often expect turnkey solutions that scale linearly. However, after a few times working with us, they understand our view and why scaling cannot rely on a one size fits all approach.

We have developed a set of modules for ejabberd and optimisations and a range of expertise at Process One down to the client. This allows us to scale to unprecedented levels. OTP offers nice patterns, but is no substitution for this experience working on the largest XMPP deployments in the world.

�

�

Edit: I have received good feedback, saying you understand our point of view. Thank you !

Just to make it clear, my point is really to think and act global at the highest architectural level. We do everyday many improvements to ejabberd at the code level and this is good for code maintenance. What makes a deployment successful is team with different background working on the whole picture.

Some things we now know to be good ideas:

It’s hard to be­lieve that there was a time when any of these weren’t con­ven­tional wis­dom, but there was such a time. Unix is com­posed of more ob­vi­ous-in-ret­ro­spect en­gi­neer­ing de­sign choices than any­thing else I’ve seen or am likely to see in my life­time.

It is im­pos­si­ble — ab­solutely im­pos­si­ble — to over­state the debt my pro­fes­sion owes to Den­nis Ritchie. I’ve been liv­ing in a world he helped in­vent for over thirty years.

• JWGC: http://jwgc.blathersource.org/
• PyAIM-t: http://pyaim-t.blathersource.org/
• PyICQ-t: http://pyicq-t.blathersource.org/

More to come as I continue porting over bug reports and such.

Incoming search terms:

• rrd graphs icon (1)

The specification, which we support in Isode M-Link, is also supported in other third party clients and servers, and is authored by Kurt Zeilenga, an Isode engineer.

Interested parties should submit comments on XEP-0258 via the XMPP Standards Foundation’s standards@xmpp.org mailing list.

just a short notice to show a feature i'm currently implementing, the hability to pipe out a command line stream via XMMP, using jp, the command line frontend of the "Salut à Toi" project.

The syntax is quite easy: imagine you have 2 people Pierre and Louise talking together. Louise is talking about the last Blender Foundation movie, Sintel, and Pierre is interested, and want to see the trailer Louise is talking about. To do that, he just has to enter the following command:

jp --pipe-in louise | mplayer -

Which mean "I'm waiting for an incoming stream from louise". Louise correspond to the name Pierre gave to its contact louise@example.org, jp do the association.
He could also have used the full jid instead: louise@example.org/Noumea .

In the other side, Louise can pipe out the trailer to Pierre with the following command:

cat sintel_trailer-480p.ogv | jp --pipe-out pierre

Quite easy isn't it ? You don't have to worry about the IP address of your contact, just to know its jid, or to have it in your roster with an easy-to remember name.

If you want to copy a file, the syntax is quite similar:

jp -wg louise

jp -g sintel_trailer-480p.ogv pierre

The following short video show this in action. It's in french, but you don't really need the comments to understand it.

To play the video, you nead a recent browser (e.g. Firefox 4+ or the last Chromium).
You can also use VLC (>=1.1 only), by using this url as a flux: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm

Last but not least, you can use mplayer: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_4_copie_et_pipe.webm"

This video is licensed under Creative Common BY-SA
Your browser doesn't manage the « video » tag, you should update, e.g. with the last Firefox

For the technical side, it's just a modified XEP-0096 . It would be intersting to propose this as a standard to the XSF, but maybe by using jingle transfer instead.

Please not that all of this is really experimental.

I plan to release the next version of "Salut à Toi" soon, stay connected :)

This is just a short list of them: New SASL SCRAM-SHA-1 authentication mechanism (EJAB-1196) New option: resource_conflict (EJAB-650) Decrease CPU usage caused by tls:send with large data Replace calls of OTP's Binary, since they would require R14 LDAP: Document ldap_tls_cacertfile and ldap_tls_depth options (EJAB-1299) LDAP: Log an error when an LDAP filter is incorrect (EJAB-1395) LDAP: New options: ldap_tls_cacertfile and ldap_tls_depth (EJAB-1299) LDAP: New option: ldap_deref_aliases (EJAB-639) MUC: Support for multiple entry with same nick to MUC rooms (EJAB-305) MUC: Support voice request and approvement MUC: New room option: allow_private_messages_from_visitors MUC: New room options: allow_voice_requests and voice_request_min_interval ODBC: Fix account counting (EJAB-1491) ODBC: Optimized mod_roster_odbc:get_roster PubSub: Enable pubsub#deliver_notification checking (EJAB-1453) PubSub: Fix Denial of Service when user sends malformed publish stanza (EJAB-1498)

Check the Release Notes for a more complete list of changes: http://www.process-one.net/en/ejabberd/release_notes/release_note_ejabberd_2.1.9

If you upgrade from ejabberd 2.0.5 or older, read carefully the release notes of ejabberd 2.1.0 too, because there were several changes in the installation path and the configuration options.

The list of solved tickets since previous version is available on ProcessOne bug tracker: http://redir.process-one.net/ejabberd-2.1.9

ejabberd 2.1.9 is available as source code package and binary installers for Linux 32 bits, 64 bits, Mac OS X Intel, and Windows: http://www.process-one.net/en/ejabberd/downloads

This alpha release contains all the changes from ejabberd 2.1.x branch, many other ejabberd 3 specific changes, and a few improvements like: Option static_modules fully working Update http_bind to XEP-0124 1.10 and XEP-0206 1.3 Replaced the full ejabberd_zlib into a simple exmpp_compress interface

The related tickets can be found on the bug tracker: http://redir.process-one.net/ejabberd-3.0.0-alpha4

Please note that the database schema used in this preliminary release is not yet definitive, and it will probably change in the next alpha and beta releases.

When compiling the source code, it is necessary to install exmpp.

Recommendation: try this alpha release far away from a production server. Try it with an empty database, or with a copy of your existing database. Please report bugs you find, including logged errors if any, in the usual https://support.process-one.net/browse/EJAB or in the ejabberd mailing list.

For more information check the release notes included in the release and in https://git.process-one.net/ejabberd/mainline/blobs/raw/master/doc/release_notes_3.0.0.txt

Source tarball and binary installers for preliminary releases can be downloaded here: http://download.process-one.net/ejabberd/

This release of exmpp contains: Many improvements in OpenSSL management code Enable port level locking in OpenSSL, stringprep and zlib drivers Use binaries for xml attribute names in the IQ macro Added presence handling to echo_client.erl

exmpp home page: http://support.process-one.net/doc/display/EXMPP/ or easier to remember: http://exmpp.org/

Download exmpp 0.9.8 source code package from: http://download.process-one.net/exmpp/

You can also check the ProcessOne Labs page: http://www.process-one.net/en/labs/

This release includes a lot of bugfixes and improvements. This is just a short list of them:

read more

“Do you anticipate that the use of WebSockets will improve performance? If so, can you estimate to what degree?”

It will since you don’t need to open and close connections all the time. I can’t estimate at what degree, but I think the communication will be much faster since currently some time is used to re-create connections.

But I see that as a false benefit. The original model for HTTP was to use the “classic” open, request, retrieve, close sequence; now all modern web servers support a single (or a small number of) connect per web session to allow for more efficient data throughput. What is false is that websockets will now run into the same problems that web servers and other client-to-server applications have been running into: NAT traversal and cross-domain issues.

Remember that websockets are just that – the browser allowing you to open a persistent socket to another tcp/ip endpoint – it doesn’t provide any of the services that are now required on the back-end. The javascript coder will need to start layering on top of their code routines that implement STUN, TURN, ICE and/or SIP.

This leads me to think that current server implementations that already support these technologies could/should be modified to support websockets – I’m looking at you XMPP :)

Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.

The 3.7.1 release is primarily a bugfix release. Amongst others, these issues have been addressed:

The full changelog is available on the Openfire project page.

We welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages.

We are all expecting to see the Amazon tablet announced, the Kindle Fire. It will be a 7 inch Android 2.x device and will not only focus on books reading but is likely to be a compelling selling point for other Amazon content as well: Movies, Music, Applications.

However, I anticipate that Amazon will soon enter the "social network" market in a broad sense.

They currently have the Amazon website, which is a huge source of reviews for hundreds of thousands of items, from books, to DVD, electronics and many more. This site has a huge audience: 20% of Internet Users Visited Amazon in June.

They also have the extremely low profile Kindle site: https://kindle.amazon.com/

This is a draft of a social network for content discovery. It is linked to your Kindle device reading. They know which books you have bought and when you have read a book, they offer you to rate. You can thus share with your followers what you have read and if you like it. You can also share your quotes from the book.

Does it sound familiar ? It looks a bit like the new Facebook feature announced last thursday to share lightweight activities. You can share on Facebook what books and articles you read. Facebook can already do more of course: You can share movies that you watched and music you have listened to.

Amazon is about to launch a tablet with new media capability and will be very soon in an excellent position to do share more behaviour.

So, I do not think Amazon will today launch a "social network". They are probably not ready yet. However, I bet that Amazon will launch a social network initiative sooner or later. When they will enter that market, they will do that with extremely good fighting chance and an obvious business model: Selling you more goods.

This article was originally posted on Google+. Check the reaction on Google+ post.

There is huge progress in MatriX. Many of our customers are demanding support for special XEPs and other library extensions. So I have been working very close with them implementing many new XEPs and other useful features. I will create separate blog posts for some of these features.

Windows Phone Mango is coming now with sockets. So I have added sockets to the Windows Phone Mango version which is RTM now.

The port of MatriX to Android using mono for Android is nearly finished. You can expect a beta version very soon. Drop me an email when you are interested to join the beta test.

Whats next? Once the Android version is done I will start to work on a iOS version with MonoTouch.

You will be able to target all major mobile platform and reuse lots of your existing code and business logic.

There was no official release for a while, but the latest stable builds are always located here: http://www.ag-software.de/download-directory/

This foreword done, the comment originated from the need for proper conversion rules when translating addresses from a communication space into another. The example was taken from the current XMPP transport practices, where the non-XMPP address handles are encoded as the node part of a JID. I believe this practice is wrong and does not possess any good technical grounding.

In an XMPP addressing space, a component such as a transport will have a JID comprised of a domain part only. Let's say "transport.montague.net". If a user on the XMPP side of the transport has contacts in the legacy side, the common practice is to apply an encoding logic on the legacy address to build the node part of a JID representing that contact in the XMPP world. The result might look like "juliet%capulet_it@transport.montague.net". The issue with this conversion lies in the resulting urge by many developers to use this "logical" encoding of the node to derive a meaning in a client for example. If the contact JID had been "a2ff356@"transport.montague.net" the programmer would never had used the node for anything but its role. The opaque node keeps all the routing properties of an good address handle, which in this case requires that a stanza using this JID be routed to the "transport.montague.net" service. It is also easy to see that this approach is completely independent of the target legacy system.

Introducing a logic in the node encoding of early transports has

• induced developers to reverse this logic inside their code, creating a de-facto legacy inside the XMPP clients and transports implementation,
• imposed at a time different encodings because the target legacy systems have different addressing spaces syntax.

Lastly, I believe there is no good reason to use a logical encoding of the JID's node for legacy contacts. Finding the contact's address can be achieved by looking-up the opaque node value in a cached table to obtain the legacy address. In terms of performances, I believe the time difference between a lookup and a decoding does not count much when compared to the actual transport wire transmission overhead.

For those interested in the nitty gritty protocol details: file transfers are negotiated through the Jingle File Transfer protocol (XEP-0234), using SOCKS5 (XEP-0260) as the main transport, and In-Band Bytestreams (XEP-0261) as fallback. To improve connectivity, we use both the NAT Port Mapping Protocol and the UPnP Internet Gateway Device protocols to allow connections through most firewalls, and SOCKS5 relaying proxies in case all else fails.

The new feature has been tested for interoperability against (slightly modified) development versions of both Pidgin and Gajim, which, together with the Pidgin-based Adium, cover a large XMPP user base. After both clients update their protocols to track the newly published Draft specification versions, all 3 should be able to exchange files seamlessly.

What still remains to be done is lots of testing (both internal testing, user testing, reliability testing, and interop testing), bugfixing, and some refactoring here and there to clean up some of the code (which already is in very good shape). Our end goal is to reach a rock solid implementation, with a near guarantee that file exchange will always work (which experience teaches us is far from trivial).

To conclude, we’ld like to thank Tobias for contributing this great new feature to Swift, for providing valuable protocol feedback to the XSF, and for laying the foundation to other exciting Jingle-based features (including voice/video conferencing).

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

Well, if we take that definition into the human communication space, we could say that speech allow a good level of “protocol” level inter-operability. When we add the knowledge of a language, then we can exchange and hopefully make use of well-formatted (syntax) and meaningful (semantics) messages. What is in my opinion a little flawed in the IEEE definition is the part about usage of the received information. I believe inter-operability does not have a meaning outside the scope of a particular application domain.

In my previous post, I stated why I do not find great interest in the SIMPLE/XMPP “inter-operability” draft proposal. To re-enforce my previous position, I would say the draft describes proper messages syntax, even a beginning of shared semantic between the two protocols, but completely fail to put the inter-operability in context. Without the intimate knowledge of a shared human language, one can receive the perfectly valid speech flow without being able to use it. A bit similar to listening an opera where a Spanish tenor and an Italian diva sing in Russian. They exchange perfect syntax and semantic but with a limited use, mainly providing marks for the other to respond. Don’t you think we may be missing, like the spectator of the opera, a great part of the meaning?

It is funny how interoperability and federation between different communication media is always reduced to "mapping". This is once again exemplified by the draft proposal trying to explain how to achieve this hypothetical interoperability. From the architectural assumption, we already get the feeling this is too good to be true. Being amongst the very few people having implemented a federation between these two protocols, and probably the only one having designed a native SIMPLE connectivity on an XMPP server, I can tell you this is slightly more complex than the draft describe…

The draft goes to great length to describe how to convert between a SIP URI and an XMPP JID. This is an excellent and accurate work, and its undisputable merit lies in providing in one single document a thorough description of each address' syntax. But in real life, what are the chances for the addresses in these two communication spaces to require direct translation?. Not very high. Why would the syntactical similarity between a SIP URI and an XMPP JID provide a guarantee that the same address must be used? After all, we do not translate JIDs directly to email addresses, nor SIP URIs either. We do not translate AIM screen names to SIP URIs, nor to JIDs. In the real world, we perform a lookup of one communication space's address in the other... We use directories to achieve the "mapping", rarely direct translation. The only case where this would be used is when SIP/SIMPLE user agents connect directly to an XMPP server, which is somewhat uncommon.

Where the draft is not up to the task is when trying to map the long term presence subscriptions of XMPP with the short term subscription of SIP. It is all fine when there are no existing subscriptions form either side. In this case, translating an XMPP subscription into a SIP SUBSCRIBE would provide the desired effect. But only the first time. The next time, the permanent XMPP subscription will trigger a presence stanza, instead of a subscription stanza. Nothing in the draft addresses how to handle this difference. In SIP we have a well delimited publish-subscribe behaviour. In XMPP we have a variable context behavior: before and after subscription.

The draft indicates that the XMPP subscription could be terminated by the SIP subscription. But this is not realistic. From an XMPP user's stand point this would mean re-subscribing to the contact on every login. And further on, this would force the XMPP user to accept a SIP contact's subscription for every contact’s log in.

Working the other way round is easier, as it is always possible to translate a SIP SUBSCRIBE into an XMPP subscription. If no subscription exists for the SIP contact, the subscription stanza will be sent to the XMPP user's client if and only if the user is online. If the user is offline, the subscription will be stored by the XMPP server, awaiting the user's acceptance. So the gateway will have to deal with this case, which is not described in the draft. Similarly, the draft does not handle the case where the XMPP user refuses the SIP contact's subscription. In SIP, if a subscription is refused it translate into an error response. The gateway would have to be aware of the presence state of the XMPP user to take the right decision. This asynchronous handling does not easily "map" with the request/response nature of SIP. Following the proposed scenario, the gateway would have to maintain a copy of every user's presence. This is both inefficient and non scalable. And again not very realistic.

As said above, SIP presence is based on short lived publish-subscribe, initiated by the requesting user agent. This is the opposite of XMPP, where the server acts as a proxy for the client user agent. SIP relies on expiration to cancel subscriptions. XMPP sessions do not time out. SIP is connectionless, whereas XMPP relies on the client connection state to deduce the end of a client session. All these fundamental differences are not highlighted in the draft, and as a consequence the cases described are both superficial and incomplete.

In the end, I find no real value in issuing a document whose only real complete description is in highlighting the difference between XMPP and SIP address handles representations. It is also detrimental to reduce interoperability between the two protocols as a simple translation between message types. None of the real issues of application interoperability are addressed in this document which looses all its substance, and by consequence its necessity. Beyond having “the longest title in IETF history” I believe this draft would be better off retracted. This energy might have a better result applied to the Jingle specification…