Re: [Technical Errata Reported] RFC7622 (5769)
Dave Cridland <[email protected]> Mon, 1 Jul 2019 23:10:48 +0100
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <CAKHUCzwg6sPtN0Dp6zPfKT75+DbfE0xies3Wv7GujXes6jY0Ng@mail.gmail.com> |
--===============7960845280047621545== Content-Type: multipart/alternative; boundary="000000000000245cf6058ca5e70e" --000000000000245cf6058ca5e70e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 1 Jul 2019 at 14:18, Barry Leiba <[email protected]> wrote: > > > 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. > > OK, so there's more to it than that. > > Hold your horses - I'm not sure that's actually true. In particular: a) I don't think that IPv4/IPv6 addresses actually belong there. Some existing client libraries and servers can handle that, but it's not clear it works outside a single server (ie, with S2S links). At best, this would be a SHOULD NOT in my opinion. 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.ietf.org/html/rfc6120#section-3.2 b) Arbitrary labels are syntactically the same as U-Labels. If anyone wants them to be different, I'm willing to mud-wrestle them for it, and nobody should want that. c) I don't think we want A-Labels. It's just going to cause confusion - is =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD the same as xn--vhqr8o.xn--fiqs8s?= They always look up the same in DNS, after all, by definition. I can't see why we'd think allowing them wasn't going to cause problems. So, again, a SHOULD NOT if not a MUST NOT. > > > 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= .. > > 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? > Clearly, =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD is OK. Is this text meant= to allow > xn--vhqr8o.xn--fiqs8s ? The text certainly says no, explicitly, but > "this means that" doesn't follow from the list of characters that are > allowed. The text seems odd in that regard. > > > 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 o= f > > the semantic of the string, instead of simply checking and performing o= n > > operations codepoints. But there is probably no use case for R-LDH > > labels in domainparts. > > But that's already necessary because of what the text says about A-labels= .. > > > > 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 > 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. 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. > > 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 think Peter is the best > person to answer that, as he wrote the text and might remember why it > was said that way. > > > 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: > > > > > > 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 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) > > 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. > > And, Florian, thanks for making the errata report and for the quick > response to discussion. > > Barry > > _______________________________________________ > xmpp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/xmpp > --000000000000245cf6058ca5e70e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, 1 Jul 2019 at 14:18, Barry Le= iba <<a href=3D"mailto:[email protected]">[email protected]<= /a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&= gt; > 1. Is this bit of text intended to say that "domainpart"= has to<br> > > *consist of* NR-LDH labels and U-labels, rather than to contain<b= r> > > 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 identifie= rs)<br> >=C2=A0 =C2=A0Those are potentially longer strings then DNS labels are a= llowed to<br> >=C2=A0 =C2=A0be.<br> <br> OK, so there's more to it than that.<br> <br></blockquote><div><br></div><div>Hold your horses - I'm not sure th= at's actually true.</div><div><br></div><div>In particular:</div><div><= br></div><div>a) I don't think that IPv4/IPv6 addresses actually belong= there. Some existing client libraries and servers can handle that, but it&= #39;s not clear it works outside a single server (ie, with S2S links). At b= est, this would be a SHOULD NOT in my opinion. For a start, most of the res= t of the langauge makes no sense, since it assumes these things can be the = subject of a DNS request - see, for example,=C2=A0<a href=3D"https://tools.= ietf.org/html/rfc6120#section-3.2">https://tools.ietf.org/html/rfc6120#sect= ion-3.2</a></div><div><br></div><div>b) Arbitrary labels are syntactically = the same as U-Labels. If anyone wants them to be different, I'm willing= to mud-wrestle them for it, and nobody should want that.</div><div><br></d= iv><div>c) I don't think we want A-Labels. It's just going to cause= confusion - is=C2=A0=E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD the same as=C2= =A0xn--vhqr8o.xn--fiqs8s? They always look up the same in DNS, after all, b= y definition. I can't see why we'd think allowing them wasn't g= oing to cause problems. So, again, a SHOULD NOT if not a MUST NOT.</div><di= v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-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-label= s.<br> <br> Of course; the point is the other way around: because A-label<br> characters are valid, A-labels could be put there.=C2=A0 Do we want that?<b= r> Clearly, =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD is OK.=C2=A0 Is this text me= ant to allow<br> xn--vhqr8o.xn--fiqs8s ?=C2=A0 The text certainly says no, explicitly, but<b= r> "this means that" doesn't follow from the list of characters = that are<br> allowed.=C2=A0 The text seems odd in that regard.<br> <br> > I think R-LDH labels should not be explicitly disallowed, as this woul= d<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. But there is probably no use case for R-LDH<br> > labels in domainparts.<br> <br> But that's already necessary because of what the text says about A-labe= ls.<br> <br> > > 2. Earlier, in Section 3.8, is this text that seems rather odd to= me:<br> > ><br> > >=C2=A0 =C2=A0 If the domainpart includes a final character conside= red to be a label<br> > >=C2=A0 =C2=A0 separator (dot) by [RFC1034]<br> > ><br> > > When I look at RFC 1034, I see that there's no mention of lab= el<br> > > separator at all, and no set of characters that are considered to= be<br> > > so.=C2=A0 It simply says:<br> > ><br> > >=C2=A0 =C2=A0 When a user needs to type a domain name, the length = of each label is<br> > >=C2=A0 =C2=A0 omitted and the labels are separated by dots ("= ..").<br> > ><br> > > Is there a reason for that specific text in Section 3.2, or are w= e<br> > > just looking for the 'DNS label separator "dot" (U+= 002E, FULL STOP)'<br> > > as suggested in the errata report?<br> ><br> > I think so.<br> <br> That's an "Is it A or B" question, so "I think so" = doesn't answer it.<br> So I'll change the question and just ask if there's a reason to use= <br> that text in Section 3.2 that cites 1034.=C2=A0 I think Peter is the best<b= r> person to answer that, as he wrote the text and might remember why it<br> was said that way.<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.<br> ><br> > > My sense is that the intended replacement *might* be this, though= I'm<br> > > not sure and need discussion/confirmation:<br> > ><br> > >=C2=A0 =C2=A0 An entity that prepares a string for inclusion in an= XMPP<br> > > domainpart slot MUST<br> > >=C2=A0 =C2=A0 ensure that the string consists only of NR-LDH label= s and U-labels,<br> > > as defined<br> > >=C2=A0 =C2=A0 in [RFC5890], separated by the DNS label separator &= quot;dot" (U+002E, FULL STOP).<br> ><br> > I just occurred to me, after submitting the errata of course, that thi= s<br> > may not be enough. Since domainparts can also act as holder for IPv6<b= r> > addresses, we also need to allow ':', '[' and ']&#= 39;, as they are also not<br> > valid characters in NR-LDH labels and U-labels.<br> ><br> > Hence my refined replacement text would be:<br> ><br> >=C2=A0 =C2=A0An entity that prepares a string for inclusion in an XMPP = domainpart<br> >=C2=A0 =C2=A0slot MUST ensure that the string consists only of<br> >=C2=A0 =C2=A0- codepoints allowed in NR-LDH labels and U-labels, as def= ined in<br> >=C2=A0 =C2=A0 =C2=A0[RFC5890]<br> >=C2=A0 =C2=A0- . U+002E (FULL STOP, DNS label separator "dot"= )<br> >=C2=A0 =C2=A0- : U+003A (COLON)<br> >=C2=A0 =C2=A0- ] U+005B (LEFT SQUARE BRACKET)<br> >=C2=A0 =C2=A0- [ 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 in= tent<br> and correct fix.=C2=A0 But I'd very much like to hear from Peter and/or= Joe<br> before we settle this.<br> <br> And, Florian, thanks for making the errata report and for the quick<br> response to discussion.<br> <br> Barry<br> <br> _______________________________________________<br> xmpp mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/xmpp" rel=3D"noreferrer" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/xmpp</a><br> </blockquote></div></div> --000000000000245cf6058ca5e70e-- --===============7960845280047621545== 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 --===============7960845280047621545==--