Hi Carsten, Thank you for your reply! We have updated the document as requested. Please see inline for a clarifying question regarding sourcecode types (note that we have trimmed this thread to remove items that have been resolved for conciseness).
>>>>>>>>>>> 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] > >>>>>>>>>>> >>>>>>>>>>> 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. [rfced] To clarify, should the type be listed as "application/schema+json" or "jso.json" (or another type)? Note that we have left the type as "jso.json" for now, but we will update to the preferred sourcecode type. Thank you! Madison Church RFC Production Center > 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] >>>>>>>>>>> 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]
