Skip to content

Latest commit

 

History

History
83 lines (54 loc) · 3.55 KB

middle.mkd

File metadata and controls

83 lines (54 loc) · 3.55 KB

Introduction

While IP-SFS makes it possible to transmit Internet protocols over semaphore signalling systems such as Clacks, the reverse is not always the case. Information sent in the overhead may be lost when Clacks messages are sent using HTTP.

This document specifies HTTP headers for transmitting overhead messages that originate or are intended for Clacks towers.

Syntax Notation

This specification uses the Augmented Backus-Naur Form (ABNF) notation of and includes, by reference, the "token", "word", "OWS", and "BWS" rules and the #rule extension as defined within Sections 3.2.1 and 3.2.4 of .

The Clacks Protocol

Clacks is a semaphore signalling system invented by Robert Dearheart. It is the primary means of communication between city-states along The Grand Trunk. Like most protocols Clacks has a Header (called the Overhead) and Payload. The Overhead contains information about (among other things) source, destination, message detail, logging, and mechanism control. This document doesn't define the Clacks protocol, only it's delivery over HTTP. The Clacks protocol definition is owned by The Grand Trunk Semaphore Company, Ankh Morpork.

TODO: Fill this out

Clacks over HTTP

The Clacks-overhead header field is used to transmit overhead messages in an HTTP response or request.

ABNF:

Clacks          = 1#clacks-overhead
clacks-overhead = clacks-code [ RWS tower-address ] RWS value
tower-address   = token
clacks-code     = 1*codechar
codechar        = ALPHA
value           = value-string / quoted-string / ext-value
ext-value       = "=" charset "'" [ language ] "'" value-chars
                ; like [](#RFC5987)

Examples

Clacks: GNU John Dearheart

IANA Considerations

The 'Clacks' and 'Accept-Clacks' header fields have been added to the "Permanent Message Header Field Names" registry defined in . FIXME: not submitted yet

Header field name: Clacks

Applicable Protocol: HTTP

Status: Standard

Author: Terry Pratchett (posthumously)

Change controller: IETF

Specification document: this specification

Security Considerations

This document represents an extension to and all security considerations therein, or in documents updating or replacing that document, also apply to this one.

Proxy considerations

Currently the majority of Clacks messages are point-to-point transmissions there is limited scope for multiple User-Agents to require the same response. However it is expected that as Clacks usage grows the cacheability of the information will grow and this standard shouldn't block this.

Due to this any point-to-point message with the Clacks-overhead header MUST also include the no-cache header defined in RFC7234 Section 5.2.1.4. Any newer service provding point-to-multipoint data is free to use HTTP headers as expeted.

#User-Agent considerations A user-agent should follow the Grand Trunk Clacks standards for Overhead definition.

Since the Clacks to HTTP gateway is expected to be a human (or Dwarf, Troll, etc.) operated process User-Agents need to cope with long session availability to provide the necessary time window to allow the message to be input.

IP-SFS Tunnelling

The Clacks-over-HTTP protocol makes available the option of tunnelling proprietary Clacks messages over an IP-SFS based network to allow for interconnection of different operator networks.