FriendlyRegistryProcess

From W3C Wiki

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.

  • draft-freed-media-type-regs: ✖
  • draft-ietf-iri-4395bis: ✔ (ref)
  • RFC3864: ✔ (ref)
  • RFC5988: ✖

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: