Tom,
I think most of what you write is allowed by, or required by, the current
spec. (As you probably knew.)
Phelan, Tom wrote:
REQ: A DCCP implementation MUST require the using application to
explicitly set the service code associated with a socket before it can
be used in a listen or connect request. The service code for a socket
MUST NOT default to 0. It could default to SC=xFFFF, which is not a
valid value for SC and will be rejected if ever used.
You mean SC=xFFFFFFFF.
The current RFC doesn't require the "MUST NOT" here.
I believe the Linux implementers went this way for a while, using SC=xFFFFFFFF
exactly as you describe. It was found frustrating for DCCP users and was
removed. I wouldn't recommend it. A default SC of 0 is OK.
REQ: A DCCP application in development SHOULD NOT use SC=0. It SHOULD
choose a code from the private use space (first ASCII character equal to
'?').
Obviously allowed by the spec.
REQ: A DCCP implementation MUST reject a DCCP-Request with SC=0 if no
socket is listening on that port with SC=0 (SC=0 MUST NOT be interpreted
as a wildcard).
This simply restates the spec. Wildcards are not allowed by the spec. (I
think you know this, just stating it out loud.)
REQ: A DCCP implementation MUST allow multiple sockets with different
service codes to listen on the same port.
This strengthens the MAY in the RFC to a MUST, and seems fine, but...
I realize that none of the existing implementations work this way, but I
think that's asking for long-term problems.
I don't know about long-term problems with the status quo. I think when port
scarcity becomes an issue in practice, Service Codes will be there to solve
the issue; and at that point "multiple SCs per port" will quickly become
widely deployed.
Eddie
