rfc9880v2.txt		rfc9880.txt
	Internet Engineering Task Force (IETF) M. Koster, Ed.		Internet Engineering Task Force (IETF) M. Koster, Ed.
	Request for Comments: 9880 KTC Control AB		Request for Comments: 9880 KTC Control AB
	Category: Standards Track C. Bormann, Ed.		Category: Standards Track C. Bormann, Ed.
	ISSN: 2070-1721 Universität Bremen TZI		ISSN: 2070-1721 Universität Bremen TZI
	A. Keränen		A. Keränen
	Ericsson		Ericsson
	October 2025		December 2025
	Semantic Definition Format (SDF) for Data and Interactions of Things		Semantic Definition Format (SDF) for Data and Interactions of Things
	Abstract		Abstract
	The Semantic Definition Format (SDF) is a format for domain experts		The Semantic Definition Format (SDF) is a format for domain experts
	to use in the creation and maintenance of data and interaction models		to use in the creation and maintenance of data and interaction models
	that describe Things, i.e., physical objects that are available for		that describe Things, i.e., physical objects that are available for
	interaction over a network. An SDF specification describes		interaction over a network. An SDF specification describes
	definitions of SDF Objects/SDF Things and their associated		definitions of SDF Objects/SDF Things and their associated
	skipping to change at line 184 ¶		skipping to change at line 184 ¶
	follow. The normative Appendix A defines the syntax of SDF in terms		follow. The normative Appendix A defines the syntax of SDF in terms
	of its JSON structures, employing the Concise Data Definition		of its JSON structures, employing the Concise Data Definition
	Language (CDDL) [RFC8610]. This is followed by the informative		Language (CDDL) [RFC8610]. This is followed by the informative
	Appendix B, a rendition of the SDF syntax in a "JSON Schema" format		Appendix B, a rendition of the SDF syntax in a "JSON Schema" format
	as they are defined by json-schema.org (collectively called JSO).		as they are defined by json-schema.org (collectively called JSO).
	The normative Appendix C defines certain terms ("data qualities")		The normative Appendix C defines certain terms ("data qualities")
	used at the SDF data model level that were inspired by JSO. The		used at the SDF data model level that were inspired by JSO. The
	informative Appendix D provides a few examples for the use of		informative Appendix D provides a few examples for the use of
	composition in SDF. Finally, Appendix E provides some historical		composition in SDF. Finally, Appendix E provides some historical
	information that can be useful in upgrading earlier, pre-standard SDF		information that can be useful in upgrading earlier, pre-standard SDF
	models and implementations to SDF base.		models and implementations to base SDF.
	1.2. Terminology and Conventions		1.2. Terminology and Conventions
	Terms introduced in this section are capitalized when used in this		Terms introduced in this section are capitalized when used in this
	section. To maintain readability, capitalization is only used when		section. To maintain readability, capitalization is only used when
	needed where they are used in the body of this document.		needed where they are used in the body of this document.
	Programming Platform Terms		Programming Platform Terms
	The following definitions mention terms that are used with specific		The following definitions mention terms that are used with specific
	skipping to change at line 426 ¶		skipping to change at line 426 ¶
	sdfProperty group, represented by a Boolean, will be true for "on"		sdfProperty group, represented by a Boolean, will be true for "on"
	and will be false for "off". The Actions on or off declared in the		and will be false for "off". The Actions on or off declared in the
	sdfAction group are redundant with setting the value and are in the		sdfAction group are redundant with setting the value and are in the
	example to illustrate that there are often different ways of		example to illustrate that there are often different ways of
	achieving the same effect. The action toggle will invert the value		achieving the same effect. The action toggle will invert the value
	of the sdfProperty value so that 2-way switches can be created;		of the sdfProperty value so that 2-way switches can be created;
	having such action will avoid the need for retrieving the current		having such action will avoid the need for retrieving the current
	value first and then applying/setting the inverted value.		value first and then applying/setting the inverted value.
	The sdfObject group lists the affordances of Things modeled by this		The sdfObject group lists the affordances of Things modeled by this
	sdfObject. The sdfProperty group lists the property affordances		sdfObject. The sdfProperty group lists the Property affordances
	described by the model; these represent various perspectives on the		described by the model; these represent various perspectives on the
	state of the sdfObject. Properties can have additional qualities to		state of the sdfObject. Properties can have additional qualities to
	describe the state more precisely. Properties can be annotated to be		describe the state more precisely. Properties can be annotated to be
	read, write, or read/write; how this is actually done by the		read, write, or read/write; how this is actually done by the
	underlying transfer protocols is not described in the SDF model but		underlying transfer protocols is not described in the SDF model but
	left to companion protocol bindings. Properties are often used with		left to companion protocol bindings. Properties are often used with
	RESTful paradigms [REST-IOT] describing state. The sdfAction group		RESTful paradigms [REST-IOT] describing state. The sdfAction group
	is the mechanism to describe other interactions in terms of their		is the mechanism to describe other interactions in terms of their
	names, input, and output data (no data are used in the example), as		names, input, and output data (no data are used in the example), as
	in a POST method in REST or in a remote procedure call. The example		in a POST method in REST or in a remote procedure call. The example
	toggle is an Action that changes the state based on the current state		toggle is an Action that changes the state based on the current state
	of the Property named value. (The third type of affordance is		of the Property named value. (The third type of affordance is
	Events, which are not described in this example.)		Events, which are not described in this example.)
	In the JSON representation, the info group is an exception in that		In the JSON representation, the info group is an exception in that
	this group's map has keys taken from the SDF vocabulary. All other		this group's map has keys taken from the SDF vocabulary. All other
	groups (such as namespace and sdfObject) have maps with keys that are		groups (such as namespace and sdfObject) have maps with keys that are
	freely defined by the model writer (Switch, value, on, etc.). These		freely defined by the model writer (Switch, value, on, etc.). These
	map keys are therefore called _given names_. The groups made up of		map keys are therefore called _given names_. The groups made up of
	entries with given names as keys usually use the named<> production		entries with given names as keys usually use the named<> production
	in the formal syntax of SDF Appendix A. Where the values of these		in the formal syntax of SDF (Appendix A). Where the values of these
	entries are maps, these again use SDF vocabulary keys, and so on,		entries are maps, these again use SDF vocabulary keys, and so on,
	generally alternating in further nesting. The SDF-defined vocabulary		generally alternating in further nesting. The SDF-defined vocabulary
	items used in the hierarchy of such groups are often, but not always,		items used in the hierarchy of such groups are often, but not always,
	called _quality names_ or _qualities_. See Section 2.3 for more		called _Quality Names_ or _qualities_. See Section 2.3 for more
	information about naming in SDF.		information about naming in SDF.
	2.2. Elements of an SDF Model		2.2. Elements of an SDF Model
	The SDF language uses six predefined Class Name Keywords for modeling		The SDF language uses six predefined Class Name Keywords for modeling
	connected Things, which are illustrated in Figure 2 (limited		connected Things, which are illustrated in Figure 2 (limited
	rendition in the plaintext form of this document, please use		rendition in the plaintext form of this document, please use
	typographic forms for full information).		typographic forms for full information).
	,--------.		,--------.
	skipping to change at line 771 ¶		skipping to change at line 771 ¶
	typically employing kebab-case for names constructed out of multiple		typically employing kebab-case for names constructed out of multiple
	words [KebabCase]. ASCII hyphen/minus can then unambiguously be		words [KebabCase]. ASCII hyphen/minus can then unambiguously be
	translated to an ASCII _ underscore character and back depending on		translated to an ASCII _ underscore character and back depending on
	the programming environment. Some styles also allow a dot (".") in		the programming environment. Some styles also allow a dot (".") in
	given names. Given Names are often sufficiently self-explanatory		given names. Given Names are often sufficiently self-explanatory
	that they can be used in place of the label quality if that is not		that they can be used in place of the label quality if that is not
	given. In turn, if a given name turns out too complicated, a more		given. In turn, if a given name turns out too complicated, a more
	elaborate label can be given and the given name kept simple. As		elaborate label can be given and the given name kept simple. As
	given names are "programmers' names", base SDF does not address		given names are "programmers' names", base SDF does not address
	internationalization of given names. (More likely qualities to		internationalization of given names. (More likely qualities to
	receive localizable equivalents by exercising the quality name		receive localizable equivalents by exercising the Quality Name
	extension point are label and description).		extension point are label and description).
	Further, to enable Given Names to have a more powerful role in		Further, to enable Given Names to have a more powerful role in
	building global hierarchical names, an extension is planned that		building global hierarchical names, an extension is planned that
	makes use of qualified names for Given Names. So, until that		makes use of qualified names for Given Names. So, until that
	extension is defined, Given Names with one or more embedded colons		extension is defined, Given Names with one or more embedded colons
	are reserved and MUST NOT be used in an SDF document.		are reserved and MUST NOT be used in an SDF document.
	All names in SDF are case-sensitive.		All names in SDF are case-sensitive.
	skipping to change at line 793 ¶		skipping to change at line 793 ¶
	SDF definitions are contained in SDF documents together with data		SDF definitions are contained in SDF documents together with data
	about the SDF document itself (information block). Definitions and		about the SDF document itself (information block). Definitions and
	declarations from additional SDF documents can be referenced;		declarations from additional SDF documents can be referenced;
	together with the definitions and declarations in the referencing SDF		together with the definitions and declarations in the referencing SDF
	document, they build the SDF model expressed by that SDF document.		document, they build the SDF model expressed by that SDF document.
	Each SDF document is represented as a single JSON map. This map can		Each SDF document is represented as a single JSON map. This map can
	be thought of as having three blocks: the information block, the		be thought of as having three blocks: the information block, the
	namespaces block, and the definitions block. These blocks contain		namespaces block, and the definitions block. These blocks contain
	zero or more JSON name/value pairs, the names of which are quality		zero or more JSON name/value pairs, the names of which are Quality
	names and the values of which mostly are (nested) maps (the exception		Names and the values of which mostly are (nested) maps (the exception
	defined in SDF base is the defaultNamespace quality, the value of		defined in base SDF is the defaultNamespace quality, the value of
	which is a text string). An empty nested map of this kind is		which is a text string). An empty nested map of this kind is
	equivalent to not having the quality included at all.		equivalent to not having the quality included at all.
	3.1. Information Block		3.1. Information Block
	The information block contains generic metadata for the SDF document		The information block contains generic metadata for the SDF document
	itself and all included definitions. To enable tool integration, the		itself and all included definitions. To enable tool integration, the
	information block is optional in the grammar of SDF; most processes		information block is optional in the grammar of SDF; most processes
	for working with SDF documents will have policies that only SDF		for working with SDF documents will have policies that only SDF
	documents with an info block can be processed. It is therefore		documents with an info block can be processed. It is therefore
	skipping to change at line 978 ¶		skipping to change at line 978 ¶
	"type": "boolean"		"type": "boolean"
	}		}
	}		}
	}		}
	}		}
	Figure 3: Example sdfObject Definition		Figure 3: Example sdfObject Definition
	This example defines an sdfObject "foo" that is defined in the		This example defines an sdfObject "foo" that is defined in the
	default namespace (full address: #/sdfObject/foo), containing a		default namespace (full address: #/sdfObject/foo), containing a
	property that can be addressed as #/sdfObject/foo/sdfProperty/bar,		Property that can be addressed as #/sdfObject/foo/sdfProperty/bar,
	with data of type boolean.		with data of type boolean.
	Often, definitions are also declarations. The definition of the		Often, definitions are also declarations. The definition of the
	entry "bar" in the property "foo" means that data corresponding to		entry "bar" in the Property "foo" means that data corresponding to
	the "foo" property in a property interaction offered by Thing can		the "foo" Property in a Property interaction offered by Thing can
	have zero or one components modeled by "bar". Entries within		have zero or one components modeled by "bar". Entries within
	sdfProperty, sdfAction, and sdfEvent that are in turn within		sdfProperty, sdfAction, and sdfEvent that are in turn within
	sdfObject or sdfThing entries, are also declarations; entries within		sdfObject or sdfThing entries, are also declarations; entries within
	sdfData are not. Similarly, sdfObject or sdfThing entries within an		sdfData are not. Similarly, sdfObject or sdfThing entries within an
	sdfThing definition specify that the interactions offered by a Thing		sdfThing definition specify that the interactions offered by a Thing
	modeled by this sdfThing include the interactions modeled by the		modeled by this sdfThing include the interactions modeled by the
	nested sdfObject or sdfThing.		nested sdfObject or sdfThing.
	3.4. Top-Level Affordances and sdfData		3.4. Top-Level Affordances and sdfData
	skipping to change at line 1281 ¶		skipping to change at line 1281 ¶
	* The Boolean value true. The affordance or grouping itself that		* The Boolean value true. The affordance or grouping itself that
	carries the sdfRequired keyword is declared to be mandatory to be		carries the sdfRequired keyword is declared to be mandatory to be
	represented.		represented.
	Note that referenceable-names are not subject to the encoding JSON		Note that referenceable-names are not subject to the encoding JSON
	Pointers require as discussed in Section 2.3.2. To ensure that		Pointers require as discussed in Section 2.3.2. To ensure that
	referenceable-names are reliably distinguished from JSON Pointers,		referenceable-names are reliably distinguished from JSON Pointers,
	they are defined such that they cannot contain ":" or "#" characters		they are defined such that they cannot contain ":" or "#" characters
	(see rule referenceable-name in Appendix A). (If these characters		(see rule referenceable-name in Appendix A). (If these characters
	are indeed contained in a Given Name, a JSON pointer needs to be		are indeed contained in a Given Name, a JSON Pointer needs to be
	formed instead in order to reference it in "sdfRequired", potentially		formed instead in order to reference it in "sdfRequired", potentially
	requiring further path elements as well as JSON Pointer encoding.		requiring further path elements as well as JSON Pointer encoding.
	The need for this is best avoided by choosing Given Names without		The need for this is best avoided by choosing Given Names without
	these characters.)		these characters.)
	The example in Figure 4 shows two required elements in the sdfObject		The example in Figure 4 shows two required elements in the sdfObject
	definition for "temperatureWithAlarm", the sdfProperty		definition for "temperatureWithAlarm", the sdfProperty
	"currentTemperature", and the sdfEvent "overTemperatureEvent". The		"currentTemperature", and the sdfEvent "overTemperatureEvent". The
	example also shows the use of JSON Pointers with "sdfRef" to use a		example also shows the use of JSON Pointers with "sdfRef" to use a
	pre-existing definition for the sdfProperty "currentTemperature" and		pre-existing definition for the sdfProperty "currentTemperature" and
	skipping to change at line 2012 ¶		skipping to change at line 2012 ¶
	7.5. Registries		7.5. Registries
	IANA has created the "Semantic Definition Format (SDF)" registry		IANA has created the "Semantic Definition Format (SDF)" registry
	group with the registries defined in this Section.		group with the registries defined in this Section.
	7.5.1. SDF Quality Names		7.5.1. SDF Quality Names
	IANA has created the "SDF Quality Names" registry in the "Semantic		IANA has created the "SDF Quality Names" registry in the "Semantic
	Definition Format (SDF)" registry group with the following template:		Definition Format (SDF)" registry group with the following template:
	Name: A quality name composed of ASCII letters, digits, and dollar		Name: A Quality Name composed of ASCII letters, digits, and dollar
	signs, starting with a lowercase ASCII letter or a dollar sign		signs, starting with a lowercase ASCII letter or a dollar sign
	(i.e., using a pattern of "[a-z$][A-Za-z$0-9]*").		(i.e., using a pattern of "[a-z$][A-Za-z$0-9]*").
	Brief Description: A brief description.		Brief Description: A brief description.
	Reference: A pointer to a specification.		Reference: A pointer to a specification.
	Change Controller: (See Section 2.3 of RFC 8126 [BCP26])		Change Controller: (See Section 2.3 of RFC 8126 [BCP26])
	Quality Names in this registry are intended to be registered in		Quality Names in this registry are intended to be registered in
	skipping to change at line 2037 ¶		skipping to change at line 2037 ¶
	"IETF Review" (Sections 4.7 and 4.8 of RFC 8126 [BCP26]) so that		"IETF Review" (Sections 4.7 and 4.8 of RFC 8126 [BCP26]) so that
	registrations can be made earlier in the process, even earlier than		registrations can be made earlier in the process, even earlier than
	foreseen in [BCP100].)		foreseen in [BCP100].)
	The instructions to the Experts are:		The instructions to the Experts are:
	* to ascertain that the specification is available in an immutable		* to ascertain that the specification is available in an immutable
	reference and has achieved a good level of review in conjunction		reference and has achieved a good level of review in conjunction
	with RFCs or activities of the IETF, and		with RFCs or activities of the IETF, and
	* to be frugal in the allocation of quality names that are		* to be frugal in the allocation of Quality Names that are
	suggestive of generally applicable semantics, keeping them in		suggestive of generally applicable semantics, keeping them in
	reserve for qualities that are likely to enjoy wide use and can		reserve for qualities that are likely to enjoy wide use and can
	make good use of their conciseness.		make good use of their conciseness.
	The "SDF Quality Names" registry starts out as in Table 13; all		The "SDF Quality Names" registry starts out as in Table 13; all
	references for these initial entries are to RFC 9880 (this document)		references for these initial entries are to RFC 9880 (this document)
	and all change controllers are "IETF"".		and all change controllers are "IETF".
	+======================+==========================================+		+======================+==========================================+
	| Name | Brief Description |		| Name | Brief Description |
	+======================+==========================================+		+======================+==========================================+
	| $comment | source code comments only, no semantics |		| $comment | source code comments only, no semantics |
	+----------------------+------------------------------------------+		+----------------------+------------------------------------------+
	| const | constant value |		| const | constant value |
	+----------------------+------------------------------------------+		+----------------------+------------------------------------------+
	| contentFormat | content format |		| contentFormat | content format |
	+----------------------+------------------------------------------+		+----------------------+------------------------------------------+
	skipping to change at line 2142 ¶		skipping to change at line 2142 ¶
	+----------------------+------------------------------------------+		+----------------------+------------------------------------------+
	Table 13: Initial Content of the SDF Quality Names Registry		Table 13: Initial Content of the SDF Quality Names Registry
	7.5.2. SDF Quality Name Prefixes		7.5.2. SDF Quality Name Prefixes
	IANA has created the "SDF Quality Name Prefixes" registry in the		IANA has created the "SDF Quality Name Prefixes" registry in the
	"Semantic Definition Format (SDF)" registry group with the following		"Semantic Definition Format (SDF)" registry group with the following
	template:		template:
	Prefix: A quality name prefix composed of lower case ASCII letters		Prefix: A Quality Name prefix composed of lower case ASCII letters
	and digits, starting with a lower case ASCII letter (i.e., using a		and digits, starting with a lower case ASCII letter (i.e., using a
	pattern of "[a-z][a-z0-9]*").		pattern of "[a-z][a-z0-9]*").
	Contact: A contact point for the organization that assigns quality		Contact: A contact point for the organization that assigns Quality
	names with this prefix.		Names with this prefix.
	Reference: A pointer to additional information, if available.		Reference: A pointer to additional information, if available.
	Quality Name Prefixes are intended to be registered by organizations		Quality Name Prefixes are intended to be registered by organizations
	that plan to define quality names constructed with an organization-		that plan to define Quality Names constructed with an organization-
	specific prefix (Section 2.3.3).		specific prefix (Section 2.3.3).
	The registration policy is Expert Review as per Section 4.5 of RFC		The registration policy is Expert Review as per Section 4.5 of RFC
	8126 [BCP26]. The instructions to the Expert are to ascertain that		8126 [BCP26]. The instructions to the Expert are to ascertain that
	the organization will handle quality names constructed using their		the organization will handle Quality Names constructed using their
	prefix in a way that roughly achieves the objectives for an IANA		prefix in a way that roughly achieves the objectives for an IANA
	registry that supports interoperability of SDF models employing these		registry that supports interoperability of SDF models employing these
	quality names, including:		Quality Names, including:
	* Stability, "stable and permanent";		* Stability, "stable and permanent";
	* Transparency, "readily available" and "in sufficient detail"		* Transparency, "readily available" and "in sufficient detail"
	(Section 4.6 of RFC 8126 [BCP26]).		(Section 4.6 of RFC 8126 [BCP26]).
	The "SDF Quality Name Prefixes" registry is empty at this time.		The "SDF Quality Name Prefixes" registry is empty at this time.
	7.5.3. sdfType Values		7.5.3. sdfType Values
	skipping to change at line 2183 ¶		skipping to change at line 2183 ¶
	Name: A name composed of lower case ASCII letters, digits and -		Name: A name composed of lower case ASCII letters, digits and -
	(ASCII hyphen/minus) characters, starting with a lower case ASCII		(ASCII hyphen/minus) characters, starting with a lower case ASCII
	letter (i.e., using a pattern of "[a-z][-a-z0-9]*").		letter (i.e., using a pattern of "[a-z][-a-z0-9]*").
	Description: A short description of the information model level		Description: A short description of the information model level
	structure and semantics.		structure and semantics.
	type: The value of the quality "type" to be used with this sdfType.		type: The value of the quality "type" to be used with this sdfType.
	JSON Representation A short description of a JSON representation		JSON Representation: A short description of a JSON representation
	that can be used for this sdfType. As per Section 4.7.1, this		that can be used for this sdfType. As per Section 4.7.1, this
	MUST be consistent with the type.		MUST be consistent with the type.
	Reference: A more detailed specification of meaning and use of		Reference: A more detailed specification of meaning and use of
	sdfType.		sdfType.
	sdfType values are intended to be registered to enable modeling		sdfType values are intended to be registered to enable modeling
	additional SDF-specific types (see Section 4.7.1).		additional SDF-specific types (see Section 4.7.1).
	The registration policy is Specification Required as per Section 4.6		The registration policy is Specification Required as per Section 4.6
	skipping to change at line 2261 ¶		skipping to change at line 2261 ¶
	cases on input, preferably by rejecting input that is invalid or that		cases on input, preferably by rejecting input that is invalid or that
	would lead to unpredictable behavior, and avoid generating these		would lead to unpredictable behavior, and avoid generating these
	cases on output.		cases on output.
	Implementations of model languages may also exhibit performance-		Implementations of model languages may also exhibit performance-
	related availability issues when the attacker can control the input,		related availability issues when the attacker can control the input,
	see Section 4.1 of [RFC9535] for a brief discussion and Section 8 of		see Section 4.1 of [RFC9535] for a brief discussion and Section 8 of
	[RFC9485] for considerations specific to the use of pattern.		[RFC9485] for considerations specific to the use of pattern.
	SDF may be used in two processes that are often security relevant:		SDF may be used in two processes that are often security relevant:
	model-based _validation_ of data that is intended to be described by		(1) model-based _validation_ of data that is intended to be described
	SDF models and model-based _augmentation_ of these data with		by SDF models, and (2) model-based _augmentation_ of these data with
	information obtained from the SDF models that apply.		information obtained from the SDF models that apply.
	Implementations need to ascertain the provenance (and thus		Implementations need to ascertain the provenance (and thus
	authenticity and integrity) and applicability of the SDF models they		authenticity and integrity) and applicability of the SDF models they
	employ operationally in such security-relevant ways. Implementations		employ operationally in such security-relevant ways. Implementations
	that make use of the composition mechanisms defined in this document		that make use of the composition mechanisms defined in this document
	need to do this for each of the components they combine into the SDF		need to do this for each of the components they combine into the SDF
	models they employ. Essentially, this process needs to undergo the		models they employ. Essentially, this process needs to undergo the
	same care and scrutiny as any other introduction of source code into		same care and scrutiny as any other introduction of source code into
	a build environment; the possibility of supply-chain attacks on the		a build environment; the possibility of supply-chain attacks on the
	modules imported needs to be considered.		modules imported needs to be considered.
	Specifically, implementations might rely on model-based input		Specifically, implementations might rely on model-based input
	validation for enforcing certain properties of the data structure		validation for enforcing certain characteristics of the data
	ingested (which, if not validated, could lead to malfunctions such as		structure ingested (which, if not validated, could lead to
	crashes and remote code execution). These implementations need to be		malfunctions such as crashes and remote code execution). These
	particularly careful about the data models they apply, including		implementations need to be particularly careful about the data models
	their provenance and potential changes of these properties that		they apply, including their provenance and potential changes of these
	upgrades to the referenced modules may (inadvertently or as part of		characteristics that upgrades to the referenced modules may
	an attack) cause. More generally speaking, implementations should		(inadvertently or as part of an attack) cause. More generally
	strive to be robust against expected and unexpected limitations of		speaking, implementations should strive to be robust against expected
	the model-based input validation mechanisms and their		and unexpected limitations of the model-based input validation
	implementations.		mechanisms and their implementations.
	Similarly, implementations that rely on model-based augmentation may		Similarly, implementations that rely on model-based augmentation may
	generate false data from their inputs; this is an integrity violation		generate false data from their inputs; this is an integrity violation
	in any case, but also can possibly be exploited for further attacks.		in any case, but also can possibly be exploited for further attacks.
	In applications that dynamically acquire models and obtain modules		In applications that dynamically acquire models and obtain modules
	from module references in these models, the security considerations		from module references in these models, the security considerations
	of dereferenceable identifiers apply (see [DEREF-ID-PATTERN] for a		of dereferenceable identifiers apply (see [DEREF-ID-PATTERN] for a
	more extensive discussion of dereferenceable identifiers).		more extensive discussion of dereferenceable identifiers).
	skipping to change at line 2533 ¶		skipping to change at line 2533 ¶
	Regular Expression Format", RFC 9485,		Regular Expression Format", RFC 9485,
	DOI 10.17487/RFC9485, October 2023,		DOI 10.17487/RFC9485, October 2023,
	<https://www.rfc-editor.org/info/rfc9485>.		<https://www.rfc-editor.org/info/rfc9485>.
	[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,		[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
	Ed., "JSONPath: Query Expressions for JSON", RFC 9535,		Ed., "JSONPath: Query Expressions for JSON", RFC 9535,
	DOI 10.17487/RFC9535, February 2024,		DOI 10.17487/RFC9535, February 2024,
	<https://www.rfc-editor.org/info/rfc9535>.		<https://www.rfc-editor.org/info/rfc9535>.
	[SDF-MAPPING]		[SDF-MAPPING]
	Bormann, C., Ed. and J. Romann, "Semantic Definition		Bormann, C. and J. Romann, "Semantic Definition Format
	Format (SDF): Mapping files", Work in Progress, Internet-		(SDF): Mapping files", Work in Progress, Internet-Draft,
	Draft, draft-bormann-asdf-sdf-mapping-05, 6 December 2024,		draft-ietf-asdf-sdf-mapping-00, 18 December 2025,
	<https://datatracker.ietf.org/doc/html/draft-bormann-asdf-		<https://datatracker.ietf.org/doc/html/draft-ietf-asdf-
	sdf-mapping-05>.		sdf-mapping-00>.
	[SDFTYPE-LINK]		[SDFTYPE-LINK]
	Bormann, C., "An sdfType for Links", Work in Progress,		Bormann, C. and A. Keränen, "An sdfType for Links", Work
	Internet-Draft, draft-bormann-asdf-sdftype-link-04, 6		in Progress, Internet-Draft, draft-ietf-asdf-sdftype-link-
	December 2024, <https://datatracker.ietf.org/doc/html/		01, 19 December 2025,
	draft-bormann-asdf-sdftype-link-04>.		<https://datatracker.ietf.org/doc/html/draft-ietf-asdf-
			sdftype-link-01>.
	[STD97] Internet Standard 97,		[STD97] Internet Standard 97,
	<https://www.rfc-editor.org/info/std97>.		<https://www.rfc-editor.org/info/std97>.
	At the time of writing, this STD comprises the following:		At the time of writing, this STD comprises the following:
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	skipping to change at line 4973 ¶		skipping to change at line 4974 ¶
	}		}
	}		}
	Figure 8: Refrigerator-Freezer Example		Figure 8: Refrigerator-Freezer Example
	Appendix E. Some Changes from Earlier Draft Versions of this		Appendix E. Some Changes from Earlier Draft Versions of this
	Specification		Specification
	This appendix is informative.		This appendix is informative.
	The present document provides the SDF base definition. Previous		The present document provides the base SDF definition. Previous
	revisions of SDF have been in use for several years, and both		revisions of SDF, as defined in earlier drafts of this specification,
	significant collections of older SDF models and older SDF conversion		have been in use for several years; both significant collections of
	tools are available today. This appendix provides a brief checklist		older SDF models and older SDF conversion tools are available today.
	that can aid in upgrading these to the standard.		This appendix provides a brief checklist that can aid in upgrading
			these to the standard.
	* The quality unit was previously called units.		* The quality unit was previously called units.
	* sdfType was developed out of a concept previously called subtype.		* sdfType was developed out of a concept previously called subtype.
	* sdfChoice is the preferred way to represent JSO enum (only a		* sdfChoice is the preferred way to represent JSO enum (only a
	limited form of which is retained) and also the way to represent		limited form of which is retained) and also the way to represent
	JSO anyOf.		JSO anyOf.
	* The length of text strings (as used with minLength/maxLength		* The length of text strings (as used with minLength/maxLength
	skipping to change at line 5029 ¶		skipping to change at line 5031 ¶
	Table 12: SDF Content-Format Registration		Table 12: SDF Content-Format Registration
	Table 13: Initial Content of the SDF Quality Names Registry		Table 13: Initial Content of the SDF Quality Names Registry
	Acknowledgements		Acknowledgements
	This specification is based on work by the One Data Model group.		This specification is based on work by the One Data Model group.
	Contributors		Contributors
	Jan Romann		Jan Romann
	Hochschule Emden/Leer		Universität Bremen
	Germany		Germany
	Email: jan.romann@hs-emden-leer.de		Email: jan.romann@uni-bremen.de
	Wouter van der Beek		Wouter van der Beek
	Cascoda Ltd.		Cascoda Ltd.
	Threefield House		Threefield House
	Threefield Lane		Threefield Lane
	Southampton		Southampton
	United Kingdom		United Kingdom
	Email: w.vanderbeek@cascoda.com		Email: w.vanderbeek@cascoda.com
	Authors' Addresses		Authors' Addresses
End of changes. 26 change blocks.
	51 lines changed or deleted		53 lines changed or added
This html diff was produced by rfcdiff 1.48.