View source

Several key areas are still up for decision.

== Transport ==

How to move [[XML]] reliably and in a flexible, secure way? [[XMPP]] is an interesting protocol from this respect,
and comes with a bunch of libraries to do it. Which encryption standards does it make sense to follow?
Can [Javascript] do something with X509 client certificates?

== Encryption ==

W3C crypto is broken. 

The main problem core the core services is that [[XSL]] is not sensitive to XML [[XML#namespaces | namespaces]], but
hash functions of serialised XML ''are''. So the obvious thing to do would be to define an extension to
W3C specs (e.g. a custom XSL transform to canonicalize the namespace prefixes and standardise position of
namespace nodes). 

The cryptography of individual packets needs to be settled. Signed? Encrypted? Or Both? Or Neither?
If so, how?

== GUI ==

How fancy does this need to be? 
Currently, the only non-command line way of interfacing with the system is the debug GUI (/soft-systems/''Account-Name''/debug.php),
which is good for debugging, but end users don't want to see this.

== FF12 Client Specification ==
An elaborate specification exists for clients [http://altruists.org/ff12 FF12],
but the code to implement this never got quite finished (Robin got tired of JS DOM and wanted a break).
Is it too elaborate? The ad hoc (simpler) framework could be pretty effective.

=== Browser GUI ===
It's a nice (and simple) idea to offer a GUI in XHTML. 
If we're not using '''FF12''', just presenting XML in cascading [[XSL]] transforms is fine.
[[Javascript]] exists to do this for Mozilla, and to send of packets etc, which would be good enough to create simple interaction.

== XSLT processor ==
Option for how to use a different xslt processor

* Xalan
* Saxon

perhpas using php/java bridge