Subject: Re: [regext] [Technical Errata Reported] RFC7482 (5621)

From: Andrew Newton <[email-masked]>
Date: Mon, 4 Mar 2019 16:14:27 -0500

I agree.

-andy

On Tue, Feb 26, 2019 at 2:43 PM Hollenbeck, Scott
<shollenbeck=[email-masked]> wrote:
>
> > -----Original Message-----
> > From: RFC Errata System <[email-masked]>
> > Sent: Friday, February 1, 2019 12:40 PM
> > To: [email-masked]; Hollenbeck, Scott <[email-masked]>;
> > [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: [EXTERNAL] [Technical Errata Reported] RFC7482 (5621)
> >
> > The following errata report has been submitted for RFC7482, "Registration
> > Data Access Protocol (RDAP) Query Format".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5621
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: John Klensin <[email-masked]>
> >
> > Section: 2.1
> >
> > Original Text
> > -------------
> > IDN: Internationalized Domain Name
> >
> > IDNA: Internationalized Domain Names in Applications, a protocol
> >       for the handling of IDNs.
> >
> > Corrected Text
> > --------------
> > IDN: Internationalized Domain Name, a [fully-qualified] domain name
> > containing one or more labels that are intended to include one or more
> > Unicode code points outside the ASCII range (cf. "domain name", "fully-
> > qualified domain name" and "internationalized domain name" in RFC 8499).
> >
> > IDNA: Internationalized Domain Names in Applications, a protocol for the
> > handling of IDNs.  In this document, "IDNA" refers specifically to the version
> > of those specifications known as "IDNA2008" [RFC5980 ff].
> >
> >
> > Notes
> > -----
> > While the proposed new text above borders on the painfully pedantic,
> > failure to be specific about these things undermines the technical validity and
> > consistency of the text (making this a technical issue rather than exclusively
> > an editorial one like a missing reference).  IDNA2008 [RFC5890 Section
> > 2.3.2.3] is very precise about what an "IDN" is (a definition incorporated by
> > reference in RFC 6365 and consistent with the definition in RFC 8499) , but
> > there are other things around that, e.g., assume either that "IDN" refers to a
> > label, not an FQDN; that an ASCII label, even one in ACE form, does not make
> > the FQDN in which it is imbedded an IDN; that all of the label components of
> > an IDN must be U-labels or A-labels, etc.  Without the definition being clear,
> > some of the statements in the document make no sense.
> >
> > A reference to 8499 is suggested above because it is the most recent
> > authoritative definition (and because I didn't write it), but 5980 would be
> > equally legitimate if the authors prefer.
> >
> > Pinning down the IDNA definition is even more important.  While there are
> > IDNA2008 references further on in the document, if the question of what the
> > generic term "IDNA" means is left to the imagination of the reader, then the
> > specification is missing language about what to do if, e.g., a query is
> > inconsistent with the U-label form of what is stored in the registry database
> > without mapping.   The opportunity for that sort of problem is clearly created
> > by the "performs any local case mapping deemed necessary" statement in
> > Section 6.1 of the document, at least unless that case mapping is constrained
> > to not be applied to domain name labels (which the text definitely does not
> > say).
>
> Some of the other acronyms in this section of RFC 7482 include references, so I think it's appropriate for these to be included as well. They do help with clarity and precision.
>
> Scott
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 5 Mar 2019 13:34:35 +0000

OK, I'll confirm it since no one has raised any objections.

Scott

> From: Andrew Newton <[email-masked]>
> Sent: Monday, March 4, 2019 4:14 PM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [regext] [Technical Errata Reported] RFC7482 (5621)
>
> I agree.
>
> -andy
>
> > > The following errata report has been submitted for RFC7482,
> > > "Registration Data Access Protocol (RDAP) Query Format".
> > >
> > > containing one or more labels that are intended to include one or
> > > more Unicode code points outside the ASCII range (cf. "domain name",
> > > "fully- qualified domain name" and "internationalized domain name" in
> RFC 8499).
> > >
> > > IDNA: Internationalized Domain Names in Applications, a protocol for
> > > the handling of IDNs.  In this document, "IDNA" refers specifically
> > > to the version of those specifications known as "IDNA2008" [RFC5980 ff].
> > >
> > >
> > > Notes
> > > -----
> > > failure to be specific about these things undermines the technical
> > > validity and consistency of the text (making this a technical issue
> > > rather than exclusively an editorial one like a missing reference).
> > > IDNA2008 [RFC5890 Section 2.3.2.3] is very precise about what an
> > > "IDN" is (a definition incorporated by reference in RFC 6365 and
> > > consistent with the definition in RFC 8499) , but there are other
> > > things around that, e.g., assume either that "IDN" refers to a
> > > label, not an FQDN; that an ASCII label, even one in ACE form, does
> > > not make the FQDN in which it is imbedded an IDN; that all of the
> > > label components of an IDN must be U-labels or A-labels, etc.  Without
> the definition being clear, some of the statements in the document make no
> sense.
> > >
> > > authoritative definition (and because I didn't write it), but 5980
> > > would be equally legitimate if the authors prefer.
> > >
> > > IDNA2008 references further on in the document, if the question of
> > > what the generic term "IDNA" means is left to the imagination of the
> > > reader, then the specification is missing language about what to do
> > > if, e.g., a query is inconsistent with the U-label form of what is stored in
> the registry database
> > > by the "performs any local case mapping deemed necessary" statement
> > > in Section 6.1 of the document, at least unless that case mapping is
> > > constrained to not be applied to domain name labels (which the text
> > > definitely does not say).
> >
> > Some of the other acronyms in this section of RFC 7482 include references,
> so I think it's appropriate for these to be included as well. They do help with
> clarity and precision.
> >
> > Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 5 Mar 2019 13:45:05 +0000

Someone with appropriate access will need to document our verification of this report:

"This page is for use by specified members of the IAB, IESG, IRSG, RFC Editorial Board, and the RFC Editor. Please contact [email-masked] with questions.".

Scott

---

From: Adam Roach <[email-masked]>
Date: Tue, 5 Mar 2019 14:19:46 -0600

Thanks. I have marked this as "Verified." I changed the type to "Editorial."

/a

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Mar 2019 15:31:31 -0500

Adam,

For the reason mentioned in the first sentence of my "Notes" on
the original submission, I believe this is actually a technical
error rather than an editorial one.  Without the changes
specified (or something equivalent), it is possible (indeed
likely) for readers to interpret the spec and how to implement
it in multiple ways that would not interoperate cleanly.  That
is a technical defect, not merely less-than-optimal phrasing or
a similar editorial issue.

I don't, however, consider that a big deal as long as there is a
clear clarification and a clear stake in the ground for any
future revision or replacement document.  Any verified erratum
accomplishes that, so suit yourself.

best,
   john

--On Tuesday, March 5, 2019 14:19 -0600 Adam Roach
<[email-masked]> wrote:

>>> Cc: [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked];
>>> [email-masked] Subject: [EXTERNAL] Re: [regext] [Technical
>>> Errata Reported] RFC7482 (5621)
>>> 
>>> I agree.
>>> 
>>> -andy
>>> 
>>>>> To: [email-masked]; Hollenbeck, Scott
>>>>> <[email-masked]>; [email-masked];
>>>>> [email-masked]; [email-masked];
>>>>> Cc: [email-masked]; [email-masked];
>>>>> [email-masked] Subject: [EXTERNAL] [Technical
>>>>> Errata Reported] RFC7482 (5621)
>>>>> 
>>>>> IDNA: Internationalized Domain Names in Applications, a
>>>>> protocol for the handling of IDNs.
>>>>> 
>>>>> Corrected Text
>>>>> --------------
>>>>> IDN: Internationalized Domain Name, a [fully-qualified]
>>>>> domain name containing one or more labels that are
>>>>> intended to include one or more Unicode code points
>>>>> outside the ASCII range (cf. "domain name", "fully-
>>>>> qualified domain name" and "internationalized domain name"
>>>>> in
>>> RFC 8499).
>>>>> IDNA: Internationalized Domain Names in Applications, a
>>>>> protocol for the handling of IDNs.  In this document,
>>>>> "IDNA" refers specifically to the version of those
>>>>> specifications known as "IDNA2008" [RFC5980 ff].
>>>>> 
>>>>> 
>>>>> Notes
>>>>> -----
>>>>> While the proposed new text above borders on the painfully
>>>>> pedantic, failure to be specific about these things
>>>>> undermines the technical validity and consistency of the
>>>>> text (making this a technical issue rather than
>>>>> exclusively an editorial one like a missing reference).
>>>>> IDNA2008 [RFC5890 Section 2.3.2.3] is very precise about
>>>>> what an "IDN" is (a definition incorporated by reference
>>>>> in RFC 6365 and consistent with the definition in RFC
>>>>> 8499) , but there are other things around that, e.g.,
>>>>> assume either that "IDN" refers to a label, not an FQDN;
>>>>> that an ASCII label, even one in ACE form, does not make
>>>>> the FQDN in which it is imbedded an IDN; that all of the
>>> the definition being clear, some of the statements in the
>>> document make no sense.
>>>>> A reference to 8499 is suggested above because it is the
>>>>> most recent authoritative definition (and because I didn't
>>>>> write it), but 5980 would be equally legitimate if the
>>>>> authors prefer.
>>>>> 
>>>>> IDNA2008 references further on in the document, if the
>>>>> question of what the generic term "IDNA" means is left to
>>>>> the imagination of the reader, then the specification is
>>>>> missing language about what to do if, e.g., a query is
>>>>> without mapping.   The opportunity for that sort of
>>>>> problem is clearly
>>> created
>>>>> by the "performs any local case mapping deemed necessary"
>>>>> statement in Section 6.1 of the document, at least unless
>>>>> that case mapping is constrained to not be applied to
>>>>> domain name labels (which the text definitely does not
>>>>> say).
>>> so I think it's appropriate for these to be included as
>>> well. They do help with clarity and precision.
>>>> Scott