Subject: RE: CIM24 schema tweaks

From: "Quevedo, Felix" <[email-masked]>
Date: Thu, 30 Nov 2000 16:10:49 -0000

In the same DSP0117 spec there is also an issue with DITContentRules. It
uses the MAY term to indicate that an entry "may attach" an auxiliary class.
Per ye olde ITU X.501, the AUX term may be more appropriate, as done in
DSP0101. Or maybe not?

Then again, IETF RFC 2252 does not detail a ditContentRules BNF.
Félix E Quevedo
? Smile, everything is possible!
E-Mail: [email-masked]
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	Larry S. Bartz [mailto:[email-masked]] 
Sent:	Thursday, November 30, 2000 07:42
To:	IETF Policy WG LIST
Cc:	LIST, DEN discussion; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject:	CIM24 schema tweaks

 << File: tweakedCIM24schema.txt >> My previous message on this subject was
mishandled by my mailer,
resulting in severe truncation. Here's a retry:

I have encountered some difficulties implementing the CIM v2.4 
schema, as described in the DSP0117 documents at
http://www.dmtf.org/spec/denh.html .

Since the IETF Policy WG's draft-ietf-policy-core-schema-08.txt depends 
upon the cim24 schema, experimental implementers of "schema-08" may find 
the following comments and attached edited ABNF helpful.

I am also sharing these comments with the DMTF's WG chairs and CIM
support e-mail addresses. I request that these comments be forwarded
to the appropriate individuals for review.

 - DESC - Some Directory products enforce a length limit on the 
   DESC terms of objectclass and attributeType descriptions. X.501 
   defines the limit as {ub-schema}. Annex C of X.520 defines
   {ub-schema} as 1024. DESC term values which exceed 1024 characters 
   violate this limit. Several of the descriptions in DSP0117 contain 
   DESC term values which exceed 1024 characters in length. 

 - Matching Rules - Many of the attribute descriptions in DSP0117 
   have no matching rule terms specified. The attachment nominates 
   matching rule terms where appropriate, with comments designated by 
   #LSB.

 - Unspecified Attributes - Several attribute types are nominated by
   objectClass descriptions but which have not been defined. These
   include three whose names begin with "dlmHelperRefTo...". Based on 
   a presumption that other previously-defined attributes were intended, 
   the attachment substitutes defined attribute names for those which 
   are not defined, with comments designated by #LSB.

 - Forward references precluded - The attachment relocates entries 
   in the file to avoid forward references.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  [email-masked]      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

---

From: <[email-masked]>
Date: Fri, 1 Dec 2000 23:36:06 -0500

Mark-

I realize that but doesn't, that sort of put the cart
before the horse, by creating an implementation barrier?

Thinking about it, I suppose the document could define
a new matching rule and say "in case your directory
implementation doesn't support this you can use <blah>",
but I was looking for what <blah> could be besides
caseIgnoreMatch.

Ryan

---- Original message ----
>Date: Fri, 01 Dec 2000 18:21:05 -0800
>From: Mark Wahl <[email-masked]>
>Subject: Re: CIM24 schema tweaks
>To: [email-masked]
>Cc: "Larry S. Bartz" <[email-masked]>, 
"Quevedo Felix" <[email-masked]>, IETF Policy WG LIST 
<[email-masked]>, [email-masked], 
[email-masked]
>
>[email-masked] wrote:
>> 
>
>> 
>> Well, as an editor, I get to play the "no complaints 
without
>> making a suggestion" card.  What do you suggest as the
>> equality match?  Based on my reading of the X.500-series 
and
>> LDAP RFCs the only option for Directory Strings is
>> caseIgnoreMatch, and I'm not at all comfortable with
>> declaring that as the matching rule for a syntax that holds
>> UTF-8 strings.
>
>There can be other matching rules for Directory String syntax 
>attributes besides case ignore.  Case ignore is just the most 
>common.  You can have a Case Sensitive, or other more complex
>ones if you define them.
>
>Mark Wahl
>Sun Microsystems Inc.

---

From: "Quevedo, Felix" <[email-masked]>
Date: Sat, 2 Dec 2000 13:15:21 -0000

All,

Interesting... Having the opportunity to be at the directory server vendor
side, and now as a server user,  I do believe the spec work has been
wonderful. Functional inter-operations are possible thanks to the effort.
Schema inter-operations... we are not there yet.

We all know there could be many implementations, but only one (one hopes)
guideline/recommendation/standard document. It would be a daunting task to
cover all possible interpretations (implementations). This may be beyond the
scope of the spec. 

To all of this we should also consider the limitations of the underlining
technology on which that implementation is based on. Is there a Directory
server that supports near 100% the LDAP spec? Maybe. Is it the one we all
use? Sure not.

Let's take MS ActiveDirectory (pardon the example). It does not support
multiple names or attribute superiors or matching rules or ... It does
however have other features like LinkID's to define relationships. So we
have to take the spec and "adjust" it to the technology. Who should do it?
The developer? The vendor? The spec editor?

The industry is hungry for guidance from the standard bodies. Not
necessarily the ultimate solution.

Thanks to all!!
Félix E Quevedo
:) Smile, everything is possible!
E-Mail: [email-masked]
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, December 01, 2000 23:36
To:	Mark Wahl
Cc:	Larry S. Bartz; Quevedo Felix; IETF Policy WG LIST;
[email-masked]; [email-masked]
Subject:	Re: CIM24 schema tweaks

Mark-

Ryan

---- Original message ----
without
and