summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--kd/oap-0001.md4
-rw-r--r--kd/oap-0002.md4
-rw-r--r--kd/oap-0003.md6
-rw-r--r--kd/oap-0004.md46
-rw-r--r--kd/oap-0005.md74
5 files changed, 127 insertions, 7 deletions
diff --git a/kd/oap-0001.md b/kd/oap-0001.md
index 535d3d6..7b577dc 100644
--- a/kd/oap-0001.md
+++ b/kd/oap-0001.md
@@ -46,7 +46,7 @@ for those who have understood and commited to the OSMORA oath.
## Audience
OAPs are intended for those who are commited to the OSMORA oath. These
-proposals must only be considered official and binding when they are approved
+proposals MUST only be considered official and binding when they are approved
by a number of OSMORA members and a single OSR (OSMORA Standards Reviewer).
@@ -72,5 +72,5 @@ OSMORA:
OSMORA Oath:
: A pledge taken by all members of OSMORA ensuring their commitment
to societal betterment, technological advancement as well as their
- loyalty to the grater good, resisting the forbidden fruit dangled
+ loyalty to the greater good, resisting the forbidden fruit dangled
by the suits.
diff --git a/kd/oap-0002.md b/kd/oap-0002.md
index 9020562..1da2d66 100644
--- a/kd/oap-0002.md
+++ b/kd/oap-0002.md
@@ -50,12 +50,12 @@ still supporting legacy POSIX applications through compatibility mechanisms such
# Compatibility
OUSI maintains compatibility through its _POSIXSHIM layer. In order for legacy
-POSIX applications to work with OUSI, they must link with the necessary compatibility
+POSIX applications to work with OUSI, they MUST link with the necessary compatibility
libraries and expose legacy POSIX mechanisms by defining "_POSIXSHIM" globally.
# Standard C library headers
-Standard C library headers should be written with OUSI in mind while exposing
+Standard C library headers SHOULD be written with OUSI in mind while exposing
legacy POSIX mechanisms if requested.
## Example of stdio.h
diff --git a/kd/oap-0003.md b/kd/oap-0003.md
index 7cd5de7..b0a4038 100644
--- a/kd/oap-0003.md
+++ b/kd/oap-0003.md
@@ -49,15 +49,15 @@ block of future OSMORA secure protocols.
# Session Requests
-If a client wishes to establish a link with a server, it must send a Session Request
+If a client wishes to establish a link with a server, it MUST send a Session Request
Packet. Doing so allows the client and server to exchange flags along with required
cryptographic keys. All key exchanges under OSTP are done with forward secrecy using
the Elliptic-curve Diffie–Hellman key agreement protocol.
# Security
-All OSTP traffic must be under AES-256-GCM and be purely ephemeral. All OSTP nodes, regardless
-of being in peer-to-peer mode or not, must be stateless and always discard received data after
+All OSTP traffic MUST be under AES-256-GCM and be purely ephemeral. All OSTP nodes, regardless
+of being in peer-to-peer mode or not, MUST be stateless and always discard received data after
use.
# References
diff --git a/kd/oap-0004.md b/kd/oap-0004.md
new file mode 100644
index 0000000..948b097
--- /dev/null
+++ b/kd/oap-0004.md
@@ -0,0 +1,46 @@
+---
+stand_alone: true
+ipr: none
+status: draft
+cat: info
+area: Societal Reform
+wg: OSMORA Standards Group
+
+docname: OAP-0004-DRAFT
+
+title: OSMORA Jurisdiction Exclusion Zones
+abbrev: OSTP
+lang: en
+kw:
+ - ojez
+ - jurisdiction exclusion zone
+ - society
+author:
+- role: editor
+ name: Ian M. Moffett
+ org: OSMORA
+ city: Washington, DC
+ region: Southeast
+ code: 20020
+ email: ian@osmora.org
+
+--- abstract
+
+OSMORA Jurisdiction Exclusion Zones (OJEZs) for limitless ways of living
+and innovation without restrictions being imposed by the suits.
+
+--- middle
+
+# Introduction
+
+An OSMORA Jurisdiction Exclusion Zone (OJEZ) is a region within a state or political division
+that is exclusive to OSMORA and its members. These zones are considered lawless by external
+governance but with minimal and fundemental rules in place to ensure peace and order while
+maintaining *true* freedom for the people.
+
+
+## Purpose
+
+Living on the outside of an OJEZ can be very limiting when it comes to creation, freedom
+and privacy. Our current goverment and society is extremely broken and corrupt and it is
+unlikely that they'll ever be fixed on their own.
diff --git a/kd/oap-0005.md b/kd/oap-0005.md
new file mode 100644
index 0000000..97d298e
--- /dev/null
+++ b/kd/oap-0005.md
@@ -0,0 +1,74 @@
+---
+stand_alone: true
+ipr: none
+cat: std
+status: draft
+area: Systems Engineering
+wg: OSMORA Standards Group
+
+docname: OAP-0005
+
+title: OSMORA Archive Format
+abbrev: OMAR
+lang: en
+kw:
+ - omar
+author:
+- role: editor
+ name: Ian M. Moffett
+ org: OSMORA
+ city: Washington, DC
+ region: Southeast
+ code: 20020
+ email: ian@osmora.org
+
+--- abstract
+
+The OSMORA Archive (OMAR) format is a minimalist replacement for CPIO and TAR perfect
+for use in in-memory filesystems and general usage.
+
+--- middle
+
+# Introduction
+
+OMAR is a simple archive format designed to be minimal and useful for general usage
+as well as for use in in-memory filesystems.
+
+## Purpose
+
+While CPIO and TAR can also get the job done (in too many different ways, that is),
+OMAR simply gets it done while keeping the implementation small and minimal.
+
+# Requirements Language
+
+{::boilerplate bcp14-tagged}
+
+# OMAR header
+
+Before the contents of each file, there MUST be a header that
+describes the file contents. This header contains things such as its
+magic (for validation), file type, length of the filename and the
+length of the file. The file path goes directly after the header
+and its length is denoted by the header filename length field. The
+actual file contents are directly after the filename, if the total
+length of the file is not a multiple of the block size (512) it MUST
+be padded to the nearest 512 byte boundary with zeros. All directories
+are to be padded with 512 bytes where data would be for regular files.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++--------------------+
+| Magic ("OMAR") | - Signature (4 bytes)
+|--------------------|
+| Type | - File type (1 byte)
+|--------------------|
+| Namelen | - Length of name (1 byte)
+|--------------------|
+| Len | - Length of file (4 bytes)
++--------------------+
+\/\/\/\/\/\/\/\/\/\/\/
+ DATA
+ 00 00 00 00 00 00
+ 00 00 00 00 00 00
+ 00 00 00 00 00 00
+ ... padding
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~