Hi Carsten, Thank you for your reply! We have updated the document as requested with feedback from both emails received on 19 December. Please see below for followup comments/questions inline. Note that we will also send along a followup question in a seperate email to your second response regarding sourcecode types.
> On Dec 19, 2025, at 3:25 AM, Carsten Bormann <[email protected]> wrote: > > Hi Madison, > > apologies for the long response time. > > On Nov 21, 2025, at 10:24 AM, Madison Church <[email protected]> > wrote: >> >> Hi Authors, >> >> Ari - Thank you for your reply! We have updated the document as requested >> and noted your approval on the AUTH48 status page (see >> https://www.rfc-editor.org/auth48/rfc9880). >> >> Authors - Please note that some questions (6, 8, 11, 14, 17, 19, 20, 21, 22, >> and 23) still await author response. These questions (as well as RFC EDITOR >> followup questions/responses) can be viewed in the main AUTH48 thread from >> mail sent on 27 October. > > I had noted "TO CHECK" in questions 6, 20, 21, 22, 23 (and I’ll still need to > write a follow-on mail for these); additional comments on 8, 11, 14, 17, 19 > are below. > > Before that, I have the following observations: > > > (a) The contributor section no longer lists the current address for Jan > Romann. > > Please use: > > <author initials="J." surname="Romann" fullname="Jan Romann"> > <organization>Universität Bremen</organization> > <address> > <postal> > <country>Germany</country> > </postal> > <email>[email protected]</email> > </address> > </author> > > > (b) Section 2.1 > > Parentheses got lost in > OLD: > usually use the named<> production in the formal syntax of SDF Appendix A. > NEW: > usually use the named<> production in the formal syntax of SDF (Appendix A). > > > (c) Plaintext Tables > > In the plaintext form, the tables no longer benefit from the processing > instructions that make them more readable in the Internet-Draft version. > I know there may be obstacles to resolving this before publication, but I > wanted to point out that this is currently a limitation of the process we > have. 1) We believe this refers to the lines separating rows within the tables and this instruction that was present in the author-submitted XML <?v3xml2rfc table_borders=“light”?>. Is this correct? In our opinion, the separators help in this document because they clearly separate the multi-line descriptions. If you would like to pursue this further, please consider filing a new issue against RFCXML (see https://github.com/ietf-tools/RFCXML/issues). > (d) Section 4.5 > > A single lowercase JSON Pointer escaped: > OLD: > JSON pointer > NEW: > JSON Pointer > > > (e) Section 7.5.3 > > A colon is missing: > OLD: > JSON Representation > NEW: > JSON Representation: > > > (f) Section 8 > > This sentence parses badly for me, as "by SDF models and model-based > augmentation” seems to cling together. > > OLD: > SDF may be used in two processes that are often security relevant: > model-based validation of data that is intended to be described of these > data with information obtained from the SDF models that apply. > > Maybe: > SDF may be used in two processes that are often security relevant: (1) > model-based validation of data that is intended to be described by SDF models > and (2) model-based augmentation of these data with information obtained from > the SDF models that apply. > > Maybe a comma before the “and” would be enough, or on the other extreme we > could turn this into a bulleted list. > (g) References, Section 9.2 > > By now, we can use the draft-ietf-… revisions that are now available for > SDF-MAPPING and SDFTYPE-LINK. 2) We have updated the internet drafts above in the document—please let us know if they appear correctly. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9880.txt https://www.rfc-editor.org/authors/rfc9880.pdf https://www.rfc-editor.org/authors/rfc9880.html https://www.rfc-editor.org/authors/rfc9880.xml https://www.rfc-editor.org/authors/rfc9880-diff.html https://www.rfc-editor.org/authors/rfc9880-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9880-auth48diff.html https://www.rfc-editor.org/authors/rfc9880-auth48rfcdiff.html (side by side) Once we receive all author approvals, we will move this document forward in the publication process. Thank you! Madison Church RFC Production Center > Now on to the questions. > >>>>> 6) <!-- [rfced] Please review whether any of the notes in this document >>>>> should be in the <aside> element. It is defined as "a container for >>>>> content that is semantically less important or tangential to the >>>>> content that surrounds it" >>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>>> --> >>>> >>>> [TO CHECK] > > (In follow-up mail, with 20-23…) > >>>> >>>>> 8) <!-- [rfced] May we rephrase the text below as follows to improve >>>>> readability and specify "it" in the second sentence? >>>>> >>>>> Original: >>>>> The keyword (map key) that defines an information block is "info". >>>>> Its value is a JSON map in turn, with a set of entries that represent >>>>> qualities that apply to the included definition. >>>>> >>>>> Perhaps: >>>>> The keyword (map key) that defines an information block as "info". >>>> >>>> This should stay “is” — not a sentence otherwise. >>>> (This is a statement about the keyword, giving its name as “info”.) >>>> >>>>> In turn, the keyword's value is a JSON map with a set of entries that >>>>> represent >>>>> qualities that apply to the included definition. >>>>> --> >>>> >>>> We could also make use of the word “nested”: >>>> >>>>> The keyword's value is nested a JSON map with a set of entries that >>>>> represent >>>>> qualities that apply to the included definition. >>>> >>>> In any case, we need to change >>>> OLD: >>>> included definition >>>> NEW: >>>> included definitions >>>> >>>> … to mirror the first paragraph of 3.1. >>> >>> 3) Thank you for your proposal! We agree with the suggested text and >>> updated the sentence with a minor correction to the placement of "nested >>> a". The sentence now reads as: "The keyword’s value is a nested JSON map…". >>> Please let us know if this is correct. > > We discussed this… We could make this more pedantically correct, but this > revision is probably easier to understand. > >>>>> 11) <!-- [rfced] FYI - In the XML, we have removed the links from "SenML >>>>> Units" and "Secondary Units" since those links do not point to the correct >>>>> section (and the correct section pointers follow shortly >>>>> thereafter). Please let us know any objections. >>>> >>>> I’m not happy with not having those fragment identifiers as links. >>>> I understand that IANA wants to keep the ability to change their format, >>>> but that has been outstanding for a long time now. >>>> The worst that can happen is that the fragment identifier part of the link >>>> does not work and the link points to the file as a whole. >>>> >>>>> Original XML: >>>>> <t>The unit name <bcp14>SHOULD</bcp14> be as >>>>> >>>>> per the <xref section="SenML Units" relative="#senml-units" >>>>> sectionFormat="bare" >>>>> target="RFC8428"/> registry >>>>> >>>>> or the <xref section="Secondary Units" relative="#secondary-units" >>>>> sectionFormat="bare" >>>>> target="RFC8798"/> registry in <xref target="IANA.senml"/> >>>>> >>>>> as specified by >>>>> >>>>> Sections <xref target="RFC8428" section="4.5.1" sectionFormat="bare"/> >>>>> and <xref >>>>> target="RFC8428" section="12.1" sectionFormat="bare"/> of <xref >>>>> target="RFC8428"/> and >>>>> <xref section="3" sectionFormat="of" target="RFC8798"/>, respectively. >>>>> </t> >>>>> --> >>> >>> 4) Understood. We have restored the links for the fragment identifiers. To >>> clarify, these links refer to RFCs 8428 (for SenML Units) and 8798 (for >>> Secondary Units) rather than the IANA registries themselves >>> (<https://www.iana.org/assignments/senml/senml.xhtml#senml-units> and >>> <https://www.iana.org/assignments/senml/senml.xhtml#secondary-units>). Is >>> this intentional? We ask this because the in-text citations that follow the >>> fragment identifier links reference the specific sections of the RFCs that >>> these registries appear in (so both RFCs are essentially referenced twice >>> in the same sentence). > > We would love to be able to use direct links to the registries (which turn > out to be fragment identifiers technically). > [We just got an IESG request to do that on a document that was on the > telechat yesterday…] > As long as IANA has not resolved how the long-term form of the fragment > identifiers will look like, they will not agree to doing that. > > The links in: > > as specified by Sections 4.5.1 and 12.1 of [RFC8428] and Section 3 of > [RFC8798], respectively. > > ...are the conventional way to do section references now, or maybe I don’t > understand the question. > >>>>> 14) <!-- [rfced] We have updated this text to remove the use of relative >>>>> references. Please review. >>>>> >>>>> Original: >>>>> Repository: combining the symbol values from the SenML Units >>>>> registry and the Secondary Units registry in [IANA.senml] as >>>>> specified by Sections 4.5.1 and 12.1 of [RFC8428] and Section 3 of >>>>> [RFC8798], respectively (which by the registration policy are >>>>> guaranteed to be non-overlapping). >>>>> >>>>> Current: >>>>> Repository: Combining the symbol values from the "SenML Units" >>>>> registry and the "Secondary Units" registry in the "Sensor >>>>> Measurement Lists (SenML)" registry group [IANA.senml] as >>>>> specified by Sections 4.5.2 and 12.1 of [RFC8428] and Section 3 of >>>>> [RFC8798], respectively (which, by the registration policy, are >>>>> guaranteed to be non-overlapping). >>>>> --> >>>>> >>>> >>>> (I can’t see the change in the plaintext here…) >>>> Please see my comment about relative references into IANA registries above >>>> in question 11. > >>> >>> 6) Noted. Relative references have also been restored in this sentence. >>> Please see our response/followup question to question 11. > > (See above.) > >>>>> 17) <!-- [rfced] References >>>>> >>>>> a) Please review the following reference. The original URL for this >>>>> reference - >>>>> http://www.openmobilealliance.org/wp/omna/lwm2m/lwm2mregistry.html - >>>>> redirects to the following URL: >>>>> https://www.openmobilealliance.org/specifications with the title "OMA >>>>> Specifications". >>>>> >>>>> We could not find a page with the original title for this reference "OMA >>>>> LightweightM2M (LwM2M) Object and Resource Registry". We did find the >>>>> following page: >>>>> https://www.openmobilealliance.org/specifications/registries, which >>>>> contains separate links to the LwM2M Objects and >>>>> Resources registries. >>>>> >>>>> Would you like to update this reference to point to this new URL? >>>>> >>>>> Current: >>>>> [OMA] Open Mobile Alliance, "OMA LightweightM2M (LwM2M) Object >>>>> and Resource Registry", >>>>> <http://www.openmobilealliance.org/wp/omna/lwm2m/ >>>>> lwm2mregistry.html>. >>>> >>>> Right, so the URL and the title would need to be updated. >>>> The actual HTML page title is awkward, though. >>>> >>>> Title: openmobilealliance.org/specifications/registries/objects/ >>>> >>>> Maybe we can use the <h1> title instead of the document.title (which I >>>> don’t find in the page source, by the way): >>>> >>>> NEW: >>>> Title: LwM2M OBJECTS >>>> Link: https://www.openmobilealliance.org/specifications/registries/objects >>>> >>>> This link is slightly more specific than what we referenced before, but >>>> fits the site of the citation (which is about objects, not about >>>> resources) even better. >>>> >>>> (With my browser, the page briefly indicates that it is embarrassed about >>>> itself and then switches back to what we want here; this may need some >>>> additional debugging.) > > The reference looks good now. > >>>>> b) The information for this reference appears to be from the 2020 version >>>>> of ECMA Standard ECMA-262. However, the URL provided points to the 2024 >>>>> edition. >>>>> >>>>> We've updated this reference to use the information from the URL - that >>>>> is, >>>>> the 2024 edition. Please let us know if you have any objections. >>>>> >>>>> Current: >>>>> [ECMA-262] Ecma International, "ECMAScript 2024 Language >>>>> Specification", 15th Edition, ECMA Standard ECMA-262, June >>>>> 2024, <https://www.ecma-international.org/wp- >>>>> content/uploads/ECMA-262.pdf>. >>>>> --> >>>> >>>> By now, that would be >>>> title: ECMA-262, 16th edition, June 2025 >>>> link: >>>> https://ecma-international.org/wp-content/uploads/ECMA-262_16th_edition_june_2025.pdf >>>> >>>> Of course, the intention is not to point just to this specific revision. >>>> I don’t think we have a general guideline how to deal with documents that >>>> are on a regular update schedule, so simply going to the 2025 revision >>>> might be the right thing to do. >>>> >>>> (This is based on the belief that the new functionality in 16th edition >>>> relative to 11th edition does not extend the pattern language resulting >>>> from applying the suggested limitations in Appendix C.2 to the referenced >>>> edition. Updating these links does need some care…) >>> >>> 7) Both references have been updated. Please review the updated files and >>> let us know if they appear as desired. > > The ECMAScript reference also looks good now (both in 9.2 and C.2). > >>>>> 19) <!-- [rfced] Does "earlier drafts" refer to earlier drafts of the I-D >>>>> that became this RFC or earlier versions of SDF (defined elsewhere)? >>>>> Perhaps this can be clarified? >>>>> >>>>> Current: >>>>> Appendix E. Some Changes From Earlier Drafts >>>>> --> >>>> >>>> The first (real) paragraph of Appendix E is actually intended to clarify >>>> this. >>>> To answer the question: All the published draft specs have been >>>> Internet-Drafts, see timeline on >>>> https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/ >>>> >>>> “Earlier drafts” of course is a bit confusing as the RFC-to-be no longer >>>> is a draft. >>>> Maybe “from drafts of this specification”? >>> >>> 8) We have updated the title of Appendix E as follows. Additionally, would >>> the following update clarify "previous revisions of SDF"? >>> >>> Current (Title of Appendix E): Some Changes from Earlier Draft Versions of >>> this Specification >>> >>> Current (Text in Appendix E): >>> Previous revisions of SDF have been in use for several years, and both >>> significant collections of older SDF models and older SDF conversion >>> tools are available today. >>> >>> Perhaps: >>> SDF, as defined in earlier drafts versions of this specification, have been >>> in use >>> for several years; both significant collections of older SDF models and >>> older SDF >>> conversion tools are available today. > > Maybe we can keep the “previous revisions”? > > Maybe: > Previous revisions of SDF, as defined in earlier drafts of this > specification, have been in use > for several years; both significant collections of older SDF models and older > SDF > conversion tools are available today. > > Grüße, Carsten > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
