Assured: The Isode Blog

New Features in R14.4v1

Our usual approach to adding new features is to do so to coincide with major and minor releases. Update versions to a release will always be drop-in replacements of previous versions of the release, and generally only contain bug fixes.

We sometimes add new features where these are non-disruptive (e.g., add-ons at the periphery, rather than changes to our core server products), particularly early in the life of a release when we do not want to make customers wait for the next release to get a new feature.

We are adding nine new features to R14.4 in the R14.4v1 update version

1. Improved GUI Management in Sodium for Security Label and Security Clearances (more)
2. Security Label/Clearance/Policy tools (more)
3. Support for XEP-0237 (Roster Versioning) in M-Link (more)
4. Improved Sodium Sync operation for Sync to Active Directory (more)
5. Support of HSQLDB as Audit Database option (more)
6. Audit Database management service (more)
7. STANAG 5066 Console Updates (more)
8. X.400 Gateway API Extensions (more)
9. Enhancements to the Java X.400 Client API (more)

Improved GUI Management in Sodium for Security Label and Security Clearances

The 14.4v0 GUI capabilities for handling security labels and security clearances meant that in practice you are restricted to either very simple labels/clearances or you load pre-prepared labels/clearances from files (XML or ASN.1).   

We have added a Catalog mechanism, that enables simple GUI selection from a standard list.  For a simple security policy, the Catalog would simply be a list of all possible labels or clearances.  For a complex security policy, it would be a selection of labels or clearances appropriate for the deployment.

This Catalog mechanism has been added to Sodium. We will add it to other places in future releases (in particular to IMA for User Clearances, and XUXA for Labels). Sodium now has Catalog support define in templates for the following applications:

M-Link/M-Vault/Third Party Applications

• User Clearance (Security Clearance in a directory entry)

M-Vault

• Security Label as operational attribute in any entry
• DSA Clearance (to control data in the server)
• DSA Label (to control connected users)

M-Link

• Server (Domain) Clearance (to control messages switched)
• Server (Domain) Label (to control connected users)
• MUC Group Clearance (to control messages switched)
• MUC Group Label (to control group members)

Isode will provide sample Catalogs, along with the sample Security Policies included with  R14.4. This will enable easy setup of Security Label capabilities in our products.

Security Label/Clearance/Policy tools

We're including a number of command line tools in the release. We've been using these internally, and it has become clear that they will be useful to customers setting up systems using Security Labels. Tools include:

Label, Clearance and SPIF tools:

• format conversion (between supported ASN.1 and XML formats)
• descriptive dump

ACDF Tool

• Evaluates the ACDF (Access Control Decision Function) to check a label against a clearance under a specific policy

Security Label & Security Clearance builders

• Tools to help correctly build complex Security Labels and Clearances according to a Security Policy 

Catalog Builder

• Creates a complete (Label or Clearance) Catalog from a SPIF (Security Policy Information File)

Support for XEP-0237 (Roster Versioning) in M-Link

XEP-0237 "Roster Versioning" has been added to M-Link.  This specification, which is expected to become part of the core XMPP protocol at some stage, optimizes client connection by only providing an updated roster if there has been a change since the last connection. This is an important optimization for clients working over slow links.

XEP-0237 uses the same techniques to optimize network use as IMAP CONDSTORE RFC 4551  "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization" which is implemented by M-Box. Isode has been a major contributor to and editor of both of these specifications.

Improved Sodium Sync operation for Sync to Active Directory

We've made some changes to Sodium Sync to improve sync to Active Directory, and in particular added support for mapping X.400 OR Addresses into the forms required by AD/Exchange.

Support of HSQLDB as Audit Database option

We've added HSQLDB support as an alternative Audit Database option to Postgres.  HSQLDB is a simple Java JDBC database.   

One reason for doing this is to clearly demonstrate and test the database independence of our tools.

The second reason is to provide an easy demo setup. We are bundling HSQLDB with the Isode product set, which makes it easy to set up an Audit Database for demonstration and evaluation purposes. Our experience suggests that HSQLDB scaling limit as an Audit Database is around 40,000 records, which

means that it is unlikely to be suitable for production use.

Audit Database management service

