w3c / did-core

W3C Decentralized Identifier Specification v1.0
https://www.w3.org/TR/did-core/
Other
405 stars 94 forks source link

Remove the IANA section for application/did+dag+cbor. #650

Closed msporny closed 3 years ago

msporny commented 3 years ago

This should have been removed by PR #593 https://github.com/w3c/did-core/pull/593/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051L6254 ... but the section has somehow reappeared in the spec. Removing again. Harder, this time.


Preview | Diff

OR13 commented 3 years ago

hmm, might we consider applying for reserving the following:

It feels like maybe all of these belong in did-spec registries... and that we use that repo to coordinate with IANA... otherwise we will be creating a problem for future representations that are created after the spec is published....

In short, I would accept this PR IF we had a PR that added application/did+dag+cbor to did spec registries, and it had been merged.

msporny commented 3 years ago

hmm, might we consider applying for reserving the following:

  • application/did+ld+cbor
  • application/did+dag+cbor
  • application/did+yaml
  • application/did+xml

To reserve something at IANA in the "standards tree", it needs to exist in specification form. The representations above do not exist in specification form, therefore if we tried to register them, the registration would be denied:

https://tools.ietf.org/html/rfc6838#section-3

It feels like maybe all of these belong in did-spec registries... and that we use that repo to coordinate with IANA... otherwise we will be creating a problem for future representations that are created after the spec is published....

The only responsibility the DID WG has in coordinating with IANA is handling the Media type registrations that it is creating. The DID Spec Registries, nor the DID WG have any responsibility for specifications that are not under our jurisdiction.

In short, I would accept this PR IF we had a PR that added application/did+dag+cbor to did spec registries, and it had been merged.

We can't do that w/o a specification... registration of that specification would be up to the author of that specification.

The DID WG had consensus to remove the DagCBOR section to a separate specification. It is up to the people that want to see that specification happen to do the work to make it happen.

If you are suggesting that the Representations section be moved into separate specifications, we don't have consensus on doing that and you'd need to raise the issue with the WG and get consensus on that topic.

It sounds like your concern has to do with there not being a clear section in DID Specification Registries to register representations? I have added language in a recent PR to address this: https://github.com/w3c/did-core/pull/644/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R2518-R2520

The only remaining thing that needs to be done is for someone to add that section in DID Specification Registries. I suggest you raise a PR to do that, which would be productive, and not block this PR from going in, which would not be productive.

iherman commented 3 years ago

I agree with @msporny that the DID Core spec must include only those IANA sections that apply to types that are specified for usage in the present document. The Core spec should not be used to register anything else.

Additionally, a small remark:

The only remaining thing that needs to be done is for someone to add that section in DID Specification Registries. I suggest you raise a PR to do that [...]

Just a warning. W3C has a specific procedure so that a W3C Recommendation (more exactly a specific section thereof) is accepted as the official media type documentation by IANA. If a media type is done in a W3C Note, this procedure may not be available for us anymore, and the media type documentation may become a bit more complicated. (I would have to check.)

OR13 commented 3 years ago

@iherman the media type specification will be registered in the note. but defined elsewhere... eventually... the core point being that the did wg will end, but did spec registries will live on.

iherman commented 3 years ago

did wg will end, but did spec registries will live on...

... happily ever after :-)

+1

msporny commented 3 years ago

Since already removed in PR #593 -- Editorial, multiple positive reviews, no changes requested, no objections, merging.