SWAMP General Transport Protocols


Experimental (Research).

1. Introduction

The SWAMP Architecture allows for various protocols to be used to convey knowledge. One class of protocols, general transport protocols, allow any RDF knowledge base to be conveyed (subject to issues of security, size, etc). Most other protocols are application-specific, allowing only a specific kind of information to be conveyed.

Many protocols, including HTTP, SMTP, TCP, and UDP, are design to allow general transport of information, but do not include a standard knowledge representation mechanism. These protocols can be used as part of a SWAMP transport protocol.

This document shows how to use these standard protocols as SWAMP transport protocols. In each case, the process involves specifying a way to identify the knowledge representation language and specifying what knowledge about the message is required for or provided by the protocol implementation.

2. Underlying Protocols


The server address is an absolute URI.

In servicing an HTTP HEAD or GET request, the extra header "Conforms-to: http://www.w3.org/2002/03/swamp/transport-1" is added.

Messages can be sent with HEAD, GET, or POST. Messages sent with HEAD get only a status code back, and are declared to be non-committal. Message sent with GET are declared to be non-committal. Any kind of message may be sent with POST, although clients SHOULD use HEAD and GET when possible. The distinction is nicely explained in TimBL's Style Guide: User Input, and Yukka Korpela's GET and POST in HTML forms.

To send with HEAD or GET, any of several techniques may be used by clients and MUST be accepted by the server:

  1. Query parameters "SWAMP-Content-Type" and "SWAMP-Content" are added; both are URI-escaped.
  2. Like (1), but if the URI is not already a query URI, the client may use a "/" instead of a "?". This makes some people happy.
  3. The fields may be added as HTTP fields instead. Probably list it in the Vary field.
  4. Maybe HTTP-Extensions, but do we want servers to have to have them?

To send using POST, either:

  1. Provide the appropriate Content-Type header, or
  2. Use Content-Type application/x-www-form-urlencoded and and put the content type and content in the form data, as with GET. When you do this, the other form data is available in the metadata.

Content-Encoding must be handled for POST. Maybe we should have SWAMP-Content-Encoding on the parameterized versions, to allow compression.

@@@ how does the metadata get presented?


Just send one or more RFC822-style headers, a blank line, then content. One header is used, the Content-Type header, as with HTTP. Any other headers, if present, get encoded into the message (somehow).

3. Content Types


The experimental Trivial Object Description Language (TODL) 1.0 can be used to encode any RDF graph. Very simple. Joy joy.

Should we register this ASAP? Or something to not be an X?

See RFC 2046 and RFC 2048.


Good if you like XML.

4. Sample API


  kb1 = /* knowledge to send */
  kb2 = /* knowledge to possibly use but not send */
  recipient = /* RDF identifier for message recipient */
  replykb = send_and_wait(kb1, recipient, kb2);
  send_and_callback(kb1, recipient, kb2, callback_function);
  send(kb1, recipient, kb2)
       (when you're not interesting in a reply, or even 
       knowing if it got delivered.)


Servers could open the network listening ports themselves, or be run like CGI or from inetd when the connection has been made.

  accept(&messkb, &metakb)

  where the metakb has info from the protocol stack about the
  message.  It's more trustworthy, etc.

  OR metakb includes reified messkb.   And it's just added to by

  reply(returnMess, [message id]?)

Sandro Hawke
$Id: general-transport.html,v 1.1 2002/03/29 20:02:53 sandro Exp $