We've added a way to manage removal of old records from the Audit Database. This is done by the AuditDB Management Daemon (which also takes on the functionality of the existing AuditDB Quarantine Management Daemon).  

STANAG 5066 Console Updates

We made some improvements to STANAG 5066 Console in order to do STANAG 5066 benchmarking, and have included these changes.  The benchmarking is described in the Isode Whitepaper "STANAG 5066 Performance Measurements over HF Radio".

X.400 Gateway API Extensions

We've extended our X.400 Gateway API to better expose the message content. This will be of interest to those handling content types other than IPM or P772, and in particular those needing to access the CMS layers of STANAG 4406 ed 2.

Enhancements to the Java X.400 Client API

The R14.4v0 Java Client API is implemented as a thin layer over the 'C' API, and provides a similar API. This is convenient for those using both APIs, but means that the Java API is quite low level and of a style that would be expected by a 'C' programmer, but does not take advantage of Java language features. We have added a higher level interface, which will be natural for Java developers, and should reduce development times for those building X.400 applications over our Java X.400 Client API.  

Google Wave: Important for Messaging

Google Wave, recently announced by Google and available later this year, is important for messaging. The launch presentation is worth viewing by anyone interested in messaging.

Google Wave has an abstraction that seeks to replace both email and IM, and perhaps shared document editing too. Google argues that email was designed a long while ago, and that with modern technologies we can do much better. A converse argument is that email is a natural and basic electronic communication that evolved without design (much as soccer evolved without the need for formal rules or design). Things that really impress me about Google Wave are:

• The amount that can be done in the browser, in a way that is clearly browser independent. This is a long, long way from static HTML.
• The way that messages are shared as you type. (Scary, but really neat technology.)
• The use of XMPP (Internet Standard eXtensible Messaging and Presence Protocol) for federation. The need for getting XMPP (as well as HTTP) into the browser seems an increasing priority.

This is a technology to watch.

Desirability of a Multi-Vector UI

I watched my son using his iPhone the other day to exchange SMS with his girlfriend. The UI was modeled on iChat (Apple’s IM client), and it seemed a natural way to use SMS. My Nokia phone has an integrated messaging interface, and gives a uniform UI for SMS and email. I can see my SMSs with a listing pretty much like my email. The key observation is that UI can be remarkably independent of the underlying technology.

Under the hood, Wave is essentially “bboards on steroids.” It is a shared data structure to which multiple users can contribute. Having this will add to the list of things that I need to interact with.

What I would like is a single UI that deals with all of the underlying abstractions (email, IM, SMS, Wave) — a communicator that can present information in an appropriate manner and use whichever channel is appropriate. It would be good to decouple the UI from the transport more strongly.

Email Won’t Go Away

I often end up in interminable email discussions with multiple nested quotes of previous messages. Engineers seem particularly fond of this style. Google Wave seems to offer a much superior interface for this type of dialogue.

However, it does not seem a replacement for all email. Email can often be a highly transactional mechanism. When dealing with emails to external organizations and individuals, there will often be shared internal review of the message and a carefully worded response before it is sent. The sharing and dynamic nature of Wave does not seem appropriate for the external communication. Email as it stands seems to have uses for which it will not get replaced. It seems to remain a basic and essential communications building block.

Google Wave Won’t Be the New Desktop Client

For those with almost permanent access to fast networks, shifting to a Web-based communications option seems quite plausible. For those who travel on trains and planes, carrying your email world on your laptop remains highly desirable. The ability to use Google Gears to replace this seems pretty much a fantasy for now.

It also feels right to me that having an optimized tool (both in UI and protocol terms) for tasks that are done a lot (and I do email a LOT) seems sensible. If you have special communications protocols such as IMAP (Internet Message Access Protocol) and XMPP, why try to layer things over HTTP?

The lack of competition in desktop email clients is a problem. I use Outlook, which I think is the best option available, but it could do so much better. The lack of serious competition to Outlook is a real problem (and yes, I know about Thunderbird). Competition in the browser market has really improved things for everyone. We need a good desktop client. It is crazy that there is not a client that does efficient IMAP and XMPP with an integrated UI.

Google Wave does not provide an answer to this, but it certainly challenges all who are concerned with communications UI.

This was originally posted on the Ferris Research Blog.