View source for FriendlyRegistries

= Friendly Registries =

This is the workspace of a cross-IETF/W3C group whose aim is to make registries more usable for Web-related purposes - especially by non-"insiders".

The registries we'll focus on are:

* URI/IRI Schemes - [http://tools.ietf.org/html/rfc4395 RFC4395], [http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg draft-ietf-iri-4395bis-irireg]
* Media Types - [http://tools.ietf.org/html/rfc4288 RFC4288], [http://tools.ietf.org/html/draft-freed-media-type-regs draft-freed-media-type-regs]
* Link Relations - [http://tools.ietf.org/html/rfc5988 RFC5988]
* HTTP Headers - [http://tools.ietf.org/html/rfc3864 RFC3864]

Discussion takes place on the [https://www.ietf.org/mailman/listinfo/happiana happiana mailing list]; all are welcome, as long as it's on-topic.

== Related Work ==

* Masinter draft (and discussed with W3C TAG): http://tools.ietf.org/html/draft-masinter-mime-web-info
* http://tools.ietf.org/html/draft-nottingham-appsawg-happiana

== Work Items ==

We're focusing our efforts in three general areas. These are somewhat general issues and suggestions now; they will become more specific as work progresses.

=== Single Source of Truth ===

Many of the issues around IANA for people who aren't familiar with it (and some who are) is finding out the status of a request, who is responsible for or blocking it, who to contact, etc.

For example, depending upon the registry in question, it might require touching IANA, Expert Reviewers, a community review list, and the IESG. 

We can greatly improve usability and reduce confusion by:

* Making the IANA tracker externally visible.
* Extending the IANA tracker for use by expert reviewers and the IESG, so that the entire workflow is captured in one place.
* Surface registration requests VERY early in the process on the registry page (e.g., with a "request in process" status)

=== Clear Process ===

The expectations upon all of the parties involved (requestors, expert reviewers, IANA, IESG) are not always clearly stated; sometimes they are left to institutional memory, or not stated from the viewpoint of the involved party. By clarifying and (where appropriate) harmonising the processes and language used, we can improve registry usability. This includes:

* Clarify workflow (including exceptions), SLAs, escalation procedures and points of contact
* Clarify the role of expert reviewers, and the criteria they apply (i.e., ERs are there to facilitate registration, not act as architectural gatekeepers)
* Make registration procedures / contacts / requirements / guidelines available in a user-friendly format (NOT just an RFC) linked from the registry page. E.g., give each registry some wiki space linked from its registry page.

See [[FriendlyRegistryProcess]] for details.

==== FAQs ====

A wiki-page of FAQs for each registry might handle a lot of the difficulties we've seen so far, clearly linked from the registry in question.

E.g.
Maybe a common list of FAQs to get this started; e.g.

* Who can register a <foo>?
* What are the requirements for registering a <foo>?
* Where should I send my request to register <foo>?
* What happens next?
* Who should I contact if I'm not happy with a response to my request?
* Who has the final say about any registration request?
* What do I do if I think there is an error in a registration?
* How do I update a registration?
* (How) can I add a comment to a registration?

As a wiki, it can be updated to reflect experience, creating an institutional memory for all to see.

There's a sample under development for the message header registry at http://trac.tools.ietf.org/area/app/trac/wiki/MessageHeaderRegistration.

=== Low Impact Process ===

The rigidity of the current processes currently can discourage registrations, and use of the registry itself. We can encourage use by:

* Introducing lightweight procedures for modifying specification addresses, change controller contact details
* Introducing lightweight procedures to mark entries deprecated / historic
* Revise current inter-SDO registration procedures to decouple ancillary information about registrations from other organizations' specs
* Introducing a "default-approve" version of the designated expert process (and use that for the rel type registry)