As you can see from the comments I left there and I am re-producing it here:

One of the things I noticed is that the .svc extension is strange if you look at it from a endpoint angle. Having

http://abc.com/def.svc/mex
http://abc.com/def.svc/ep1
http://abc.com/def.svc/ep2

is rather unnatural. I had a couple of attendees who actually thought it was a typo in the HOL (the HOLs are full of typos, btw) and changed it to

http://abc.com/ep1/def.svc
http://abc.com/ep2/def.svc

Of course that didnt work as well. They had a hard time grappling with the unnatural look and feel of it.

I would think that receiving client applications would do a double-take on this as well once they look at the actual endpoint address

Getting rid of the physical file extensions would be a great and welcomed idea! Afterall, it is good convergence with the servlets of J2, Remoting and httpHandlers of .NET, Content Management Servers and others as well.

If I am not wrong, isnt that how REST Web Service works as well ? Something like http://abc.com/ep1 or http://abc.com/getSomething. It is a verb thingy. There is really no physical file on the other end.

To me, its simpler as well as now if I have to change any type information, it will be in the .config file only and nothing more. God forbid customers to deploy multiple physical files as well ... and to some of us who are used to doing inline scripting in these asmx or svc files (for debugging and testing purposes, not for production use), .NET 2.0 already gives us dynamic compilation in App_Code

To me, the solution is clear: Dump the svc file extensions

If you have other ideas, opinions or just want to echo my same thoughts, do feel free to drop by Steve's post and let him know !