replaced ':' in anchor names (texinfo doesn't like it).

7 files changed, 28 insertions, 28 deletions

diff --git a/doc/cha-cert-auth.texi b/doc/cha-cert-auth.texi
index 4898980a40..7cd344968b 100644
--- a/doc/cha-cert-auth.texi
+++ b/doc/cha-cert-auth.texi
@@ -68,14 +68,14 @@ entities.  Usually more than one certification authorities exist, and
 certification authorities may certify other authorities to issue
 certificates as well, following a hierarchical model.
 
-@float Figure,fig:x509
+@float Figure,fig-x509
 @image{gnutls-x509,7cm}
 @caption{An example of the X.509 hierarchical trust model.}
 @end float
 
 One needs to trust one or more CAs for his secure communications. In
 that case only the certificates issued by the trusted authorities are
-acceptable.  The framework is illustrated on @ref{fig:x509}.
+acceptable.  The framework is illustrated on @ref{fig-x509}.
 
 @menu
 * X.509 certificate structure::
@@ -192,7 +192,7 @@ private keys with the @code{gnutls_x509_privkey_t} type.  All the
 available functions for @acronym{X.509} certificate handling have
 their prototypes in @file{gnutls/x509.h}. An example program to
 demonstrate the @acronym{X.509} parsing capabilities can be found in
-@ref{ex:x509-info}.
+@ref{ex-x509-info}.
 
 @node Importing an X.509 certificate
 @subsubsection Importing an X.509 certificate
@@ -280,7 +280,7 @@ is always set on a verification error and more detailed flags will also be set w
 
 @showenumdesc{gnutls_certificate_status_t,The @code{gnutls_@-certificate_@-status_t} enumeration.}
 
-An example of certificate verification is shown in @ref{ex:verify2}.
+An example of certificate verification is shown in @ref{ex-verify2}.
 It is also possible to have a set of certificates that
 are trusted for a particular server but not to authorize other certificates.
 This purpose is served by the functions @funcref{gnutls_x509_trust_list_add_named_crt} and @funcref{gnutls_x509_trust_list_verify_named_crt}.
@@ -321,10 +321,10 @@ CA. @acronym{OpenPGP} allows anyone to sign anyone else's public
 key. When Alice signs Bob's key, she is introducing Bob's key to
 anyone who trusts Alice. If someone trusts Alice to introduce keys,
 then Alice is a trusted introducer in the mind of that observer.
-For example in @ref{fig:openpgp}, David trusts Alice to be an introducer and Alice
+For example in @ref{fig-openpgp}, David trusts Alice to be an introducer and Alice
 signed Bob's key thus Dave trusts Bob's key to be the real one.
 
-@float Figure,fig:openpgp
+@float Figure,fig-openpgp
 @image{gnutls-pgp,8cm}
 @caption{An example of the OpenPGP trust model.}
 @end float
diff --git a/doc/cha-cert-auth2.texi b/doc/cha-cert-auth2.texi
index df8b1ed2f0..0cd328240e 100644
--- a/doc/cha-cert-auth2.texi
+++ b/doc/cha-cert-auth2.texi
@@ -49,7 +49,7 @@ The following example is about generating a certificate request, and a
 private key. A certificate request can be later be processed by a CA
 which should return a signed certificate.
 
-@anchor{ex:crq}
+@anchor{ex-crq}
 @verbatiminclude examples/ex-crq.c
 
 @node PKIX certificate revocation lists
diff --git a/doc/cha-gtls-app.texi b/doc/cha-gtls-app.texi
index acf0abc87d..24301753ae 100644
--- a/doc/cha-gtls-app.texi
+++ b/doc/cha-gtls-app.texi
@@ -37,7 +37,7 @@ and the manpages is recommended.
 @subsection General idea
 
 A brief description of how @acronym{GnuTLS} sessions operate is shown
-at @ref{fig:gnutls-design}. This section will become more clear when it
+at @ref{fig-gnutls-design}. This section will become more clear when it
 is completely read.
 As shown in the figure, there is a read-only global state that is
 initialized once by the global initialization function.  This global
@@ -49,7 +49,7 @@ for the deinitialization function which frees all allocated memory
 and must be called after the program has permanently
 finished using @acronym{GnuTLS}.
 
-@float Figure,fig:gnutls-design
+@float Figure,fig-gnutls-design
 @image{gnutls-internals,12cm}
 @caption{High level design of GnuTLS.}
 @end float
diff --git a/doc/cha-gtls-examples.texi b/doc/cha-gtls-examples.texi
index f50c776362..e01c078602 100644
--- a/doc/cha-gtls-examples.texi
+++ b/doc/cha-gtls-examples.texi
@@ -41,7 +41,7 @@ implemented by another example.
 
 @node Simple client example with X.509 certificate support
 @subsection Simple client example with @acronym{X.509} certificate support
-@anchor{ex:verify}
+@anchor{ex-verify}
 
 Let's assume now that we want to create a TCP client which
 communicates with servers that use @acronym{X.509} or
@@ -111,7 +111,7 @@ certificate selection callback.
 
 @node Verifying a certificate
 @subsection Verifying a certificate
-@anchor{ex:verify2}
+@anchor{ex-verify2}
 
 An example is listed below which uses the high level verification
 functions to verify a given certificate list.
@@ -120,7 +120,7 @@ functions to verify a given certificate list.
 
 @node Client using a smart card with TLS
 @subsection Using a smart card with TLS
-@anchor{ex:pkcs11-client}
+@anchor{ex-pkcs11-client}
 @cindex Smart card example
 
 This example will demonstrate how to load keys and certificates
@@ -132,7 +132,7 @@ use it in a TLS connection.
 
 @node Client with Resume capability example
 @subsection Client with resume capability example
-@anchor{ex:resume-client}
+@anchor{ex-resume-client}
 
 This is a modification of the simple client example. Here we
 demonstrate the use of session resumption. The client tries to connect
@@ -266,7 +266,7 @@ current session.
 
 @node X.509 certificate parsing example
 @subsection @acronym{X.509} certificate parsing example
-@anchor{ex:x509-info}
+@anchor{ex-x509-info}
 
 To demonstrate the @acronym{X.509} parsing capabilities an example program is
 listed below.  That program reads the peer's certificate, and prints
diff --git a/doc/cha-internals.texi b/doc/cha-internals.texi
index b8eddc52b7..6a04ac221d 100644
--- a/doc/cha-internals.texi
+++ b/doc/cha-internals.texi
@@ -17,12 +17,12 @@ happens inside the black box.
 
 @node The TLS Protocol
 @section The TLS Protocol
-The main use case for the TLS protocol is shown in @ref{fig:client-server}.
+The main use case for the TLS protocol is shown in @ref{fig-client-server}.
 A user of a library implementing the protocol expects no less than this functionality,
 i.e., to be able to set parameters such as the accepted security level, perform a
 negotiation with the peer and be able to exchange data.
 
-@float Figure,fig:client-server
+@float Figure,fig-client-server
 @image{gnutls-client-server-use-case,9cm}
 @caption{TLS protocol use case.}
 @end float
@@ -31,9 +31,9 @@ negotiation with the peer and be able to exchange data.
 @section TLS Handshake Protocol
 The @acronym{GnuTLS} handshake protocol is implemented as a state
 machine that waits for input or returns immediately when the non-blocking
-transport layer functions are used. The main idea is shown in @ref{fig:gnutls-handshake}.
+transport layer functions are used. The main idea is shown in @ref{fig-gnutls-handshake}.
 
-@float Figure,fig:gnutls-handshake
+@float Figure,fig-gnutls-handshake
 @image{gnutls-handshake-state,9cm}
 @caption{GnuTLS handshake state machine.}
 @end float
@@ -43,9 +43,9 @@ implementations of the internal handlers are available and
 @funcref{gnutls_handshake} only multiplexes the input to the appropriate 
 handler. For example a @acronym{PSK} ciphersuite has a different 
 implementation of the @code{process_client_key_exchange} than a
-certificate ciphersuite. We illustrate the idea in @ref{fig:gnutls-handshake-sequence}.
+certificate ciphersuite. We illustrate the idea in @ref{fig-gnutls-handshake-sequence}.
 
-@float Figure,fig:gnutls-handshake-sequence
+@float Figure,fig-gnutls-handshake-sequence
 @image{gnutls-handshake-sequence,12cm}
 @caption{GnuTLS handshake process sequence.}
 @end float
@@ -457,9 +457,9 @@ those is a challenging task for every cryptographic  application or
 library. Unfortunately the cryptographic library that GnuTLS is based 
 on takes no advantage of these capabilities. For this reason GnuTLS handles 
 this internally by following a layered approach to accessing
-cryptographic operations as in @ref{fig:crypto-layers}.
+cryptographic operations as in @ref{fig-crypto-layers}.
 
-@float Figure,fig:crypto-layers
+@float Figure,fig-crypto-layers
 @image{gnutls-crypto-layers,12cm}
 @caption{GnuTLS cryptographic back-end design.}
 @end float
diff --git a/doc/cha-intro-tls.texi b/doc/cha-intro-tls.texi
index de6155f9ef..f154e7c97e 100644
--- a/doc/cha-intro-tls.texi
+++ b/doc/cha-intro-tls.texi
@@ -48,9 +48,9 @@ alert protocol is above the record protocol.
 The handshake protocol is responsible for the security parameters'
 negotiation, the initial key exchange and authentication.  
 @xref{The Handshake Protocol}, for more information about the handshake
-protocol.  The protocol layering in TLS is shown in @ref{fig:tls-layers}.
+protocol.  The protocol layering in TLS is shown in @ref{fig-tls-layers}.
 
-@float Figure,fig:tls-layers
+@float Figure,fig-tls-layers
 @image{gnutls-layers,12cm}
 @caption{The TLS protocol layers.}
 @end float
@@ -384,7 +384,7 @@ established keys, meaning the server needs to store the state of established
 connections (unless session tickets are used -- @ref{Session tickets}).
 
 Session resumption is an integral part of @acronym{GnuTLS}, and 
-@ref{Session resumption}, @ref{ex:resume-client} illustrate typical 
+@ref{Session resumption}, @ref{ex-resume-client} illustrate typical 
 uses of it.
 
 @node TLS Extensions
diff --git a/doc/cha-tokens.texi b/doc/cha-tokens.texi
index 8287ff2cc8..40ad477d9f 100644
--- a/doc/cha-tokens.texi
+++ b/doc/cha-tokens.texi
@@ -179,12 +179,12 @@ and signing without exposing the key. In GnuTLS the PKCS #11 functionality is
 available in @code{gnutls/pkcs11.h}.
 
 Moreover @acronym{PKCS} #11 can be (ab)used to allow all applications in the same operating system to access
-shared cryptographic keys and certificates in a uniform way, as in @ref{fig:pkcs11-vision}.
+shared cryptographic keys and certificates in a uniform way, as in @ref{fig-pkcs11-vision}.
 That way applications could load their trusted certificate list, as well as user
 certificates from a common PKCS #11 module. Such a provider exists in the @acronym{Gnome} 
 system, being the @acronym{Gnome Keyring}.
 
-@float Figure,fig:pkcs11-vision
+@float Figure,fig-pkcs11-vision
 @image{pkcs11-vision,9cm}
 @caption{PKCS #11 module usage.}
 @end float
@@ -353,7 +353,7 @@ entered before accessing the object (for operations or otherwise).
 @subsection Using a @acronym{PKCS} #11 token with TLS
 
 It is possible to use a @acronym{PKCS} #11 token to a TLS
-session, as shown in @ref{ex:pkcs11-client}. In addition
+session, as shown in @ref{ex-pkcs11-client}. In addition
 the following functions can be used to load PKCS #11 key and
 certificates by specifying a PKCS #11 URL instead of a filename.