RE: [dccp] Re: wildcard service code?

[john.loughney at nokia.com]

Mark,

>On the subject of service codes, and not wildcarding them....
>
>Service codes are clearly not meant to be "secure" - an 
>application can always lie.
>
>Service codes are intended to help with a number of problems 
>with well known ports, as used in TCP.  The most obvious 
>problem is simply that the well-known port space is far too 
>small, so there's back-pressure not to register random 
>services.  With a 32-bit service code space, you can use a 
>*very* lightweight registration mechanism, without fear of 
>exhaustion.  So hopefully this will encourage any application 
>that isn't actively trying to hide to declare itself properly.

Just out of curiosity, is the Service Code somewhat analagous to
the payload protocol-id in SCTP: 

[RFC 2960]
   o  payload protocol-id - A 32 bit unsigned integer that is to be
      passed to the peer indicating the type of payload protocol data
      being transmitted.  This value is passed as opaque data by SCTP.

I believe there were similar goals back when we were developing
SCTP.  I was talking with Randy Stewart in Vancouver over lunch
and he mentioned that he is seeing some work (I forget where)
in using SCTP's PPI for other things than just protocol data,
re-using it to signal some additional stuff.  I can imagine folks
doing similar things with the service codes in DCCP - I don't actually
think that is a bug, but I expect that Service Codes will be used 
for some other purposes, especially for folks wanting to conserve
header bits.

John