The first draft as written by me in the beginning of 2005 after I left ASRG. The draft bounced back and forth over the last few years among an informal group of people at a mailing list maintained by Dave Crocker at MIPA. A large number of the list members were also members of MAAWG (of which I never formally participated but had the pleasure of speaking at their first conference in DC).

As I ran out of time, others have taken over the editing of the draft until the current editor, Murray Kucheraway took over. He has been very helpful in pushing for IETF standardization. A funny thing happened along the way as well – big ISPs started using the format – first AOL, then Yahoo and Microsoft.

This year, the IETF finally chartered a new working group which will now hopefully standardize this format and set it in a fixed version, so it can be used even more widely. Along with this, there is possibility of expanding different parts or uses of it as well.

A word of thanks goes out to all of the people that made this happen.

No word on whether any of those licensing fees will be refunded.

I also saw a related post by Kim Cameron of Microsoft on the licensing behind InfoCard. While he is very short on real details, he seems to assure us that it will be a normal RAND license. Where have we heard this before?

During the Sender-ID debacle, the same exact story took place. Microsoft promised that the license will be compatible with open source ONLY to release a license explictly incompatible with the GPL. Who says this will not happen again?

All posts in this blog will be merged with my main blog under a new category. I will try to preserve comments. You can point to my main blog feed http://feeds.feedburner.com/NetwizardsBlog or use this convient button to subscribe:

One of the recurring themes in standards development is the inevitable tug of war between standards bodies and the industry. Many times, specific companies may come up with different ways to solve the same problem and then seek to standardize it either for IPR or PR advantage. However, often part of the process is giving up the right to control the standards process which may mean that the end result might bear no resemblence to the original product. For this reason, many companies are relucant to give up their ideas to become standards. At the same time, it is often happens that the members of the standards body are reluctant to accept ideas from a company since they have been burned badly in the past. This results in friction among standars bodies and the industry, which of course is not good for anyone.

Ideally, the two should work together since it is the industry support which gets a standard rolling. Some of the best examples of that are bodies like the OpenGroup, the WiFi Alliance, and MAAWG which do not seek to impose standards but rather help with implementation and collectively provide industry input to the standards process. Standards bodies should also not ignore industry input but rather seek to engage them in discussions. Like everything this is a balancing act – one that requires a lot of tolerance from all parties.

About a month ago I wrote about the Forgent JPEG Patent saga. Recently a faithful reader sent me a copy of a demand letter sent on behalf of Forgent (to a company that shall remain unnamed). I have taken the liberty of transcribing the letter into PDF and HTML, making it available here (I removed the information of the company to whom the letter was originally sent). There are three documents:

1. Pages 2 and 3 of the actual letter demanding royalties (PDF or HTML)
2. Copy of the press release (PDF or HTML)
3. Partial list of companies already licensing the Forgent patent (PDF or HTML)

From the letter a few interesting things emerge. First of all, it seems that Forgent hired a law firm and a licensing firm for this. The law firm is probably acting like the bad cop, prodding people into compliance; while the licensing firm is the good cop offering terms. Second, what they want is 1.5% of all product sales which for companies like Microsoft will translate into a lot of money. Third, they are explictly going after the JPEG standard which means that any open source software and companies distributing it are at risk. They are also not stopping at going after big companies but are even looking for smaller fish as well.

One of these days I am going to get around to writing a more complete background of this draft and the process around it.

For quite some time, Mozilla-based browsers such as FireFox, Netscape and Galeon had a feature called “pre-fetching”. What this feature does is that it enabled browsers to “pre-fetch” any webpage link marked with a tag “rel=’prefetch’” to make the browsing experience seem faster. Google even added a feature to their search results to take advantage of that.

Also, back in January, Google in conjunction with many other search engines and weblog software vendors announced a new feature to combat comment spam – the “no follow” tag. Marking a link with “rel=’nofollow’” tells search engines to ignore the link in results, thus killing the very purpose for comment spam.

