[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Object naming guidelines
At 02:17 PM 9/3/2003 -0400, Tim Moses wrote: >Colleagues - Here is a first draft of a proposal for naming objects in the >dss committee. This is much needed. Some comments - 0) The OASIS File Naming Document downloads fine at the moment [0], you mentioned it was broken earlier. We're pretty close, but we could be more adherent to it, as I point out below. 1) Do you intend version to be preceed with a "v"? The examples do so, but your draft itself isn't named this way. The OASIS document doesn't use a "v", so I'd say skip it. 2) The Requirements Draft (and your "object naming guidelines" draft) don't clearly have a "Part" attribute, since they apply to more than just "core". Could "Part" be omitted if not needed? - oasis-dss-1.0-requirements-wd-12 oasis-dss-1.0-object-naming-guidelines-wd-01 3) Instead of "cd" for committee draft, I think "cs" for committee spec is the more appropriate term. This is what SAML, XACML, and the OASIS doc use. 4) "wd", "cd" (or "cs"), and "os" aren't very descriptive. Looking at SAML's guidelines [1], they always use "draft" but differentiate between TC drafts (which have consensus) and individual drafts. The OASIS doc uses "draft" and "cs", and then says OASIS will assign the OASIS Standard name, so we can't control that. I think we could follow the OASIS doc, but also differentiate between TC and individual drafts: "draft" for TC drafts "draft-[person's last name]" for individual drafts "cs" for committee specs For example, we have 2 individual protocol schema drafts: oasis-dss-1.0-protocol-schema-draft-perrin-01 oasis-dss-1.0-protocol-schema-draft-carlos-01 We'd call the requirements (which is a TC draft): oasis-dss-1.0-requirements-draft-12 5) The OASIS doc places the "version" after the "object", so the requirements would become: oasis-dss-requirements-1.0-draft-12 Don't care much one way or the other, but it might be nice to be consistent with their doc. 6) I wouldn't mind dropping the "oasis", which would be more consistent with the OASIS doc and other TCs, I think. But this doesn't matter much. 7) OASIS has a URN namespace (see RFC 3121, or [2]). We are assigned "urn:oasis:names:tc:dss". Here's how SAML and XACML use it for their schemas: urn:oasis:names:tc:SAML:1.0:protocol urn:oasis:names:tc:SAML:1.0:assertion urn:oasis:names:tc:xacml:1.0:policy urn:oasis:names:tc:xacml:1.0:context I'm not sure how we want to arrange our schemas. We have protocols, and we also have the time-stamping and requestor identity elements. Frederick's outline of the core document assumes we might have 2 schemas, one for the protocols and one for the core elements, so a strawman might be something like: urn:oasis:names:tc:dss:1.0:protocol urn:oasis:names:tc:dss:1.0:elements (for time-stamp and requestor-identity elements) 8) Is there any point to specifying a URI format, if we have no control over it? 9) Once we finalize this, I'll rename and upload our docs, since I think that's the editor's job. Trevor [0] http://www.oasis-open.org/spectools/docs/chairs-filenaming-02.html [1] http://www.oasis-open.org/committees/security/docs/draft-sstc-doc-guidelines-02.txt [2] http://www.oasis-open.org/committees/guidelines.php#namespaces
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]