Don makes a distinction between a service that is service-oriented and one that is not. I am not sure I agree with the distinction, though. This is akin to justifying 500 lines of code in Button1_Click events versus proper application design: jsut because you can, doesn’t mean you should, even in smaller scale scenarios.
If you version a service interface by adding parameters, then you affect the ability for legacy systems to version along with the system. Instead of focusing on the message contract, they are now split between the message contract and an independently versioned API.
The key point is that the focus is on the message contract. The schema itself is the asset to the enterprise, not the individual realization of the schema in a single service endpoint. The goal for services is to create them so that the service interface has a longer lifespan than its implementation. The schema can (and should) be reused among multiple service endpoints, and new message types should be formed that composite existing schema types together. By encapsulaing version information within the message schema, you enable this type of composition within a single message contract.
Consider also that many current implementations of SOA are not API-based, but rather focused on the transport. Many messages are not transported with a full SOAP envelope, but rather the XML payload that is later wrapped with a SOAP envelope. Versioning the proxy and server to accomodate multiple messages within a single queue message puts more burden on a greater number of systems as the number of touchpoints across the enterprise increases.