See the MCP web site for information about the MCP 2.1 specification on which this is based. Terms and concepts not defined here will most likely be available there.

mcp-negotiate 2.1 MCP 2.2

Last Edit: 6 September 2001

About This Draft
Introduction
Specification of mcp-negotiate 2.1 MCP 2.2
Implementation Checklist for Upgrading From 2.0MCP 2.1
Other Comments
Example Startup

1. Introduction

This document describes version 2.1 of the mcp-negotiate package; 2.2 of MCP; the prior versions, 2.0 and 1.0, are 2.1, is described in the original MCP 2.1 specification document. This protocol release is primarily intended for clarification and fixing of mis-specifications in the prior versions, though we have taken advantage of the opportunity to introduce a couple of new facilities that these fixes enable. Issues clarified, changed, or specified for the first time concern

(newly specified) The temporal placement of the mcp-negotiate-can message(s) for the mcp-negotiate package itself.
(newly specified) The handling of multiple mcp-negotiate-can messages for the same package.
(clarified) The point at which version negotiation is deemed to be complete, after which package messages may be recognized and processed.
(changed) The timing of the sending of messages in a package with respect to the mcp-negotiate-can message(s) for that package, and the handling of messages for unsupported packages during version negotiation.

The following notable new features are enabled by these changes:

The ability for an implementation to specify support for an arbitrary set of versions, i.e., to not be required to support all versions ever released between its earliest supported version and its latest supported version.
The ability to speculatively send package messages in certain cases where version negotiation is not complete.

Since certain semantic changes have necessarily been introduced, compliance will not be automatic.

Terminology

Unadorned version numbers will be referring to versions of mcp-negotiate. In general, one should be careful about confusing MCP version numbers with mcp-negotiate version numbers, even though they happen to coincide with this release.

The original specification refers to a client and a server, a distinction that has no significance here. When describing the characteristics/role of an implementation, we prefer to use the term local to reference to the connection endpoint being implemented and peer to refer to the other end of the connection to/from which said endpoint is sending/receiving.

Specification of `mcp-negotiate` 2.1 MCP 2.2

Version 2.1 of mcp-negotiate is version 2.0 Version 2.2 of MCP is version 2.1 as modified by 7 specific rules, described below. Matters unspecified here are as per the 2.0 specification in the original MCP 2.1 document. The paragraphs following each of the numbered lists are intended as rationale/explanation; they should not be interpreted as introducing additional rules themselves.

General Version Negotiation Rules

Version negotiation is deemed to be complete at a given connection endpoint upon receipt from the peer of any mcp-negotiate-can message specifying a range that includes any locally supported version. The maximal such version in that range is to be chosen as the negotiated package version for this session. Further mcp-negotiate-can messages pertaining to this package must be ignored.
All locally supported versions must be advertised by sending mcp-negotiate-can messages. If multiple mcp-negotiate-can messages are sent for a given package, the order must be such that the max-version values form a non-increasing sequence.

Prior to 2.12.2, an mcp-negotiate-can message merely advertised support for all versions within the specified range. Under 2.12.2, the same message also explicitly denies support for all later versions that are not themselves within the version ranges of previously received mcp-negotiate-can messages for that package. Note that no statement should be inferred about support for earlier versions.

This interpretation is entirely equivalent to the previous (2.0MCP 2.1) interpretation in the case where only one mcp-negotiate-can is ever sent for a given package; for this case, the above rule simply restate how these messages were handled in 2.0MCP 2.1. Moreover, since 2.0MCP 2.1 leaves the correct handling of multiple mcp-negotiate-can messages completely unspecified, resolving them via the 2.12.2 rules is still a valid implementation for 2.0 or 1.0MCP 2.1 or 1.0 support.

For the sake of clarity, it is recommended that distinct mcp-negotiate-can messages sent for the same package advertise completely disjoint version ranges.

Note that completion of version negotiation is an end-point-specific event. In general, such completions will happen at the local site and the peer at different times; There are no claims to be made about the relative ordering of local and peer events beyond those required by causality.

Special Version Negotiation Rules for the `mcp-negotiate` Package

For negotiating the version of the mcp-negotiate package itself, the following additional rules apply:

