two comments for testing collaboration #7
Conversation
edited for clarity
Added Headers and Method sections.
Added comment
janus/message-transport.md
Outdated
|
|
||
| ### Headers | ||
| Accept: message/vnd.janus | ||
| Content-Type: message/vnd.janus |
There was a problem hiding this comment.
I don't like vnd! vnd suggest that it is vender specific. like vnd.ms-excel from Microsoft. I think we should choose one even if it's not part of the mime-type spec. We can use it and I think we can get it into the spec fairly easily once we have adoption.
There was a problem hiding this comment.
OK. How about message/janus? You suggested application/sov-msg. Other options are application/indy-msg, application/janus-msg. The reason I suggested message\ is because it exists and seems more applicable than application. I suggest janus because I think the peer-to-peer protocol could be independent of Sovrin or of Indy. What do you think?
There was a problem hiding this comment.
I like the top level type 'message'. Did not know it existed but it expresses what we want just fine. Not a lot of register sub-types for 'message', so it should be easy to get accepted into the standard. The only concern I would have is sometimes when a part of a spec is ill-used the real world implementation doesn't work well. I think we found this with TLS. The overwhelming majority are 'application', I wonder if there are implementations that assume normal top-level types (application, image, video, etc). I don't think this is too important.
I like not attaching to sovrin or indy. It is a good insight that I was not thinking of. We should be hoping that there are uses for this outside of sovrin or Indy.
more comments
Removed vnd
No description provided.