Now last week comes a new Google Labs creation – the Google Web Accelerator. This little tool prefetches and caches pages to make the browsing experience faster. However, this time not everything went as smoothly as before – as pointed out on the Signals Vs. Noise Blog causes many problems. However, the only way to turn it off is the same way as turning off prefetching – by looking for a special HTTP header. Note that regular prefetching as described above is set via an HTML link but can only be turned off via an HTTP header.

There are several interesting questions. First of all, prefetching as defined by the Mozilla FAQ refers to the specific act of prefetching web pages marked with the “prefetch” link. However, Google’s Web Accelerator is using the same header EVEN for links that are not marked that way. Second, among the suggested solutions for some of the problems caused by Web Accelerator was to use the “nofollow” tag to indicate to Google that specific links should not be fetched. BUT there is no way to do that since the “nofollow” tag is used for search engine rankings. Of course we can defined a new “noprefetch” tag type but that would only help if Google follows it.

Unfortunatly, what is missing from the discussion so far is one glaring fact – none of the “tags”, “headers” or “behaviors” described here are standards of any kind. Instead, all of them are proprietary extensions by vendors, must alike some of the non-standard behavior often used by Microsoft. However, this time since this are the darlings of the Internet – Google and Mozilla, there is no outcry. Unfortunatly, there are not standards – rather their are “non-standards”. A lot of the issues that are being described by people with these tools are due to the way different people do things on the Internet. Standards are ways to get around that by having an common agreement.

So what’s the solution? It is time for all the parties involved to sit down and formally standardize all of this stuff. All of the companies involved are members of the W3C and should be able to submit this for formal standardization while working out the thorny issues. Otherwise, these will simply devolve into a “Wild West” game of “non standards”.

Slashdot posted a story about the approval of the new OpenDocument standard by OASIS. The actual standard is available in PDF and OpenOffice formats. The obvious focus of this activity is against Microsoft and its closed Office formats. A closer look reveals some interesting details.

First of all, this has not been yet approved as an official OASIS standard – merely as an “OASIS committee draft”. This means that this standard is approved by this committee but is yet to be approved by OASIS as whole (similar to IETF’s WG vs. IESG approval). Nevertheless this is a big step in the standardization process but should not be construed as “final approval”. (As an interesting sidepoint, Microsoft is a member of OASIS with a director on the OASIS Board who serves as secretary of the board. At the same time, the appeals process for OASIS goes to the Board.)

UPDATE: Formal OASIS approval was announced

Additionally, it is interesting to note who OASIS is. It is a standards body which originally concetrated on development of SGML and eventually started focusing on XML-related standards, mainly in the business area. In the Internet standards world, the W3C has been focusing on basic XML standards such as XML itself, XSLT, RDF, etc. while OASIS has been working on “value added” XML standards, especially industry or task specific XML dialects such as the OpenDocument format. Given their existing relationship with ISO, approval by OASIS creates a pathway towards approval by the ISO itself. Of course, ISO approval is important for governments who are one of the main areas being focused by OpenOffice and other open source folks pushing this.

It is also interesting to see who the working group members are. Tom Magliery used to work on the original NCSA Mosaic browser and is also one of the original members of the XML working group at the W3C. Nathaniel Borenstein is the creator of MIME and is a well known IETF member. David Faure is one of KDE contributors. There are also some IBM and Sun folks as well as some individuals. Given IBM’s interest in OpenOffice and Sun’s involvement in StarOffice, their membership is not suprising. There is also Patrick Durusau of the Society of Biblical Literature (not for much longer) (I would venture to guess that given that the Bible is the most widely printed book in the world, it would make sense that a Bible society would be interested in open document standards).

Now about the format itself: OpenDocument is an XML-based format for word processing, spreadsheets and presentation documents. It grew out of the OpenOffice 1.0 format (which itself is based on Sun’s StarOffice). Unlike Microsoft Office, WordPerfect and a slew of other propertietary formats, this format is completely open and royalty-free (well, almost – Sun’s has an IPR disclosure requiring reciprocal licensing). What this means is that everyone is free to create, share and edit this format in any program that supports it. However, what is more important is that anyone can write software to support this format. Since this specification is wide-open and freely available, open source, closed source and mixed-source software is free to work with this format.

