Remove <validate/> from the registrar submission and instead state the
requirement that 'status-addresses' form field values must be of type
xs:anyURI in the text.
The reference to RFC 6120 was incorrect, what this really meant is RFC
6415. But instead of simply s/RFC 6120/RFC 6415/ here, I decided to
reorganize stating the requirements of XRD and JRD a little.
The result IQ's <query/> child element does not need to carry the node
information. And in this case the node information was actually wrong,
since "documents/test2.txt" was queried, and not "test2.txt".
This pipeline features the following:
- Building of an nginx image with the XEPs as static files,
in all formats.
- Incremental builds on the main branch and incremental builds
for MRs based on the last main build.
- Automatic archiving of changed XEPs to the attic
- Automatic announcement to the mailing lists
If it is known that the documents have already been built or if it
is imperative to use the versions built even if local changes have
been applied since the last build, this switch comes in handy.
Most jobs depend on build or one of its subdirectories. By default,
this causes make to take the timestamp of the `build` directory (or
the respective subdirectory) into account when calculating whether
a job needs rebuilding.
This is a problem, because the modified timestamp of `build` updates
whenever a file is put into it. Effectively, this breaks incremental
builds.
Luckily, GNU(?) Make supports Order-only Dependencies, prefixed with
a pipe (`|`) symbol in the dependency list. That means that the
dependencies are not taken into account for freshness checks, but
will be built before the target (if they are non-fresh).
This commit introduces usage of Order-only Dependencies for the
output directories, which fixes incremental building.
While Blake2b is capable to produce digests of any size from 1 to 64 bytes, It's default mode is 64 bytes (512 bits) though.
Some libraries implement just default digest size.
* OpenSSL supports blake2s-256 and blake2b-512 (no blake2b-256)
* gcrypt supports both blake2b-256 and blake2b-512
* nss supports none of blake2b
* Botan - any digest size
* Java: https://github.com/alphazero/Blake2b - any digest size
* Go-lang: https://godoc.org/golang.org/x/crypto/blake2b - both blake2b-256 and blake2b-512
* Rust: https://docs.rs/blake2/0.8.1/blake2/ - any digest size, 512 by default
* JS: https://github.com/dcposch/blakejs - any digest size, 512 by default
Also various libraries based on openssl will provide just blake2b-512.
So it looks to be a preferable choice over blake2b-256
