Home

• explain
• command-line
• schemas
  • b: ms: base
  • c: msc: concept
• contact

Message parts

• Contracts
• Services
• Transport
• Payload
• Maintenance

Standard messages

Standardization is crucial to improved cooperation. We do live in a computer society with many standards (like XML, SMTP, SATA) and many standardizing organizations (like IETF, ISO, W3C). Meshy Space is not competing with those standards, but embracing them: building a network with them.

Totally unusual amongst standards, MSI is a standard which plans for change: prepared to evolve over time. It will see a few versions per year. The service definitions have features to guide that smooth evolution. We will start small, and grow with the ever changing needs.

Some thoughts at start

• Whether the message itself is exchanged in JSON, XML, some binary format, or any other formatting still to be invented is not important. This website defines the messages in XML schemas only for its expression power to describe data-structures and data-types;
• Whether (parts of the) messages are exchanged via SOAP, REST, Thrift, FTP, WebDAV, or any other data sharing alternative is not important;
• Whether data is packaged, compressed, crypto-signed etc, is not important: based on negotiation;
• Who has the copyrights, jurisdiction, recall rules, quality, privacy is important in every data-exchange.
• Each subset of data contains versioning, expiration, and a unique identifier. Caching/reuse is important;
• Messages are designed for gradual migration to the next version of the component: compatible upgrades by design.

The URI used to contact the server shows which protocol and formatting is used for the messages. At first contact, the client and server exchange their feature list. This will be very detailed.

Message parts

What makes the Meshy Space Interface stand out, is that it embraces existing technologies into a super-set of what people need in their communication. Normal human society business interactions are guiding us what the messages need.

Cont(r)acts

To be able to comply to data-processing and privacy regulation, parties have to establish an official contract, usually via a Trusted Third Party (TTP). Contracts wrap (anonymized) user information, jurisdiction, licenses, (micro-)payments, and such trading details. Such contract is formalized in authorization tokens, which are passed with each message.
>> More on contracts.

Service definition

Like the semi-static WSDL files for SOAP: description of the end-points which are available. Extended with interface maintenance features, like deprecation cycle, parallel versions, client-side sharding, pricing, tracing, and flow control. >> More on service definitions.

Data transport

MSI is designed to transport small but also huge quantities of data between services. From kilobytes to terabytes of data per day. This may use side channels (like ftp), packaging, compression, encryption, and more. Transport may also be very simple: in-line. >> More on transport.

Payload

Standardizing the operation specific component is a community effort. Related services are RECOMMENDED to work together to offer interchangeable operations.
TODO: explain how to design a payload.

Data maintenance

Every contract will contain the requirement to follow-up on updates for previously delivered information. For instance, data which is withdrawn for reasons of copyright violations, changes made to the source data, legal rulings, or simply to repair delivery mistakes. >> More on data maintenance.