Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] We are having trouble understanding how the text after the comma relates to the earlier part of the sentence. Does this mean Group in nested definitions also represents the SDF document? Please clarify. Original (full definition included for context): Group: An entry in the main JSON map that represents the SDF document, and in certain nested definitions. A group has a Class Name Keyword as its key and a map of named definition entries (Definition Group) as a value. Perhaps: Group: An entry in the main JSON map and certain nested definitions that represent the SDF document. --> 3) <!-- [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. --> 4) <!-- [rfced] The SVG figure contains duplicate ids, which generates invalid HTML. We ran a utility that is supposed to create unique ids within the SVG on a copy of the file, but it didn't seem to work. xml2rfc yields the following warning - please review and let us know if a correction is possible. rfc9880.xml(480): Warning: Duplicate attribute id="link_sdfAction_sdfData" found after including svg from inline:b'<svg xmlns:xlink="http://www.w3' .... This can cause problems with some browsers. --> 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. --> 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). --> 7) <!-- [rfced] May we rephrase "itself" to "which is" for improved readability? Original: From the outside of a specification, Given Names are usually used as part of a hierarchical name that looks like a JSON pointer [RFC6901], itself generally rooted in (used as the fragment identifier in) an outer namespace that looks like an https:// URL (see Section 4). Perhaps: From the outside of a specification, Given Names are usually used as part of a hierarchical name that looks like a JSON pointer [RFC6901], which is generally rooted in (used as the fragment identifier in) an outer namespace that looks like an https:// URL (see Section 4). --> 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". In turn, the keyword's value is a JSON map with a set of entries that represent qualities that apply to the included definition. --> 9) <!-- [rfced] We suggest rephrasing the following sentence (i.e., adjusting the placement of "using"). Does the following suggestion retain the sentence's original meaning? Original: This specification does not give a strict definition for the format of the version string but each using system or organization should define internal structure and semantics to the level needed for their use. Perhaps: This specification does not give a strict definition for the format of the version string, but each system or organization using the version string should define internal structure and semantics to the level needed for their use. --> 10) <!-- [rfced] Should "JSON pointer" be rephrased as "a JSON pointer" or "JSON pointers" to describe Figure 4? Original: The example also shows the use of JSON pointer with "sdfRef" to use a pre-existing definition for the sdfProperty "currentTemperature" and for the sdfOutputData produced by the sdfEvent "overTemperatureEvent". Perhaps: The example also shows the use of a JSON pointer with "sdfRef" to use a pre-existing definition for the sdfProperty "currentTemperature" and for the sdfOutputData produced by the sdfEvent "overTemperatureEvent". Or: The example also shows the use of JSON pointers with "sdfRef" to use a pre-existing definition for the sdfProperty "currentTemperature" and for the sdfOutputData produced by the sdfEvent "overTemperatureEvent". --> 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. 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> --> 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 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 --> 13) <!-- [rfced] IANA provided the following notes to the RFC Production Center. We believe the document has been updated accordingly. Please review and let us know if any updates are needed. NOTE 1: The authors have notified us that "4.5.1" (Names) needs to be changed to "4.5.2" (Units) both in the "Repository" field in Section 7.3 and in Note 1 to Table 4 in Section 4.7. NOTE 2: With author permission, we've prepended "SDF" to the three new registry names that didn't already refer to SDF. --> 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). --> 15) <!-- [rfced] Please review the text below. We note that "sub-delims" is not mentioned in Section 2.3 of RFC 3986 [STD66]. The term is defined in Section 2.2 of RFC 3986 [STD66]. Should Section 2.3 be updated to Section 2.2? Original: Index value: Percent-encoding (Section 2.1 of RFC 3986 [STD66]) is required of any characters in unit names except for the set "unreserved" (Section 2.3 of RFC 3986 [STD66]), the set "sub- delims" (Section 2.3 of RFC 3986 [STD66]), ":" or "@" (i.e., the result must match the ABNF rule "pchar" in Section 3.3 of RFC 3986 [STD66]). --> 16) <!-- [rfced] What is "these" referring to in the sentence below? Current: In applications that dynamically acquire models and obtain modules from module references in these, the security considerations of dereferenceable identifiers apply (see [DEREFERENCEABLE-ID-PATTERN] for a more extensive discussion of dereferenceable identifiers). Perhaps: In applications that dynamically acquire models and obtain modules from module references in these applications, the security considerations of dereferenceable identifiers apply (see [DEREF-ID-PATTERN] for a more extensive discussion of dereferenceable identifiers). --> 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>. 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>. --> 18) <!-- [rfced] Should "their complements" be placed on a separate bullet to follow the original pattern of this list? Original: * characters; * character classes in square brackets, including ranges; their complements; * simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and {n,}; * grouping parentheses; * the choice operator |; * and anchors (beginning-of-input ^ and end-of-input $). Perhaps: * characters; * character classes in square brackets, including ranges; * their complements; * simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and {n,}; * grouping parentheses; * the choice operator |; * and anchors (beginning-of-input ^ and end-of-input $). --> 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 --> 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. In addition, please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly. 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. --> 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. <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 affordance vs. Affordance boolean vs. Boolean CURIE vs. curie JSON pointer vs. JSON Pointer Properties vs. properties quality names vs. Quality Names SDF model vs. SDF Model b) Spacing data qualities vs. dataqualities data quality vs. data quality 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. --> 24) <!-- [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 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]
