From 068e96fefcff8be47f6d07e02aa51d1afb479fa2 Mon Sep 17 00:00:00 2001 From: Devin Fisher Date: Fri, 20 Apr 2018 17:07:25 -0600 Subject: [PATCH 1/9] two comments for testing colabiration --- README.md | 7 +++++++ janus/message-transport.md | 1 + 2 files changed, 8 insertions(+) diff --git a/README.md b/README.md index e54556e..cee4922 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,10 @@ + + # The Sovrin Protocol The Sovrin Protocol is a set of standards, patterns, and tools that facilitate diff --git a/janus/message-transport.md b/janus/message-transport.md index 1b63e73..1261661 100644 --- a/janus/message-transport.md +++ b/janus/message-transport.md @@ -13,6 +13,7 @@ Example: https://agency.example.com/msg/ ## Headers + TODO: Any thoughts on http headers ## Response ### Codes From 3126918336b3221f353724086e438b01ae975e57 Mon Sep 17 00:00:00 2001 From: Jason Law Date: Sat, 21 Apr 2018 00:07:12 -0600 Subject: [PATCH 2/9] Update README.md edited for clarity --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index cee4922..939db88 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ - From 25b70db877a5f483302e5ee2d3055b39318b1761 Mon Sep 17 00:00:00 2001 From: Jason Law Date: Sat, 21 Apr 2018 01:18:41 -0600 Subject: [PATCH 3/9] Update message-transport.md Added Headers and Method sections. --- janus/message-transport.md | 43 +++++++++++++++++++++++++------------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/janus/message-transport.md b/janus/message-transport.md index 1261661..b523301 100644 --- a/janus/message-transport.md +++ b/janus/message-transport.md @@ -6,23 +6,38 @@ Messaging is transport agnostic. Messaging does not rely on transport for guaran Despite the agnostic nature of the messaging protocol, the use of a transport protocol requires agreement on conventions for the use of the said protocol. These conventions will be protocol specific and their scope is only decisions needed to transport the message on the said protocol. Anything related to the meaning, security or routing of the message is expressly out of scope. # HTTP/HTTPS -## URL -The endpoint URL for messages should be a simple endpoint. It should not have route info (ex. DIDs) and should be consistent for all users of the endpoint service. +## Request +### URL +Endpoint URLs for Janus messages should be simple. The URL should not expose any extra information about the message (e.g., the type of message being sent). It should have no route info (e.g., DIDs) and should be consistent for all users of the endpoint service. Message types and destination DIDs are encapsulated in the encrypted messages themselves, so as not to reveal information to proxy agents and routers along the path to the ultimate destination. -Example: +Example: https://agency.example.com/msg/ + +### Method +The method used for Janus messages should be `POST`, and agents with HTTP interfaces that receive a different message are encouraged to return a 405 Method Not Allowed. + +Janus does not depend on the transport protocol for confidential communications, therefore an HTTP method can leak details about the message being sent. HTTP is resource-oriented, and Janus is message-oriented. The intent of a Janus message is embedded in the message type. + +### Headers +Accept: message/vnd.janus +Content-Type: message/vnd.janus -https://agency.example.com/msg/ -## Headers - -TODO: Any thoughts on http headers ## Response -### Codes -#### OK -How the message is processed and what response is given is the prerogative of the receiver of the message. There is two conventions for non-error response. -**202 Accepted** -- The message is processed asynchronously. No content is return. +### Headers +If a response contains a message then include a Content-Type header. + +Content-Type: message/vnd.janus + +### Status Codes +How the message is processed and what response is given is the prerogative of the receiver of the message. There are two conventions for non-error response. + +#### Success +**200 OK** -- The message was processed successfully, and the body contains the response message. + +**202 Accepted** -- The message will be processed asynchronously. No response message. + +**204 No Content** -- The message was processed succesfully with no response message. -**200 OK** -- If the message is processed synchronously and the return is the corresponding message. +#### Errors -#### Error -Standard 400s codes for client errors and standard 500s codes for server errors. \ No newline at end of file +Standard 4xx codes for client errors and 5xx codes for server errors. From 452b023c0668d69465d7f67dedcc5b46dfaaab59 Mon Sep 17 00:00:00 2001 From: Jason Law Date: Sat, 21 Apr 2018 01:21:10 -0600 Subject: [PATCH 4/9] Update README.md Added comment --- README.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 939db88..e9dea5e 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,12 @@ - + # The Sovrin Protocol From e7302630f3ccc83bd3aa1f883a1bc3250b898840 Mon Sep 17 00:00:00 2001 From: Devin Fisher Date: Sat, 21 Apr 2018 21:18:25 -0600 Subject: [PATCH 5/9] comment --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index e9dea5e..7f45180 100644 --- a/README.md +++ b/README.md @@ -6,6 +6,9 @@ DF: Throughout the repo there are at least two types of data: How do we want to distinguish them (or do we). Should we have a directory that is background reading and/or design principles? JL: Yes, I think we should organized them, and cross reference. What do you recommend? +DF: I'm thinking that maybe we should have a folder/codename like Janus for the background theory, where we layout + our case for our goals, princibles, etc. We decribe the folder as not containing specs, per say, but as a foundation to + understand our protocol. --> # The Sovrin Protocol From 0324e70c03a3f7c2b605d9ea64bd07de22edfdbd Mon Sep 17 00:00:00 2001 From: Devin Fisher Date: Sat, 21 Apr 2018 21:24:11 -0600 Subject: [PATCH 6/9] comment --- janus/message-transport.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/janus/message-transport.md b/janus/message-transport.md index b523301..4c5c01f 100644 --- a/janus/message-transport.md +++ b/janus/message-transport.md @@ -18,6 +18,9 @@ The method used for Janus messages should be `POST`, and agents with HTTP interf Janus does not depend on the transport protocol for confidential communications, therefore an HTTP method can leak details about the message being sent. HTTP is resource-oriented, and Janus is message-oriented. The intent of a Janus message is embedded in the message type. ### Headers + Accept: message/vnd.janus Content-Type: message/vnd.janus From ec78126807ee94de36ec706f7c583d389eb9f408 Mon Sep 17 00:00:00 2001 From: Jason Law Date: Sat, 21 Apr 2018 23:31:16 -0600 Subject: [PATCH 7/9] Update README.md more comments --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 7f45180..219e80f 100644 --- a/README.md +++ b/README.md @@ -7,8 +7,11 @@ DF: Throughout the repo there are at least two types of data: reading and/or design principles? JL: Yes, I think we should organized them, and cross reference. What do you recommend? DF: I'm thinking that maybe we should have a folder/codename like Janus for the background theory, where we layout - our case for our goals, princibles, etc. We decribe the folder as not containing specs, per say, but as a foundation to + our case for our goals, principles, etc. We decribe the folder as not containing specs, per se, but as a foundation to understand our protocol. +JL: OK, that sounds good. What should the main README have in it then? Super high level summary with a + reference to documents for principles and for specs? + --> # The Sovrin Protocol From 63822459d584103f67b24aeb6d39052aabb20d16 Mon Sep 17 00:00:00 2001 From: Jason Law Date: Sat, 21 Apr 2018 23:33:19 -0600 Subject: [PATCH 8/9] Update message-transport.md Removed vnd --- janus/message-transport.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/janus/message-transport.md b/janus/message-transport.md index 4c5c01f..369edbe 100644 --- a/janus/message-transport.md +++ b/janus/message-transport.md @@ -18,18 +18,15 @@ The method used for Janus messages should be `POST`, and agents with HTTP interf Janus does not depend on the transport protocol for confidential communications, therefore an HTTP method can leak details about the message being sent. HTTP is resource-oriented, and Janus is message-oriented. The intent of a Janus message is embedded in the message type. ### Headers - -Accept: message/vnd.janus -Content-Type: message/vnd.janus +Accept: message/janus +Content-Type: message/janus ## Response ### Headers If a response contains a message then include a Content-Type header. -Content-Type: message/vnd.janus +Content-Type: message/janus ### Status Codes How the message is processed and what response is given is the prerogative of the receiver of the message. There are two conventions for non-error response. From 81e75bc28516b10c3455b637db31ebf992d61a34 Mon Sep 17 00:00:00 2001 From: Devin Fisher Date: Mon, 23 Apr 2018 09:03:23 -0600 Subject: [PATCH 9/9] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 219e80f..52137a6 100644 --- a/README.md +++ b/README.md @@ -11,6 +11,7 @@ DF: I'm thinking that maybe we should have a folder/codename like Janus for the understand our protocol. JL: OK, that sounds good. What should the main README have in it then? Super high level summary with a reference to documents for principles and for specs? +DF: Yeah, a map to where to go depending on what you are wanting to read. -->