What is also exciting is that OpenOffice 2.0 and KWord 1.4 (part of KOffice, the KDE office Suite) will support this format by default. At the same time given that governments are pushing open document standards, this couldn’t be a better time for this. Assuming that OASIS approves this standard and the ISO follows, Microsoft and other closed-format vendors will be at somewhat of a disadvantage regarding this.

One possibility as to what may happen is that proprietary vendors may start supporting open formats just like they are forced to support open standards (most of the time). That means that closed-source and open-source vendors can finally compete on a more level playing fields: based on functionality and technical merits as opposed to being locked in by a specific proprietary format or standards, or as in open source solely on price. Of course the fear is that just like every other standards, vendors may start making custom extensions to the formats/standards, this locking people in. It remains to be seen what actually will take place.

We were experiencing problems with the main RSS feed. Everything should be fixed now but if you are still having problems, please drop me an email.

Last April a company called Forgent Networks initiated 31 lawsuits against various companies using the JPEG format based on an old US Patent # 4,698,672 which Forgent acquired by buying up some other company. The patent was known as early as 2002 when they put up a press release on their website. The format itself is an international standard called ” ISO/IEC IS 10918-1″ or “ITU-T Recommendation T.81″. Another interesting twist is that the patent was issued on October 6th, 1987 which means that it expires 18 years later – on October 6th, 2005. Given such short timeframe and the tendency for patent lawsuits to drag out forever, what gain what Forgent have from this?

The latest twist in this drama is a series of lawsuits between Forgent and Microsoft. It seems that after discussions with Forgent didn’t work out, Microsoft sued to have the patents declared invalid. As shown previously with the famous Eolas patent, Microsoft might have been sucessfuly with convincing the W3C to support it and this will probably be no different. Given that the ISO, the ITU and the JPEG comitee are not exactly approving of this patent, there will probably be a range of letters from these bodies to the USPTO once the lawsuit proceeds.

A connected question comes to mind is to why does Microsoft bother suing Forgent? Why not drag out the discussions even further and then wait for the patent to expire? The answer is that patent holders can sue for past damages even once the patent has expired. That means that Forgent can sue every single software and hardware maker that used JPEG in the last 15 years and make it off with a load of cash. This is exactly why Microsoft wants to pre-empt this instead of paying damages for the use of JPEG in Windows and IE (of course they can always settle and then sic Forgent on the open source folks).

Of course all of these combined with the GIF patent controversy just shows more reasons why a patent-free format like PNG is preferable as a standard. This also highlights the increasing problem with the current IPR system which can let a patent holder sue someone almost two decades after the patent is issued AND widely used worldwide.

Quite a few news outlets are carrying the story of Microsoft inventing a new technology called “Metro” intended to replace Adobe’s PDF format. According to Microsoft Watch ” Metro is a “new fixed document format built on top of XML”, is also referred to as a “Page Description Language (PDL)” and is even characterized “a new native (print) spool filter for Longhorn.” There is also talk about support in hardware as the article quotes a Microsoft representative stating that “printers with Metro “interpreters” and/or those which are Metro-enabled will be able to best print Metro-based documents and photos”.

According to Wikipedia, Page Description Languages include Adobe’s PDF and Postscript, HP’s PCL and an existing XML-based standard called XSL-FO made by the W3C. Given the wide variety of existing languages, at least two of which (Postscript and PCL) support printers, why is there a need for a new one? There is also glaringly very little effort to standardize this in a proper fashion or to even consult the W3C on this. Given that XSL-FO already exists, albeit not entirely suitable for this task, why not make a new open standard?

Additionally there are questions about the licensing policy for this “new standards”. According to all the news articles, Microsoft has promised to make “Metro” available royalty-free”. However, as the MARID debacle has shown royalty-free many times doesn’t mean that everyone can use it. And in this case there is plenty of what to worry about – let’s compare the existing Adobe PDF license to what Microsoft is planning for “Metro”. The Adobe PDF license states as follows:

