were intending to contact. Think of a NAT, for example; a NAT that changed payload could work for connections using nonstandard ports, if it knew which app was running on which port.
I think the service code is a very good idea for the NAT case. However, since
some service codes mangle the payload, when I write my new application, I will
have to choose a random service code which doesn't, for my application to work.
But if most connections on the Internet have the default Service Code, we will never know how much Service Codes could have helped. This is why I'm pushing back.
Similary you will never know if they didn't help as you are forcing people to
use them =D
Perhaps the NULL service code will emerge naturally since not all applications writers want to interact with the Service Code allocation authority.
The possibility has crossed my mind.
Again, there's always Service Code 0, which "represents the absence of a meaningful Service Code". This should be the default, if you desperately want a default. A Linux- or DCCP-specific default Service Code would be strictly worse than 0.
Shouldn't this be made explicit? This way an application writer knows that by
using service code 0, no one will modify / drop the payload [unless explicitly
configured].
Seems clear already...?
In practice, everyone will probably start using the WWW SC since it will be the
only one which doesn't get dropped blindly or gets mangled [perhaps a
transparent proxy on the way might do strange stuff].
This seems unlikely. Everyone using 0 is more likely.
Eddie