Subject: Match rule to dereference pointers

From: "David Chadwick" <[email-masked]>
Date: Mon, 25 Oct 1999 15:41:32 +0100

Ryan et al

I have been reading your ID and trying to puzzle out your schema 
and syntax, and how it fits in with the existing LDAPv3 specs. I cant 
quite make it all fit together. Here are my problems:

i) Your dereferencingMatch rule has a syntax of ....12, which means 
a DN. Hence, according to my understanding, user presented 
values must be DNs. But yours do not appear to be, but rather the 
user presented values seem to be filters. Therefore you need to 
define a new LDAPv3 attribute syntax for filter, and allocate it an 
OID. YOu will need to liaise with Mark Wahl about the next available 
OID number in the series.

ii) When you use extensibleMatch, then according to RFC 2254 the 
first component should be the attribute type to be matched on (first 
alternative of two possible ones). Again your examples do not seem 
to be an attribute type, but rather they have the string targetDN as 
the attribute type. Therefore can I suggest as a minimum that you  
define a new dummy attribute type of targetDN and give it an OID, 
and give it the appropriate semantics.

Your spec should then be more consistent with the current LDAPv3 
specs

Regards

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "Ryan Moats" <[email-masked]>
Date: Mon, 25 Oct 1999 10:14:38 -0500

David-

I've seen your other mail, and I just haven't had a chance to
respond to it, but maybe this will poke me :-(...

| Ryan et al
| 
| I have been reading your ID and trying to puzzle out your schema 
| and syntax, and how it fits in with the existing LDAPv3 specs. I cant 
| quite make it all fit together. Here are my problems:
| 
| i) Your dereferencingMatch rule has a syntax of ....12, which means 
| a DN. Hence, according to my understanding, user presented 
| values must be DNs. But yours do not appear to be, but rather the 
| user presented values seem to be filters. Therefore you need to 
| define a new LDAPv3 attribute syntax for filter, and allocate it an 
| OID. YOu will need to liaise with Mark Wahl about the next available 
| OID number in the series.

I'll have to revisit that part of the draft, but if what you are saying
is correct, then yes, we definitely have to change it.  Thanks for
the comment...

| ii) When you use extensibleMatch, then according to RFC 2254 the 
| first component should be the attribute type to be matched on (first 
| alternative of two possible ones). Again your examples do not seem 
| to be an attribute type, but rather they have the string targetDN as 
| the attribute type. Therefore can I suggest as a minimum that you  
| define a new dummy attribute type of targetDN and give it an OID, 
| and give it the appropriate semantics.

As per your other mail, I will ignore this...

Ryan