Niels Möller wrote:
Henrick Hellström <henrick%streamsec.se@localhost> writes:Niels Möller wrote:I think, quite strongly, that such substructure should be out of scope for the core drafts.Fair enough, but I suggest that there at least should be stipulated in the specification that locally assigned disconnect codes MUST NOT be sent by standard protocol features.Right, locally defined numbers should not appear on the wire unless you have somehow agreed with the receiver what they should mean. One example where that can be used safely on the wire, is if you receive a CHANNEL_OPEN request for some locally defined channel type "foo-channel%lysator.liu.se@localhost", then you can safely reply with a CHANNEL_OPEN_FAILURE and any locally defined reason code associated with the specification for that channel type.
This example implies that in the channel_open / channel_open_failure
case we may want three ranges:
0x0000 0000 - 0xFDFF FFFF IETF / connection layer
0xFE00 0000 - 0xFEFF FFFF channel-type specific, numbers from
this range for channel-types with @domain in their names are
defined by the maintainer of the @domain. For channel-types
without an @domain are defined by IETF action, and these
numbers are allocated by IANA. This registery is currently
empty for all IETF defined channel-types.
0xFF00 0000 - 0xFFFF FFFF private range, used any way
implemention wants, may not interoperate with other non-standard
implementations, but will never conflict with a standard
implementation.
The disconnect messages don't have this third range because
they aren't scoped by an extensible name.
- Joseph
PS. For simplicity, I still like just using a bit mask:
The high order two bits scope the reason code; the
following scopes are defined:
00 - IETF / connection layer reason codes
01 - Reserved for future use
10 - Channel-type specific
11 - Private range
Again, when we are talking about a billion reason codes,
I don't think we need to worry about any scope running
out!
But I'm not going to argue to hard for this.