Add IANA registries#380
Conversation
mickenordin
requested review from
MahdiBaghbani and
glpatcern
and removed request for
glpatcern
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
Thanks Micke, I have a couple of fixes and a conceptual question
| | SHARE_UNSHARED | Share | active | This document | | ||
| | REQUEST_RESHARE | Share | experimental | This document | | ||
| | RESHARE_UNDO | Share | experimental | This document | | ||
| | RESHARE_CHANGE_PERMISSION | Share | experimental | This document | |
There was a problem hiding this comment.
I think we also have USER_REMOVED, though I realize we mention it only in spec.yaml, not (yet) in the I-D. That's pending on the notifications work...
There was a problem hiding this comment.
Yes, what I want is to add the regestires, but I fully expect that the content change as we fix notifications.
product of the other registries.
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
Some more comments. I start to get the principle, that is we define a way for implementers to extend the spec in the parts that may be extended, without needing to touch the core spec. This is very good in view of a final RFC.
| A Sending Server MUST NOT send a share for a combination that the | ||
| Receiving Server does not advertise in Discovery (see | ||
| [Share Creation Notification](#share-creation-notification)). |
There was a problem hiding this comment.
I think we should allow webdav as a legacy exception
| specifications MAY register additional combinations, including ones | ||
| that extend an already-registered protocol to a new resource type or | ||
| share type; doing so does not modify that protocol's own registration. | ||
| The federation combinations are registered in this way by [OCM-MLS]. |
There was a problem hiding this comment.
I understand the concept, but I disagree with this. What about adding federation here, where Reference is populated with This document and [OCM-MLS], and drop it from the other I-D?
My point is we do allow federation also as share payload, even if it's not specified, so the type belongs here, the internals belong to [OCM-MLS].
2 participants
This PR adds IANA registires for:
It also registers OCM-MLS notification entries.
The idea with the registries is to try to find where the extension points of OCM should be. We want the protocol to be extensible AND interoperable. Where the spec is unclear or under-developed interoperability suffers. If we add extension points to the specification with out making it possible to explain how to use that extension point, only proprietary single vendor extensions are possible.
So for example writing in the specification text, that other kinds of notifications are allowed and that implementors MUST ignore notifications they don't understand, is adding an extension point, that is guaranteed not to be interoperable. The registries make sure that we get both extensibility AND interoperabilities at the same time.