-
Notifications
You must be signed in to change notification settings - Fork 0
/
introduction.xml
74 lines (74 loc) · 4.24 KB
/
introduction.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<?xml version="1.0" encoding="UTF-8"?>
<section anchor="intro" title="Introduction">
<section anchor="purpose" title="Purpose">
<t>The Federated Object Storage Protocol (FOSP) is an application-level protocol
for exchanging structured and unstructured data generated by users of different providers.
It is designed to fulfill the needs of online social networks by combining necessary features into one simple protocol.
</t>
<t>FOSP aims to provide three core features:
<list style="numbers">
<t>Store data online and support standard operations on it.</t>
<t>Enforce access control on the data, for users from different hosts, without central authentication.</t>
<t>Notify users when data is added, removed or has changed.</t>
</list>
</t>
<t>All these features must be available in a federated network.
Furthermore, some non-functional requirements are imposed.
The protocol needs to be data agnostic and should support structured, unstructured and meta-data.
It also must be as simple as possible, e.g. it must be easy to implement and it should be possible to write easy to deploy applications for it.
</t>
</section>
<section anchor="conventions" title="Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" />.
</t>
<t>This document also makes use of the augmented Backus-Naur Form (<xref target="RFC5234" />) to formally describe the syntax of messages.
</t>
</section>
<section anchor="requirements" title="Requirements">
<t>FOSP builds on existing protocols and data formats.
The transport protocol for FOSP messages currently is the WebSocket protocol as defined in <xref target="RFC6455" /> and a HTTP (<xref target="RFC7230" />) binding is in the works.
Other options may be added in the future.
Objects are serialized into the JavaScript Object Notation (JSON) according to <xref target="RFC7159" />.
Besides these technical dependencies, FOSP is inspired by WebDAV (<xref target="RFC4918" />) and XMPP (<xref target="RFC6120" />) and has similarities to LDAP (<xref target="RFC4370" />).
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>This document uses a number of terminologies to refer to concepts found in FOSP.
<list style="hanging">
<t hangText="provider">An entity that provides storage space on the Internet for the data of users.
It is identified by a fully qualified domain name.
</t>
<t hangText="server">A FOSP server stores the data of users of a certain provider.
The term server applies to the the software that processes request as well as to the machine that runs the software.
For fault tolerance and load balancing purposes, a provider might deploy multiple servers.
</t>
<t hangText="client">A FOSP client is a program a user uses to communicate with a FOSP server.
It facilitates accessing the data of the user that is stored on the server.
</t>
<t hangText="message">A message is the basic unit of communication in FOSP.
Messages come in three different flavors.
</t>
<t hangText="request">A request is a message sent from a client to a server.
It is used to retrieve or alter data.
</t>
<t hangText="response">A response is a message sent from a server to a client.
It is always sent as an answer to a request and contains the status of the request and possibly data.
</t>
<t hangText="notification">A notification is a message that is sent by servers when changes happen to an object.
</t>
<t hangText="object">An object is the basic unit of data in FOSP.
It consists of structured data expressed in JSON.
</t>
<t hangText="attachment">An attachment is a binary or text file that is associated with an object.
Each object can only have one attachment.
</t>
<t hangText="tree">The objects of a users form a tree structure.
Each object has exactly one parent object, except for the root object.
There exists exactly one tree per user.
</t>
</list>
</t>
</section>
</section>