Add functions, roles, and object models to draft #297
Conversation
This updates IETF-RFC.md with a significantly expanded conceptual framework for OCM. It introduces formal definitions of OCM functions, clarifies the roles of Sending and Receiving Servers, and adds detailed object models for Address Books, Contacts, Invites, Providers, Shares, Users, and Resources. The change reorganizes and expands terminology, adds diagrams to illustrate relationships, and alphabetizes and harmonizes defined terms. Legacy duplicated sections are removed or merged into the new structure. Signed-off-by: Micke Nordin <kano@sunet.se>
mickenordin
force-pushed
the
kano-definitions
branch
from
4047ebd to
75c89ee
Compare
KrausMatthias
left a comment
KrausMatthias
left a comment
There was a problem hiding this comment.
This is a great improvement! Adds a lot of clarity to the involved concepts.
I think a distinction on what is Binding Specification and what is helpful context should be added.
| - acts as an API client, allowing the receiving user to access the | ||
| Resource through an API (e.g., WebDAV [RFC4918]) of the sending | ||
| server. | ||
| * __Remote Resource__ - A Resource provided by the Sending Server. |
There was a problem hiding this comment.
A Resource accessible on a Receiving Server via a Share from a Sending Server ?
| * __Shared Resource__ - A Resource shared by an OCM Server, becoming a | ||
| Remote Resource if accepted by the Invite Receiver OCM Server. |
There was a problem hiding this comment.
Whats the difference to a Resource?
There was a problem hiding this comment.
These two (this and your comment above) have been part of the definitions for a long time, I just alphabetized them. But I take your point that there is a lot of redundancy in definitions, and I was also pondering that when sorting them.
| * the Invite Receiver OCM Server sends the Invite Acceptance Request to | ||
| the Invite Sender OCM Server | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Add Users and their actions (Alice and Bob :D )?
|
I think my main concern is still what is strictly necessary for interoperability, and what should be left open to implementations (while guidance regarding the concepts is still extremely helpful there). So I'm not after removing details but clearly separating, "this must what a share payload looks like with these semantics so it works with other implementations" and "this is what you might keep track of in your implementation to build a working service, but doing it differently would still work". So maybe we could have two separate sections? "Protocol Specification" and "Context and Implementation Guidance" ? |
Overall I'm quite sympathetic with this comment. I appreciate the overall effort to "canonicalize" the implementations, but it has to be clear what is prescribed and what is guidance. I did not have time yet to review this PR in details and I thank both of you for the combined effort! |
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
I started to give a full review and already have a few comments, possibly more to come, but overall I think it's an effort in the good direction
| | Added | | ||
| +-------------+ | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Here I'd either include the mermaid-formatted Sequence Diagrams we have in the repo or refer to them, as opposed to try and draw them.
| Shares; similar to "Resource Owner" in OAuth [RFC6749], identified by | ||
| its OCM Address. | ||
| * __Sending Server__ - The server that: | ||
| - holds the Resource ("file server" or "Entreprise File Sync and Share |
There was a problem hiding this comment.
I'd remove the file server or EFSS example, or explicitly state for instance, a file server.
| Resources. It MAY provide it's users with an _Address Book_ of | ||
| _Contacts_ and the ability to accept _Invites_. | ||
|
|
||
| ## Object models |
There was a problem hiding this comment.
I'm not so convinced that this section should be at the very beginning of the Draft. What do other people think?
This updates IETF-RFC.md with a significantly expanded framework for describing OCM using ASCII diagrams in the vain of https://datatracker.ietf.org/doc/rfc3290/ as referenced by https://datatracker.ietf.org/doc/rfc3444/.
It introduces formal definitions of OCM functions, clarifies the roles of Sending and Receiving Servers, and adds detailed object models for Address Books, Contacts, Invites, Providers, Shares, Users, and Resources. The change reorganizes and expands terminology, adds diagrams to illustrate relationships, and alphabetizes and harmonizes defined terms. Legacy duplicated sections are removed or merged into the new structure.