Authors,
While reviewing this document during Final Review, please resolve (as
necessary)
the following questions, which are also in GitHub issues
(see https://github.com/rfc-editor/AUTH48-rfc9988/issues).
1) <!-- [rfced] We will do the following when we convert to RFCXML:
a) fix the blockquote in Appendix A to appear within the <li>.
b) ensure the paragraphs are correctly nested under "authority" in Section 6.1
(seems the "[^toascii-note]:" in the .md file causes the subsequent paragraphs
to not nest correctly in the output files - see question below about removing
"[^toascii-note]:").
-->
2) <!-- [rfced] References
a) Regarding this note:
RFC Editor: please replace with version current at publication
(probably 17.0.0) and check whether D80, D120, and D92 are still
pointing to the same definitions as in 13.0.0
We have updated the [Unicode] reference entry to
17.0.0 (the most current version) and also confirmed that the
definitions at D80, D120, and D92 match those from Version 13.0.0.
b) Regarding this note from the intake form:
[W3C.REC-html52-20171214] is a snapshot reference where we actually
mean the concept of HTML; I don't know what we reference for HTML
these days.
The HTML standard is now a Web Hypertext Application Technology
Working Group (WHATWG) Living Standard. See:
https://html.spec.whatwg.org/multipage/. (Note: the "Latest
published version" URL on the W3C Recommendation also redirects to
the WHATWG Living Standard (https://www.w3.org/TR/html/).
Would you like to update this reference to point to the WHATWG
Living Standard? Note that we have a recommend reference format for WHATWG
Living Standards that include a "commit snapshot" URL in the
annotation that captures the specification as it existed at the time
of publication:
Original:
[W3C.REC-html52-20171214]
Danilo, A., Ed., Eicholz, A., Ed., Moon, S., Ed.,
Faulkner, S., Ed., and T. Leithead, Ed., "HTML 5.2", W3C
REC REC-html52-20171214, W3C REC-html52-20171214, 14
December 2017,
<https://www.w3.org/TR/2017/REC-html52-20171214/>.
Perhaps:
[HTML] WHATWG, "HTML", WHATWG Living Standard,
<https://html.spec.whatwg.org/>. Commit snapshot:
<https://html.spec.whatwg.org/commit-snapshots/0d220b5ebbe45b2dae0fc1f65ae84431eedb3737/>.
-->
3) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
4) <!-- [rfced] Would updating this sentence to avoid using "either" twice
improve readability?
Original:
(For example, for a CRI reference where authority is either not set or
has either of the NOAUTHORITY values, the equivalent URI reference's
authority is absent.)
Perhaps:
(For example, for a CRI reference where authority either is not set or
has one of the NOAUTHORITY values, the equivalent URI reference's
authority is absent.)
-->
5) <!-- [rfced] Should "as in URIs' scheme section" be updated to "in the URI's
scheme section"? Or is the current correct?
Original:
Optionally, it
can instead be identified by its scheme-name (a text string giving
the scheme name as in URIs' scheme section, mapped to lower case).
Perhaps:
Optionally, it
can instead be identified by its scheme-name (a text string giving
the scheme name in the URI's scheme section, mapped to lowercase).
-->
6) <!-- [rfced] Editor's note in Section 6.1
a) Please confirm that the "Editor's note" paragraph in Section 6.1 should be
removed from the document. It is tagged with "[^toascii-note]:" in the .md
file, and the text is placed in a <cref> comment in the XML file generated
from the .md (so the text is not rendered in the TXT, HTML, and PDF output
files).
b) Informative reference RFC 3490 has been obsoleted by RFCs 5890 and
5891. The "Editor's note" is the only place were RFC 5890 is mentioned; RFC
5891 is not mentioned at all. We suggest mentioning RFCs 5890 and 5891 (e.g.,
RFC 3490 has been obsoleted by RFCs 5890 and 5891); see Section 4.8.6 in the
RFC Style Guide (RFC 7322).
If the "Editor's note" is retained, we can update it to include citations and
a mention of RFC 5891; if the "Editor's note" is removed, we can add the
mention of RFCs 5890 and 5891 to the existing implementation note where RFC
3490 is mentioned.
-->
7) <!-- [rfced] We are having trouble understanding the text starting with "if
text (scheme-name); or, if a negative integer ...". How may we clarify?
Original:
If the CRI reference contains a scheme section, the scheme
component of the URI reference consists of the value of that
section, if text (scheme-name); or, if a negative integer is given
(scheme-id), the lower case scheme name corresponding to the
scheme-id as per Section 5.1.1.
-->
8) <!-- [rfced] May we move "More important in practice" to the text introducing
the unordered list?
Original:
Extensions are or will be necessary to cover two limitations of
Simple CRIs:
* Simple CRIs do not support IPvFuture (Section 3.2.2 of RFC 3986
[STD66]). Definition of such an extension probably best waits
until a wider use of new IP literal formats is planned.
* More important in practice:
Simple CRIs do not support URI ...
Perhaps:
Extensions are or will be necessary to cover two limitations of
Simple CRIs (the second is more important in practice):
* Simple CRIs do not support IPvFuture (Section 3.2.2 of RFC 3986
[STD66]). Definition of such an extension probably best waits
until a wider use of new IP literal formats is planned.
* Simple CRIs do not support URI ...
-->
9) <!-- [rfced] Would using an unordered list be helpful here?
Current:
2. If the request includes a Uri-Host Option, insert an authority
with its value determined as follows: If the value of the Uri-
Host Option is a reg-name, split it on any dots in the name and
use the resulting text string values as the elements of the host-
name array. If the value is an IP-literal or IPv4address,
represent the IP address as a byte string of the correct length
in host-ip; if a zone-id can be extracted from the request's
destination IP address and if the IP address is ambiguous in the
context of the local system, append the zone-id. If the value is
none of the three, fail this algorithm.
Perhaps:
2. If the request includes a Uri-Host Option, insert an authority
with its value determined as follows:
* If the value of the Uri-Host Option is a reg-name, split it on any
dots in the name and use the resulting text string values as the
elements of the host-name array.
* If the value is an IP-literal or IPv4address, represent the IP
address as a byte string of the correct length in host-ip; if
a zone-id can be extracted from the request's destination IP
address and if the IP address is ambiguous in the context of
the local system, append the zone-id.
* If the value is none of the three values listed above, fail this
algorithm.
-->
10) <!--[rfced] Regarding Section 9 ("Implementation Status"), is it your
intention that this section remain in the RFC? The reason we ask is because
RFC 7942 recommends removing it but also states that it's not mandatory to
remove it.
-->
11) <!-- [rfced] How does "an unsigned integer unique in this registry" connect
to
the rest of the sentence?
Original:
RFC 7595 [BCP35] is updated to add a column "CRI Scheme Number" to
the "Uniform Resource Identifier (URI) Schemes" Registry, an unsigned
integer unique in this registry.
Perhaps:
This document updates RFC 7595 [BCP35] by adding a column called
"CRI Scheme Number" to
the "Uniform Resource Identifier (URI) Schemes" registry [IANA.uri-schemes].
Each CRI scheme number is a unique unsigned integer in this registry.
-->
12) <!-- [rfced] Section 11.1 and Appendix B
a) Although a note requests that the RPC remove Appendix B, we have retained
it because it contains Table 10, which documents where the values in the "CRI
Scheme Number" column originated. We confirmed this with IANA.
b) We have removed the "Reference" column from Table 10 as this does not
appear in the registry. Per IANA, the reference at the top of the registry
can serve as a reference for the values in the new column.
c) Appendix B: We updated the sentences below as follows. Please review
and let us know if any further updates are needed.
Original:
Table 10 defines the initial mapping from CRI scheme numbers to URI
scheme names. Rows with URI scheme names hat have a registration in
"Uniform Resource Identifier (URI) Schemes" registry are used to
populate the new "CRI scheme numbers" column in that registry
(Section 11.1).
Updated:
Table 10 defines the initial mapping of CRI scheme numbers to URI
scheme names. Table 10 only contains URI scheme names that were
registered in the "Uniform Resource Identifier (URI) Schemes"
registry at the time the registry was set up; see Section 11.1.
d) Section 11.1: We have also updated this text. Please review and
let us know if any further updates are needed. (A note for the RPC indicates
to replace "Appendix B" in this text with a reference to the IANA registry,
but we have not done so as Appendix B will remain in the document.)
Original:
The column is initially populated from the numbers in the "CRI scheme
number" column of entries in Appendix B. Existing rows that are not
listed in Appendix B at the time of initial setup are treated as
specified for new registrations below.
Updated:
The column was initially populated with the numbers in the "CRI
Scheme Number" column of Table 10 in Appendix B. Additions to the
registry after initial setup are not listed in Table 10; these were
treated as new registrations as specified below.
e) Appendix B: Please confirm that the following text should be removed from
the document. It is tagged with "[^add-regs]" in the .md file, and the text is
placed in a <cref> comment in the XML file generated from the .md (so the text
is not rendered in the TXT, HTML, and PDF output files).
Original (.md file):
[^add-regs]:
Rows with URI scheme names that do not currently have a registration in the
"Uniform Resource Identifier (URI) Schemes" registry are intended for
registration before publication of this document.
f) Appendix B: Should the following be removed? Is this helpful for readers or
only for IANA? (Note that we have another question about the use of "ruby" as
a sourcecode type.)
Original:
The assignments from this table can be extracted from the XML form of
this document (when stored in a file "this.xml") into CSV form
[RFC4180] using this short Ruby program:
require 'rexml/document'; include REXML
XPath.each(Document.new(File.read("this.xml")),"/rfc/back//tr") {|r|
puts XPath.each(r,"td").map{|d|d.text()}[0..1].join(",")}
-->
13) <!-- [rfced] FYI: We made some updates to the note that has been added to
the
"Uniform Resource Identifier (URI) Schemes" registry (see Section 11.1). We
will ask IANA to update the note in the registry to match the document prior
to publication.
Link to registry: https://www.iana.org/assignments/uri-schemes
-->
14) <!-- [rfced] Will "exceptionally also may make such a registration" be clear
to readers?
Original:
The expert exceptionally also may make such a registration for text
strings that have not been registered in the Uniform Resource
Identifier (URI) Schemes registry if and only if the expert considers
them to be in wide use in place of URI scheme names in constrained
applications.
Perhaps:
The expert may also make a registration for text
strings that have not been registered in the "Uniform Resource
Identifier (URI) Schemes" registry if and only if the expert
considers them to be in wide use in place of URI scheme names in
constrained applications.
-->
15) <!-- [rfced] Is "leading in to an authority" correct? Or should this be
updated to "leading to an authority" (i.e., no "in")?
Original:
s://x//foo works, but in a
s://foo URI or an (absolute-path) URI reference of the form //foo
the double slash would be mis-parsed as leading in to an
authority.
Perhaps:
s://x//foo works, but in a
s://foo URI or an (absolute-path) URI reference of the form //foo,
the double slash would be mis-parsed as leading to an
authority.
-->
16) <!-- [rfced] The following types are used for sourcecode in the document,
but
these do not appear on the list of preferred values at
https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types:
uri
ruby (may be removed per another question)
We have removed "uri", and those blocks now convert to <artwork> in the XML.
Would you like to request that "ruby" be added to the list? It is also
acceptable to leave the "type" attribute not set.
-->
17) <!-- [rfced] What is meant by "current author team"? Does this mean the
authors of this document or authors working on CoRAL? Also, would updating "a
view to achieve" to "with the goal of achieving" (or similar) improve this
sentence?
Original:
The current author team is
completing this work with a view to achieve good integration with the
potential use cases, both inside and outside of CoRAL.
Perhaps:
The current author team working on CoRAL is
completing this work with the goal of achieving good integration with the
potential use cases, both inside and outside of CoRAL.
-->
18) <!-- [rfced] Some author comments are present in the XML. Please confirm
that
no updates related to these comments are outstanding. Note that the comments
will be deleted prior to publication. -->
19) <!-- [rfced] Would you like to include quotation marks around the colon,
period, slash, and ampersand in the sentences below? Note that backticks are
used for these in the .md file, so they are rendered with fixed-width font and
a slightly shaded background in the HTML and PDF outputs. However, no
formatting appears in the TXT output.
Original:
If the discard value is
1 and the first element of the path contains a :, the path
component is prefixed by "./" (this avoids the first element to
appear as supplying a URI scheme; compare path-noscheme in
Section 4.2 of RFC 3986 [STD66]).
...
Note that the separators . (for authority parts), / (for
paths), & (for query parameters) are special in that they
are syntactic delimiters of their respective components in
CRIs (note that . is doubly special because it is not a
reserved character in [STD66] and therefore any percent-
encoding would be normalized away).
Perhaps:
If the discard value is
1 and the first element of the path contains a colon (":"), the path
component is prefixed by "./" (this avoids the first element to
appear as supplying a URI scheme; compare this with path-noscheme in
Section 4.2 of RFC 3986 [STD66]).
...
Note that the separators "." (for authority parts), "/" (for
paths), and "&" (for query parameters) are special in that
they are syntactic delimiters of their respective components
in CRIs (note that "." is doubly special because it is not a
reserved character in [STD66] and therefore any percent-
encoding would be normalized away).
-->
20) <!-- [rfced] How should PET be expanded? "Percent Encoding (PET)" doesn't
account for the "T" in "PET"; is a word missing?
Original:
7.2. Extended CRI: Accommodating Percent Encoding (PET)
...
...and the minimal use of PET elements in the text-or-pet feature as per
Section 7.2).
-->
21) <!-- [rfced] Terminology
a) We note inconsistencies in the terms below. Should these be uniform? If so,
please let us know which form is preferred.
Stand-in Items
stand-in items
CoAP Options
CoAP options
Syntax-Based Normalization
syntax-based normalization
Scheme-Based Normalization
scheme-based normalization
URI Scheme
URI scheme
b) In the following sentences, may we update "the CoAP protocol" to simply
"CoAP"? If expanded, it would read "the Constrained Application Protocol
protocol". (We do note that RFC 7252 uses "the CoAP protocol".)
Original:
It should be sufficient for all applications that use
the CoAP protocol, as well as most other protocols employing URIs.
...
This section discusses ways in which CRIs can be used in the context
of the CoAP protocol [RFC7252] and of Authorization for Constrained
Environments (ACE), specifically the Authorization Information Format
(AIF) [RFC9237].
Perhaps:
It should be sufficient for all applications that use
CoAP, as well as most other protocols employing URIs.
...
This section discusses ways in which CRIs can be used in the context
of CoAP [RFC7252] and Authorization for Constrained
Environments (ACE), specifically the Authorization Information Format
(AIF) [RFC9237].
-->
22) <!-- [rfced] Note that we have removed mentions of specific paragraph
numbers
as they do not seem to be correct; see below. We have also submitted this
issue: https://github.com/ietf-tools/xml2rfc/issues/1324.
a) For "Section 3, Paragraph 7" and "Section 6.1, Paragraph 4" in these
sentences, we believe readers will be able to find the correct information in
the section without the paragraph mention.
Original:
C0. Text strings in CRIs ("CRI text strings") are CBOR text strings
(i.e., in UTF-8 form [STD63]) that represent Unicode strings
(see Definition D80 in [Unicode]) in Unicode Normalization Form
C (NFC) (see Definition D120 in [Unicode] and specifically
Section 3, Paragraph 7).
...
C4. An IP address can be either an IPv4 address or an IPv6 address
(optionally with a zone identifier; see Section 6.1, Paragraph
4).
Current:
C0. Text strings in CRIs ("CRI text strings") are CBOR text strings
(i.e., in UTF-8 form [STD63]) that represent Unicode strings
(see Definition D80 in [Unicode]) in Unicode Normalization Form
C (NFC) (see Definition D120 in [Unicode] and specifically
Section 3).
...
C4. An IP address can be either an IPv4 address or an IPv6 address
(optionally with a zone identifier; see Section 6.1).
b) We updated the two mentions of "Section 5.1, Paragraph 10" to "the
last paragraph of Section 5.1".
Original:
(Note: this skipping can be implemented in
bounded memory for CRIs that do not use indefinite length encoding,
as mandated for CRIs as separate encoded data items in Section 5.1,
Paragraph 10.)
...
Extensions to CRIs are not intended to change encoding constraints;
e.g., Section 5.1, Paragraph 10 is applicable to extended forms of
CRIs as well.
Current:
(Note: This skipping can be implemented in
bounded memory for CRIs that do not use indefinite length encoding,
as mandated for CRIs as separate encoded data items in the last
paragraph of Section 5.1.)
...
Extensions to CRIs are not intended to change encoding constraints;
e.g., the last paragraph of Section 5.1 is applicable to extended
forms of CRIs as well.
c) For this sentence with "Section 6.1, Paragraph 3", is there a specific
phrase used in that paragraph that we can add so that the reader can easily
find the information since we removed the paragraph number?
Original:
Only if it does not, include
a Uri-Host Option, and let that option's value be the text value
of the URI representation of the IP address, as derived in
Section 6.1, Paragraph 3 (note that zone-ids are never present in
Uri-Host Options).
Current:
Only if it does
not, include a Uri-Host Option, and let that option's value be
the text value of the URI representation of the IP address, as
derived in Section 6.1 (note that zone-ids are never present in
Uri-Host Options).
-->
23) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
Madison Church and Rebecca VanRheenen
RFC Production Center
On May 21, 2026, at 6:02 PM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/LCXXXX.xml
https://www.rfc-editor.org/authors/LCXXXX.html
https://www.rfc-editor.org/authors/LCXXXX.pdf
https://www.rfc-editor.org/authors/LCXXXX.txt
Diff file of the text:
https://www.rfc-editor.org/authors/LCXXXX-diff.html
https://www.rfc-editor.org/authors/LCXXXX-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/LCXXXX-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/LCXXXX
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9988 (draft-ietf-core-href)
Title : Constrained Resource Identifiers
Author(s) : C. Bormann, Ed.,
H. Birkholz
WG Chair(s) : Marco Tiloca, Jaime Jimenez, Carsten Bormann
Area Director(s) : Mike Bishop, Gorry Fairhurst
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
