From a49781690c4a3244ee1ea0fa26061fcca9e5c474 Mon Sep 17 00:00:00 2001
From: Michael Hanselmann <hansmi@google.com>
Date: Fri, 20 Aug 2010 15:13:51 +0200
Subject: [PATCH] Use Sphinx' :rfc: extension to refer to RFCs
Signed-off-by: Michael Hanselmann <hansmi@google.com>
Reviewed-by: Iustin Pop <iustin@google.com>
---
NEWS | 2 +-
doc/design-2.2.rst | 2 +-
doc/rapi.rst | 11 +++++------
doc/security.rst | 2 +-
4 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/NEWS b/NEWS
index 5cb7ec6ad..e1d544686 100644
--- a/NEWS
+++ b/NEWS
@@ -88,7 +88,7 @@ Version 2.2.0 beta 0
- Added per-request RPC timeout
- RAPI now requires a Content-Type header for requests with a body (e.g.
``PUT`` or ``POST``) which must be set to ``application/json`` (see
- RFC2616 (HTTP/1.1), section 7.2.1)
+ :rfc:`2616` (HTTP/1.1), section 7.2.1)
- ``ganeti-watcher`` attempts to restart ``ganeti-rapi`` if RAPI is not
reachable
- Implemented initial support for running Ganeti daemons as separate
diff --git a/doc/design-2.2.rst b/doc/design-2.2.rst
index 2017fe67e..57a67803b 100644
--- a/doc/design-2.2.rst
+++ b/doc/design-2.2.rst
@@ -411,7 +411,7 @@ between clusters before instances can be moved. If the third party does
not know the secret, it can't forge the certificates or redirect the
data. Unless disabled by a new cluster parameter, verifying the HMAC
signatures must be mandatory. The HMAC signature for X509 certificates
-will be prepended to the certificate similar to an RFC822 header and
+will be prepended to the certificate similar to an :rfc:`822` header and
only covers the certificate (from ``-----BEGIN CERTIFICATE-----`` to
``-----END CERTIFICATE-----``). The header name will be
``X-Ganeti-Signature`` and its value will have the format
diff --git a/doc/rapi.rst b/doc/rapi.rst
index b9fe651d9..b01d21785 100644
--- a/doc/rapi.rst
+++ b/doc/rapi.rst
@@ -53,7 +53,7 @@ Example::
.. [#pwhash] Using the MD5 hash of username, realm and password is
- described in RFC2617_ ("HTTP Authentication"), sections 3.2.2.2 and
+ described in :rfc:`2617` ("HTTP Authentication"), sections 3.2.2.2 and
3.3. The reason for using it over another algorithm is forward
compatibility. If ``ganeti-rapi`` were to implement HTTP Digest
authentication in the future, the same hash could be used.
@@ -65,11 +65,10 @@ Protocol
--------
The protocol used is JSON_ over HTTP designed after the REST_ principle.
-HTTP Basic authentication as per RFC2617_ is supported.
+HTTP Basic authentication as per :rfc:`2617` is supported.
.. _JSON: http://www.json.org/
.. _REST: http://en.wikipedia.org/wiki/Representational_State_Transfer
-.. _RFC2617: http://tools.ietf.org/rfc/rfc2617.txt
A note on JSON as used by RAPI
@@ -108,9 +107,9 @@ problems.
PUT or POST?
------------
-According to RFC2616 the main difference between PUT and POST is that
-POST can create new resources but PUT can only create the resource the
-URI was pointing to on the PUT request.
+According to :rfc:`2616` the main difference between PUT and POST is
+that POST can create new resources but PUT can only create the resource
+the URI was pointing to on the PUT request.
Unfortunately, due to historic reasons, the Ganeti RAPI library is not
consistent with this usage, so just use the methods as documented below
diff --git a/doc/security.rst b/doc/security.rst
index 48251c0e8..a02a72e23 100644
--- a/doc/security.rst
+++ b/doc/security.rst
@@ -93,7 +93,7 @@ Remote API
----------
Starting with Ganeti 2.0, Remote API traffic is encrypted using SSL/TLS
-by default. It supports Basic authentication as per RFC2617.
+by default. It supports Basic authentication as per :rfc:`2617`.
Paths for certificate, private key and CA files required for SSL/TLS
will be set at source configure time. Symlinks or command line
--
GitLab