docs: more tweaking on the docs

AI Prompts:
claude-sonnet-4-6: do you see anything that is obviously outdated?
claude-sonnet-4-6: Please convert the markdown link to RST
claude-sonnet-4-6: Fix typos.

Author: tobixen

docs/source/about.rst

@@ -41,8 +41,7 @@ If serious problems are found with v2.2.6 during 2026, v2.2.7 will be
 released.
 
 The 3.x version series (released 2026-03) is almost
-backwards-compatible with version 2.x.  Python 3.10+ is required
-(Python 3.8 and 3.9 are no longer supported).  The
+backwards-compatible with version 2.x.  The
 ``caldav/objects.py`` backward-compatibility shim has been removed;
 any code doing ``from caldav.objects import <something>`` must be
 updated to import directly from ``caldav``.  The wildcard import has
@@ -59,7 +58,7 @@ Python compatibility notice
 ===========================
 
 Most of the code is regularly tested towards different versions of
-Python, the oldest being Python 3.10 (as of v3.0).
+Python.  As of 3.x.x, 3.10 to 3.14 is tested.  The 3.x-series does not support Python 3.8 (due to type hints), Python 3.9 is just not tested.
 
 Support for Python2 was officially not supported starting from caldav
 version 1.0.
@@ -105,28 +104,6 @@ support, but as many people requested the vobject dependency to be
 replaced with icalendar, both are now supported, and the icalendar
 library is now consistently used internally
 
-Misbehaving server implementations
-----------------------------------
-
-Some server implementations may have some "caldav"-support that either
-doesn't implement all of :rfc:`4791`, breaks the standard a bit, or has
-extra features.  As long as it doesn't add too much complexity to the
-code, hacks and workarounds for "badly behaving caldav servers" are
-considered to be within the scope.  Ideally, users of the caldav
-library should be able to download all the data from one calendar
-server or cloud provider, upload it to another server type or cloud
-provider, and continue using the library without noticing any
-differences.  To get there, it may be needed to add tweaks in the
-library covering the things the servers are doing wrong.
-
-There exists an extension to the standard covering calendar color and
-calendar order, allegedly with an xml namespace
-``http://apple.com/ns/ical/``. That URL gives (301 https and
-then) 404.  I've so far found no documentation at all
-on this extension - however, it seems to be supported by several
-caldav libraries, clients and servers.  As of 0.7, calendar colors and
-order is available for "power users".
-
 
 Notable classes and workflow
 ============================
@@ -160,10 +137,11 @@ For convenience, the classes above are also available as
 Compatibility
 =============
 
-CalDAV server implementations vary widely in which optional RFC features they
-support, and how gracefully they handle things they do not support.  The caldav
-library contains a compatibility layer that works around known issues
-automatically when the server is identified.
+The calendaring server supporting the CalDAV standards fully and perfectly does not exist.  CalDAV server implementations vary widely in which optional RFC features they
+support, and how gracefully they handle things they do not support, as well as how the standard is interpreted, things not working due to bugs, etc.
+
+The caldav library contains a compatibility layer that works around
+some known issues automatically when the server is identified.
 
 Compatibility hints system
 --------------------------
@@ -187,6 +165,10 @@ range when ``search.unlimited-time-range`` is ``broken``).
 Configuring compatibility hints
 --------------------------------
 
+A separate tool https://github.com/python-caldav/caldav-server-tester has been split out to do compatibility testing towards the servers.  The results are stored in ``caldav/compatibility_hints.py``.  The server supporting everything in the CalDAV RFCs perfectly does not exist.
+
+Compatibility testing has traditionally only been done by the maintainer - one of the purposes of the caldav-server-tester is to allow anyone to run the checks towards the software they use, without having to share any account information with the CalDAV maintainer.  The tool may spit out code blocks to be included in the compatibility hints file, as well as yaml snippets to be included in configuration files.
+
 The ``features`` parameter of :func:`caldav.get_davclient` (or
 :class:`caldav.DAVClient`) selects a named server profile from
 ``compatibility_hints.py``, or accepts a dict of feature overrides:
@@ -216,11 +198,9 @@ that the server deviates from the standard.
 Server-specific highlights
 --------------------------
 
-A separate tool https://github.com/python-caldav/caldav-server-tester has been split out to do compatibility testing towards the servers.  The results are stored in ``caldav/compatibility_hints.py``.  The server supporting everything in the CalDAV RFCs perfectly does not exist.
-
 Over the past years, the focus has been on compatibility-testing towards open source calendar servers.  In particular Google and iCloud haven't been tested for a long time.  Google officially supports CalDAV, see https://developers.google.com/workspace/calendar/caldav/v2/guide - iCloud supports CalDAV partly, but there exists no official information about it. iCloud limitations has been tracked in https://github.com/python-caldav/caldav/issues/3
 
-Compatibility testing has traditionally only been done by the maintainer - one of the purposes of the caldav-server-tester is to allow anyone to run the checks towards the software they use, without having to share any account information with the CalDAV maintainer.
+(This section contained lots of detailed information on how the different servers handle it, but it has been removed as much of it was outdated.  All the information is available in ``compatibility_hints.py``, though it should probably be redone a bit for better readability)
 
 Some notes on CalDAV URLs
 =========================
