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 <[email protected]>
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! |
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.