The Register® — Biting the hand that feeds IT

Comments on: Microsoft to EC: define 'unreasonable'

"We had to look up 'reasonable' on Wikipedia, but we're always willing to haggle." 

Posted Tuesday 24th April 2007 07:20 GMT

Preferably for months and years, until the whole issue becomes moot. Anything to keep FOSS from becoming fully compatible with Windows directory services, because they know that would spell the end for their shitty software.

Microsoft already defined 'reasonable' 

Posted Tuesday 24th April 2007 07:37 GMT

Reasonable is free of cost with no precontract requirement. Just like the documentation for all their other APIs:

http://msdn.microsoft.com

They *Microsoft* defined what is reasonable when they decided how they would document and distribute the document for all the other APIs. To do anything different for these particular API Microsoft has to show how come these APIs related to its anti-competitive behaviour should be treated differently.

Reasoning on reasonable 

Posted Tuesday 24th April 2007 12:58 GMT

Reasonable costs, surely, means "no more than what it NEEDS to cost".

For a paper document, that means the cost of the paper, the cost of the toner, the exact amount paid to the post office and perhaps even the cost of 30 seconds of time by a person paid the national minimum labour rate for putting it in the envelope. Nothing more, and most definitely no element of profit for microsoft or third party fulfillers.

But the sensible answer is not to supply the document on paper, but to put it on the web and let those who want it download it themselves. The cost, then, is a most definite ZERO. The demand isn't going to stretch microsoft's existing server capacity, so no reason to make a charge at all.

But it begs the question, why didn't the EU have the sense to say "you must make the information available in the form of a free PDF download" instead of mentioning the unnecessary loophole of a reasonable (or unreasonable) charge.

Protocols not APIs 

Posted Tuesday 24th April 2007 12:59 GMT

MSDN just provides you with their APIs, even these are incomplete in some areas.

This is about protocols and what messages are sent to achieve various tasks like authentication, printing, file sharing etc...

An API just tells you how to write software to use the functionality that uses the protocols.

Take MSN Messenger as an example, the protocol for this has had to be reverse engineered. You think that is on MSDN?

Protocol = API 

Posted Tuesday 24th April 2007 15:06 GMT

"This is about protocols and what messages are sent to achieve various tasks like authentication, printing, file sharing etc..."

Changing the name doesn't change the substance, and they certainly do document 'protocols':

http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/pluggable/pluggable.asp

They set the price at zero, no precontract. They defined reasonable, they should live with their decision.

protocol != api 

Posted Wednesday 25th April 2007 08:34 GMT

Have a look at the MSINet component API for use in VC++, VB etc... especially the FTP parts.

Then look up RFC 959 (FTP Protocol).

An API (Application Programming Interface) allows you to hide the nuts and bolts of a process from the programmer through a defined entry point. A protocol *is* the nuts and bolts hidden behind that API.

Just because you have access to the API, does not mean that you know what is really happening behind the scenes, and what is more, there are times when that API is not (or badly) explained, or (as in the case of the good old Wininet api) only a very basic rendering of the underlying protocol is effectivly encapsulated.

Ok, wininet is just an api wrapper for basic HTTP and FTP programming, and these are open protocols defined by open, community developed internet drafts and RFC's, but how about all the rest? Windows shares with SMB? Windows login authentication? MSN Messenger? Nope, you just get an api which (watered down explanation follows) allows you to enter a machine name and a password and returns true or false. From an API viewpoint, it's perfect, but from a protocol point of view, how does a Mac/linux/favorite non-MS connected hardware do the same thing? How is data sent? encrypted, plaintext, BCD? That is all defined in the protocol. No protocol? Then you have to break out Ethereal and reverse engineer it. Oh, sorry, you are in the US, and the DCMA seems to forbid that... and even if it does not, can you personally stand up to a large corporation's legal department?

Cheers,

Daniel

Don’t Miss

NovellNovell grooms NetWare-Linux lovechild

Real-server tools meet fake-server tools

Tape cartridges 75x75What's wrong with tape backup?

Three papers about storage

DellDell opens up on NAS gateways

File access to EqualLogic block arrays

MicronMicron becomes Fusion follower

UPDATE Maybe even Fusion over-taker