Hi Authors, Happy new year!
This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process. We also note that questions 6, 21, and 23 are still outstanding. Thank you! Madison Church RFC Production Center > On Dec 23, 2025, at 12:29 PM, Madison Church <[email protected]> > wrote: > > 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]
