[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] draft-zeilenga-ldap-readentry-03.txt
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: [ldapext] draft-zeilenga-ldap-readentry-03.txt
- From: Andrew Sciberras <andrew.sciberras@eB2Bcom.com>
- Date: Wed, 27 Oct 2004 08:52:57 +1000
- Cc: Ldapext <ldapext@ietf.org>
- Organization: eB2Bcom
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
Hi Kurt,
Section 1.
"The extension utilizes controls [Protocol] attached update
requests to request and return copies of the target entry."
Insert a 'to' between 'attached' and 'update'.
Now, the last thing I want to do is get into a discussion about the
criticality of controls, since we've been over this a number of times.
However, two statements exist which leave me puzzled:
"The normal processing of the update operation and the processing of
this control MUST be performed as one atomic action isolated from
other update operations."
"The criticality may be TRUE or FALSE."
So, the operation MUST be atomic and the control may have a criticality
of FALSE.
What would happen if a DSA received a modifyRequest with a controlType
whose value is IANA-ASSIGNED-OID.1 and a controlValue of an empty OCTET
STRING and a criticality of FALSE?
The DSA:
* recognizes the control (and supports it),
* is aware of the atomic nature of this request,
* cannot decode the controlValue
* Can rightfully ignore the control since it's not critical
Does the DSA fail the operation (for atomic reasons) or proceed (based
on the criticality)?
I don't know the right answer... but would be inclined to state that
this control should not change the LDAP semantics of the criticality
field of the control and therefore continue processing.
Cheers,
_________________________________________
Andrew Sciberras
eB2Bcom - Software Engineer
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext