From wiki.gpii
Jump to: navigation, search

Text in BLUE and marked with ### is retrieved from ISO/IEC 24800-2:2011(E)

Text in RED and marked with @@@ is retrieved from ISO/IEC 24727-6:2010(E)

Text in GREEN and marked with &&& is ours



2. Normative References

3. Terms and definitions * Used in this document

4. Symbols and abbreviations used

5. General

6. Appointment of the registration authority

7. Review of applications 

7.1 Process

The HOST shall create and maintain the process for accepting and maintaining the REGISTRY in compliance with the following.

There shall be an application processes for new entries and a process for nominating TERMS to become CERTIFIED that are established and posted by link from on the home page of the REGISTRY.

The processing including acceptance or rejection of new REGULAR entries shall be carried out promptly with 80% or greater completed within 20 working day and all processed within 60 working days.

[LN] I think that there should be terms, and recommended terms. The recommended terms would be ones that the HOST or its nominated cttee has decided are stable, useful, etc. 'Certified' is much too heavy and if the cttee wants to change to recommend a better term later on, it will be a bit more difficult to 'uncertify' a term. I think that recommended terms could form a common 'application profile' that would be the first thing that a new group might work with, before modifying it to suit their purposes etc. I think that it is also very important that we make sure that the 'recommended terms' are in synch with terms being promoted by schema.org, etc. not just because they are our terms that are used a lot, etc...

7.2  Types of Entries

There shall be three types of entries in the REGISTRY

    • All new entries shall be REGULAR entries. All entries that are not CERTIFIED or APPLICATION UNIQUE are REGULAR TERMS.
    • TERMs are promoted to CERTIFIED by the Oversight Committee based on the following criteria
      • Uniqueness (not overlapping with another CERTIFIED TERM
      • Stability (not likely to be changed)
      • Usage of term (most used overall or within a domain)

[LN] Elegance is always a virtue! There is no need for a name for terms that are terms. Once a term is recognised as special, as I would say suitable for 'recommendation', it could be called a recommended term. Application specific terms need to be differentiated from terms in an application profile ie terms that are vendor/application specific may need a name - but it might be helpful to avoid the use of the word 'application' in this context because it could easily be confused with 'application profile' which is used to describe a set of terms that a group recommends. [LN] Where there are duplicates, such as where a vendor wants to use an existing term's concept but give it a different name because they use a different name, it should be possible to simply add the extra name to the existing term. There should not be a duplication of the term... Note that the MLR has been designed to make it possible for terms to have multiple names, in multiple languages, without repetition of the concept. in other words, we should be registering concepts and letting people add names for them - not thinking of multiple terms that are the same.....

7.2 Acceptance Criteria

 An application is always accepted unless one or more of these situations occur:

  • The applicant is not a person or organization with whom reliable communication can be established.   
  • The information in the application is incomplete, incomprehensible or incompatible with the purpose of the registry (e.g. spam).

[LN] I suggest we don't make it that there is an application process so much as that there is a registration process and then review by a cttee. This way, people would register terms, the process would notify the cttee, and the cttee could ratify or veto the registration - so it would be that after registration, within one month, the term must be considered by the cttee.

7.4 Notification process

Details of the successful application shall be recorded in the CT REGISTRY by the HOST, and the applicant shall be informed of the TERM registered and its URI.

If rejected, the applicant will be informed of the rejection and the reason why, as well as the standing instructions on how to create a valid entry, and the appeal process.

[LN] If we have registration and ratification/veto, then there would simply be making the term live, a not to the proposer, if they are known (and I think we decided that we want to decide if it's a good term, not worry about who it came from so even if we don't know the proposer we could have the term), and maybe people can be on an email list to get notification of new terms? That way, people with older terms could sort of 'defend them - thinking now, the proposers of old terms might be interested in new ones, so perhaps the general public could register for an email list that tells them of new proposals, and one that talks of what's accepted, and then we might get some good and valuable discussion from the community when new terms come up? This would surely help the cttee in its review process, as well?

7.5 Oversight and Appeals

how to compose the oversight committee so that it

  • includes real users of the registry
  • prevents abuse by commercial (or ideological) concerns  
  • is representative of different languages/cultures

[LN] I think the DCMI made some big mistakes because they appointed people to make decisions and those people were not always the best people to make those decisions. It is very important, IMHO, that we engage the community and that if there is discussion and a term rejected, or accepted contrary to people's ideas, there appeal process should also be open. Not sure how to do this other than have open involvement from the community in the process.

7.6 Assignment of identifiers

The review process and syntax ensure that the assigned ID is unique within the CT REGISTRY and that the same ID is not assigned to another TERM. After the assignment has been made, the ID and associated information shall be included in the CT REGISTRY and JPSRA shall inform the user of the assignment.

The JPSRA definition shall be recorded in the registry at the time when the ID is assigned.

[LN]Identifiers should be URIs and there should be an automated process for creating them. There are an infinite number available so this is a simple technical problem. It is important to note here that when a word appears in an URI, such as http://wordlist/accessmode, it should be understood that the word is actually non-linguistic. This is very important, technical, and pretty much incontrovertible!!!

7.4 Maintenance


For the purpose of maintenance of the registry, the JPSRA shall implement mechanisms for maintaining the integrity of registry including adequate backup for retaining records.

An ID owner may update the associated schema and translation rules through a Request of Replace.

A user can request information about registered schemas and translation rules through a Request for Registered Information.

7.6 Appeals

8. Content of application

8.1 General


Information required by the RA to conduct the registration process may be submitted by e-mail, facsimile, compact disk or paper copy, or (should the RA chooses to support these options) as a Web-based form or using Web Services protocols. Additional information regarding obligations of the applicants and information regarding applicable laws are contained in the conditions for application of the Registration Authority.

8.2 Applicantions


The application shall include all the information required by Annexes A, B and C for AP registration and Annex D for AP adoption registration including associated requirements stated in those annexes for the inclusion of documents, indemnities and diagrams.

For AP registration the application forms collect the following information:

  1. contact and commercial identification information of the applicant;
  2. a completed authentication-protocol-template (derived from ISO/IEC 24727-3 Annex A and B) populated with specific details of the authentication protocol proposed and cryptographic algorithms supported;
  3. intellectual property details of the applicant and the AP including patent country and patent number and ownership;
  4. an authentication-protocol-test-plan (APTP) populated with specific details required to test the proposed AP according to ISO/IEC 24727-5 [to be published];
  5. the Certification form, see Annex C;
  6. other comments the applicant requires for publication.

For AP adoption registration the application form collects the following information:

  1. contact and commercial information of the applicant;
  2. name of the operation, specification, standard or recommendation which uses the RAP OID;
  3. the RAP OID to be used;
  4. the cryptographic algorithms supported;
  5. the ISO/IEC 24727-4 Stack Model supported;
  6. other comments the applicant requires for publication.

8.3 Maitenance of a web-based register


The RA shall maintain two registers to include the following:

  • registered authentication protocol including the registered OID;
  • a register of authentication-protocol-adoption including the OID adopted.

Each entry shall give the identifier information, together with a link to the full details provided in the approved application with the exception of payment related information and signatures.

The RA shall provide a website which displays the contents of the registers. The RA shall be responsible for determining the internal procedures necessary for the maintenance of the register in a timely and appropriate manner.

The RA provides annual reports to the ISO/IEC JTC1/SC 17 Sub-Committee and ISO Secretariat. These are available by request from the Sub-Committee.

9. References for setting up a Registry