Use of `didcomm.org` in PIURIs

[llorllale]

Is DIDComm v2 reserving the use of the didcomm.org authority in standard PIURIs? Are they also allowed in the standard extensions? Can anyone arbitrarily publish their own extension or protocol under this same authority?

[tplooker]

@llorllale I dont think you could normatively enforce people to not do this, it would just be strongly recommended implementation guide that people should follow the rules that govern the didcomm.org namespace.

[kdenhartog]

I agree with Tobias that it's hard to enforce these things. Would the preferred outcome for this be that we add some text to the spec to talk a bit more about the didcomm.org uri?

My guess is that developers who do these types of issues would just end up causing interop issues for themselves more then anything else. If people chose to override the namespace then the implementations wouldn't end up being compliant. If they decided to add to the namespace without having approval then developers who want to support that protocol URI wouldn't know where to find additional documentation (because it's not at the didcomm.org domain)

[TelegramSam]

A discussion of what we should do with didcomm.org may help this discussion.

The vision (currently, anyway) for didcomm.org is to act as a pack repository of sorts - not of code, but of protocol specs. This allows anybody to 'register' a package there by providing documentation. This means that the 'authority' of didcomm.org protocols doesn't come from being linked to the domain itself, but rather the adoption of them.

Those protocols identified by the community as 'core' have authority because of the presence in the spec, not because of the didcomm.org namespace.

Thoughts? Disagreements?

[TelegramSam]

Close in WG Meeting 2020-11-02