Re: [Technical Errata Reported] RFC7622 (5769)
Matthias Wimmer <[email protected]> Tue, 02 Jul 2019 00:53:36 +0200
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <[email protected]> |
--===============7042625864380811815==
Content-Type: multipart/alternative;
boundary="----TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ"
Content-Transfer-Encoding: 7bit
------TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I'd also like to point to http://unicode=2Eorg/reports/tr46/#Notation
According to the definition there labels are not only separated by U+002E =
but also three other types of full stops as well=2E
This definition has also been in RFC3490 section 4 (IDNA2003) but I cannot=
find it explicitly in IDNA2008=2E Not even in the list of things that have=
changed=2E
For the given example of =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD I think a=
Chinese user would more likely enter =E5=95=86=E4=B8=9A=E3=80=82=E4=B8=AD=
=E5=9B=BD because while entering Chinese characters there is no key on the =
keyboard, that would enter a Western full stop=2E So to enter =E5=95=86=E4=
=B8=9A=2E=E4=B8=AD=E5=9B=BD he would have to change his keyboard layout at =
least twice=2E
Regards,
Matthias
Am 2=2E Juli 2019 00:16:00 MESZ schrieb Barry Leiba <barryleiba@computer=
=2Eorg>:
>More evidence that correcting this properly goes to =E2=80=9CHeld for Doc=
ument
>Update=E2=80=9D=2E There needs to be proper discussion and arrival at co=
nsensus,
>beyond the scope of an errata report=2E
>
>Barry
>
>On Mon, Jul 1, 2019 at 6:11 PM Dave Cridland <dave@cridland=2Enet> wrote:
>
>>
>>
>> On Mon, 1 Jul 2019 at 14:18, Barry Leiba <barryleiba@computer=2Eorg>
>wrote:
>>
>>> > > 1=2E 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=2E
>>>
>>> OK, so there's more to it than that=2E
>>>
>>>
>> Hold your horses - I'm not sure that's actually true=2E
>>
>> In particular:
>>
>> a) I don't think that IPv4/IPv6 addresses actually belong there=2E Some
>> existing client libraries and servers can handle that, but it's not
>clear
>> it works outside a single server (ie, with S2S links)=2E At best, this
>would
>> be a SHOULD NOT in my opinion=2E For a start, most of the rest of the
>> langauge makes no sense, since it assumes these things can be the
>subject
>> of a DNS request - see, for example,
>> https://tools=2Eietf=2Eorg/html/rfc6120#section-3=2E2
>>
>> b) Arbitrary labels are syntactically the same as U-Labels=2E If anyone
>> wants them to be different, I'm willing to mud-wrestle them for it,
>and
>> nobody should want that=2E
>>
>> c) I don't think we want A-Labels=2E It's just going to cause confusion
>-
>> is =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD the same as xn--vhqr8o=2Exn-=
-fiqs8s? They always look up the
>same in
>> DNS, after all, by definition=2E I can't see why we'd think allowing
>them
>> wasn't going to cause problems=2E So, again, a SHOULD NOT if not a MUST
>NOT=2E=2E
>>
>>
>>> > > 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=2E
>>>
>>> Of course; the point is the other way around: because A-label
>>> characters are valid, A-labels could be put there=2E Do we want that?
>>> Clearly, =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD is OK=2E Is this tex=
t meant to allow
>>> xn--vhqr8o=2Exn--fiqs8s ? The text certainly says no, explicitly, but
>>> "this means that" doesn't follow from the list of characters that
>are
>>> allowed=2E The text seems odd in that regard=2E
>>>
>>> > 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=2E But there is probably no use case for R-LDH
>>> > labels in domainparts=2E
>>>
>>> But that's already necessary because of what the text says about
>A-labels=2E
>>>
>>> > > 2=2E Earlier, in Section 3=2E8, is this text that seems rather odd
>to me:
>>> > >
>>> > > If the domainpart includes a final character considered to be
>a
>>> label
>>> > > 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=2E 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 ("=2E")=2E
>>> > >
>>> > > Is there a reason for that specific text in Section 3=2E2, or are
>we
>>> > > just looking for the 'DNS label separator "dot" (U+002E, FULL
>STOP)'
>>> > > as suggested in the errata report?
>>> >
>>> > I think so=2E
>>>
>>> That's an "Is it A or B" question, so "I think so" doesn't answer
>it=2E
>>> So I'll change the question and just ask if there's a reason to use
>>> that text in Section 3=2E2 that cites 1034=2E I think Peter is the be=
st
>>> person to answer that, as he wrote the text and might remember why
>it
>>> was said that way=2E
>>>
>>> > 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=2E
>>> >
>>> > > 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)=2E
>>> >
>>> > I just occurred to me, after submitting the errata of course, that
>this
>>> > may not be enough=2E 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=2E
>>> >
>>> > 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]
>>> > - =2E U+002E (FULL STOP, DNS label separator "dot")
>>> > - : U+003A (COLON)
>>> > - ] U+005B (LEFT SQUARE BRACKET)
>>> > - [ U+005D (RIGHT SQUARE BRACKET)
>>>
>>> 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=2E But I'd very much like to hear from Peter and/or
>Joe
>>> before we settle this=2E
>>>
>>> And, Florian, thanks for making the errata report and for the quick
>>> response to discussion=2E
>>>
>>> Barry
>>>
>>> _______________________________________________
>>> xmpp mailing list
>>> xmpp@ietf=2Eorg
>>> https://www=2Eietf=2Eorg/mailman/listinfo/xmpp
>>>
>>
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>I'd also like to point to <a href=3D"http://unicod=
e=2Eorg/reports/tr46/#Notation">http://unicode=2Eorg/reports/tr46/#Notation=
</a><br><br>According to the definition there labels are not only separated=
by U+002E but also three other types of full stops as well=2E<br><br>This =
definition has also been in RFC3490 section 4 (IDNA2003) but I cannot find =
it explicitly in IDNA2008=2E Not even in the list of things that have chang=
ed=2E<br><br>For the given example of =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=
=BD I think a Chinese user would more likely enter =E5=95=86=E4=B8=9A=E3=80=
=82=E4=B8=AD=E5=9B=BD because while entering Chinese characters there is no=
key on the keyboard, that would enter a Western full stop=2E So to enter =
=E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD he would have to change his keyboar=
d layout at least twice=2E<br><br><br>Regards,<br>Matthias<br><br><div clas=
s=3D"gmail_quote">Am 2=2E Juli 2019 00:16:00 MESZ schrieb Barry Leiba <b=
arryleiba@computer=2Eorg>:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204); paddin=
g-left: 1ex;">
<div><div dir=3D"auto">More evidence that correcting this properly goes to=
=E2=80=9CHeld for Document Update=E2=80=9D=2E There needs to be prop=
er discussion and arrival at consensus, beyond the scope of an errata repor=
t=2E</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Barry</div><d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Mon, Jul 1, 2019 at 6:11 PM Dave Cridland <<a href=3D"mailto:dave@cridla=
nd=2Enet">dave@cridland=2Enet</a>> wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 =2E8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 1 Jul 2019 at 14:=
18, Barry Leiba <<a href=3D"mailto:barryleiba@computer=2Eorg" target=3D"=
_blank">barryleiba@computer=2Eorg</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=2E8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">> > 1=2E Is this bit of text inten=
ded to say that "domainpart" has to<br>
> > *consist of* NR-LDH labels and U-labels, rather than to contain<=
br>
> > characters valid for those?<br>
><br>
> XMPP domainparts may contain<br>
> - IPv4/v6 addresses<br>
> - DNS names<br>
> - "Hostnames" (more or less arbitrary XMPP service identifiers)<br>
> Those are potentially longer strings then DNS labels are =
allowed to<br>
> be=2E<br>
<br>
OK, so there's more to it than that=2E<br>
<br></blockquote><div><br></div><div>Hold your horses - I'm not sure that'=
s actually true=2E</div><div><br></div><div>In particular:</div><div><br></=
div><div>a) I don't think that IPv4/IPv6 addresses actually belong there=2E=
Some existing client libraries and servers can handle that, but it's not c=
lear it works outside a single server (ie, with S2S links)=2E At best, this=
would be a SHOULD NOT in my opinion=2E For a start, most of the rest of th=
e langauge makes no sense, since it assumes these things can be the subject=
of a DNS request - see, for example, <a href=3D"https://tools=2Eietf=
=2Eorg/html/rfc6120#section-3=2E2" target=3D"_blank">https://tools=2Eietf=
=2Eorg/html/rfc6120#section-3=2E2</a></div><div><br></div><div>b) Arbitrary=
labels are syntactically the same as U-Labels=2E If anyone wants them to b=
e different, I'm willing to mud-wrestle them for it, and nobody should want=
that=2E</div><div><br></div><div>c) I don't think we want A-Labels=2E It's=
just going to cause confusion - is =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=
=9B=BD the same as xn--vhqr8o=2Exn--fiqs8s? They always look up the sa=
me in DNS, after all, by definition=2E I can't see why we'd think allowing =
them wasn't going to cause problems=2E So, again, a SHOULD NOT if not a MUS=
T NOT=2E</div><div> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0=2E8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"></blockquote></div></div><div dir=3D"ltr"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=2E8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
> > Characters valid for those are also valid<br>
> > for R-LDH labels and A-labels as well,<br>
><br>
> Not every code point which is valid for U-labels is allowed in A-labe=
ls=2E<br>
<br>
Of course; the point is the other way around: because A-label<br>
characters are valid, A-labels could be put there=2E Do we want that=
?<br>
Clearly, =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD is OK=2E Is this te=
xt meant to allow<br>
xn--vhqr8o=2Exn--fiqs8s ? The text certainly says no, explicitly, bu=
t<br>
"this means that" doesn't follow from the list of characters that are<br>
allowed=2E The text seems odd in that regard=2E<br>
<br>
> I think R-LDH labels should not be explicitly disallowed, as this wou=
ld<br>
> mean that the PRECIS profile for XMPP addresses needs to become aware=
of<br>
> the semantic of the string, instead of simply checking and performing=
on<br>
> operations codepoints=2E But there is probably no use case for R-LDH<=
br>
> labels in domainparts=2E<br>
<br>
But that's already necessary because of what the text says about A-labels=
=2E<br>
<br>
> > 2=2E Earlier, in Section 3=2E8, is this text that seems rather o=
dd to me:<br>
> ><br>
> > If the domainpart includes a final character consid=
ered to be a label<br>
> > separator (dot) by [RFC1034]<br>
> ><br>
> > When I look at RFC 1034, I see that there's no mention of label<=
br>
> > separator at all, and no set of characters that are considered t=
o be<br>
> > so=2E It simply says:<br>
> ><br>
> > When a user needs to type a domain name, the length=
of each label is<br>
> > omitted and the labels are separated by dots ("=2E=
=2E")=2E<br>
> ><br>
> > Is there a reason for that specific text in Section 3=2E2, or ar=
e we<br>
> > just looking for the 'DNS label separator "dot" (U+002E, FULL ST=
OP)'<br>
> > as suggested in the errata report?<br>
><br>
> I think so=2E<br>
<br>
That's an "Is it A or B" question, so "I think so" doesn't answer it=2E<br=
>
So I'll change the question and just ask if there's a reason to use<br>
that text in Section 3=2E2 that cites 1034=2E I think Peter is the b=
est<br>
person to answer that, as he wrote the text and might remember why it<br>
was said that way=2E<br>
<br>
> And yes, "label" and "Label separator" in RFC 7622 should<br>
> probably be qualified with DNS and a reference to the relevant<br>
> specifications should be inserted=2E<br>
><br>
> > My sense is that the intended replacement *might* be this, thoug=
h I'm<br>
> > not sure and need discussion/confirmation:<br>
> ><br>
> > An entity that prepares a string for inclusion in a=
n XMPP<br>
> > domainpart slot MUST<br>
> > ensure that the string consists only of NR-LDH labe=
ls and U-labels,<br>
> > as defined<br>
> > in [RFC5890], separated by the DNS label separator =
"dot" (U+002E, FULL STOP)=2E<br>
><br>
> I just occurred to me, after submitting the errata of course, that th=
is<br>
> may not be enough=2E Since domainparts can also act as holder for IPv=
6<br>
> addresses, we also need to allow ':', '[' and ']', as they are also n=
ot<br>
> valid characters in NR-LDH labels and U-labels=2E<br>
><br>
> Hence my refined replacement text would be:<br>
><br>
> An entity that prepares a string for inclusion in an XMPP=
domainpart<br>
> slot MUST ensure that the string consists only of<br>
> - codepoints allowed in NR-LDH labels and U-labels, as de=
fined in<br>
> [RFC5890]<br>
> - =2E U+002E (FULL STOP, DNS label separator "dot")<br>
> - : U+003A (COLON)<br>
> - ] U+005B (LEFT SQUARE BRACKET)<br>
> - [ U+005D (RIGHT SQUARE BRACKET)<br>
<br>
And all that tells me that this is likely to be "Held for Document<br>
Update", if there's more discussion needed to sort out the real intent<br>
and correct fix=2E But I'd very much like to hear from Peter and/or =
Joe<br>
before we settle this=2E<br>
<br>
And, Florian, thanks for making the errata report and for the quick<br>
response to discussion=2E<br>
<br>
Barry<br>
<br></blockquote></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=2E8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
xmpp mailing list<br>
<a href=3D"mailto:xmpp@ietf=2Eorg" target=3D"_blank">xmpp@ietf=2Eorg</a><b=
r>
<a href=3D"https://www=2Eietf=2Eorg/mailman/listinfo/xmpp" rel=3D"noreferr=
er" target=3D"_blank">https://www=2Eietf=2Eorg/mailman/listinfo/xmpp</a><br=
>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail=2E=
Please excuse my brevity=2E</body></html>
------TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ--
--===============7042625864380811815==
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
--===============7042625864380811815==--