-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reviewing changes per issue #24 #35
Comments
Reflecting on my reflections... I think the draft is a bit schizo about the specific use of IANA registries. There are many references to IANA registries, but much of the language in the spec (-02) seems to avoid being specific about IANA registries, while not really mentioning any alternatives. An example here would be the use of a public wiki as an alternative to an IANA registry. |
hello graham. On 2016-03-10 15:00, gklyne wrote:
this pops up every couple months, usually because people working with
this would be a breaking change, and you would introduce aliases by |
going through your comments one by one... On 2016-03-10 15:00, gklyne wrote:
i absolutely agree. but the point is that there is this conflation of i fully agree that registries should be for documenting the identifiers
yes, that's what i think as well. however, that distinction is |
Yes, this already exists as defined in RFC 4287. It has also been heavily discussed in mnot/I-D#140. |
On 2016-03-10 10:00, gklyne wrote:
same here... ;-) and maybe we can do so in person later this week.
absolutely agreed, but that's not part of operations, is it? i think |
agreed that this (the ability to use non-IANA registries) needs to be in
|
On 12/04/2016 14:04, Erik Wilde wrote:
I'm a bit fuzzy on the context of this discussion (which isn't managed well by
When a registration request is submited to IANA, then if the registry calls for
But if the namespace may contain reviewed and non-reviewed values (as is the #g |
just wondering here, @gklyne: would that issue be addressed by talking about various "categories" of values that a registry might have? this could be associated with different levels of review/process and thus make it possible to have different "spaces" in one registry: they would share the same value space (the registered value), but have different policies associated with them in terms of what it takes to be accepted into the registry. |
That (.. various "categories" of values ..) is effectively what happens now for URI scheme registration: the requirement for provisional registration is first-come first-served, where the requirements for permanent are more stringent. As the currently designated reviewer, I've requested that I'm notified by IANA about provisional registrations, but I have no formal role in determining their acceptance. I think "that issue" you refer to is my comment about handing off to a wiki-like mechanism. That comment was made over a year ago now, and I'm not certain what was in my mind at the time. But it does seem to me that if the provisional entries are separated from the registry of reviewed permanent entries, then it's more work to ensure that collisions are avoided. I'm also not sure if wiki edit wars might ensue (e.g. if someone didn't recognize the priority of permanently registered schemes). |
On 2017-08-01 13:49, gklyne wrote:
That (.. various "categories" of values ..) is effectively what happens
now for URI scheme registration: the requirement for provisional
registration is first-come first-served, where the requirements for
permanent are more stringent.
good, i think that's a useful aspect to add to the draft. i have created
#65 for this.
As the currently designated reviewer, I've requested that I'm notified
by IANA about provisional registrations, but I have no formal role in
determining their acceptance.
that's probably a useful and common pattern.
I think "that issue" you refer to is my comment about handing off to a
wiki-like mechanism. That comment was made over a year ago now, and I'm
not certain what was in my mind at the time. But it does seem to me that
if the provisional entries are separated from the registry of reviewed
permanent entries, then it's more work to ensure that collisions are
avoided. I'm also not sure if wiki edit wars might ensue (e.g. if
someone didn't recognize the priority of permanently registered schemes).
thanks for bearing with me. i am only getting back to the registry topic
now, after i did let it sit quiet for a long time. i hope i'll be able
to produce an updated version of the draft pretty soon. thanks for your
feedback, it is very much appreciated!
|
Catching up, re issue #24 ...
Specifics first. More general comments at the end.
section 5.2. Entry Levels, nit
The provisional/permanent pattern was introduced by the message header registration spec (BCP 90), and subsequently adopted and adapted by the URI scheme spec. I'm not aware of any other registries that have also adopted the pattern.
This is just a historical nit, and doesn't affect the substantive content of your text.
5.3. Separation by Value Syntax
I believe there was a proposal to map registered registered link relations into URI space in a consistent fashion, but don't offhand recall where I saw it.
In the case of link relations, I think it is possible to gracefully migrate between categories by retaining the previous use; e.g. a registered link relation could be documented as being equivalent to some URI used as link relation. It's not perfect, but not (IMO) as disruptive as your text seems to suggest, and not in the same league as the "X-" prefix problem.
6.1. Registry Operations
FWIW, I think IANA are moving towards an underlying XML model for at least some registries that also supports machine readable data. E.g. http://www.iana.org/assignments/uri-schemes/uri-schemes.xml (look at page source). Other formats are also available.
I think there's an important registry operation matter that you haven't touched on here: IANA have great administrative skills, but they cannot be expected to have technical knowledge of any particular protocol or system. So, if registration approval requires any kind of technical judgement, you end up being pretty much compelled to involve an expert review in the registration process.
6.7. Registry Access
This section feels out of place to me, as a subsection of "using registries". It feels more like an operations concern, not something that is really relevant to registry designers, and maybe should be a subsection of 6.1?
6.8. Runtime vs. Design-Time
I'm not aware of any IANA registries that are intended to allow dynamic access. It feels to me like a "bad idea", because it potentially makes IANA a bottleneck in Internet operations, and I'm not sure they have the infrastructure resilience to support this.
I tentatively suggest that if there is an element of dynamic access, then this needs to be part of the related protocol spec rather than pushed onto a registry.
General comments
Reflecting on the revised spec and our ealier discussions (per issue #24), I feel that the role of registries as a means to make values discoverable is a bit obscured. It's there in the document (section 3.7), but the message of discoverability does't come over so clearly to me. I think it's partly the choice of section title, and partly because the content also discusses design time vs run time in a way that I think distracts from the key idea of design-time discovery. To my mind, allowing designers and implementers to find out about parameter values is the purpose of IANA registries, and anything else is secondary.
I'd suggest:
My suggestion for the first paragraph
OLD:
NEW:
Something else that I think has got lost in the detail here is the role of registries in recording community consensus, or providing recommendations for values to be used as opposed just descriptions of options. This is part of what is at the heart of the permanent/provisional pattern. I guess this is a distinction between use by protocol designers ("we recommend you use these values") vs implementers ("what should my implementation do when it sees this value").
In considering the above, I recall your earlier #24 (comment):
I think the key ideas that need too be surfaced are: what can protocol designers do, when thinking about registry designs, to ensure their goals are not subverted by others who find the registration requirements too onerous? Having at most one way to do something is a key feature for aiding interoperability, which one hopes everyone buys into, and is one of the main purposes of registries.
Maybe some overview of our discussion, e.g. at #24 (comment), would usefully be surfaced earlier in the document?
The text was updated successfully, but these errors were encountered: