Re: [Technical Errata Reported] RFC7622 (5769)
Barry Leiba <[email protected]> Mon, 1 Jul 2019 18:16:00 -0400
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <CALaySJKcozQ7sQJvQHMVq2m9mFT2=jXc5wVd=pqMWSZK_=Qr7A@mail.gmail.com> |
--===============8005271906126865184== Content-Type: multipart/alternative; boundary="000000000000d4ee78058ca5f95d" --000000000000d4ee78058ca5f95d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable More evidence that correcting this properly goes to =E2=80=9CHeld for Docum= ent Update=E2=80=9D. There needs to be proper discussion and arrival at consen= sus, beyond the scope of an errata report. Barry On Mon, Jul 1, 2019 at 6:11 PM Dave Cridland <[email protected]> wrote: > > > 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 woul= d > 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--fiqs8= s? 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-label= s. >> >> 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 mean= t 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 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. >> >> But that's already necessary because of what the text says about A-label= s. >> >> > > 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-label= s, >> > > 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) >> >> 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 >> > --000000000000d4ee78058ca5f95d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div><div dir=3D"auto">More evidence that correcting this properly goes to = =E2=80=9CHeld for Document Update=E2=80=9D.=C2=A0 There needs to be proper = discussion and arrival at consensus, beyond the scope of an errata report.<= /div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Barry</div><div><b= r><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:[email protected]= t">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= ><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 L= eiba <<a href=3D"mailto:[email protected]" target=3D"_blank">barry= [email protected]</a>> wrote:<br></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">> > 1. Is this bit of text intended to say that &qu= ot;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" target=3D"_blank">https://tools.ietf.org= /html/rfc6120#section-3.2</a></div><div><br></div><div>b) Arbitrary labels = are syntactically the same as U-Labels. If anyone wants them to be differen= t, I'm willing to mud-wrestle them for it, and nobody should want that.= </div><div><br></div><div>c) I don't think we want A-Labels. It's j= ust 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, 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.</div><div>=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-lef= t: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.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></blockquote></div></div><div dir=3D"ltr"><div class=3D"gmail_quote"><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex"> _______________________________________________<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> </blockquote></div></div> --000000000000d4ee78058ca5f95d-- --===============8005271906126865184== 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 --===============8005271906126865184==--