Hi Madison, here are some responses to questions 6 and 20-23.
6, 21, and 23 are marked as WAITING FOR FULL REREAD; I’ll get to those later. Grüße, Carsten On Dec 16, 2025, at 22:27, Madison Church <[email protected]> wrote: > > Hi Authors, > > This is another friendly reminder that we have yet to hear back from some of > you regarding this document’s readiness for publication. > > Please review the AUTH48 status page > (http://www.rfc-editor.org/auth48/rfc9880) for further information and the > previous messages in this thread (sent on 27 October). Note that questions 6, > 8, 11, 14, 17, 19, 20, 21, 22, and 23 still await author response. We will > wait to hear from you at your earliest convenience. >>>>>>>>>> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Fen%2Frfcxml-vocabulary%23aside&data=05%7C02%7Cari.keranen%40ericsson.com%7C6e838e68034445cd375208de2203af4a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638985596745433644%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nla5ZZiycjR%2FmcbzrKFngG5jvOQ6zmpWTLpBgQNyl0w%3D&reserved=0). >>>>>>>>>> —> >>>>>>>>> [WAITING FOR FULL REREAD] >>>>>>>> >>>>>>>>>> 20) <!-- [rfced] Please review each artwork element and let us know >>>>>>>>>> if any >>>>>>>>>> should be marked as sourcecode (or another element) instead. The artwork elements are fine. >>>>>>>>>> >>>>>>>>>> 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). So we would like to change: OLD: <sourcecode type=""><![CDATA[ NEW: <sourcecode type="json"><![CDATA[ >>>>>>>>>> In addition, please consider whether the "type" attribute of any >>>>>>>>>> sourcecode >>>>>>>>>> element should be set and/or has been set correctly. See above for Figure 5. Of the 25 <sourcecode already marked type=“json”, the type is correct (but see below). The remaining 2 <sourcecode are in the appendixes, one with type=“cddl” (correct) and one with type=“jso.json”. There was a draft that was attempting to register “application/schema+json” for the latter (https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-rest-api-mediatypes-03), but the newer https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-rest-api-mediatypes-08 no longer does that. I don’t know why, but it seems there is no registered media type right now for jso.json. So I’d stick with the name we have invented for that. Maybe there is some other prior practice. It would be correct, but confusing to use type=“json”, because we use that for SDF snippets in this specification. >>>>>>>>> >>>>>>>>> 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.) So, in summary, those 25 instances should be changed from type=“json” to type=“sdf+json” (leaving out the “application/“ as is customary), as well as that for Figure 5 (type=“” ➔ type=“sdf+json”). >>>>>>>>> >>>>>>>>>> --> >>>>>>>>>> 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. >>>>>>>>> [WAITING FOR FULL REREAD] >>>>>>>>> >>>>>>>>> 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 We need to be very careful here (see definition of “Property” in 1.2): We are using uppercase “Property” for the affordance (which is represented in SDF using the class keyword “sdfProperty”), not for the JSO name for map entries (which is typically in typewriter font). This is already quite consistent, maybe the following changes could help some more: OLD: the property affordances described by the model NEW: the Property affordances described by the model OLD: containing a property that can be addressed NEW: containing a Property that can be addressed OLD: The definition of the entry "bar" in the property "foo" means that data corresponding to the "foo" property in a property interaction NEW: The definition of the entry "bar" in the Property "foo" means that data corresponding to the "foo" Property in a Property interaction I don’t think we should change Table 6. In Section 8 we mean the English sense of “properties”, maybe we should change these two instances to “characteristics” to reduce confusion. Appendix A and B should not be changed. There are several occurrences of “properties” in Appendix C that mean those other (JSO) “properties” and therefore don’t need to be changed. >>>>>>>>>> quality names vs. Quality Names All 7 “quality names” should be changed to “Quality Names”. >>>>>>>>>> SDF model vs. SDF Model There are few occurrences of “SDF Model” outside title case. These are OK in Section 1.2, which says: <t>Terms introduced in this section are capitalized when used in this section. To maintain readability, capitalization is only used when I couldn’t find any other, so we are consistently using “SDF model” outside 1.2 and titles. >>>>>>>>>> >>>>>>>>>> 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 We are using “dataqualities” and sometimes “dataquality” in the limited case when we refer to the concept formally described in CDDL in Appendix A, and “data qualities” everywhere else. The boundary is fuzzy here, but I think we are already getting this right. >>>>>>>> >>>>>>>>>> c) Other >>>>>>>>>> base SDF vs. SDF base There are only 3 instances of SDF base, which are best converted to base SDF. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. [WAITING FOR FULL REREAD] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
