[Anders Lund] > I think I'll have to talk to others here to give you a definitive > answer to this question, but this is mainly to give the schema a > "home" to stay together with where the OIDs have been allocated?
Yes. The idea is to give the common and static parts of the current DNS schemas, the attributes representing DNS record types, a common home for others to fetch a updated schema with all the attributes defined so far, to ensure naming, syntax and other attribute settings stay the same. > So basically what is needed is _one_ schema file. Defining the > attributes once and then at the end list both dNSZone and dNSDomain2 > object classes. Right? Actually, I would suggest to only define the attributes in the file distributed from Uninett, and leave the definition of the object classes to thers, as the people defining dNSZone and dNSDomain2 seem to change their definition over time as new dns record types are defined. This would make it possible for those defining the object types to include the attribute schema for the attributes and a different schema for the object classes, and users wanting to include both object classes to do so without conflicts. :) I guess the schema file name could be dnsattributes.schema or some thing like that, and it should include a time stamp and URL to the source of the latest version at the top of the file. :) > Sounds nice to me. I could perhaps ask others here if a fitting > place to have this schema distributed is via the OID registry page > at UNINETT. Does this sound ok to you? Great. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
