Subject: RE: FW: I-D ACTION:draft-ietf-ldapbis-iana-01.txt

From: "Timothy Hahn" <[email-masked]>
Date: Fri, 20 Apr 2001 14:37:43 -0400

Hi all,

I feel that changing OIDs but representing the SAME attribute type is a 
bad idea.  If there were one thing we were thinking we could "count on" 
was that IF and OID were assigned, then while the attribute type name 
might change, the OID wouldn't.

A different OID would represent a different attribute type/object 
class/syntax from my perspective.

Now, for standards track RFCs, sponsored by IETF workgroups, that are 
created from some point in time forward, it seems reasonable to me to 
require these to use OIDs that are managed/granted by an organization such 
as IANA.  We have all seen the trepidation that certain groups have had in 
having an IETF workgroup-sponsored RFC contain OIDs that were assigned by 
a private organization (I've seen this in the printers schema and the 
Kerberos schema as well).

I wouldn't go changing existing stuff though.  Once IANA is established as 
a place for document editors to go to get OIDs assigned, then lets 
recommend/require its use for IETF workgroup-sponsored RFCs.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 24 Apr 2001 11:13:20 +1000

I've noticed that the 4th edition of X.501 corrects a long standing defect
in the MatchingRuleDescription ASN.1 type. The MatchingRuleDescription
type mirrors the MATCHING-RULE information object class so that matching
rule definitions can be carried in protocol (information objects cannot
be encoded). The 2nd edition definition of the MATCHING-RULE information
object class allowed the assertion syntax (the SYNTAX field) to be omitted,
so that matching rules with a variable assertion syntax could be supported.
Unfortunately, the 2nd edition definition for MatchingRuleDescription had
the assertion syntax (the "information" field) as a mandatory component.
The 4th edition now makes the information field OPTIONAL, the way it
should have been in the first place.

The LDAP string encoding for the Matching Rule Description syntax adheres
to the flawed X.501 MatchingRuleDescription in making the SYNTAX field
a mandatory term. I'd like to see this corrected in the successor to
RFC 2252 to make the SYNTAX field an optional term.

The Adacel implementation has a number of private matching rules where
the assertion syntax is variable. In my component matching rules draft
I need to define additional rules that also have a variable assertion
syntax. At the moment I have no standard defined way to encode their
definitions as a value of the Matching Rule Description syntax.
The alternative is for me to define an LDAP syntax which is taken to
mean "a variable assertion syntax". Making the SYNTAX field optional
is a cleaner, more consistent, solution.

Comments ?

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Apr 2001 08:13:23 -0700

I think such a change might cause some interoperability
problems.  I note that both the OpenLDAP server and C SDK
treat matching rule's SYNTAX field as required.

The alternative, defining a "variable assertion syntax",
to me sounds like a reasonable approach to support the
desired functionality.

Kurt