You might know that StAX (JSR 173) and the System.Xml.XmlReader/Writer classes are quite similar, at the very least in scope. A very interesting difference (that gave me a lot of grief in porting/implementing these APIs) is the way namespace attributes are being treated.

In StAX, namespace attributes are typically dealt with through different calls than those used for 'normal' attributes. This special treatment also comes with a table, where defined namespaces can be stored and referenced. In .NET, a namespace attribute is just another attribute, but they also have an XML namespace table, managing prefixes and scope.

While the differences are only significant on layer 8 and 9 of the ISO stack (politics and religion), porting from one to the other API is quite interesting and - at times - forces you to think about the infoset in new ways.

WCF can be quite annoying - that is, it sometimes does thing in a way I personally don't like.

While happily coding FIFI (the Fast Infoset implementation for WCF that will be demoed on JavaOne), I noticed that the System.ServiceModel.Message.Write(XmlWriter) method does not use WriteStartDocument and WriteEndDocument. This is quite annoying, since nodes in FI need to be properly terminated. Sigh ...

XML and Web services are loosely coupled, right? And loosely coupled and object references do usually not play nice together...

This is quite interesting: It looks like you can preserve object references and pass them along when setting the preserveObjectReference flag to true in a new DataContractSerializer.

I will play around with this and see how this looks on the wire ... stay tuned.

Lauren Wood sent me this web link.

Internet Net Neutrality

I wrote this a few years ago, just months after moving to the U.S. I was in San Diego at that time, at the 49th IETF meeting. One afternoon, I had some time, so I decided to drive to the U.S.-Mexican border. It was quite an experience, and quickly afterwards I sat down in a small outdoor cafe to write down some thoughts that I had back then. I just found this piece when cleaning up my home directory.

Sadly, the House Commitee on Energy & Commerce decided to strike down the provisions in a draft bill that would have allowed the FCC to stop ISPs and telco from extorting customers and web service providers. The arguments of the ISPs are hypocritical: the lack of such provision will allow them to stifle innovation, effectively shut down or limit competition (like e.g. Vonage VoIP service, or the next generation of media delivery).

I sincerely hope that other commitees of the House and maybe other parts of Congress in general will handle this ciritical situation with a better understanding of the technological and commercial ramifications. I also hope that Rep. Markey will not bow down to this defeat, but instead fight for his very sensible provisions elsewhere.

It is interesting to see what Microsoft has done with Windows Mobile so far, and where they plan on going. This presentation give a good overview and also a fairly good lookout on what is coming and when.

Some highlights:

• Windows Mobile 5.0 - released
• MSMQ support
• SQL Server 2005 mobile
• .NET 2.0 compact
  
• 'Crossbow' Release in late 2006, to hit the market by mid-2007
• 'Photon' Release in late 2007, to hit the market by mid-2008
• New kernel
  

It seems that they are now switching to releasing a new version of the mobile OS every year or so.

Interestingly enough, they seem to have cut the roadmap slides in the above version (or am I missing something?), but you can still see the full slide deck using Google's cache.

If you are at all interested in non-SOAPy web services, you might want to take a close  look at WADL, the Web Application (!) Description Language. It is an XML based language that can be used to describe general HTTP-based service APIs that can not be described reasonably in other meta-description frameworks, such as WSDL.

Ultimately, this technology will allow web service providers (such as Amazon, Ebay, Google, Yahoo!) to focus on providing their respective services, and not on creating new APIs in a variety of languages to use these services.

Aside from everything else happening around me, I had 'one of those days' yesterday:

It actually started pretty good. I finally got my acto together and moved my 19" rack from my garage to work, to get better use out of it. Fortunately Marc H. was able to help me, since this thing is really heavy (and would never fit into my little crappy car). Everything worked great, and in less than two hours the rack was happily humming in my lab. We went to lunch.

Now, after lunch I want to move my old server (mail, file & print, CVS, etc.) into the rack. Fair enough, not a big one: everything in the rack connected, I start the system, BIOS and POST come up, the OS is starting to boot happily ... 3 ... 2 ... 1 ... BLACK. No more restarts - the system is DEAD.

A few sweat drops later, I see that the fuse in the power supply blew. Well, not a problem: it is a six year old system and after a little scavenging in old PC rubble, I find a compatible 6.3A fuse, replace it, put the system back together: it works! Great, back into the rack, power on, BIOS comes up ... 3 ... 2 ... 1 ... BANG, smoke coming out of my server .... argh!

The adrenalin level is quite high now, and I decide that a smoking power supply will be a little too hard to fix. CompUSA is your friend, and a few 45 minutes later I am back with a brand new 500W power supply. Finally. Well, the old one was over 6 years old anyways, no surprise. Into the rack, power on ... 3 ... 2 ... 1 ... BANG ..BANG.... (dead silence).

Something is definitively fishy here, right? Have I just lost my marbles or what is going on?

Well, something is strange, but this time it was not me: The Compaq (now Hewlett Packard) PDU (Power Distribution Unit) is a 127V 30A monster, which comes with a fat power cord and a huge three prong plug. In the past it fit happily into a 125V, 30A outlet. The outlet in my lab, which fits the plug really well, is a 250V outlet.

It seems to me that either (i) the electricians of the building have made a fatal mistake, (ii) the Compaq (now HP) engineer designing the PDU was smoking something terribly unhealthy or (iii) the electrical code is inconsistent. Either one of the three possibilities is not quite reassuring ...

Here is my presentation from yesterday's panel discussion at the Network Security 2006 conference (many thanks to Hubert and Eve, which have essentially provided the largest part of this).

Network Security - SAMLv20.pdf (103.81 KB)

After an interesting panel discussion yesterday at the Network Security 2006Conference, I started to think about security protocols in general again. One comment from a gentleman in the audience struck me in particular: PKI (and other authentication systems) are hard to setup and control, because every time you create a new authentication service you have to fill in all kind of attributes for the user at hand, e.g. name, employee id, group membership etc.

As we all know, directories are great, but they are not exactly capable of solving this problem. Instead, this problem could be solved by separating authentication and autorization data, keeping the authZ data in a common format [1]. SAML (in particular attribute statements) might be a good solution for the authZ data format, since it is well undestood, extensible and has good privacy features. But obviously, there might be other good, open authZ languages, as well.

If the authentication mechanism are now capable of carrying the authZ data (such as the in the SAML TLS proposal, or in GSS-SAML), then a few requirements of a good authorization model are fullfilled:

1. The authorization data is described by an open language.
   
2. The authorization language is stable across different authentication mechanisms.
3. It can be carried directly within the framework of the authentication protocol, - or -
   it can be left on the authorization server an only be referrenced.
   
4. It provides at least for pseudonymity, if properly properly profiled also for anonymous authorization.
   

[1] I am assuming here that a bag of attributes is sufficient to enable authZ decisions.

On May 17, 2006 at 9:30pm Paul, Santiago and I will host a BOF on "Project FIFI - Bridging the Interoperability Chasm". FIFI (Fast Infoset For Indigo) is a prototype project that aims at bringing the Fast Infoset ITU-T/ISO standard to the .NET 2.0 platform and furthermore integrating it with the upcoming Windows Communication Framework (WCF - aka Indigo).

BOF 2535: Project FIFI - Bridging the Interoperability Chasm
Track: Web Tier
Room: Hall E 135
Date: 17-MAY-06
Start Time: 21:30

Stay tuned for more.

Fresh from Washington state: Indigo to support POX in TextEncoder

Combine this with Marc Hadley's adventures with REST in JAX-WS, and you might actually get something interoperable ..