Re: [Technical Errata Reported] RFC7622 (5769)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============8293747236318242204==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi
Content-Type: multipart/mixed; boundary="SuWDfjsDxw3AQBV6GxNIguigqI5uOiMRP";
 protected-headers="v1"
From: Florian Schmaus <[email protected]>
To: Barry Leiba <[email protected]>,
 RFC Errata System <[email protected]>
Cc: Peter Saint-Andre <[email protected]>,
 Joe Hildebrand <[email protected]>, Alexey Melnikov
 <[email protected]>, Adam Roach <[email protected]>, [email protected]
Message-ID: <[email protected]>
Subject: Re: [Technical Errata Reported] RFC7622 (5769)
References: <[email protected]>
 <CALaySJJ0t58BgMYE6G9XLFc-ydskvV6CS48d9++8xBfNZ_cLDg@mail.gmail.com>
In-Reply-To: <CALaySJJ0t58BgMYE6G9XLFc-ydskvV6CS48d9++8xBfNZ_cLDg@mail.gmail.com>

--SuWDfjsDxw3AQBV6GxNIguigqI5uOiMRP
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable

On 01.07.19 00:23, Barry Leiba wrote:
> This report seems basically correct to me, though I'm not sure the
> suggested fix is the right one, so let's have some discussion first:
>=20
> 1. Is this bit of text intended to say that "domainpart" has to
> *consist of* NR-LDH labels and U-labels, rather than to contain
> characters valid for those?

XMPP domainparts may contain
- IPv4/v6 addresses
- DNS names
- "Hostnames" (more or less arbitrary XMPP service identifiers)
  Those are potentially longer strings then DNS labels are allowed to
  be.

> Characters valid for those are also valid
> for R-LDH labels and A-labels as well,

Not every code point which is valid for U-labels is allowed in A-labels.

> so it seems a bit of a
> confusing way to define it (in particular, "xn--" are all valid
> characters in U-labels, but my sense is that we do not want labels in
> XMPP "domainpart" to actually be A-labels... right?).  Similarly, do
> we intend to allow R-LDH labels in XMPP "domainpart"?  The characters
> are valid, so they would be allowed by the cited text.

I think R-LDH labels should not be explicitly disallowed, as this would
mean that the PRECIS profile for XMPP addresses needs to become aware of
the semantic of the string, instead of simply checking and performing on
operations codepoints. But there is probably no use case for R-LDH
labels in domainparts.

> 2. Earlier, in Section 3.8, is this text that seems rather odd to me:
>=20
>    If the domainpart includes a final character considered to be a labe=
l
>    separator (dot) by [RFC1034]
>=20
> When I look at RFC 1034, I see that there's no mention of label
> separator at all, and no set of characters that are considered to be
> so.  It simply says:
>=20
>    When a user needs to type a domain name, the length of each label is=

>    omitted and the labels are separated by dots (".").
>=20
> Is there a reason for that specific text in Section 3.2, or are we
> just looking for the 'DNS label separator "dot" (U+002E, FULL STOP)'
> as suggested in the errata report?

I think so. And yes, "label" and "Label separator" in RFC 7622 should
probably be qualified with DNS and a reference to the relevant
specifications should be inserted.

> My sense is that the intended replacement *might* be this, though I'm
> not sure and need discussion/confirmation:
>=20
>    An entity that prepares a string for inclusion in an XMPP
> domainpart slot MUST
>    ensure that the string consists only of NR-LDH labels and U-labels,
> as defined
>    in [RFC5890], separated by the DNS label separator "dot" (U+002E, FU=
LL STOP).

I just occurred to me, after submitting the errata of course, that this
may not be enough. Since domainparts can also act as holder for IPv6
addresses, we also need to allow ':', '[' and ']', as they are also not
valid characters in NR-LDH labels and U-labels.

Hence my refined replacement text would be:

  An entity that prepares a string for inclusion in an XMPP domainpart
  slot MUST ensure that the string consists only of
  - codepoints allowed in NR-LDH labels and U-labels, as defined in
    [RFC5890]
  - . U+002E (FULL STOP, DNS label separator "dot")
  - : U+003A (COLON)
  - ] U+005B (LEFT SQUARE BRACKET)
  - [ U+005D (RIGHT SQUARE BRACKET)

- Florian

> On Sun, Jun 30, 2019 at 5:49 PM RFC Errata System
> <[email protected]> wrote:
>>
>> The following errata report has been submitted for RFC7622,
>> "Extensible Messaging and Presence Protocol (XMPP): Address Format".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid5769
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Florian Schmaus <[email protected]>
>>
>> Section: 3.2.1
>>
>> Original Text
>> -------------
>> An entity that prepares a string for inclusion in an XMPP domainpart
>> slot MUST ensure that the string consists only of Unicode code points
>> that are allowed in NR-LDH labels or U-labels as defined in
>> [RFC5890].
>>
>> Corrected Text
>> --------------
>> An entity that prepares a string for inclusion in an XMPP domainpart
>> slot MUST ensure that the string consists only of Unicode code points
>> that are allowed in NR-LDH labels or U-labels as defined in
>> [RFC5890], or the DNS label separator "dot" (U+002E, FULL STOP).
>>
>> Notes
>> -----
>> The current specification forbids the inclusion of dots (".") in the d=
omainpart, since they are not allowed in NR-LDH nor U-labels. But they sh=
ould be allowed, as otherwise a DNS name could never be put into an XMPP =
domainpart (which is commonly done).
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC7622 (draft-ietf-xmpp-6122bis-24)
>> --------------------------------------
>> Title               : Extensible Messaging and Presence Protocol (XMPP=
): Address Format
>> Publication Date    : September 2015
>> Author(s)           : P. Saint-Andre
>> Category            : PROPOSED STANDARD
>> Source              : Extensible Messaging and Presence Protocol
>> Area                : Applications and Real-Time
>> Stream              : IETF
>> Verifying Party     : IESG



--SuWDfjsDxw3AQBV6GxNIguigqI5uOiMRP--

--Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0ZoH9fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3
NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF
IFIFYgf/Z8nPkid01NoJj3tHJRM/ztvduHjF8Ofs0++pzmf6ZUDu+Wh96alx3yJ+
BBWK6JhPIaK2fs9wnGoJPjdUjsT7DiSfpW15Wrl/TRbBBygSkYKrUcMo+Why0YTd
+6ITznNwvV6MlOVo+gisjzp8V8St7BIcGYnM46t2YYuFnDjlPjeZoIE/c+/YxLbQ
+Tk9J5In0Bo7O9cfneka3VcW2cbLkt9Np2IcpYVq+xJXv09AvfKXzsMCdwU3ySos
B6PHoiIIC9Mseut2BJdbbGwtrgqz8W8ZezKTWuEvA3MMVBLZ1aU4rtZ3vO6MmtwW
Y6HRsfyUNX3IaRtB3lyoXZvzo+ORLA==
=/Nu6
-----END PGP SIGNATURE-----

--Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi--


--===============8293747236318242204==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp

--===============8293747236318242204==--