Jeffrey Hutzelman wrote:
On Friday, September 24, 2004 10:25:01 -0600 Joseph Galbraith <galb-list%vandyke.com@localhost> wrote: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, numbersfrom 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 numbersare 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.Good, except we shouldn't set an allocation policy for the channel-type-specific range. It is up to the channel type to define the meaning of these values and to establish a registry if one is appropriate (I expect it will frequently not be needed, just as wedon't establish separate registries for the method-specific message type ranges).
Right, but at a minimum the RFC should state that channel-type specific numbers or private numbers MUST NOT be sent unless a channel with @domain in its name has been requested.The same restriction should be applied to disconnect reason codes: They MUST NOT be sent unless the peers have previously negotiated a domain specific protocol feature (such as keyagreement@domain or service@domain).
Any numeric code in a private range SHOULD be administrated by the entity that owns the @domain of the previously negotiated protocol feature. The specification of the domain specific feature MIGHT add further restrictions and implementations SHOULD respect these restrictions to avoid interoperability problems.
Also note that the phrase...
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.
...is illogical. If the standard states that an implementation MIGHT use numbers in the private range, and the implementation does use numbers in the private range, then the implementation *is* standard compliant. (I hope this point is made clear by the paragraphs I wrote above.)