Re: [regext] [Errata Verified] RFC7482 (5621)
Howdy, I note John suggests a reference to either RFC 8499 or RFC 5980. The latter is almost certainly meant to be RFC 5890, since that is the definitions and document framework for the IDNA 2008 series. I would disagree, however, that this is a useful reference, since neither RFC 5980 or RFC 5984 (which supplies the rational) actually has a definition of the form this document presumes. RFC 3490 does: An "internationalized domain name" (IDN) is a domain name in which every label is an internationalized label. This implies that every ASCII domain name is an IDN (which implies that it is possible for a name to be an IDN without it containing any non-ASCII characters). This document does not attempt to define an "internationalized host name". Just as has been the case with ASCII names, some DNS zone administrators may impose restrictions, beyond those imposed by DNS or IDNA, on the characters or strings that may be registered as labels in their zones. Such restrictions have no impact on the syntax or semantics of DNS protocol messages; a query for a name that matches no records will yield the same response regardless of the reason why it is not in the zone. Clients issuing queries or interpreting responses cannot be assumed to have any knowledge of zone-specific restrictions or conventions. but given it was obsoleted by RFC 5980, I think you are left with RFC 8499 as the best choice. regards, Ted On Tue, Mar 5, 2019 at 12:18 PM RFC Errata System wrote: > The following errata report has been verified for RFC7482, > "Registration Data Access Protocol (RDAP) Query Format". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5621 > > -- > Status: Verified > Type: Editorial > > Reported by: John Klensin > Date Reported: 2019-02-01 > Verified by: Adam Roach (IESG) > > 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]. > > > 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). > > -- > RFC7482 (draft-ietf-weirds-rdap-query-18) > -- > Title : Registration Data Access Protocol (RDAP) Query Format > Publication Date: March 2015 > Author(s) : A. Newton, S. Hollenbeck > Category: PROPOSED STANDARD > Source : Web Extensible Internet Registration Data Service > Area: Applications > Stream : IETF > Verifying Party : IESG > >
[regext] [Errata Verified] RFC7482 (5621)
The following errata report has been verified for RFC7482, "Registration Data Access Protocol (RDAP) Query Format". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5621 -- Status: Verified Type: Editorial Reported by: John Klensin Date Reported: 2019-02-01 Verified by: Adam Roach (IESG) 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]. 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). -- RFC7482 (draft-ietf-weirds-rdap-query-18) -- Title : Registration Data Access Protocol (RDAP) Query Format Publication Date: March 2015 Author(s) : A. Newton, S. Hollenbeck Category: PROPOSED STANDARD Source : Web Extensible Internet Registration Data Service Area: Applications Stream : IETF Verifying Party : IESG ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [gtld-tech] EPDP recommendations and EPP
On Tue, Mar 5, 2019, at 07:42, Gavin Brown wrote: > > Instead of updating RFC5733 I would suggest creating a new object, > > a "light (or shallow) contact" which is like a contact currently, just with > > less fields. > > Domains could use "full contacts" (the ones we know today) or light > > contacts (the new > > ones). > > I can't see how this would work. Let's say we define a new object > mapping for "light" contacts, with its own namespace, to be used with > just the element in domain objects. > > Could such contacts be used with domains without an update to RFC 5731? Probably not, but so what? You can not just "update" RFC 5733, you will need to write a new one, with a new XML schema, and hence you will need to update RFC 5731 as well. > Could a registrar determine whether a given contact object was a "full" > contact or a "light" without performing an command? Since the registrar created the object in the first place, I do not see the issue there. Also, there may not be a need to mix contacts: a registry can decide to use only one form (if the new schema is constructed in such a way to fit all contacts cases), and hence there is no question. > I think this would cause a huge amount of confusion and pain. Using placeholders creates even more confusion and just tries to go around a schema that does not fit its use anymore... > Furthermore, my research[1] indicates that the "one-to-many" > relationship between domains and contacts that is implicit in EPP does > not reflect reality, And yet in the nearly 20 years of existence of EPP noone came forward to propose working on this... Please do not use the result of an ICANN *policy* to change the protocol while implying this is needed for all EPP servers as it is was an EPP deficiencies in the first place. It may well be an EPP deficiency and if so it needs to be tackled separately, but that is really not the correct channel at this point. > If we're going to write a new RFC just for technical contacts then I I never suggested "just for technical contacts". On the contrary, if defined properly, the schema could be used, in place, for all contacts. For some registries, like gTLDs ones bound by specific contracts, they could then just use those instead of the current "contact-1.0" ones. > would suggest that it should define an extension to the domain object, > since that is (a) simpler for clients and servers to implement and (b) > more accurately maps to the way the data is represented and handled > outside of EPP. This would create even more confusion, as clearly today the hosts as objects vs hosts as attributes is one of the major pain point of any registrar (again, one has to try to be in registrar shoes, for a registry everything is simple, it has one case to handle, its own, and it can often forget that its registrar have other cases to handle too, so all the complexities finish on the registrars' shoulders) > > One has to keep remembering that EPP is not just used by gTLDs, so any > > change has to > > be done in such a way that it does not impact negatively any operation done > > outside > > of ICANN circles. > > It seems to me that updating RFC5733 would have a bigger impact outside > the gTLD world than either of the other options I've proposed: I am still waiting on non-gTLD registries to participate in the subject and to see how much they will be happy to see EPP changed for everyone *just because* ICANN enacted some new policy. > presumably many ccTLD registries rely on the the XML schema in RFC 5733 > to enforce their data collection policies, but if we change that schema, > and they unknowingly update their implementation, then their data > collection policy will be changed without them knowingly accepting it. You can not "change that schema". You need to create a new namespace. Besides, I have no idea what you mean. Registries policies on contact data go far beyond what is in the EPP schema, in the sense of validation done and constraints. You already have far more problematic issue like "id" being either ignored or just refused (while being mandatory in the schema), the "int" vs "loc" issue, the semantics of "update" on "postalAddr", etc. And again, if a new contact schema appears, registries that want it use it, those that want to keep the current contact-1.0 keep it, and all is fine (besides the complexities for registrars, but obviously they will have to deal with it in any way, placeholders introduce their own complexities as they will be hardcoded in every piece of code, so that the value is not offered for edition for example, etc.) -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Technical Errata Reported] RFC7482 (5621)
OK, I'll confirm it since no one has raised any objections. Scott > -Original Message- > From: Andrew Newton > Sent: Monday, March 4, 2019 4:14 PM > To: Hollenbeck, Scott > Cc: rfc-edi...@rfc-editor.org; a...@arin.net; b...@nostrum.com; > aamelni...@fastmail.fm; a...@nostrum.com; o...@nlnetlabs.nl; > superu...@gmail.com; john-i...@jck.com; wei...@ietf.org > Subject: [EXTERNAL] Re: [regext] [Technical Errata Reported] RFC7482 (5621) > > I agree. > > -andy > > On Tue, Feb 26, 2019 at 2:43 PM Hollenbeck, Scott > wrote: > > > > > -Original Message- > > > From: RFC Errata System > > > Sent: Friday, February 1, 2019 12:40 PM > > > To: a...@arin.net; Hollenbeck, Scott ; > > > b...@nostrum.com; aamelni...@fastmail.fm; a...@nostrum.com; > > > o...@nlnetlabs.nl; superu...@gmail.com > > > Cc: john-i...@jck.com; wei...@ietf.org; rfc-edi...@rfc-editor.org > > > 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 > > > > > > 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 > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [gtld-tech] EPDP recommendations and EPP
On 01/03/2019 15:03, Patrick Mevzek wrote: > [snip] > > Instead of updating RFC5733 I would suggest creating a new object, > a "light (or shallow) contact" which is like a contact currently, just with > less fields. > Domains could use "full contacts" (the ones we know today) or light contacts > (the new > ones). I can't see how this would work. Let's say we define a new object mapping for "light" contacts, with its own namespace, to be used with just the element in domain objects. Could such contacts be used with domains without an update to RFC 5731? Could a registrar determine whether a given contact object was a "full" contact or a "light" without performing an command? I think this would cause a huge amount of confusion and pain. Furthermore, my research[1] indicates that the "one-to-many" relationship between domains and contacts that is implicit in EPP does not reflect reality, so defining a new "first class" EPP object just perpetuates the data management issues that registries currently have to deal with. If we're going to write a new RFC just for technical contacts then I would suggest that it should define an extension to the domain object, since that is (a) simpler for clients and servers to implement and (b) more accurately maps to the way the data is represented and handled outside of EPP. > One has to keep remembering that EPP is not just used by gTLDs, so any change > has to > be done in such a way that it does not impact negatively any operation done > outside > of ICANN circles. It seems to me that updating RFC5733 would have a bigger impact outside the gTLD world than either of the other options I've proposed: presumably many ccTLD registries rely on the the XML schema in RFC 5733 to enforce their data collection policies, but if we change that schema, and they unknowingly update their implementation, then their data collection policy will be changed without them knowingly accepting it. G. [1]: http://regiops.net/wp-content/uploads/2017/05/ROW6_Brown_Contact-Object-Management-by-Registrars.pdf -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ +44.7548243029 CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Technical Errata Reported] RFC7482 (5621)
I agree. -andy On Tue, Feb 26, 2019 at 2:43 PM Hollenbeck, Scott wrote: > > > -Original Message- > > From: RFC Errata System > > Sent: Friday, February 1, 2019 12:40 PM > > To: a...@arin.net; Hollenbeck, Scott ; > > b...@nostrum.com; aamelni...@fastmail.fm; a...@nostrum.com; > > o...@nlnetlabs.nl; superu...@gmail.com > > Cc: john-i...@jck.com; wei...@ietf.org; rfc-edi...@rfc-editor.org > > 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 > > > > 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 > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
