diff --git a/spec.asciidoc b/spec.asciidoc
index 2508d96..5e4f29c 100644
--- a/spec.asciidoc
+++ b/spec.asciidoc
@@ -210,6 +210,49 @@ https://www.radio-browser.info/ fornisce molte info utili su delle radio. Grazie
 RadioDroid is a fine Android app to listen to stream. We'd like to have an improved version of RadioDroid that
 also includes features that RadioManifest provide. See the _Player_ use case.
 
+== Why it is like this
+
+Of course, similar goals to the one achieved by RadioManifest could have been achieved in different ways. So
+let me try to answer to some frequently answered question. More in general, we tried to adhere to
+link:http://scripting.com/2017/05/09/rulesForStandardsmakers.html[Rules for Standards makers]
+
+=== Why XML? Why not JSON?
+
+I understand why XML is fading out. Believe me, this choice is not about the technical merit of XML in itself!
+
+Feeds are still very important. While JsonFeed may look promising for the future, RSS is the present.
+Since any reasonable RadioManifest client would also need to implement feed parsing, they need a XML parser
+anyway. So, let's stick with this.
+
+=== Why are ``shows`` based on XBEL, instead of OPML?
+
+Good question. OPML are heavily used in the RSS-world, so it would have made sense to base our ``shows.xml``
+format on OPML. However, OPML looks not so easy to extend. XBEL is much easier on this front. We want our
+format to be easy to extend in the future.
+
+=== Why not add some more field here and there?
+
+Good point. It's pretty hard to define a threshold: should we add a ``slogan`` for a radio? Image? Logo?
+Gallery? Frequency of broadcasting? We applied the principle of sticking to (what we felt was) the bare
+minimum, knowing that the standard is easily extendable, so future needs can be accomodated.
+
+=== Why not extend RSS itself? We could add more info to the ``<channel>>`` tag
+
+That's a nice idea. However, we think this would make the adoption harder.
+
+Let's say that you are using a CMS for your radio right now. Let's say Drupal (but it could be anything else
+of course). You should teach Drupal to put this nice information into the ``<channel>`` section of its feeds.
+How easy is it? I don't think this is *so* easy.
+
+With the current setup, the radiomanifest.xml can be used as a very simple static file. Most web servers can be
+told to serve this from a directory on the server, without passing through your CMS code at all.
+This static file is also changing very rarely: it's totally reasonable to write it once, and forget about it
+for years, so you don't even need a special software to keep it working.
+
+Of course, nothing prevents a CMS to generate this file dynamically, making this way simpler for users. But we
+wanted RadioManifest to be deployable as _"just a bunch of static files"_, as a way to increase early adoption.
+
+
 == Meta
 
 This specification is versioned on {url-repo}[Git]