Hi Dave
Not sure there is yet another issue around the Enumservices derived URI
label registrations.
As I understand this document (RFC 8552) is based on RFC 7553 regarding
Enumservices, which states:
The Enumservice Registration [RFC6117] parameters are
reversed (i.e., subtype(s) before type), prepended with an underscore
(_), and prepended to the owner name in separate labels.
[...]
For example, suppose we are looking for the URI for a service with
ENUM Service Parameter "A:B:C" for host example.com. Then we would
query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").
However, RFC 8552 only lists the Enumservices labels for Types, but not
for Subtypes:
https://www.iana.org/assignments/enum-services/enum-services.xhtml
Shouldn't the labels for Subtypes also go to this (initial) URI Registry?
cheers,
Bernie (Designated Expert for Enum)
--
http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology
On Wed, 3 Aug 2022, Dave Crocker wrote:
On 8/2/2022 8:04 AM, RFC Errata System wrote:
Type: Editorial
Reported by: Bernie Hoeneisen <ber...@ietf.hoeneisen.ch>
Section: 4.1.2.
Original Text
-------------
| URI | _acct | [RFC6118] |
Corrected Text
--------------
| URI | _acct | [RFC7566] |
Notes
-----
Wrong reference. Note that is also has an impact to the IANA registry:
https://www.iana.org/assignments/dns-parameters/dns-pa
rameters.xhtml#underscored-globally-scoped-dns-node-names
Folks,
1. Bernie, thanks for bringing this up
2. Using this case as an example, the history in the attrleaf development
seems concerning. The RFC cited for this entry
changes, over the course of a number of I-D versions. So, in -13 is was
RFC 7553, -14 is was RFC 7566, and in -15 it
went to RFC 6118.
3. That the published version landed on the wrong choice should raise a
question possibly about process but especially about
understanding.
In Spring, 2018 and again in Fall, 2018, there was some focused discussion
(see: dnsop) about _acct, and related strings,
and which citation to use for the enum-related values. The choice bounced
around, as I've cited. This includes having what
is now being deemed the 'correct' choice in -14...
Note that none of the cited documents refers to the exact string "_acct". So
there is a derivation process that seems to be
unclear. I believe the attrleaf RFC contains no pedagogy about this, but it
probably should.
Before doing the simple -- but possibly wrong -- thing of agreeing on a new --
or, rather, returning to an old -- better RFC
citation, I suggest there be some community discussion about the why of the
right choice and consideration of how to document
that, this time, this latest choice is the truly correct one.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
