Docs: De-clarify the rfc2047 default charset

[users/heiko/exim.git] / doc / doc-docbook / spec.xfpt

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index a8b7af4f9b3d76da872d2f6c09f37bcfff2c7dc2..af41e4493f8f4e70682abc3af779592c1d94ebf5 100644 (file)
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -1860,7 +1860,7 @@ described RFC 2047. This makes it possible to transmit characters that are not
 in the ASCII character set, and to label them as being in a particular
 character set. When Exim is inspecting header lines by means of the &%$h_%&
 mechanism, it decodes them, and translates them into a specified character set
-(default ISO-8859-1). The translation is possible only if the operating system
+(default is set at build time). The translation is possible only if the operating system
 supports the &[iconv()]& function.
 
 However, some of the operating systems that supply &[iconv()]& do not support
@@ -7388,7 +7388,7 @@ SMTP authentication. See the &%ldapauth%& expansion string condition in chapter
 The &(ldapdn)& lookup type returns the Distinguished Name from a single entry
 as a sequence of values, for example
 .code
-cn=manager, o=University of Cambridge, c=UK
+cn=manager,o=University of Cambridge,c=UK
 .endd
 The &(ldap)& lookup type generates an error if more than one entry matches the
 search filter, whereas &(ldapm)& permits this case, and inserts a newline in
@@ -7399,7 +7399,8 @@ directory.
 
 In the common case where you specify a single attribute in your LDAP query, the
 result is not quoted, and does not contain the attribute name. If the attribute
-has multiple values, they are separated by commas.
+has multiple values, they are separated by commas. Any comma that is
+part of an attribute's value is doubled.
 
 If you specify multiple attributes, the result contains space-separated, quoted
 strings, each preceded by the attribute name and an equals sign. Within the
@@ -7414,7 +7415,9 @@ same as specifying all of an entry's attributes.
 Here are some examples of the output format. The first line of each pair is an
 LDAP query, and the second is the data that is returned. The attribute called
 &%attr1%& has two values, one of them with an embedded comma, whereas
-&%attr2%& has only one value:
+&%attr2%& has only one value. Both attributes are derived from &%attr%&
+(they have SUP &%attr%& in their schema definitions).
+
 .code
 ldap:///o=base?attr1?sub?(uid=fred)
 value1.1,value1,,2
@@ -7422,6 +7425,9 @@ value1.1,value1,,2
 ldap:///o=base?attr2?sub?(uid=fred)
 value two
 
+ldap:///o=base?attr?sub?(uid=fred)
+value1.1,value1,,2,value two
+
 ldap:///o=base?attr1,attr2?sub?(uid=fred)
 attr1="value1.1,value1,,2" attr2="value two"
 
@@ -10322,7 +10328,7 @@ f.7.2.0.0.0.0.c.d.c.b.a.1.0.0.0.9.0.0.0.2.4.c.0.8.b.d.0.1.0.0.2
 This operator encodes text according to the rules of RFC 2047. This is an
 encoding that is used in header lines to encode non-ASCII characters. It is
 assumed that the input string is in the encoding specified by the
-&%headers_charset%& option, which defaults to ISO-8859-1. If the string
+&%headers_charset%& option, which gets its default at build time. If the string
 contains only characters in the range 33&--126, and no instances of the
 characters
 .code
@@ -24351,7 +24357,7 @@ replaced, not just the working part. The replacement must be a complete RFC
 2822 address, including the angle brackets if necessary. If text outside angle
 brackets contains a character whose value is greater than 126 or less than 32
 (except for tab), the text is encoded according to RFC 2047. The character set
-is taken from &%headers_charset%&, which defaults to ISO-8859-1.
+is taken from &%headers_charset%&, which gets its default at build time.
 
 When the &"w"& flag is set on a rule that causes an envelope address to be
 rewritten, all but the working part of the replacement address is discarded.