Hi Carsten, Note that we have added IANA to this thread.
After further discussion with IANA regarding questions 11 and 14, we have removed the relative links because they are not permanent. We have reverted the text, so the registry titles appear in quotes (i.e., “SenML Units” and “Secondary Units”) as shown in the updated files. Please let us know if there are any additional textual updates needed. Updated files: 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 Updated diff files: 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) AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9880 Thank you, Madison Church RFC Production Center > On Oct 27, 2025, at 6:42 AM, Madison Church <[email protected]> > wrote: > > Hi Carsten, > > Thank you for your reply, and apologies for the delayed response! We have > updated the document accordingly. Please see below for followup > questions/comments. Note that we have left outstanding items in this thread > for convenience (and removed questions that have been resolved). > >> On Oct 10, 2025, at 3:02 PM, Carsten Bormann <[email protected]> wrote: >> >> RFC-editor, >> >> thank you for preparing this RFC-to-be. >> >> We’ll first reply to the more specific ones of your questions below. >> We will respond to more general questions (that require us to scan the >> document) in the next round (marked here with TO CHECK in questions 6, 20, >> 21, 22, 23). >> >> Please note that we are also preparing a -25, with two typo/C&P fixes and >> one more technical omission fixed (PR #187 to #189 in >> https://github.com/ietf-wg-asdf/SDF/pulls). >> We previously prepared a -24 with PR #186 in it (technical omissions), which >> you already picked up. >> You probably need AD approval for all these. > > 1) Thank you for letting us know! We incorporated these edits into the > document and also sent a reminder (on October 23) for the AD(s) to review > these updates. These updates may be best viewed side-by-side in this diff > file: https://www.rfc-editor.org/authors/rfc9880-auth48rfcdiff.html. Please > review the files carefully and let us know if they appear as desired. > >> Grüße, Carsten >> >> >> On 2025-10-07, at 07:03, [email protected] wrote: >>> >>> Authors, >>> >>> While reviewing this document during AUTH48, please resolve (as necessary) >>> the following questions, which are also in the source file. >>> 5) <!-- [rfced] Figure 2: The SVG includes additional information that is >>> not present in the text. Is this as expected? For example, we see 0+, 1, >>> and (c) in the SVG but not in the text artwork. In addition, sdfEvent and >>> sdfAction appear in a different order. Please review. >>> --> >> >> We originally had completely given up on providing a plaintext form of the >> illustration. >> The plaintext illustration that now is in there is somewhat rudimentary. >> As you notice, it doesn’t have the occurrence labels (0+, 1), and it doesn’t >> mark the boxes as compositions which looks almost like a © symbol in the >> generated SVG. >> >> We do warn that this is a limited rendition, so we think we are good. > > 2) Thank you for the explanation! We also note that pointing to the HTML in > the text (and removing the ASCII art) is also an option to avoid mismatching > figures; see https://authors.ietf.org/en/diagrams. Let us know if you prefer > to keep the text/figure as is, or if you would like to update the document. > For example, Figure 1 in RFC 9633 > (https://www.rfc-editor.org/rfc/rfc9633.txt) shows how this would appear in > the text output. > >>> 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] >> >>> 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. > >>> 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). > >>> 12) <!-- [rfced] The IANA registry includes "(note 1)" as part of the >>> description for unix-time, but there is no note included in the registry. >>> Should the notes be included in the registry >> >> Yes, please. > > 5) We will ask IANA to update to include this note. > >>> or perhaps "(note 1)" should >>> be removed from the description? >>> >>> Original (text): >>> | unix-time | A point in | number | POSIX time | Section | >>> | | civil time | | | 3.4.2 of | >>> | | (note 1) | | | RFC 8949 | >>> | | | | | [STD94] | >>> >>> See the IANA registry: >>> https://www.iana.org/assignments/sdf/sdf.xhtml#sdftype-values >>> --> > >>> 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. > >>> 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.) >> >>> 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. > >>> 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. > >>> 20) <!-- [rfced] Please review each artwork element and let us know if any >>> should be marked as sourcecode (or another element) instead. >>> >>> We updated Figure 5 from artwork to sourcecode. Please confirm that this is >>> correct. >> >> When does a snippet (like the one about warning/danger in 2.3.2, which is >> marked as artwork) become sourcecode? >> Figure 5 is not really parsable per se, it needs to be integrated into >> context to *really* be sourcecode. >> Despite this, marking it as JSON sourcecode probably is OK (even if >> kramdown-rfc would complain that it isn’t really JSON, because it is a >> snippet, or actually two of them in one figure). >> >>> In addition, please consider whether the "type" attribute of any sourcecode >>> element should be set and/or has been set correctly. >> >> [TO CHECK] >> >>> The current list of preferred values for "type" is available at >>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >>> If the current list does not contain an applicable type, feel free to >>> suggest additions for consideration. Note that it is also acceptable >>> to leave the "type" attribute not set. >> >> We haven’t really discussed so far whether there should be a sourcecode type >> specifically for SDF. >> By default, application/sdf+json is one (usually leaving out application/, >> so just “sdf+json”). >> We do have precedent for using structured syntax suffixes in >> yang-instance-data+json, so nothing appears to speak against use that. >> (There are 25 instances where this needs to be checked.) >> >>> --> >>> 21) <!-- [rfced] We note that these terms appear both with and without <tt> >>> tags. Please review each instance of the terms below and ensure that they >>> appear in the document as desired. If these terms should be formatted >>> consistently or follow a specific pattern, please let us know. >> >> [TO CHECK] >> >> Generally, when the sourcecode construct is meant, we use the typewriter >> font; when the concept is meant (“an array of string values”…), we don’t, >> and we then use the English capitalization (“Boolean”). >> >>> <tt>absolute-URI</tt> >>> <tt>array</tt> >>> <tt>boolean</tt> >>> <tt>curie</tt> >>> <tt>date-time</tt> (also appears in quotes) >>> <tt>defaultNamespace</tt> >>> <tt>description</tt> >>> <tt>enum</tt> >>> <tt>false</tt> >>> <tt>features</tt> (also appears in quotes) >>> <tt>format</tt> >>> <tt>info</tt> >>> <tt>integer</tt> >>> <tt>items</tt> >>> <tt>json-schema.org</tt> >>> <tt>label</tt> >>> <tt>length</tt> >>> <tt>named-sdq</tt> >>> <tt>namespace</tt> >>> <tt>null</tt> >>> <tt>number</tt> >>> <tt>object</tt> (also appears in quotes) >>> <tt>pattern</tt> (also appears in quotes) >>> <tt>properties</tt> (also appears in quotes) >>> <tt>referenceable-name</tt> (also appears in quotes) >>> <tt>required</tt> >>> <tt>sdfAction</tt> >>> <tt>sdfChoice</tt> >>> <tt>sdfData</tt> >>> <tt>sdfEvent</tt> >>> <tt>sdfObject</tt> >>> <tt>sdfOutputData</tt> >>> <tt>sdfProperty</tt> >>> <tt>sdfRef</tt> >>> <tt>sdfRequired</tt> (also appears in quotes) >>> <tt>sdfThing</tt> >>> <tt>sdf</tt> >>> <tt>sdfType</tt> >>> <tt>string</tt> >>> <tt>toggle</tt> (also appears in quotes) >>> <tt>true</tt> >>> <tt>type</tt> >>> <tt>unit(s)</tt> >>> <tt>value</tt> >>> --> >>> >>> >>> 22) <!-- [rfced] Please review the following terms and let us know if/how >>> we should update for consistency. >>> >>> a) Capitalization >> >> Continue here later… [TO CHECK] >> >>> Properties vs. properties >>> quality names vs. Quality Names >>> SDF model vs. SDF Model >>> >>> b) Spacing >>> data qualities vs. dataqualities >>> data quality vs. data quality >> >> ? > > 9) Apologies for the confusion. Here is the correct side-by-side comparison: > data quality vs. dataquality > >>> c) Other >>> base SDF vs. SDF base >>> --> >>> >>> >>> 23) <!-- [rfced] FYI - We have added expansions for abbreviations upon >>> first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >>> each expansion in the document carefully to ensure correctness. >>> --> >> >> We’ll get to this in the diff reading phase. >> [TO CHECK] > > 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 > > Diff files: > 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) > > For the AUTH48 status page, see: https://www.rfc-editor.org/auth48/rfc9880. > > Thank you! > > Madison Church > RFC Production Center > >>> Thank you. >> >> Thank you! >> >>> Madison Church and Sandy Ginoza >>> RFC Production Center >>> >>> >>> >>> >>> On Oct 6, 2025, at 9:57 PM, [email protected] wrote: >>> >>> *****IMPORTANT***** >>> >>> Updated 2025/10/06 >>> >>> 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/rfc9880.xml >>> https://www.rfc-editor.org/authors/rfc9880.html >>> https://www.rfc-editor.org/authors/rfc9880.pdf >>> https://www.rfc-editor.org/authors/rfc9880.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9880-diff.html >>> https://www.rfc-editor.org/authors/rfc9880-rfcdiff.html (side by side) >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9880-xmldiff1.html >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9880 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC 9880 (draft-ietf-asdf-sdf-24) >>> >>> Title : Semantic Definition Format (SDF) for Data and >>> Interactions of Things >>> Author(s) : M. Koster, Ed., C. Bormann, Ed., A. Keränen >>> WG Chair(s) : Michael Richardson, Lorenzo Corneo >>> >>> Area Director(s) : Andy Newton, Orie Steele >>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
