Modular Extension Mechanism Architecture

Rationale In this document, we attempt to explain the rationale behind the extension mechanism, and its abstract properties. At the abstract level, we are addressing its suitability for extending any of the information-delivery protocols traditionally represented by UR*s.

Defintions An information service drawn from the family of tradtional transport protocols (*TP: FTP, SMTP, HTTP, NNTP, etc) handles naming, packaging, and processing of representations of information objects. Clients and servers communicate across a chain of such transport agents.

Modules correspond to well-known features. Modules may also correspond to executable functions that can transform representations.

Agents need to be able to negotiate about the existence of features, and to reprocess representations while indicating clearly what kinds of inverse processing will have to be invoked by counterparties.

Properties Agents need to reason about the following properties of modules:

1. Names of features, and name-compatibility

2. Negotiable parameters

3. Formal parameters for function applications

4. Ordering information, for multi-stage reprocessing

5. Scope, where multiple agents may be involved

6. Strength, for negotiation purposes

In the context of e-mail, MIME defined many of these properties, but limited the degrees of freedom at several points:

1. Names are selected from an overregulated and restrictive two-level registry.

2. parameters can only be passed from the mime-type, not from enclosing header-lines.

3. As a consequence, argument values are packaged into separate MIME-parts, as in MOSS.

4. Content-transfer-encodings cannot be layered or nested.

5. The email-medium is only point-to-point, so there is no bidirectional negotiation (hence, multipart/alternative), nor should any transport agents reprocess MIME mail.

6. MIME content-type recognition is always mandatory to reason about messages.

In SMTP, common extensions to SMTP are keyed off of sendmail server versions and, as of RFC 1651, through named features. Such features as command pieplining and checkpoint/restart are always optional, and SMTP agents can only negotiate the presence/absence of features, with some parameters. There is no facility for one SMPT agent to direct another to reprocess message representations (uudecode, 7bit, etc). SMTP does reprocess addresses and routes, but that's totally site-dependent behavior, with insufficient inband information.

Given these abstract properties, we can realize them in several ways. One is the extension syntax being proposed for HTTP; it would apply to HTTP and any of the information transports commonly gated through it. Another is a generic RPC system that can test for the presence/absence of libraries/types, and an ASCII encoding format for the deferred calls.

Go Up (Parent):

[Old-Drafts]

See Also (Siblings):

[Extension Proposal] [W3CSP Core Features] [Modular Extension Mechanism for HTTP] [Extension Syntax]