If, at a time where version negotiation for mcp-negotiate has not yet completed, either an mcp-negotiate-end or an mcp-negotiate-can for some package other than mcp-negotiate itself is received, version negotiation for mcp-negotiate itself is immediately deemed semi-complete. Semi-completeness establishes that the eventual negotiated version for mcp-negotiate will be either 2.0 or 1.0, according as a mcp-negotiate-can for mcp-negotiate itself is ever received or not, even if the previous rules might, by themselves, specify a later version.
mcp-negotiate-can messages for mcp-negotiate itself that refer to versions later than 2.0 must precede mcp-negotiate-can messages for all other packages.

The idea here is that receipt of mcp-negotiate-end or an mcp-negotiate-can for some package other than mcp-negotiate itself should be interpreted as an explicit denial by the peer of support for all versions of mcp-negotiate later than 2.0 that are not within the version ranges of previously received mcp-negotiate-can messages for mcp-negotiate.

Note that this partially supercedes the statement, "No ordering is necessary or imposed on the transmission of mcp-negotiate-can messages [which are] thought of as being transmitted in parallel..." in the original MCP 2.1 spec [see section 3.1]. Still, mcp-negotiate-can messages for the other non-(mcp-negotiate) packages can continue to be thought of as being sent in parallel; it is only the temporal orderings with respect to the messages for mcp-negotiate itself that are affected.

Modification of the Waiting Rule

For any package other from mcp-negotiate itself where multiple mcp-negotiate-can messages are to be sent an implementation may postpone sending the 2nd and later such messages until completion of version negotation for mcp-negotiate.
This provision is null and void if the negotiated version of MCP itself is one that explicitly requires support for mcp-negotiate 2.1 or later.

The rules thus far have been such that an implementation following them will be compliant with existing mcp-negotiate 2.0 and 1.0 rules. However, in the case where version negotiation for mcp-negotiate semi-completes or completes at version 2.0, an implementation cannot rely on a peer interpreting multiple mcp-negotiate-can messages in any particular way (let alone in the specific 2.1-specified manner), hence, sending multiple mcp-negotiate-can messages is not recommended in this situation. Rule 5 allows the sender to send the first such message, postponing the remaining ones advertising disjoint lower ranges until it is certain the peer will handle them correctly.

Admittedly, this explicitly violates 2.0's provision that mcp-negotiate messages all be sent immediately, however, this violation is not observable by the peer, or at least, is not distinguishable from an interruption in service by the underlying network layer which can happen at any time and therefore must be assumed to be manageable by the peer. Moreover, if the peer is a 2.0-only implementation that is compelled to send all mcp-negotiate messages immediately, no deadlock can result. Hence this violation is harmless.

We do, however, find this provision sufficiently distasteful that should it turn out to be unnecessary due to some future version of MCP itself requiring support for mcp-negotiate 2.1 or later (meaning that we will know upon completion of MCP negotiation itself that mutliple version ranges must be understood by the peer), we'll be quite happy to have this rule go away.

Rules for package startup and unknown messages

For packages other than mcp-negotiate, the following provisions hold once version negotiation for the mcp-negotiate package itself MCP is complete and the version is determined to be 2.12.2 or later.

An implementation may begin sending messages in a given package only after version negotiation for that package is complete.
Implementations must ignore messages in the package received prior to completion of version negotiation for that package.
An implementation may begin sending messages in a given package only after having sent the first mcp-negotiate-can message advertising the negotiated version. at any time.

The original specification for MCP 2.1 was intended to have a rule providing for sending (the) mcp-negotiate-can message prior to sending any package messages, but we goofed.

This can be viewed as a slight strengthening of the MCP 2.1 specification's provisions for error handling (section 2.3) in which it is enouraged that unknown messages be silently discarded, expanding the notion of "unknown" messages to include those belonging to supported but not yet version-negotiated packages.

"Ignore" is meant in the same sense as before, with the following clarification: Ignored messges should have no substantive effect on any facility or application not specifically intended for profiling or debugging MCP applications themselves. Unobtrusively reporting such messages to the user remains acceptable under the assumption that the user is interested in, say, debugging an MCP session or otherwise analyzing MCP message traffic for its own sake; it should not be done in the course of the normal functioning of an application that is not devoted to MCP debugging or analysis.

Rule 7 overrides a the previous rule about having to wait for the peer's mcp-negotiate-can before proceeding with package startup, hence allowing speculative package startup, which may be useful in situations of network connections with high latency.

Implementation Checklist for Upgrading From 2.0 MCP 2.1

Minimal 2.1 2.2 Compliance

If you have an existing implementation compliant with mcp-negotiate 2.0 MCP 2.1, the following changes or inspections should be sufficient to allow it to be advertised as supporting version 2.12.2:

