These are some quick thoughts behind the design of the MUX protocol naming and negotiation.
Traditionally protocols are considered to be "biggies" like FTP and HTTP. However, as more and more applets and mobile agents start to come into play along with message signing and other initiatives, the granularity of protocols have become much smaller.
In the case of HTTP, the PEP proposal considers a single new header as an extension. PEP is a mechanism for introducing extensions into HTTP. The extensions are defined with a scope, a strength, and the order by which they are applied. PEP is designed to work with HTTP messages but extensions may very well carry state in which case they work across multiple HTTP messages and hence constitute a "virtual session" within HTTP. It is up to the individual PEP extension when and how a session is terminated, the important thing to note is that an extension does not have to follow the same message semantics as the protocol it extends.
Therefore, by providing a uniform naming scheme across protocol stacks it becomes much easier to describe extensions to existing protocols independently of the individual protocol semantics. For example, a virtual HTTP session may as well be expressed as a MUX session with its own session ID. This also allows generic protocols, for example a compression or digital signature protocol, to be used across multiple protocols that do not have native support for this features.
The consequence of having a fine protocol granularity in MUX is that sessions will tend to be very short lived or there will be a very large set of sessions each running small variations of very similar protocol stacks. Examples are HTTP using compression, including PICS headers or a payment scheme protocol. In the case of HTTP, for example, the life time of a "extension session" may in some cases be as small as a single message.
With the points above in mind we can try and draw a picture of how various naming schemes perform. Below, I have tried to enumerate the pros and cons of three naming schemes that come to mind: hash functions, enumerations, and tokens.
| Method | Pros and Cons |
|---|---|
| 32 bit hash functions |
+ Allows protocol stacks + No registry is required + Fixed length names - Risk of hash collisions - Closed set of possible combinations - No fallback strategy and version compatibility is difficult - Only full protocol enumeration is possible |
|
IANA Protocol Enumerations |
- Protocol stacks can not be expressed - A protocol registry is required + Fixed length names - Closed set of possible combinations + Simple case is simple - Only full protocol enumeration is possible |
|
Hierarchical tokens in combination with URLs |
+ Allows protocol stacks ~ A protocol registry needed for simple cases. More complicated cased can be solved using URLs - Variable length + Open ended set of possible combinations and full extensibility + Simple case is simple + Partial protocol enumeration is possible |
Based on the pros and cons, I think that a hierarchical naming scheme turns out to be the best with respect to extensibility and support for enumeration - two of the main concerns for handling a potential large set of protocol handled by MUX.
Protocol initiation implies that the initiator of a new session using either a new protocol stack or an already named protocol stack. In the examples below we use ASCII notation. This doesn't have to be the case as we may use length indicators instead. If we stay in the BNF world then the syntax is
protocol-stack = ID 1#( protocol | URL ) ID = 1*DIGIT protocol = token "/" 1*DIGIT "." 1*DIGIT URL = as defined by RFC 1738 and RFC 1808
The first element is an identification token or short-name by which the initiator will call this stack until it is redefined or the MUX connection is closed. IDs follows the same semantics as the MUX session IDs in that the receiver uses odd and the sender uses even numbers. The following tokens and URLs describe the protocol stack including the protocol versions. Some examples of protocol initiations are
1 TCP/1.0 SSL/3.0 HTTP/1.1 7 TCP/1.0 GZIP/1.0 HTTP/1.1 13 TCP/1.0 HTTP/1.1 25 13 HenriksSignatureWrappingProtocol/1.0 61 13 http://www.money.com/payment
Note that short-names can be used in defining other protocol stacks. Other combinations are possible, for example
15 13 GZIP/1.0
which is equivalent to a "Accept-Encoding: gzip" header in a
HTTP/1.1 request message. It may very well be that default short-names
become so popular that they can be used directly instead of defined each
time through protocol tokens.
Protocol enumerations are required in order to be able to handle situations where a protocol stack is not understood by the recipient and for debugging purposes. The first is targeted automated processing whereas the latter is targeted human interaction. As the set of protocols become potentially very large, the task of enumerating the complete set can be very costly. In this case it is a great advantage to have a hierarchical name space compared to a flat hash function name space. The reason is that the recipient only has to provide alternatives from the point where it doesn't understand the protocol token.
The sender starts a new session using the following protocol stack description:
1 TCP/1.0 SSL/3.0 HTTP/1.1
The receiver does not understand HTTP/1.1 and sends back the alternatives that it can handle
2 TCP/1.0 SSL/3.0 4 2 HTTP/1.0 6 2 FTP/1.0
The sender can then look at the protocol stacks enumerated and select one or refuse to continue. It is important to know that the sender does not need to know apriori whether the receiver understands a protocol stack or not. It may include data in the MUX packet and hope that the protocol is understood by the other end. If the receiver sends back a "protocol stack not supported" and a set of alternatives, the sender must then consider if it wants to use any of these and resend the data using the new protocol.