Authors of software that accepts input in the form of the Portable Document Format must make reasonable efforts to ensure that the software they create respects the access permissions and permissions controls listed in Table 3.20 of the PDF Reference, to the extent that they are used in any particular document. These access permissions express the rights that the document’s author has granted to users of the document. It is the responsibility of Portable Document Format consuming software to respect the author’s intent.

Anyone who uses the copyrighted list of data structures and operators, as stated above, must include an appropriate copyright notice.

Basically speaking there are only two requirements: respect Adobe’s DRM and stick in a copyright notice. However, if we look at the the Microsoft FAQ on “Metro”, we find the following statement:

The Metro licensing program has not yet been finalized. The general Metro license is likely to be similar to that of the Office XML licenses which comprise a copyright license and a patent license.

The problem with the current Office XML schemas is mentioned here:

You are not licensed to sublicense or transfer your rights.

Of course not having the ability to sublicense, effectively kills any use of this license in conjunction with the GPL which requires it, a situation very similar to what happened to MARID. What is even more interesting is that while Microsoft is promising to bend on the Office XML schema license, they did not do so with MARID and there is now way to tell if they will with “Metro”.

Now we come to the interesting question as to why this was done. The first reason obviously is that just like with XAML and other parts of Longhorn, Microsoft is moving in the direction of using XML for many subsystems in Windows. Since the print path in Windows is probably pretty old in design, it was due for an overhaul anyway. However, if we take to heart what Joel Spolsky has written, it makes a lot of sense:

…suddenly, Microsoft’s API doesn’t matter so much. Web applications don’t require Windows.

It’s not that Microsoft didn’t notice this was happening. Of course they did, and when the implications became clear, they slammed on the brakes. Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There’s no way Microsoft is going to allow DHTML to get any better than it already is: it’s just too dangerous to their core business, the rich client. The big meme at Microsoft these days is: “Microsoft is betting the company on the rich client.” You’ll see that somewhere in every slide presentation about Longhorn. Joe Beda, from the Avalon team, says that “Avalon, and Longhorn in general, is Microsoft’s stake in the ground, saying that we believe power on your desktop, locally sitting there doing cool stuff, is here to stay. We’re investing on the desktop, we think it’s a good place to be, and we hope we’re going to start a wave of excitement…”

The trouble is: it’s too late.

Inventing new web-based or web-related standards and keeping them under some form of control, while not letting their biggest competitor (namely open source) to use them is the perfect tactic to combat this. I personally think that “Metro” is just one latest example of this, since a standard by definition is used by many people. One can just imagine how an XML web based standard for printing and sharing documents coupled with the very large desktop market share of Microsoft can kill both PDF and IPP at once. Instead of open and semi-open standards, we might end up locked into the Longhorn infrastructure, albeit Web-based.

Of course one shouldn’t ignore the large installed base of PDF at this point. However, at one point Netscape ruled the web and things nevertheless went downhill very quickly for them. If I were Adobe at this point, I would run with PDF and Postscript, and make them both official standards AND start supporting the open source communities. After all, this was the gambit that AOL took with Mozilla and the result is FireFox which is slowly nipping at the heels of Internet Explorer. I can easily see Adobe’s fully open, standardized PDF/XML hybrid winning with the help of governments and the open source communities. But then again, Sun has missed this chance with Java once, and “those who ignore mistakes of history tend to repeat them”.

Welcome to “The Internet Standards Blog” – the newest discussion place for everything revolving around Internet standards. After searching far and wide for a site that would keep me upto date on standards activities and current news, I decided to create one myself. We are still working on setting things up so occasionally you may see some broken things. But please bear with us while we finish up.

To contact us, send email to standardsblog /at/ shaftek [.] org. All ideas, tips, comments, rants and flames are welcome.

UPDATE: All entries from this blog have been merged into my main blog here.