Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

update references to RFCs

  • Loading branch information...
commit de44519960d46a8660d77a87c2730c81fe032c4c 1 parent 150c715
@marschap marschap authored
View
2  lib/Net/LDAP.pod
@@ -855,7 +855,7 @@ certificate. See the IO::Socket::SSL documentation for information
about this class.
For example, to get the subject name (in a peculiar OpenSSL-specific
-format, different from RFC 1779 and RFC 2253) from the server's
+format, different from RFC 1779 and RFC 4514) from the server's
certificate, do this:
print "Subject DN: " . $ldaps->certificate->subject_name . "\n";
View
2  lib/Net/LDAP/Extension/SetPassword.pm
@@ -89,7 +89,7 @@ OPTIONS is a list of key/value pairs. The following keys are recognized:
If present, this option contains the octet string representation of the
user associated with the request. Depending on how users are identified
-in the directory this string may or may not be a DN according to RFC 2253.
+in the directory this string may or may not be a DN according to RFC 4514.
If this option is not present, the request acts up upon the password
of the user currently associated with the LDAP session.
View
6 lib/Net/LDAP/FAQ.pod
@@ -391,7 +391,7 @@ another server.
A continuation reference is returned when B<part> of the operation must be
resent to another server.
-See RFC 2251 section 4.5.3 for more details.
+See RFC 4511 section 4.5.3 for more details.
=head1 PERL-LDAP INSTALLATION
@@ -931,12 +931,12 @@ rule which is defined for the member attribute.
Asking for (member=c*) is not OK - there is no defined substring
matching rule for the member attribute. That's because the member
values are *not* strings, but distinguished names. There is no
-substring matching rule for DNs, see RFC 2256 section 5.50.
+substring matching rule for DNs, see RFC 4519 section 2.7.
What you have to do is get the results of (member=*) and then select
the required results from the returned values. You need to do this
using knowledge of the string representation of DNs defined in RFC
-2253, which is important because the same DN can have different string
+4514, which is important because the same DN can have different string
representations. So you need to perform some canonicalization if you
want to be correct.
View
10 lib/Net/LDAP/Filter.pod
@@ -45,8 +45,8 @@ selected output handle if FH is not given.
=head1 FILTER SYNTAX
-Below is the syntax for a filter given in
-RFC-2254 http://www.ietf.org/rfc/rfc2254.txt
+Below is the syntax for a filter given in RFC 4515
+http://www.ietf.org/rfc/rfc4515.txt
filter = "(" filtercomp ")"
filtercomp = and / or / not / item
@@ -68,9 +68,9 @@ RFC-2254 http://www.ietf.org/rfc/rfc2254.txt
initial = value
any = "*" *(value "*")
final = value
- attr = AttributeDescription from Section 4.1.5 of RFC-2251
- matchingrule = MatchingRuleId from Section 4.1.9 of RFC-2251
- value = AttributeValue from Section 4.1.6 of RFC-2251
+ attr = AttributeDescription from Section 4.1.4 of RFC 4511
+ matchingrule = MatchingRuleId from Section 4.1.8 of RFC 4511
+ value = AttributeValue from Section 4.1.5 of RFC 4511
Special Character encodings
View
2  lib/Net/LDAP/Schema.pod
@@ -35,7 +35,7 @@ may be supplied.
Each returned item of schema (eg an attribute definition) is returned
in a HASH. The keys in the returned HASH are lowercased versions of
the keys read from the server. Here's a partial list (not all HASHes
-define all keys) although note that RFC 2252 permits other keys as
+define all keys) although note that RFC 4512 permits other keys as
well:
name
View
12 lib/Net/LDAP/Util.pm
@@ -215,7 +215,7 @@ of a name.
=item *
-Escapes all RFC 2253 special characters (",", "+", """, "\", "E<lt>",
+Escapes all RFC 4514 special characters (",", "+", """, "\", "E<lt>",
"E<gt>", ";", "#", "=", " "), slashes ("/"), and any other character
where the ASCII code is E<lt> 32 as \hexpair.
@@ -356,7 +356,7 @@ For example, the DN 'OU=Sales+CN=J. Smith,DC=example,DC=net' is exploded to:
}
]
-(RFC2253 string) DNs might also contain values, which are the bytes of the
+(RFC4514 string) DNs might also contain values, which are the bytes of the
BER encoding of the X.500 AttributeValue rather than some LDAP string syntax.
These values are hex-encoded and prefixed with a #. To distinguish such BER
values, ldap_explode_dn uses references to the actual values,
@@ -489,7 +489,7 @@ sub ldap_explode_dn($%) {
=item escape_filter_value ( VALUES )
-Escapes the given B<VALUES> according to RFC 2254 so that they
+Escapes the given B<VALUES> according to RFC 4515 so that they
can be safely used in LDAP filters.
Any control characters with an ACII code E<lt> 32 as well as the
@@ -541,11 +541,11 @@ my @values = @_;
=item escape_dn_value ( VALUES )
-Escapes the given B<VALUES> according to RFC 2253 so that they
+Escapes the given B<VALUES> according to RFC 4514 so that they
can be safely used in LDAP DNs.
-The characters ",", "+", """, "\", "E<lt>", "E<gt>", ";", "#", "="
-with a special meaning in RFC 2252 are preceded by ba backslash.
+The characters ",", "+", """, "\", "E<lt>", "E<gt>", ";", "#", "=" with
+a special meaning in section 2.4 of RFC 4514 are preceded by a backslash.
Control characters with an ASCII code E<lt> 32 are represented
as \hexpair.
Finally all leading and trailing spaces are converted to
Please sign in to comment.
Something went wrong with that request. Please try again.