FriendlyRegistryProcess
Review
What level of review is appropriate?
Emphasis should be on community review/input, NOT gatekeeping. Expert reviewer, where specified, should act as a shepherd.
- draft-freed-media-type-regs: ✔ (ref)
- draft-ietf-iri-4395bis: ✖
- RFC3864: ✖
- RFC5988: ✖
Provisional Registration
How are preliminary / "stub" registrations handled? E.g., to "hold" an entry.
Each registry should establish a "provisional" state. Bar to registration of this state should be MUCH lower, probably just a sanity/spam check by the expert reviewer.
Need to discuss whether provisional registration is necessary in all cases.
X- Registration
How are x- (or synonymous) registrations handled?
Should be allowed for widely deployed, but discouraged for new elements.
- draft-freed-media-type-regs: ✔ (ref)
- draft-ietf-iri-4395bis: ✖ (not explicitly addressed)
- RFC3864: ✖ (not explicitly addressed)
- RFC5988: ✖ (not explicitly addressed)
Third-Party Registration
How should parameters in wide use that aren't registered be handled?
Third parties should be allowed to register widely-used parameters, as long as ownership remains with appropriate parties.
- draft-freed-media-type-regs: ✔ (ref)
- draft-ietf-iri-4395bis: ✔ (ref)
- RFC3864: ✖ (not explicitly addressed)
- RFC5988: ✔ (ref)
Third parties should be allowed to annotate, comment on, or supply additional material that wasn't supplied in the original registration. For example, adding or correcting "magic number" or "fragment identifier" information in media types, while leaving the main registration material alone.
Contact Changes
What if a responsible party changes contacts, dies, etc.?
Contact changes should be able to be handled without bothering the IESG or expert.
- draft-freed-media-type-regs: ✔ (ref)
- draft-ietf-iri-4395bis: ✖ (not explicitly addressed)
- RFC3864: ✖ (not explicitly addressed)
- RFC5988: ✖ (not explicitly addressed)
Can the 'contact' be an organization, role, mailing list, and not an individual?
Organizations often have difficulty finding someone who is _personally_ responsible for the registration in the future, or to whom they are willing to grant long-term authority to make changes to registered values.
Technical Changes
What if the underlying specification changes or needs updates?
Technical changes should go through the same process required for the original registration.
- draft-freed-media-type-regs: ✔ (ref)
- draft-ietf-iri-4395bis: ✔ (ref)
- RFC3864: ✔ (ref)
- RFC5988: ✖ (not explicitly addressed)
Annotations
What if different communities / users have application- or implementation- specific information that's relevant? Registries should accommodate annotations / comments. If they are anticipated to be extensive, more specific registry fields (or sub-registries) should be established.
- draft-freed-media-type-regs: ✔ (ref)
- draft-ietf-iri-4395bis: ✖
- RFC3864: ✖
- RFC5988: ✔ (see 'appdata'; likely needs changes/elaboration)
Appeal Process
What happens when someone is unhappy?
Appeal processes need to be documented, with possible outcomes, timelines and points of contact (e.g., e-mail addresses). Often, it'll be the IESG.
- draft-freed-media-type-regs: ✔ (ref)
- draft-ietf-iri-4395bis: ✔ (ref)
- RFC3864: ✔ (ref)
- RFC5988: ✔ (ref)
Some need more information (e.g., contact details)
Deprecation
How are registry entries that are no longer in use handled?
Each registry should establish a "historic" state.
- draft-freed-media-type-regs: ✔ (uses "OBSOLETE")
- draft-ietf-iri-4395bis: ✔ (ref)
- RFC3864: ✔ (ref; no specific procedure for moving to historic)
- RFC5988: ✖ (not explicitly addressed)
Single Registry
How should the registry be presented?
All registries should be available in a single/combined view; i.e., holding all states (provisional, historic, etc.).
- draft-freed-media-type-regs: ✔
- draft-ietf-iri-4395bis: ✖ (ref; on same page, but separated by status)
- RFC3864: ✖
- RFC5988: ✔
Copyright
What copyright commitments should be made?
- draft-freed-media-type-regs:
- draft-ietf-iri-4395bis:
- RFC3864:
- RFC5988: