2.1.28 Schema Registration (schema) BOF

Minutes of the Schema Registration BOF

Reported by John Strassner


I. Bash the charter
II. Current Holes in the Schema Listing Requirements Document (Chris Apple)
III. Discussion of Open Issues
IV. Action Items

I. Discussion of Charter

There were no problems with the charter.

II. Schema Listing Requirements Document

Holes in the document that need to be patched:

· Doesn't match Scott Bradner's requirement terminology.
· Security considerations.
· The philosophy of unlimited read and tightly controlled write needs to be spelled out in the document.

Other issues resolved:

· Syntax specs should be BNF.
· Localized versions of the schema should be made available and should be pointed to by the main schema. This includes language tags.
· OIDs will be used to uniquely identify schema.
· A question about two competing requests (i.e.. same names, but different content) came up. This should be handled in a separate process document. However, since the service will be assigning OIDs to the schema, each schema will have a unique name.
· Does a change in the machine-readable portion of a schema require a rev of the entire schema? YES.
· The schema listing file name for a given schema will be the last component of the OID assigned to that schema. We should not include any other human semantics in the file name.
· Again, this is a listing service, not a vetting service. Schema standardization will happen after schemas are listed.
· We will be adding a usage scenario section to the document.
· We will be selecting one syntax as a required syntax for the service and will add two more if we can get the parsers. The three agreed upon by the group are LDIF, ASN.1, and XML. We'll do a small list poll for the required one.
· We will be requiring FTP and HTTP access to the repository.

III. Open Issues

· Should any document that specifies schema be allowed to be registered? This is an issue for the list.
· Who owns the database? Who runs it? This will be discussed as we get closer to the process document.
· Do we need to track and forbid display name collision of schema and attributes? For example, two people trying to register the 'Person' schema although they have different OIDs?
· Should the listing service be searchable? We need to decide whether it is, and if so, what engine would be used. There are also the matters of UI and complexity of the interface.
· Can this service be tied into the URN infrastructure?
· For January 1, 1998, should we allow machine submission of schema? We are leaning towards NO but will take to the list.
· Which, if any, of the submitted schema will be made into RFCs?
· Should schema be signed so that people can verify that their schemas are indeed the ones that they sent? Which signature algorithm should be used?
· Do we store metaschema (i.e., schema not tied to any protocol, such as the Dublin Core). If so, how? How do we tie them to their expressions in various protocols?
· What character sets should we support? How do we support them?
· What are the required metadata elements for a schema listing?
· Should we push for LDAP and SMTP access to the repository for January 1?
· How do we control versioning?
· Can we provide an automated submission process for January 1?
· Is the store moderated to avoid BadGuy(tm) or StupidGuy(tm) attacks? One general rule is that we could agree that unsigned schema are automatically rejected.

IV. Action Items

a) Change the acronym of the working group so that it doesn't contain the name schema..
b) Put together the engineering team. Volunteers are:

c) Rev the document and start the list discussions. We will cut off list discussion no later than 15 September to insure that the engineering team has everything it needs.

Attendees List

go to list

Previous PageNext Page