Hi Carsten, Thank you for your reply! And I'm sorry to hear about the fever :(
I have some followup questions/comments: a) Regarding: >> * If you need/want to make updates to your document, we encourage you to >> make those >> changes and resubmit to the Datatracker. This allows for the easy creation >> of diffs, >> which facilitates review by interested parties (e.g., authors, ADs, doc >> shepherds). > > We have submitted a -29 in response to the IANA registrations, which needed a > task done (integrate newest URI-Scheme registrations) as well as follow a new > clarification in RFC 9876 for content-format registrations. > The IANA work now seems to be complete. > > We could roll up the changes (author’s address, fixing “coap-diag") mentioned > below in a -30, if that helps. > > We will write a separate response on the validation of the sourcecode > elements; if there are any surprise changes they probably can be > independently integrated. Yes, please incorporate these into that version -30. That way it's clear where the change originated. b) Regarding: >> * Are the Authors' Addresses, Contributors, and Acknowledgments >> sections current? > > The author’s address for Henk Birkholz needs this change: > > OLD: > [email protected] > NEW: > [email protected] > > Sorry for missing this in -29. Could you add this to version -30? c) Regarding: >> * Is the sourcecode type indicated in the XML? (See information about >> sourcecode types.) > > Yes, with one mistake > > OLD: > ~~~ coap-diag > NEW: > ~~~ cbor-diag > > There is no sourcecode-type coap-diag > (Amazingly, this mistake lingered for some four years.) Good catch! Could you also add this to the version -30? d) Regarding: >> The RPC cannot update SVG diagrams, so please ensure that: >> >> * the SVG figures match the ASCII art used in the text output, and >> * the figures fit on the pages of the PDF output. > > Which PDF output? If you made a PDF, you could see if there were a difference. Feel free to disregard at this time, but this might be an additional question in AUTH48 if we notice differences in the PDF / TXT / HTML outputs (e.g., asterisks appearing as large black circles that obscure the diagram). e) Regarding: >> If so, please let us know and provide a self-contained kramdown-rfc file. > > You can extract the markdown source (with the includes performed) from a > RFCXML directly submitted as such in the following way: > > kramdown-rfc-extract-markdown draft-ietf-core-href-29.xml > > draft-ietf-core-href-29.md > > I have attached a markdown file extracted this way. > (This is different from the markdown file in the WG repository [1] because > that does not have the includes performed, so additional files are needed to > compose a complete input.) > > [1]: https://github.com/core-wg/href Unfortunately, we do need a self-contained markdown file with the additional files included. But since there appears to be a need for a version -30, please send the -30 markdown instead. So no need for a -29 markdown. f) Regarding: >> 12) Would you like to participate in the RPC Pilot Test for completing >> AUTH48 in >> GitHub? If so, please let us know. For more information about this >> experiment, >> see: >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test. > > I wonder how this combines with 11, but using individual, separate pull > requests would very much fit our style of working. Yes! We're hoping to build a process that fits authors' working styles! Just for clarity, I'm going to leave this draft in AUTh state until I get notification about the version -30 and subsequently get AD approval. Thank you, Sarah Tarrant RFC Production Center > On Nov 20, 2025, at 4:08 AM, Carsten Bormann <[email protected]> wrote: > > Hi Sarah, > > apologies for our tardiness (first an IETF got in the way, and then a > post-IETF fever.) > > On 2025-11-06, at 17:38, Sarah Tarrant <[email protected]> wrote: >> >> […] >> * If you need/want to make updates to your document, we encourage you to >> make those >> changes and resubmit to the Datatracker. This allows for the easy creation >> of diffs, >> which facilitates review by interested parties (e.g., authors, ADs, doc >> shepherds). > > We have submitted a -29 in response to the IANA registrations, which needed a > task done (integrate newest URI-Scheme registrations) as well as follow a new > clarification in RFC 9876 for content-format registrations. > The IANA work now seems to be complete. > > We could roll up the changes (author’s address, fixing “coap-diag") mentioned > below in a -30, if that helps. > > We will write a separate response on the validation of the sourcecode > elements; if there are any surprise changes they probably can be > independently integrated. > > >> […] >> >> 1) As there may have been multiple updates made to the document during Last >> Call, >> please review the current version of the document: >> >> * Is the text in the Abstract still accurate? > > Yes. > (You will delete the yellow CREF which is commentary on the processing and > not to be included in the RFC-to-be.) > >> * Are the Authors' Addresses, Contributors, and Acknowledgments >> sections current? > > The author’s address for Henk Birkholz needs this change: > > OLD: > [email protected] > NEW: > [email protected] > > Sorry for missing this in -29. > > >> 2) Please share any style information that could help us with editing your >> document. For example: >> >> * Is your document's format or its terminology based on another document? >> If so, please provide a pointer to that document (e.g., this document's >> terminology should match DNS terminology in RFC 9499). > > Clearly, RFC 3986/3987 are documents the terminology of which we want to > match. > >> * Is there a pattern of capitalization or formatting of terms? (e.g., field >> names >> should have initial capitalization; parameter names should be in double >> quotes; >> <tt/> should be used for token names; etc.) > > Trying to reconstruct the rules we have been using: > > We are frugal with capitalization, reserving it for places where a term > defined elsewhere is used without the context already established, as in > > Uniform Resource Identifier (URI) [STD66] > This document defines the _Constrained Resource Identifier (CRI)_ by > (Belt and suspender, see item 6 below) > _Simple CRIs_ (i.e., not using CRI extensions, see Section 7) > (Ditto) > Concise Binary Object Representation (CBOR) [STD94] > Constrained Application Protocol (CoAP) [RFC7252] > Hypertext Transfer Protocol (HTTP) [STD97] > Uniform Resource Names (URNs) [RFC8141] > Syntax-Based Normalization level (Section 6.2.2 of RFC 3986 [STD66]) > Scheme-Based Normalization level (Section 6.2.3 of RFC 3986 [STD66]). > > Title case is somewhat likely to be inconsistent, as we didn’t make a run > fixing titles/captions at the end of editing. > There are special cases such as > > 2.2. CRI References: The discard Component > > … where discard really is typewriter font here, as can be seen in the > markdown: > > ## CRI References: The `discard` Component {#discard} > > … which should not be capitalized (generally all typewriter passages are > meant to be verbatim to data definition language rules or example content). > > See also 6 below. > > We have often combined typewriter markup with surrounding quotes so they > remain visible in the plaintext form, e.g.: > >>> 9. {:#c-path-segment} A path segment can be any CRI text string, with >>> the exception of the special "`.`" and "`..`" complete path segments. > > > Note that the inverse arrangement is intentional (the typewriter text > contains double quotes; we need to liberate quotes to ever get this right): > >>> Note that path components can be empty; `ftp://example.com/a/` >>> includes the two path components `"a"` and `""`; the latter is the one >>> that will be discarded when the URI reference `"b"` is resolved with >>> `ftp://example.com/a/` as its base URI. > > >> 3) Please review the entries in the References section carefully with >> the following in mind. Note that we will update as follows unless we >> hear otherwise at this time: >> >> * References to obsoleted RFCs will be updated to point to the current >> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 >> (RFC Style Guide). >> >> * References to I-Ds that have been replaced by another I-D will be >> updated to point to the replacement I-D. >> >> * References to documents from other organizations that have been >> superseded will be updated to their superseding version. >> >> Note: To check for outdated RFC and I-D references, you can use >> idnits <https://author-tools.ietf.org/idnits>. You can also help the >> IETF Tools Team by testing idnits3 <https://author-tools.ietf.org/idnits3/> >> with your document and reporting any issues to them. > > We have a couple of deliberate informative historic references to RFCs: > > * RFC 6874 (obsoleted by RFC 9844). > * Please see also the editors’ note in 6.1 about the reference to RFC 3490. > * [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. > > [Unicode] is a normative reference to an updatable document; again, we don’t > mean 13.0.0 (17.0.0) but Unicode in general. We do reference specific > definitions the number of which (D80, D120, D92) might change in Unicode > revisions (but apparently haven’t between 13.0.0 and 17.0.0). > > >> 4) Is there any text that should be handled extra cautiously? For example, >> are >> there any sections that were contentious when the document was drafted? > > There are no such passages. > > >> 5) Is there anything else that the RPC should be aware of while editing this >> document? > > There was a last minute (-27 ➔ -28) removal of the text that was used to > create and maintain a separate CRI Numbers registry. The potential for > clerical errors here probably warrants additional attention. > > >> 6) This document uses one or more of the following text styles. >> Are these elements used consistently? >> >> * fixed width font (<tt/> or `) > > This font is mainly used as a visual cue for text snippets that would appear > on the wire, as well as parts (e.g., CDDL rule names, data items in > diagnostic notation) of formal text in the specification. > Since fixed width font is no longer visible in the plaintext version, there > should always be additional cues from the context. > (This should not be overdone — e.g., `true` and `“true”` are different data > items in [JSON and] CBOR, so adding double quotes would need to be carefully > checked.) > I didn’t recheck all the 253 occurrences; we did spend some attention to this > during editing already. > > See also 2 above. > >> * italics (<em/> or *) > > 1.1 says: > > Terms defined in this document appear in _italics_ where they are > introduced (in the plaintext form of this document, they are rendered > as the new term surrounded by underscores). > > Except for this specific example, which doesn’t actually define “italics”, an > emphasized “<em>not</em>” and an emphasized "<em>are</em>” later in the text, > and some <dl-like styling in a list in Appendix A, this is actually intended > to be the only use of emphasis for the entire document. > >> * bold (<strong/> or **) > > (Not used in the present document.) > > >> 7) This document contains sourcecode: >> >> * Does the sourcecode validate? > > TODO > (We so far have tested this manually and would now like to write some > properly automated CI checks; we’ll get back to you before Thanksgiving.) > >> * Some sourcecode types (e.g., YANG) require certain references and/or text >> in the Security Considerations section. Is this information correct? > > N/A > >> * Is the sourcecode type indicated in the XML? (See information about >> sourcecode types.) > > Yes, with one mistake > > OLD: > ~~~ coap-diag > NEW: > ~~~ cbor-diag > > There is no sourcecode-type coap-diag > (Amazingly, this mistake lingered for some four years.) > > >> 8) This document contains SVG. What tool did you use to make the svg? > > * kgt (Kate’s Grammar Tool) for the railroad diagram (Figure 1) > * tex2svg (part of mathjax-node-cli) for the formula (Section 5.1.1) > * [not svg, but related to tex2svg: utftex for the formula's text rendition] > > Please see > https://github.com/cabo/kramdown-rfc/wiki/SVG > for details on how to install and use these tools. > > Note that kgt outputs tentative width/height values that need to be adjusted > for the height actually used (too much space is currently left unused), so > editing the SVG is required here. > >> The RPC cannot update SVG diagrams, so please ensure that: >> >> * the SVG figures match the ASCII art used in the text output, and >> * the figures fit on the pages of the PDF output. > > Which PDF output? > > >> 9) This document is part of Cluster 561. >> >> * To help the reader understand the content of the cluster, is there a >> document in the cluster that should be read first? Next? If so, please >> provide >> the order and we will provide RFC numbers for the documents accordingly. >> If order is not important, please let us know. > > [C561] EDIT *draft-ietf-netmod-rfc6991-bis > [C561] AUTH*A*R draft-ietf-core-href > > 6991 bis is cited by core-href as the source of deliberations on how to deal > with the use of zone-ids with IP addresses. This is input that is useful for > that particular corner of core-href, so it is useful to have read 6991bis > before that, but the priority of giving 6991bis an RFC number lower than that > for core-href is limited. > >> * Is there any text that has been repeated within the cluster document that >> should be edited in the same way (for instance, parallel introductory text >> or >> Security Considerations)? > > No, this is a rather loose relationship. > >> * For more information about clusters, see >> https://www.rfc-editor.org/about/clusters/ >> * For a list of all current clusters, see: >> http://www.rfc-editor.org/all_clusters.php > > >> 10) Because this document updates RFC 7595, please review >> the reported errata and confirm whether they have been addressed in this >> document or are not relevant: >> >> * RFC 7595 (https://www.rfc-editor.org/errata/rfc7595) > > These two errata reports are unrelated to core-href. > > >> 11) Would you like to participate in the RPC Pilot Test for editing in >> kramdown-rfc? > > Certainly! > >> If so, please let us know and provide a self-contained kramdown-rfc file. > > You can extract the markdown source (with the includes performed) from a > RFCXML directly submitted as such in the following way: > > kramdown-rfc-extract-markdown draft-ietf-core-href-29.xml > > draft-ietf-core-href-29.md > > I have attached a markdown file extracted this way. > (This is different from the markdown file in the WG repository [1] because > that does not have the includes performed, so additional files are needed to > compose a complete input.) > > [1]: https://github.com/core-wg/href > >> For more >> information about this experiment, see: >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. > > >> 12) Would you like to participate in the RPC Pilot Test for completing >> AUTH48 in >> GitHub? If so, please let us know. For more information about this >> experiment, >> see: >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test. > > I wonder how this combines with 11, but using individual, separate pull > requests would very much fit our style of working. > > Grüße, Carsten > > <draft-ietf-core-href-29.md> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
