Re: [Technical Errata Reported] RFC7622 (5769)

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--lXHNt2LmOr9CMvfwEsF2lozJpNeG9ZHQ4
Content-Type: multipart/mixed; boundary="BAf3wkN6BTq1fkgLYoXIVoIgzHKFD1d6d";
 protected-headers="v1"
From: Florian Schmaus <[email protected]>
To: Barry Leiba <[email protected]>
Cc: RFC Errata System <[email protected]>,
 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>
 <[email protected]>
 <CALaySJKztZ40OLNL6Jsvt1wzFgjYzqxUNq3Xj60KwOkAvJGxZA@mail.gmail.com>
In-Reply-To: <CALaySJKztZ40OLNL6Jsvt1wzFgjYzqxUNq3Xj60KwOkAvJGxZA@mail.gmail.com>

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

On 01.07.19 15:18, Barry Leiba wrote:
>>> 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-label=
s.
>=20
> Of course; the point is the other way around: because A-label
> characters are valid, A-labels could be put there.  Do we want that?

I do believe that this is the wrong question. We want to allow every
code point that is allowed in U-labels to be in XMPP domainparts. And
since I believe that every valid code point in an A-label is also a
valid code point of a U-label (could be wrong here), this means that
people could use 'xn--vhqr8o.xn--fiqs8s' as domainpart in their JID.
Thought it is probably not sensible to do so.

If RFC 7622 where to allow U-labels but explicitly disallow A-labels,
then we once again would need to perform a more costly operation on the
String because it would require to check the semantic.


>> I think R-LDH labels should not be explicitly disallowed, as this woul=
d
>> 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.
>=20
> But that's already necessary because of what the text says about A-labe=
ls.

I see. Personally I would simply remove that requirement, since a PRECIS
preparation function can not tell if it is an A-label or just an
hostname which mimics an A-label.

FWIW I'd also remove the "In addition, the string MUST be encoded as
UTF-8 [RFC3629]." requirement, since it bears no benefit. But I am
drifting away from the topic.

>>> 2. Earlier, in Section 3.8, is this text that seems rather odd to me:=

>>>
>>>    If the domainpart includes a final character considered to be a la=
bel
>>>    separator (dot) by [RFC1034]
>>>
>>> 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:
>>>
>>>    When a user needs to type a domain name, the length of each label =
is
>>>    omitted and the labels are separated by dots (".").
>>>
>>> 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.
>=20
> That's an "Is it A or B" question, so "I think so" doesn't answer it.
> So I'll change the question and just ask if there's a reason to use
> that text in Section 3.2 that cites 1034.
I am sorry, I believe there is a specific reason for that: It is
probably to normalize DNS names:

- example.org
- example.org.

are both the same DNS name.

> I think Peter is the best
> person to answer that, as he wrote the text and might remember why it
> was said that way.

Yep. I am also looking forward to some further comments on this from othe=
rs.

>>> My sense is that the intended replacement *might* be this, though I'm=

>>> not sure and need discussion/confirmation:
>>>
>>>    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, =
FULL STOP).
>>
>> I just occurred to me, after submitting the errata of course, that thi=
s
>> may not be enough. Since domainparts can also act as holder for IPv6
>> addresses, we also need to allow ':', '[' and ']', as they are also no=
t
>> 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)
>=20
> And all that tells me that this is likely to be "Held for Document
> Update", if there's more discussion needed to sort out the real intent
> and correct fix.  But I'd very much like to hear from Peter and/or Joe
> before we settle this.

One more refinement of my proposed replacement text (sorry!). I am not
sure why the RFC currently explicitly mentions NR-LDH labels. AFAIKT all
code points in NR-LDH labels are also valid code points in U-labels. I
suppose it could be because U-labels are required to contain at least
one non-ASCII character. But then explicitly mentioning NR-LDH labels
appears to cause unnecessary complexity. It is probably enough and
easier to comprehend if the text simply states:

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

- Florian


--BAf3wkN6BTq1fkgLYoXIVoIgzHKFD1d6d--

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

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

iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0aN3ZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3
NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF
IFI/ogf/fFRu6Zda+V6qB/71mEvTQYl0V/pnrjpR9p8T59+1kpYaDl7SbN7ou2nK
ZzMFQs94ay7qylXnJ77FxfNew8vMSM+vPlLOTEEPJpFnyqSwe69E7y1VnoiM2rt8
xONDwUwOf33kMWzIEzqXPEqKWsWoPqLYnkNJNTeE9vbXlS1zp1Ffpeomxjlzamh9
DLv+FZoL6kshW1U1fk4vUSwDlxGiE2ArJru24yr2Qyx+yEd34rvVh55hASIFa2ew
K8J/tEdQc3GZIN1j+4rqJIAiAvme8pJ5lmNQmALWfYkH3GdVZTJgd36sslLQpeUt
j/rzUorYiW0ED7bD1v7UHnwYq5po0w==
=hp0r
-----END PGP SIGNATURE-----

--lXHNt2LmOr9CMvfwEsF2lozJpNeG9ZHQ4--


--===============2282541016499506379==
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

--===============2282541016499506379==--