RSpecExtensions

The RSpec must accomodate a large number of stakeholders. Therefore, one of its key features must be extensibility. The purpose of RSpec extensions is to allow a client or server to pass optional information without having to resort to go outside of the GENI framework. These extensions will allow the RSPec to be flexible while the core RSPec can act as a stable foundation.

Extensions Must Be Ignorable

Not all clients or servers will support all extensions. If a client or server does not support a particular extension, then the tags which are part of that extension will be ignored. This will allow extensions to be created and deployed incrementally with much greater ease than a change to the core RSpec.

This requirement limits the kinds of things that extensions can do. Extensions are useful when providing information about resources or expressing soft constraints on those resources. But they can never be used to communicate hard requirements because those requirements might be ignored if your communication partner doesn't know about that extension.

Extensions Must Be Modular

Each extension can mix elements or attributes into the main RSpec, but those elements and attributes must be explicitly tied to their extension. Every extension must be able to co-exist with every other extension.

Extensions Must Be Validated

In order to tag extensions, each one must use a unique XML namespace. We must be able to validate any XML document using the core schema. The core schema should validate the elements and attributes in the main RSpec namespace and ignore tags outside of it.

But the extensions themselves must be validated. We must create or use a validation framework which can take independent schemas for any set of extensions and validate that set of extensions and the core schema while ignoring any tags in other namespaces. We are currently investigating NVDL (http://www.nvdl.org/) for this purpose.

Extensions Must Allow Encryption

Clients and servers are required to understand and comply with the core RSpec semantics. This means that if there is sensitive information, it will be marked as such in the core RSpec. That information will be sent along a secure channel to the client. Then the client has the responsibility of deciding how or when that information should be disseminated. This means that the core RSpec does not itself need an encryption mechanism.

But the situation changes when it comes to extensions. Extensions must be ignorable because not all clients and servers implement them. This means that if sensitive information is included in an extension, the client will ignore that extension if the client doesn't implement it. This means that there is no way for the client to know of the existence of sensitive information in extensions it does not implement. That means that it no longer makes sense to expect clients to manage sensitive information themselves if that sensitive information is in an extension.

Therefore, the extension system should provide a mechanism to encrypt portions of the RSpec to prevent inadvertent information leakage. This might involve encrypting those portions using the client's public key in a standard way. The extension mechanism should also provide some standard mechanism to allow extensions to authenticate their portions of the RSpec.