You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by el...@apache.org on 2019/01/14 23:01:42 UTC

svn commit: r1851306 - /directory/site/trunk/content/apacheds/features.mdtext

Author: elecharny
Date: Mon Jan 14 23:01:42 2019
New Revision: 1851306

URL: http://svn.apache.org/viewvc?rev=1851306&view=rev
Log:
Upatded the page: some typos, completed infos

Modified:
    directory/site/trunk/content/apacheds/features.mdtext

Modified: directory/site/trunk/content/apacheds/features.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/features.mdtext?rev=1851306&r1=1851305&r2=1851306&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/features.mdtext (original)
+++ directory/site/trunk/content/apacheds/features.mdtext Mon Jan 14 23:01:42 2019
@@ -67,9 +67,90 @@ Here's what we've assigned to date:
 | 1.3.6.1.4.1.18060.5 | Triplesec | Alex Karasulu |
 | 1.3.6.1.4.1.18060.10 | Hadoop | Owen O'Malley |
 | 1.3.6.1.4.1.18060.11 | Tomcat | Bernhard Unger |
-| 1.3.6.1.4.1.18060.12 | HTTPdvJoe Orton |
+| 1.3.6.1.4.1.18060.12 | HTTPd | Joe Orton |
 | 1.3.6.1.4.1.18060.14 | Synapse | Hiranya Jayathilaka |
 | 1.3.6.1.4.1.18060.15 | CloudStack | David Nalley |
 | 1.3.6.1.4.1.18060.16 | Apache Ambari | Paul Codding |
-| 1.3.6.1.4.1.18060.17 | Apache Fortress Shawn McKinney |
+| 1.3.6.1.4.1.18060.17 | Apache Fortress | Shawn McKinney |
 | 1.3.6.1.4.1.18060.18 | Apache Guacamole | Mike Jumper |
+
+
+Each contact person is the authority for assigning unique **OID** values and ranges to projects or persons. Contact that person for more assignments.
+
+
+## Making Assignments
+
+Contacts may wonder what scheme is best for making assignments. There is no rule for doing this. However some would recommend assigning the first digit past the enterprise number of an organization to be for identifying a protocol. Obviously we did not do this for **Apache**. The reason for this is because we feel it's better to model the assignments based on the structure of the organization since these are private ranges and need not conform to a global convention.
+
+However this still does not tell us how contacts should make assignments. I think this is up to you. Perhaps a good example will be how the **Directory** TLP does things which is somewhat specific to their products and the nature of their products.
+
+
+### Assignment Scheme For Apache Directory
+
+The ninth component in the **OID** could be reserved for subprojects like **ApacheDS** and **Triplesec**. This might be more attractive in TLPs with many subprojects because a single authority or contact can be used for a specific subproject. So here could be one assignment scheme:
+
+| Branch Assignement | Assign To |
+|:-:|:-:|
+| 1.3.6.1.4.1.18060.0.0 | ApacheDS |
+
+Here's how the ApacheDS OID is branched off:
+
+
+The ninth component in the **OID** could be reserved for subprojects like **ApacheDS** and **Triplesec**. This might be more attractive in TLPs with many subprojects because a single authority or contact can be used for a specific subproject. So here could be one assignment scheme:
+
+| Branch Assignement | Assign To |
+|:-:|:-:|
+| 1.3.6.1.4.1.18060.0.0 | ApacheDS LDAP Controls |
+| 1.3.6.1.4.1.18060.0.1 | ApacheDS LDAP Extended Operations |
+| 1.3.6.1.4.1.18060.0.2 | ApacheDS LDAP Supported Features |
+| 1.3.6.1.4.1.18060.0.3 | ApacheDS LDAP Protocol Mechanisms |
+| 1.3.6.1.4.1.18060.0.4 | ApacheDS LDAP Attribute Values |
+| 1.3.6.1.4.1.18060.0.4.X.0 | ApacheDS LDAP Schema syntaxes |
+| 1.3.6.1.4.1.18060.0.4.X.1 | ApacheDS LDAP Schema matchingRules |
+| 1.3.6.1.4.1.18060.0.4.X.2 | ApacheDS LDAP Schema attributeTypes |
+| 1.3.6.1.4.1.18060.0.4.X.3 | ApacheDS LDAP Schema objectClasses |
+| 1.3.6.1.4.1.18060.0.4.X.4 | ApacheDS LDAP Schema dITStructureRules |
+| 1.3.6.1.4.1.18060.0.4.X.5 | ApacheDS LDAP Schema nameForms |
+
+
+where **X** is a unique number associated with one of the specific **ApacheDS** schema.
+
+NOTE: _dITContentRules_ do not have their own OID, rather they reference the **OID** of the structural _objectClass_ they influence. The same sort of situation exists for _matchingRuleUse_ which uses the **OID** of the _matchingRule_ it is associated with.
+
+And here are the schema **OID**s (where the **X** is substituted by the proper number):
+
+
+| Branch Assignement | Assign To |
+|:-:|:-:|
+| 1.3.6.1.4.1.18060.0.4.0 | ApacheDS LDAP Meta Schema |
+| 1.3.6.1.4.1.18060.0.4.1 | ApacheDS LDAP Apache Schema |
+| 1.3.6.1.4.1.18060.0.4.2 | ApacheDS LDAP Apache DNS Schema |
+| 1.3.6.1.4.1.18060.0.4.3 | Apache Directory Documentation Examples Schema |
+| 1.3.6.1.4.1.18060.0.4.4 | Quartz Schema |
+| 1.3.6.1.4.1.18060.0.4.5 | Bean Schema |
+
+(Some of those schema are long gone, but the assignement is still existing)
+
+
+### OID's for ApacheDS specific controls
+
+Here are the new **OID**s used:
+
+| OID | Control |
+|:-:|:-:|
+| 1.3.6.1.4.1.18060.0.0.1 | Cascade Control |
+
+### OID's for the extended operations
+
+Here are the new **OID**s used:
+
+| OID | Extended Operation |
+|:-:|:-:|
+| 1.3.6.1.4.1.18060.0.1.1 | LaunchDiagnosticUiRequest |
+| 1.3.6.1.4.1.18060.0.1.2 | LaunchDiagnosticUiResponse |
+| 1.3.6.1.4.1.18060.0.1.3 | GracefulShutdownRequest |
+| 1.3.6.1.4.1.18060.0.1.4 | GracefulShutdownResponse |
+| 1.3.6.1.4.1.18060.0.1.5 | GracefulDisconnect |
+| 1.3.6.1.4.1.18060.0.1.6 | StoredProcedureRequest |
+| 1.3.6.1.4.1.18060.0.1.7 | StoredProcedureResponse |
+