Make sure you are sending your mcp-negotiate-can package: mcp-negotiate message immediately upon completion of MCP version negotiation and prior to any mcp-negotiate-can for any other package.
An mcp-negotiate-can message arriving for a package whose version has already been established must be ignored.
An mcp-negotiate-can message arriving for a package whose version is not yet established must not be ignored (i.e., even if some previous such negotiation attempt for that package has failed).
Make sure that all messages for any package whose version negotiation is not yet complete are indeed being dropped.
Make sure that at least one all mcp-negotiate-can messages for a given package has have been sent before sending any messages for that package.

Deferrable but recommended task

make sure that if your peer doesn't send his mcp-negotiate-can package: mcp-negotiate messages first, that you are not ever going to set the negotiated mcp-negotiate version higher than 2.0, thus disabling your own implementations of any post-2.0 facilities.

Clearly, if you never actually implement any post-2.0 facilities, the negotiated version number for mcp-negotiate will not have any significance, since nothing in 2.1 requires behavior that is observably illegal in previous versions. However even though you may have no particular use for particular facilities enabled by 2.1, e.g., speculative package startup or multiple version ranges, it is still recommended that your implementation eventually be able to track the mcp-negotiate version number itself (at least in the 2.0+ range; the distinction between 2.0 and 1.0 being likewise unobservable) for the sake of what later versions might introduce.

Optional tasks

These are only necessary if you wish your implementation to make use of specific new features.

Implement support for discontiguous version ranges in your own packages.
In order to support a package over a discontiguous set of ranges, you will need to
- be able to compare a range from an incoming mcp-negotiate-can with a set of your own ranges rather than just a single range as before,
- be sure you are sending the multiple mcp-negotiate-cans in the correct (max-version-descending) order,
- be checking that you are only sending the 2nd through nth multiple mcp-negotiate-can messages when the mcp-negotiate version indicates that it is safe to do so.
Implement speculative startup hooks for those packages that need them.

Other Comments

Note that this specification does not change the version negotiation algorithm for MCP itself, which must therefore still be supported over a single contiguous range of versions.

Specifying multiple disjoint version ranges for mcp-negotiate itself is problematical, the main issue being that it is not entirely certain a priori how a 2.0-max-version peer will respond to the second mcp-negotiate-can. Figure that since a range above 2.0 is being excluded, the first message from the local side cannot mention version 2.0, and therefore version negotiation will initially fail at the peer. Behavior at this point is not completely specified, though one might suppose that since a prerequisite to supporting MCP 2.1 is support for some version of mcp-negotiate, there is nothing that prevents the peer from charging on ahead anyway. If so, then everything else should work since the actual version number is mostly irrelevent to pre-2.1 implementations. However, it is also not illegitimage for the peer to immediately shut down the MCP session completely ...

Example Version Negotiation

A complete startup, between a client supporting the edit, mcp-cord, and spam packages, and a server supporting the edit and mcp-cord packages:
(--> : messages to peer, <-- : messages from peer)

--> #$#mcp-negotiate-can 3487 package: mcp-negotiate min-version: 1.0 max-version: 2.1: Tell peer that we support the mcp-negotiate package.
--> #$#mcp-negotiate-can 3487 package: edit min-version: 1.0 max-version: 2.1: Tell peer that we support the edit package.
<-- #$#mcp-negotiate-can 3487 package: mcp-negotiate min-version: 1.0 max-version: 2.1: Peer says she supports the mcp-negotiate package. Negotiated version is 2.1
<-- #$#mcp-negotiate-can 3487 package: mcp-cord min-version: 1.0 max-version: 1.0: Peer says she supports the mcp-cord package
<-- #$#mcp-negotiate-can 3487 package: spam min-version: 1.0 max-version: 2.0: The server, which does not support the spam package, ignores this.
<-- #$#mcp-negotiate-can 3487 package: edit min-version: 1.0 max-version: 1.0: Peer says she supports the edit package.
<-- #$#mcp-negotiate-end 3487: We are done sending mcp-negotiate-can messages.
--> #$#mcp-negotiate-can 3487 package: mcp-cord min-version: 1.0 max-version: 1.0: Tell peer that we support the mcp-cord package.
--> #$#mcp-negotiate-end 3487: Peer is done sending mcp-negotiate-can messages.

Authors

Roger Crew, . . .

Substantial additional contributions and critical comments by . . .