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.
|
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
I think many of these concerns are addressed now, by moving it to an appendix and stating that it is non-normative. |
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
I think this looks good now, the requested changes are just spelling mistakes.
mickenordin
force-pushed
the
kano-definitions
branch
3 times, most recently
from
16145ce to
2177cf1
Compare
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
I'm happy with this now. @KrausMatthias what about you?
KrausMatthias
left a comment
KrausMatthias
left a comment
There was a problem hiding this comment.
Should we distinguish between Sent Shares and Received Shares in the Object models?
Otherwise I think it's perfect :)
MahdiBaghbani
left a comment
MahdiBaghbani
left a comment
There was a problem hiding this comment.
I've read it now, It's great, nice ascii flowcharts! Thanks Micke
True that in a real implementation (e.g. in Reva) those two types are expected to be quite different, at least because in the Received Share the remote URI has to be stored. We may want to emphasize that. |
This is a great point, I will add a 'direction' to the model. |
Co-authored-by: Giuseppe Lo Presti <giuseppe.lopresti@cern.ch>
mickenordin
force-pushed
the
kano-definitions
branch
from
2177cf1 to
2a26d1a
Compare
|
I added a direction to the share model now |
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.