@@ -236,7 +216,7 @@ CalDAV URLs can be quite confusing, some software requires the URL to the calend
   typical icloud calendar URL looks like
   ``https://p12-caldav.icloud.com/12345/calendars/CALNAME``.
   If you encounter troubles with iCloud, try toggling
-  between IPv4 and IPv6 (see [issue 393](https://github.com/python-caldav/caldav/issues/393))
+  between IPv4 and IPv6 (see `issue 393 <https://github.com/python-caldav/caldav/issues/393>`_)
 
 * Google - legacy:  ``https://www.google.com/calendar/dav/``,
   The calendar URL for the primary personal calendar seems to be of the
@@ -245,13 +225,13 @@ CalDAV URLs can be quite confusing, some software requires the URL to the calend
   namespace.
 
 * Google - new api: see https://developers.google.com/calendar/caldav/v2/guide.
-  There is some information in https://github.com/python-caldav/caldav/issues/119 on how to connect to Google, and there are two contributed :ref:`examples:examples` on how to obtain a bearer token and use it in the caldav lbirary.  There is also a `blog post <https://blog.lasall.dev/post/tell-me-why-google-and-caldav/>`_ describing the process.
+  There is some information in https://github.com/python-caldav/caldav/issues/119 on how to connect to Google, and there are two contributed :ref:`examples:examples` on how to obtain a bearer token and use it in the caldav library.  There is also a `blog post <https://blog.lasall.dev/post/tell-me-why-google-and-caldav/>`_ describing the process.
 
 * DAViCal: The caldav URL typically seems to be on the format ``https://your.server.example.com/caldav.php/``, though it depends on how the web server is configured.  The primary calendars have URLs like ``https://your.server.example.com/caldav.php/donald/calendar`` and other calendars have names like ``https://your.server.example.com/caldav.php/donald/golfing_calendar``.
 
 * Zimbra: The caldav URL is typically on the format ``https://mail.example.com/dav/``, calendar URLs can be on the format ``https://mail.example.com/dav/donald@example.com/My%20Golfing%20Calendar``.  Display name always matches the last part of the URL.
 
-* Fastmail: ``https://caldav.fastmail.com/dav/`` - note that the trailing dash is significant (ref https://github.com/home-assistant/core/issues/66599)
+* Fastmail: ``https://caldav.fastmail.com/dav/`` - note that the trailing slash is significant (ref https://github.com/home-assistant/core/issues/66599)
 
 * GMX: `f"https://caldav.gmx.net/begenda/dav/{userid}@gmx.net/calendar`"`
 
@@ -285,7 +265,7 @@ private servers into tests/caldav_test_servers.yaml, see tests/caldav_test_serve
 Niquests vs Requests vs HTTPX
 =============================
 
-By default, CalDAV depends on the niquests library.  Some people are not happy with that, there exists fallbacks to utilize httpx and requests.  See the :doc:`http-libraries` document.
+By default, CalDAV depends on the niquests library.  Some people are not happy with that, so there exists fallbacks to utilize httpx and requests.  See the :doc:`http-libraries` document.
 
 Documentation
 =============
@@ -294,12 +274,12 @@ To build the documentation, install sphinx and run:
 
 .. code-block:: bash
 
-  $ python setup.py build_sphinx
+  $ make html
 
 Code of Conduct
 ===============
 
-While I hope we never will need to refer to it, the `Contributor Covenant <https://www.contributor-covenant.org/version/2/1/code_of_conduct/>`_ applies to this project, see also `CODE_OF_CONDUCT <https://github.com/python-caldav/caldav/blob/master/CODE_OF_CONDUCT>`_.  Avoid toxic negativity in general, but Tobias Brox can probably handle some blunt criticism if it may help getting the project on a better track.
+While I hope we never will need to refer to it, the `Contributor Covenant <https://www.contributor-covenant.org/version/2/1/code_of_conduct/>`_ applies to this project, see also `CODE_OF_CONDUCT <https://github.com/python-caldav/caldav/blob/master/CODE_OF_CONDUCT>`_.  Avoid toxic negativity in general, but the maintainer can handle some blunt criticism as long as it may help getting the project on a better track.
 
 License
 =======

docs/source/http-libraries.rst

@@ -21,9 +21,6 @@ a complaint was raised from a distro package maintainer who found
 niquests unacceptable.  Due to that the CalDAV library now has a
 fallback implemented; it can use requests for sync communication.
 
-Niquests started with contributions to the urllib3 and requests
-library, but the changes were not accepted, hence the fork.
-
 For async communications (and also as a replacement for requests in
 sync usage), **httpx** seems to have been the most popular library
 candidate.  However, niquests supports async communication.  It was
@@ -54,7 +51,7 @@ Recommendations
 * If you're using the CalDAV library in an async project that is
   already heavily dependent on httpx and don't want to drag in extra
   dependencies, use httpx - but do your own due diligence.
-* If you have strong personal opinions against niquests, then don't use it - but it would be nice if you could share your reasons, i.e. in issue https://github.com/python-caldav/caldav/issues/611
+* If you have strong personal opinions against niquests, then don't use it.  Please share your thoughts at https://github.com/python-caldav/caldav/issues/611
 
 Multiplexing
 ------------