Doc: Centralize RFC documentation-links in rfc.qdoc
In the effort of repairing broken links as per QTBUG-96127, a series of RFC links referring to `tools.ietf.org/html/*` were modified to point to the new address that the site redirected to. To simplify executing a similar task and to diminish the duplication of manually inserted urls, the already existing `rfc.qdoc` file, containing `\externalpage` commands directing to RFC locations, was enhanced with links to all RFCs that were mentioned in the current documentation, so as to aggregate this common category of links. All links pointing to a `ietf` domain inside QDoc documentation blocks were then changed to use the newly provided external-references. Task-number: QTBUG-96127 Pick-to: 6.2 Change-Id: I2a52eb6aa8c9e346f64ef1a627b039220d9f6c2a Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This commit is contained in:
parent
0246bfd40a
commit
10eedd175e
@ -46,6 +46,11 @@
|
||||
\title RFC 1738
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc1918
|
||||
\title RFC 1918
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc1928
|
||||
\title RFC 1928
|
||||
@ -88,12 +93,102 @@
|
||||
\title RFC 3491
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc3492
|
||||
\title RFC 3492
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc3986
|
||||
\title RFC 3986
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc4122
|
||||
\title RFC 4122
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc4627
|
||||
\title RFC 4627
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc4648
|
||||
\title RFC 4648
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc4686
|
||||
\title RFC 4686
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.1
|
||||
\title RFC 5280, section 5.3.1
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc6347
|
||||
\title RFC 6347
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1
|
||||
\title RFC 6347, section 4.2.1
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.8
|
||||
\title RFC 6347, section 4.2.8
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc6724
|
||||
\title RFC 6724
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc7049
|
||||
\title RFC 7049
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc7049#section-3.9
|
||||
\title RFC 7049, section 3.9
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc7049#section-3.10
|
||||
\title RFC 7049, section 3.10
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc7049#section-6
|
||||
\title RFC 7049, section 6
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc7252
|
||||
\title RFC 7252
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc8018#section-5.1
|
||||
\title RFC 8018, section 5.1
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc8018#section-5.2
|
||||
\title RFC 8018, section 5.2
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc8152
|
||||
\title RFC 8152
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage https://datatracker.ietf.org/doc/html/rfc8446#section-6
|
||||
\title RFC 8446, section 6
|
||||
*/
|
||||
|
@ -37,7 +37,7 @@
|
||||
game generally involves serializing each game object's member variables
|
||||
to a file. Many formats can be used for this purpose, one of which is JSON.
|
||||
With QJsonDocument, you also have the ability to serialize a document in a
|
||||
\l {https://tools.ietf.org/html/rfc7049} {CBOR} format, which is great if you
|
||||
\l {RFC 7049} {CBOR} format, which is great if you
|
||||
don't want the save file to be readable, or if you need to keep the file size down.
|
||||
|
||||
In this example, we'll demonstrate how to save and load a simple game to
|
||||
|
@ -46,11 +46,6 @@
|
||||
\title ISO 8601
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage http://www.ietf.org/rfc/rfc4648.txt
|
||||
\title RFC 4648
|
||||
*/
|
||||
|
||||
/*!
|
||||
\externalpage http://www.iana.org/assignments/character-sets/character-sets.xml
|
||||
\title IANA character-sets encoding file
|
||||
|
@ -43,7 +43,7 @@
|
||||
modify and save JSON data.
|
||||
|
||||
More details about the JSON data format can be found at \l{http://json.org}{json.org}
|
||||
and in \l{https://datatracker.ietf.org/doc/html/rfc4627}{RFC-4627}.
|
||||
and in \l {RFC 4627}.
|
||||
|
||||
\tableofcontents
|
||||
|
||||
|
@ -1958,7 +1958,7 @@ void QUrl::setUrl(const QString &url, ParsingMode parsingMode)
|
||||
The scheme describes the type (or protocol) of the URL. It's
|
||||
represented by one or more ASCII characters at the start the URL.
|
||||
|
||||
A scheme is strictly \l {http://www.ietf.org/rfc/rfc3986.txt} {RFC 3986}-compliant:
|
||||
A scheme is strictly \l {RFC 3986}-compliant:
|
||||
\tt {scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )}
|
||||
|
||||
The following example shows a URL where the scheme is "ftp":
|
||||
|
@ -286,7 +286,7 @@ static QUuid createFromName(const QUuid &ns, const QByteArray &baseData, QCrypto
|
||||
\endtable
|
||||
|
||||
The field layouts for the DCE versions listed in the table above
|
||||
are specified in the \l{http://www.ietf.org/rfc/rfc4122.txt}
|
||||
are specified in the \l{RFC 4122}
|
||||
{Network Working Group UUID Specification}.
|
||||
|
||||
Most platforms provide a tool for generating new UUIDs, e.g. \c
|
||||
|
@ -59,7 +59,7 @@ using namespace QtCbor;
|
||||
binary data encoding that is a superset of JSON. It was created by the IETF
|
||||
Constrained RESTful Environments (CoRE) WG, which has used it in many new
|
||||
RFCs. It is meant to be used alongside the
|
||||
\l{https://tools.ietf.org/html/rfc7252}{CoAP protocol}.
|
||||
\l{RFC 7252}{CoAP protocol}.
|
||||
|
||||
QCborArray is very similar to \l QVariantList and \l QJsonArray and its API
|
||||
is almost identical to those two classes. It can also be converted to and
|
||||
|
@ -153,11 +153,11 @@ QDataStream &operator>>(QDataStream &ds, QCborSimpleType &st)
|
||||
is the exponent of the power of 10, the second the integral
|
||||
mantissa. The value 273.15 would be encoded as array \c{[-2, 27315]}.
|
||||
\value Bigfloat Similar to Decimal, but the exponent is a power of 2 instead.
|
||||
\value COSE_Encrypt0 An \c Encrypt0 map as specified by \l{https://tools.ietf.org/html/rfc8152}{RFC 8152}
|
||||
\value COSE_Encrypt0 An \c Encrypt0 map as specified by \l{RFC 8152}
|
||||
(CBOR Object Signing and Encryption).
|
||||
\value COSE_Mac0 A \c Mac0 map as specified by \l{https://tools.ietf.org/html/rfc8152}{RFC 8152}
|
||||
\value COSE_Mac0 A \c Mac0 map as specified by \l{RFC 8152}
|
||||
(CBOR Object Signing and Encryption).
|
||||
\value COSE_Sign1 A \c Sign1 map as specified by \l{https://tools.ietf.org/html/rfc8152}{RFC 8152}
|
||||
\value COSE_Sign1 A \c Sign1 map as specified by \l{RFC 8152}
|
||||
(CBOR Object Signing and Encryption).
|
||||
\value ExpectedBase64url Indicates that the byte array should be encoded using Base64url
|
||||
if the stream is converted to JSON.
|
||||
@ -172,13 +172,13 @@ QDataStream &operator>>(QDataStream &ds, QCborSimpleType &st)
|
||||
\value RegularExpression Indicates that the string contains a Perl-Compatible Regular
|
||||
Expression pattern.
|
||||
\value MimeMessage Indicates that the string contains a MIME message (according to
|
||||
\l{https://tools.ietf.org/html/rfc2045}){RFC 2045}.
|
||||
\l{RFC 2045}).
|
||||
\value Uuid Indicates that the byte array contains a UUID.
|
||||
\value COSE_Encrypt An \c Encrypt map as specified by \l{https://tools.ietf.org/html/rfc8152}{RFC 8152}
|
||||
\value COSE_Encrypt An \c Encrypt map as specified by \l{RFC 8152}
|
||||
(CBOR Object Signing and Encryption).
|
||||
\value COSE_Mac A \c Mac map as specified by \l{https://tools.ietf.org/html/rfc8152}{RFC 8152}
|
||||
\value COSE_Mac A \c Mac map as specified by \l{RFC 8152}
|
||||
(CBOR Object Signing and Encryption).
|
||||
\value COSE_Sign A \c Sign map as specified by \l{https://tools.ietf.org/html/rfc8152}{RFC 8152}
|
||||
\value COSE_Sign A \c Sign map as specified by \l{RFC 8152}
|
||||
(CBOR Object Signing and Encryption).
|
||||
\value Signature No change in interpretation; this tag can be used as the outermost
|
||||
tag in a CBOR stream as the file header.
|
||||
|
@ -326,7 +326,7 @@ void DiagnosticNotation::appendValue(const QCborValue &v)
|
||||
would be possible.
|
||||
|
||||
CBOR diagnostic notation is specified by
|
||||
\l{https://tools.ietf.org/html/rfc7049#section-6}{section 6} of RFC 7049.
|
||||
\l{RFC 7049, section 6}{section 6} of RFC 7049.
|
||||
It is a text representation of the CBOR stream and it is very similar to
|
||||
JSON, but it supports the CBOR types not found in JSON. The extended format
|
||||
enabled by the \l{DiagnosticNotationOption}{ExtendedFormat} flag is
|
||||
|
@ -58,7 +58,7 @@ using namespace QtCbor;
|
||||
Representation, a very compact form of binary data encoding that is a
|
||||
superset of JSON. It was created by the IETF Constrained RESTful
|
||||
Environments (CoRE) WG, which has used it in many new RFCs. It is meant to
|
||||
be used alongside the \l{https://tools.ietf.org/html/rfc7252}{CoAP
|
||||
be used alongside the \l{RFC 7252}{CoAP
|
||||
protocol}.
|
||||
|
||||
Unlike JSON and \l QVariantMap, CBOR map keys can be of any type, not just
|
||||
|
@ -109,7 +109,7 @@ static_assert(int(QCborStreamReader::Invalid) == CborInvalidType);
|
||||
Representation, a very compact form of binary data encoding that is
|
||||
compatible with JSON. It was created by the IETF Constrained RESTful
|
||||
Environments (CoRE) WG, which has used it in many new RFCs. It is meant to
|
||||
be used alongside the \l{https://tools.ietf.org/html/rfc7252}{CoAP
|
||||
be used alongside the \l{RFC 7252}{CoAP
|
||||
protocol}.
|
||||
|
||||
QCborStreamReader provides a StAX-like API, similar to that of
|
||||
|
@ -92,8 +92,7 @@ Q_DECLARE_TYPEINFO(CborEncoder, Q_PRIMITIVE_TYPE);
|
||||
Representation, a very compact form of binary data encoding that is
|
||||
compatible with JSON. It was created by the IETF Constrained RESTful
|
||||
Environments (CoRE) WG, which has used it in many new RFCs. It is meant to
|
||||
be used alongside the \l{https://tools.ietf.org/html/rfc7252}{CoAP
|
||||
protocol}.
|
||||
be used alongside the \l{RFC 7252}{CoAP protocol}.
|
||||
|
||||
QCborStreamWriter provides a StAX-like API, similar to that of
|
||||
\l{QXmlStreamWriter}. It is rather low-level and requires a bit of knowledge
|
||||
@ -123,7 +122,7 @@ Q_DECLARE_TYPEINFO(CborEncoder, Q_PRIMITIVE_TYPE);
|
||||
|
||||
QCborStreamWriter supports all CBOR features required to create canonical
|
||||
and strict streams. It implements almost all of the features specified in
|
||||
\l {https://tools.ietf.org/html/rfc7049}{RFC 7049}.
|
||||
\l {RFC 7049}.
|
||||
|
||||
The following table lists the CBOR features that QCborStreamWriter supports.
|
||||
|
||||
@ -151,7 +150,7 @@ Q_DECLARE_TYPEINFO(CborEncoder, Q_PRIMITIVE_TYPE);
|
||||
\section2 Canonical CBOR encoding
|
||||
|
||||
Canonical CBOR encoding is defined by
|
||||
\l{https://tools.ietf.org/html/rfc7049#section-3.9}{Section 3.9 of RFC
|
||||
\l{RFC 7049, section 3.9}{Section 3.9 of RFC
|
||||
7049}. Canonical encoding is not a requirement for Qt's CBOR decoding
|
||||
functionality, but it may be required for some protocols. In particular,
|
||||
protocols that require the ability to reproduce the same stream identically
|
||||
@ -181,7 +180,7 @@ Q_DECLARE_TYPEINFO(CborEncoder, Q_PRIMITIVE_TYPE);
|
||||
\section2 Strict CBOR mode
|
||||
|
||||
Strict mode is defined by
|
||||
\l{https://tools.ietf.org/html/rfc7049#section-3.10}{Section 3.10 of RFC
|
||||
\l{RFC 7049, section 3.10}{Section 3.10 of RFC
|
||||
7049}. As for Canonical encoding above, QCborStreamWriter makes it possible
|
||||
to create strict CBOR streams, but does not require them or validate that
|
||||
the output is so.
|
||||
|
@ -75,7 +75,7 @@ QT_BEGIN_NAMESPACE
|
||||
binary data encoding that is a superset of JSON. It was created by the IETF
|
||||
Constrained RESTful Environments (CoRE) WG, which has used it in many
|
||||
new RFCs. It is meant to be used alongside the
|
||||
\l{https://tools.ietf.org/html/rfc7252}{CoAP protocol}.
|
||||
\l{RFC 7252}{CoAP protocol}.
|
||||
|
||||
CBOR has three groups of built-in types:
|
||||
|
||||
@ -159,7 +159,7 @@ QT_BEGIN_NAMESPACE
|
||||
|
||||
QCborValue supports all CBOR features required to create canonical and
|
||||
strict streams. It implements almost all of the features specified in \l
|
||||
{https://tools.ietf.org/html/rfc7049}{RFC 7049}.
|
||||
{RFC 7049}.
|
||||
|
||||
The following table lists the CBOR features that QCborValue supports.
|
||||
|
||||
@ -1283,8 +1283,8 @@ inline int QCborContainerPrivate::compareElement_helper(const QCborContainerPriv
|
||||
|
||||
\section3 Sorting order
|
||||
|
||||
Sorting order in CBOR is defined in RFC 7049
|
||||
{https://tools.ietf.org/html/rfc7049#section-3.9}{section 3.9}, which
|
||||
Sorting order in CBOR is defined in
|
||||
\l{RFC 7049, section 3.9}, which
|
||||
discusses the sorting of keys in a map when following the Canonical
|
||||
encoding. According to the specification, "sorting is performed on the
|
||||
bytes of the representation of the key data items" and lists as
|
||||
|
@ -468,7 +468,7 @@ void QJsonValue::swap(QJsonValue &other) noexcept
|
||||
fails the value is replaced by a null JSON value. Note that
|
||||
QVariant::toString() is also lossy for the majority of types. For example,
|
||||
if the passed QVariant is representing raw byte array data, it is recommended
|
||||
to pre-encode it to \l {https://www.ietf.org/rfc/rfc4648.txt}{Base64} (or
|
||||
to pre-encode it to \l {RFC 4686}{Base64} (or
|
||||
another lossless encoding), otherwise a lossy conversion using QString::fromUtf8()
|
||||
will be used.
|
||||
|
||||
|
@ -72,7 +72,7 @@
|
||||
eavesdropping, tampering, or message forgery. The DTLS protocol is based on the
|
||||
stream-oriented Transport Layer Security (TLS) protocol. QtNetwork enables
|
||||
the use of DTLS with User Datagram Protocol (UDP), as defined by
|
||||
\l {https://tools.ietf.org/html/rfc6347}{RFC 6347}.
|
||||
\l {RFC 6347}.
|
||||
|
||||
\section1 Import and Export Restrictions
|
||||
|
||||
|
@ -1143,7 +1143,7 @@ bool QHostAddress::isLoopback() const
|
||||
|
||||
Note that IPv6 unique local unicast addresses are considered global
|
||||
addresses (see isUniqueLocalUnicast()), as are IPv4 addresses reserved for
|
||||
local networks by \l {https://tools.ietf.org/html/rfc1918}{RFC 1918}.
|
||||
local networks by \l {RFC 1918}.
|
||||
|
||||
Also note that IPv6 site-local addresses are deprecated and should be
|
||||
considered as global in new applications. This function returns true for
|
||||
|
@ -234,7 +234,7 @@ bool QHostInfoResult::event(QEvent *event)
|
||||
QHostInfo::localHostName() function.
|
||||
|
||||
QHostInfo uses the mechanisms provided by the operating system
|
||||
to perform the lookup. As per {https://tools.ietf.org/html/rfc6724}{RFC 6724}
|
||||
to perform the lookup. As per \l {RFC 6724}
|
||||
there is no guarantee that all IP addresses registered for a domain or
|
||||
host will be returned.
|
||||
|
||||
@ -245,8 +245,7 @@ bool QHostInfoResult::event(QEvent *event)
|
||||
\note Since Qt 4.6.3 QHostInfo is using a small internal 60 second DNS cache
|
||||
for performance improvements.
|
||||
|
||||
\sa QAbstractSocket, {http://www.rfc-editor.org/rfc/rfc3492.txt}{RFC 3492},
|
||||
{https://tools.ietf.org/html/rfc6724}{RFC 6724}
|
||||
\sa QAbstractSocket, {RFC 3492}, {RFC 6724}
|
||||
*/
|
||||
|
||||
static int nextId()
|
||||
|
@ -58,7 +58,7 @@
|
||||
|
||||
The QDtlsClientVerifier class implements server-side DTLS cookie generation
|
||||
and verification. Datagram security protocols are highly susceptible to a
|
||||
variety of Denial-of-Service attacks. According to \l {https://tools.ietf.org/html/rfc6347#section-4.2.1}{RFC 6347, section 4.2.1},
|
||||
variety of Denial-of-Service attacks. According to \l {RFC 6347, section 4.2.1},
|
||||
these are two of the more common types of attack:
|
||||
|
||||
\list
|
||||
@ -71,7 +71,7 @@
|
||||
which can be quite large, thus flooding the victim machine with datagrams.
|
||||
\endlist
|
||||
|
||||
As a countermeasure to these attacks, \l {https://tools.ietf.org/html/rfc6347#section-4.2.1}{RFC 6347, section 4.2.1}
|
||||
As a countermeasure to these attacks, \l {RFC 6347, section 4.2.1}
|
||||
proposes a stateless cookie technique that a server may deploy:
|
||||
|
||||
\list
|
||||
@ -119,7 +119,7 @@
|
||||
|
||||
\note The default secret is shared by all objects of the classes QDtlsClientVerifier
|
||||
and QDtls. Since this can impose security risks, RFC 6347 recommends to change
|
||||
the server's secret frequently. Please see \l {https://tools.ietf.org/html/rfc6347}{RFC 6347, section 4.2.1}
|
||||
the server's secret frequently. Please see \l {RFC 6347, section 4.2.1}
|
||||
for hints about possible server implementations. Cookie generator parameters
|
||||
can be set using the class QDtlsClientVerifier::GeneratorParameters and
|
||||
setCookieGeneratorParameters():
|
||||
@ -250,7 +250,7 @@
|
||||
\warning It's recommended to call shutdown() before destroying the client's QDtls
|
||||
object if you are planning to re-use the same port number to connect to the
|
||||
server later. Otherwise, the server may drop incoming ClientHello messages,
|
||||
see \l{https://tools.ietf.org/html/rfc6347#page-25}{RFC 6347, section 4.2.8}
|
||||
see \l {RFC 6347, section 4.2.8}
|
||||
for more details and implementation hints.
|
||||
|
||||
If the server does not use QDtlsClientVerifier, it \e must configure its
|
||||
|
@ -95,7 +95,7 @@ QT_BEGIN_NAMESPACE
|
||||
\inmodule QtNetwork
|
||||
|
||||
|
||||
This enumeration describes revocation reasons, defined in \l{https://tools.ietf.org/html/rfc5280#section-5.3.1}{RFC 5280, section 5.3.1}
|
||||
This enumeration describes revocation reasons, defined in \l{RFC 5280, section 5.3.1}
|
||||
|
||||
\value None
|
||||
\value Unspecified
|
||||
|
@ -60,7 +60,7 @@ namespace QPasswordDigestor {
|
||||
\since 5.12
|
||||
|
||||
Returns a hash computed using the PBKDF1-algorithm as defined in
|
||||
\l {https://tools.ietf.org/html/rfc8018#section-5.1} {RFC 8018}.
|
||||
\l {RFC 8018, section 5.1}.
|
||||
|
||||
The function takes the \a data and \a salt, and then hashes it repeatedly
|
||||
for \a iterations iterations using the specified hash \a algorithm. If the
|
||||
@ -126,7 +126,7 @@ Q_NETWORK_EXPORT QByteArray deriveKeyPbkdf1(QCryptographicHash::Algorithm algori
|
||||
\since 5.12
|
||||
|
||||
Derive a key using the PBKDF2-algorithm as defined in
|
||||
\l {https://tools.ietf.org/html/rfc8018#section-5.2} {RFC 8018}.
|
||||
\l {RFC 8018, section 5.2}.
|
||||
|
||||
This function takes the \a data and \a salt, and then applies HMAC-X, where
|
||||
the X is \a algorithm, repeatedly. It internally concatenates intermediate
|
||||
|
@ -204,7 +204,7 @@ Q_LOGGING_CATEGORY(lcSsl, "qt.network.ssl");
|
||||
\ingroup ssl
|
||||
\inmodule QtNetwork
|
||||
|
||||
See \l{https://tools.ietf.org/html/rfc8446#page-85}{RFC 8446, section 6}
|
||||
See \l{RFC 8446, section 6}
|
||||
for the possible values and their meaning.
|
||||
|
||||
\value CloseNotify,
|
||||
|
@ -2083,7 +2083,7 @@ DtlsBase::~DtlsBase() = default;
|
||||
and \c false otherwise. If no valid cookie was found in the \a dgram, this verifier should use
|
||||
\a socket to send a HelloVerifyRequest message, using \a address and \a port as the destination
|
||||
and a source material for cookie generation, see also
|
||||
\l {https://tools.ietf.org/html/rfc6347#section-4.2.1}{RFC 6347, section 4.2.1}
|
||||
\l {RFC 6347, section 4.2.1}
|
||||
|
||||
\sa QDtlsClientVerifier
|
||||
*/
|
||||
|
Loading…
Reference in New Issue
Block a user