... | ... | @@ -3,16 +3,25 @@ |
|
|
After some time, I managed to write this list of requirements for Fenrir:
|
|
|
* **Efficiency**: The protocol must not be above the 5th layer of the ISO/OSI pile and must be a binary one -- no XML.
|
|
|
* **Completeness**: The protocol must handle authentication, authorization, encryption of the connection.
|
|
|
* **Flexibility**: It must be adaptable to multiple needs -- udp or tcp-like trasmission with retransmission or not, as the programmer of the application using it desires.
|
|
|
* **Flexibility**: It must be adaptable to multiple needs:
|
|
|
* multiple streams
|
|
|
* both _reliable_ and _unreliable connections
|
|
|
* both _ordered_ and _unordered_ messages
|
|
|
* both _bytestream_ and _datagram_ transmission
|
|
|
* any combination of the above
|
|
|
* Forward Eror Correction support
|
|
|
* **Interoperbility**: A developer must be able to use a single library for multiple vendors, without any change (f**k OAuth).
|
|
|
* **Federation**: As in kerberos, federated Authentication must be possible.
|
|
|
* **Token-based**: We don't like to give our password away too often...
|
|
|
* **Federation**: As in kerberos, federated authentication must be possible.
|
|
|
* **Token-based**: We don't like to give our password away too often.
|
|
|
* **Nonce-based**: I really don't like to keep synchronized clocks between client and server...
|
|
|
* **Securely desinged**: The protocol must not have any amplification attack.
|
|
|
* **Securely desinged**: The protocol must not have any amplification attack. and provide formal proofs.
|
|
|
* multiple **authorization levels**. We'd like to grant different levels of privilege to different applications.
|
|
|
|
|
|
These are just the main requirements. a lot of other small but important stuff is:
|
|
|
* **Stream-based**: We like having multiple streams in a connection.
|
|
|
|
|
|
These are just the main requirements. A lot of other small but important stuff is:
|
|
|
* **Reconnect** Without big handshakes: - tcp handshake + ssl handshake + OAuth handshake takes a **LOT** of time, being able to associate once and then reuse the association even after a quick network failure is a good thing.
|
|
|
* **Multi-homing** support: Possibly dynamic for long connections and mobile clients.
|
|
|
* **Mobility** support: the connection stays up even if we change IPs.
|
|
|
* Do something about the ridiculous **[X.509](X.509) certificate** situation.
|
|
|
* Make **coffee**: and a **good** one. I'm Italian, after all. |
|
|
|
|
|
---- |
|
|
\ No newline at end of file |