RE: some suggested changes to the specs...

[Chris Weider <cweider@xxxxxxxxxxxxx>]

One comment below...
Chris

> -----Original Message-----
> From:	Michael Mealling [SMTP:michael@xxxxxxxxxxxxxxxx]
> Sent:	Thursday, October 16, 1997 5:26 PM
> To:	ietf-schema-reg@xxxxxxx
> Subject:	some suggested changes to the specs...
> 
> Hi all!
> 
> After being out of touch for a few weeks and seeing what came out of
> the discussions I missed I had a few nits to pick. I always hate it
> when a discussion gets re-opened so if I'm out of line please let me
> know.
> 
> The first nit was that we had gotten away from allowing arbitrary 
> representations of a schema. I'm not suggesting that the listing
> service
> need to understand arbitrary representations, just be able to store
> and
> return them on request. My concern was that if we required everyone
> to translate their schema's into and back out of the MIME-DIR version
> that
> it would be too high a barrier for adoption.
	[Chris Weider]  Ah, but without some recommended schema we're
allowing folks to register any old crap whether it's useful or not.


> My suggestion was that we still require our 'common' representation
> but
> that the registering entity be able to include in the submittal other
> files along with their file type. As someone who hopes to help out
> with the implementation this seems fairly easy to implement.
> 
> The other concerns the relationship between the OID and the version
> number. It seemed to me that the version number could just as easily
> been part of the OID. The problem was that the OID specified was
> the one given to the registry by the submitter. This meant that if
> the registry tried to muck with the OID that it would walk on the
> toes of the schema owner's subtrees.
> 
> My solution was to have two OIDs if necessary. E.g.  LDAP calls 
> Vcard '1.3.6.1.4.1.2309.1.1.1.1'. MIME-DIR calls it 'vcard'. Both
> are what each application-area/protocol uses for a name. The registry
> doesn't have any control over those which is dangerous because it
> can't
> manage them or gaurantee uniqueness. Thus we cause the registry
> to create a unique-id for it. As far as the registry is concerned this
> 
> unique-id is the real _name_.
> 
> Here's the example:
> 
> Vcard is registered. In the metadata we say that its known as 
> '1.3.6.1.4.1.2309.1.1.1.1' via LDAP and 'vcard' via MIME-DIR. The
> registry creates a new unique-id which is itself an OID. Its just
> that its kind of flat because its just the part of the tree that 
> the registry uses. E.g. we get a subtree from the IANA and create
> numbers underneath it like this:
> 
> <iana-subtree>.1 becomes the listing service _name_ for Vcard.
> 
> LDAP and X.500 shouldn't care because they can't create new subtrees
> under our subtree. No collisions and we get to dictate revision terms.
> I'd do something like this:
> <iana-subtree>.x.y
> 
> where:
> x = listing sequence number
> y = listing version number
> 
> This way if the entity that registered says that its a child and not
> a peer we iterate the version number. If they consider a wholly new
> thing then we gen the sequence number. It's really up to them
> anyway...
> 
> This gives us a directory structure that looks like this:
> 
> schema-repository/1/schema.ldif
> schema-repository/1/schema.xml
> schema-repository/1/schema.mdl
> schema-repository/1/schema.metadata
> schema-repository/1.1/schema.ldif
> schema-repository/1.1/schema.metadata
> schema-repository/2/schema.ldif
> schema-repository/2/schema.html
> schema-repository/2/schema.metadata
> 
> You could even turn the dots into directories and further seperate
> them...
> What the actual filename is doesn't matter. The 'schema' part looks
> kind of redundant doesn't it.
> 
> Comments?
> 
> -MM
> -- 
> ----------------------------------------------------------------------
> --------
> Michael Mealling	| 505 Huntmar Park Drive       | Phone:
> (703)742-0400
> Software Engineer	| Herndon, VA 22070	       | Fax:
> (703)742-9552
> Network Solutions	| <URL:http://www.netsol.com>  |
> michaelm@xxxxxxxxxx