Minor cleanups

[kerolasa]

This pull request contains three commits.

• fix example template

  The TTL field as a variable is not currently supported. The "launchURL"
  is removed because it does not appear anywhere else in the spec.

  Signed-off-by: Sami Kerola kerolasa@iki.fi

• try to use documentation IPs and domains when possible

  After this there are still some references to public domains and IPs where
  they cannot be easily changed.

  RFC 2606: Reserved Top Level DNS Names
  RFC 5737: IPv4 Address Blocks Reserved for Documentation
  Signed-off-by: Sami Kerola kerolasa@iki.fi

• use asciidoc title levels in sequence

  This fixes nine warnings similar to the one mentioned below.

    $ asciidoctor "./Domain Connect Spec Draft.adoc"
    asciidoctor: WARNING: Domain Connect Spec Draft.adoc: line 2204: section title out of sequence: expected level 2, got level 3
    [...]
  

  Signed-off-by: Sami Kerola kerolasa@iki.fi

[pawel-kow]

This is good stuff. TBH I was not aware of RFC 2606 and RFC 5737 so it's useful in context of potential IETF submission.

What are the other places and why it's not easy to fix them?

Very interesting catch with the examples of variables in TTL field. It may increase the chance that this "feature" is actually implemented by some folks if they based more on examples rather than normative text. Let's discuss it in the next call.

[kerolasa]

What are the other places and why it's not easy to fix them?

For example virtucondomains.com that would require new images to be uploaded is a little bit tricky to change to example.com. And then there is the public key validation that uses a=1&b=2&ip=10.10.10.10&domain=foobar.com. To make that nice update should use documentation IP and domain while matching the validation signature.

These are not impossible to fix, but a bit more involved than just sed 's/this/that/'

[pawel-kow]

Got it.

For the screenshots I'm afraid I don't even have the source files for them, so one would need to create new ones or take a different approach.
For EITF submission I replaced them with ASCII-Art already, so I think this is the way to go about it:
https://github.com/Domain-Connect/spec/blob/feature/ietf-submission/draft-domain-connect-04.adoc

For the signature the keys seem to be the same as in example service, so the private key is also in the source code (sic!):
https://github.com/Domain-Connect/exampleservice/blob/master/config.py

https://exampleservice.domainconnect.org/sig tool "Generating the Signature" can create a new signature and without private key it will even use the one of example service, so the task should not be that difficult.

[pawel-kow]

@kerolasa I continued this work and opened #93 with the added changes (I had no rights to commit to your repo to extend the original PR).
May you please review and give your OK?