core-wg / href

Other
2 stars 0 forks source link

Draft text for URI-Scheme-ID registry #57

Closed cabo closed 1 year ago

cabo commented 1 year ago

As discussed today in the interim

cabo commented 1 year ago

In the meeting, we agreed to look at existing URI-schemes to include in the initial content. A wiki for collecting information we find is set up at https://github.com/core-wg/href/wiki/uri-schemes-that-we-want-numbers-for The present PR will leave draft status once the results from that collection activity have found their way into the PR.

cabo commented 1 year ago

We are not covering provisional vs. permanent registrations.

How do we get people to notice the opportunity to register a negative number?

chrysn commented 1 year ago

In the interim the "number now or never" vs. "numbers later but x- problem" issue.

Neither option feels really right for me, both have too grave downsides. Trying to think out of the box here: Can we get around this dilemma by declaring text versions second class citizens from the onset? Like, "Using the text form is a fallback for when no numeric form has been assigned, and not for when the receiving party may or may not know the numeric form. Users of CRIs other than generic interconverters need to make sure that the protocols they actually dereference have assigned numbers". And "Generic converters between URIs and CRIs should be deployed with updatability in mind" (as all IoT software should be). That'd allow schemes to be assigned numbers later, and while not solving the x-dash problem in full, would at least be very explicit about the expectations that are set, in that nobody should be stuck with text.

cabo commented 1 year ago

The problem really is that I can't generate nint labels if I don't know whether the recipient understands them. So, as a generator, I'm eternally stuck with text labels.

cabo commented 1 year ago

We now have converged on a radically different approach: register a nint for everything.