Microsoft publishes dozens of its network protocol specifications on MSDN

Microsoft made a big announcement today about having a new policy of promoting interoperability with its major products, citing modern needs, etc. If you ask me, the need for interoperability today is not much greater than it was a few years ago and this policy shift is way overdue. Along with the announcement which made for an amusing assortment of corporate-speak, Microsoft made the operative move of immediately publishing dozens of network protocol specifications on the MSDN Library. Their index can be found here. Apparently, documentation for things other than protocols (i.e., APIs) is forthcoming.

Having spent a few minutes going over some of these specifications, I have several observations to make:

  • Many of these specifications have been updated multiple times during the past year or so. Unlike Microsoft’s forgotten Internet Draft for the DCOM protocol from the late 1990s, finally we see up-to-date specifications for a change. I hope with the wide availability at a high-profile location like the MSDN Library, these contemporary specs will keep getting the love they need and could be relied upon to reflect the current Microsoft implementations.
  • Nearly every network service included with Microsoft Windows appears to be documented.
  • The detailed specifications are a gold mine to anyone seeking an under-the-hood glimpse of the internals of Microsoft’s network services. I was particularly thrilled, as can be expected, to encounter up to date descriptions of the extensions Microsoft made to the DCE RPC protocol, the DCOM network protocol and even how COM+ (MSDTC) implements network transactions over the prior.
  • The specifications are coherent in the sense that each makes appropriate references to related protocols. e.g., the COM+ specification references the DCOM specification, which references the RPC extensions specification. Even third-party references are made, e.g. to the “Open” Group’s DCE RPC 1.1 specification. (Open in quotes since, ironically, while I could readily download a protocol specification PDF from Microsoft’s MSDN with no intrusion, the so-called “Open” Group required compulsory registration for the free download, which seems to have nothing in for me except the prospect of future spam…)
  • I did not tolerate enough of the corporate speak in the press release to understand the legal status of the document release, but I hope it such that will allow popular open source diagnostic tools such as Wireshark to provide detailed, complete and accurate diagnostic information about these protocols.
  • The specifications tend to read more “official” than “practical.” In other words, they are more like an ISO standard than an IETF RFC. There’s hardly introductory text describing the protocols in context but rather really long glossaries you have to skim over to “get to the good stuff.” While raw technical descriptions are important, one has to question Microsoft’s true commitment to the promotion of interoperability given this state of affairs. Perhaps with their now altered target audience, we shall see improvements in this department in the not so distant future?
  • Some network protocols (Exchange, SQL Server) are not yet available, but are scheduled to be released sooner rather than later. In particular, I consider the publishing of the Exchange protocols as crucial to the promotion of interoperability in the groupware realm.

So what’s your favorite Microsoft network protocol? :-)

Advertisements

10 thoughts on “Microsoft publishes dozens of its network protocol specifications on MSDN

  1. Microsoft is also promising to release documentation of the Microsoft Office file formats in the near future. Strangely enough it’s listed as a “protocol” in the list of what’s to come.
    Until now the only way to interoperate with Microsoft Office formats was through some confusing COM interfaces for application automation.
    With the new Office file format being all modernish fancy-schmancy XML, documentation is rarely needed as the format is easy to understand or reverse engineer.
    However, since most of the Office documents out there are still in the old file-system-approach, parse-quickly-on-a-286-machine, resistant-to-bad-sectors-on-a-floppy-disk format, groups such as the Open Office project and the likes will surely take the opportunity to improve their rendering engines for the aging format.

    Linux lovers, rejoice!

  2. LOL @ “Windows Compound Binary File Format Specification”.
    Remember “Binder”, that useless application that would package several files into one big mess and stopped shipping with Microsoft Office a decade ago? IIRC it was based around the ability to keep several streams under a single file, like a tarball but with more overhead and less compatibility.
    I guess now I can write my own Binder clone. But I’d rather eat a bug.

    I wonder when they’re going to release the source code for Microsoft Bob(tm).

  3. Several years ago as part of a legal settlement with the DOJ, Microsoft published a disclosure of some heretofore undocumented APIs in winternl.h. The published APIs were incomplete with little or no usage docs, but it satisfied the plaintiff’s demands.

    Recently EU took legal action regarding opacity of Windows Server protocols allegedly being leveraged to sell Windows desktop OSes.

    I wonder if this most recent disclosure is a response (in part) to that litigation. From what I know of certain undocumented protocols the disclosure appears to be incomplete in certain areas. And it looks very lawyer-ish, something that would be published to satisfy a legal settlement rather than to actually be useful.

    -Alan Klietz

  4. For example, the recently disclosed specification titled Microsoft NT Backup File Structure Specification (MS-BKUP) allegedly describes the Windows NTBACKUP file format (.bkf) . The disclosure shows some of the stream formats but it omits the stream IDs. And it omits any description of the DBLK headers. This makes it pretty much useless.

  5. Alan, I am disappointed but not surprised by your finding regarding the incompleteness of Microsoft’s newly released specifications. It appears Microsoft’s new “interoperability” face still leaves much to be desired.
    The true test of their intentions is whether they will promptly document things like those NTBACKUP stream IDs when called on to do so.

    I agree about the lawyer-ish vibe in those specs… they don’t read “like RFCs” and don’t seem like anyone really intended an actual dev to sit down with these and be able to sanely implement the protocol at hand.

  6. Pingback: How Open is Open? or Did I Speak to Soon? « Chilmark Research

  7. Pingback: How Open is Open? or Did I Speak to Soon? | Chilmark Research

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s