Hi Dave,
hi Alexios,
On the one hand, I really think that it does not hurt to separate the
concepts of constraining a model (i.e., profile) and adding to a model
(i.e., extension), explicitly. RFC7925 is a good example for a profile.
Both a profile definition and an extension definition can be included in
the same specification. Separating them explicitly just makes it simpler
for implementers to quickly grasp what goes where. I have to point out
that I am quite reluctant to agree with the premise that is "We all
understand that, if we are going to have a number of profiles, each one
of them will include some new information (for example, new fields)."
Maybe I am reading it wrong.
On the other hand, I also really think that the IP analogy does not work
very well here. My 2c:
1.) TCP neither creates nor modifies IP
2.) The IP comes with an IANA registry for "the next level protocol"
(RFC790). That list of registered protocols is "mutable" (e.g. entries
can be added or deprecated). Packets that conform with IP standards can
express various states or configurations, but that does not render the
protocols themselves "mutable". I am having a really hard time to relate
the quality "mutable" with IP, tbh.
3.) TCP is not a profile/extension/augment of IP. TCP is simply a "next
level protocol" that specifies PDUs (segments) that can be nested in IP
PDUs (packets), as it literally works on a different layer of protocol
stacks. Another example would be QUIC that is nested in UDP.
Viele Grüße,
Henk
On 12.04.21 22:41, David Kemp wrote:
Hi Alexios,
Regarding the general meaning of Object, Field and Type: in UML a
datatype is a simple classifier ("DataType differs from Class in that
instances of a DataType are identified only by their value. All
instances of a DataType with the same value are considered to be equal
instances.") and a Class is a structured classifier ("to specify a
classification of objects and to specify the Features that characterize
the structure and behavior of those objects.")
Objects are used when modeling the real world, but types are used when
modeling data. Data instances are values, data types have neither
behavior nor inheritance, and the only relationships between data types
are "contain" and "reference". Documents contain their own content and
can link to other documents. The PDF version of the SPDX spec knows
nothing about SPDX, it just knows about paragraphs, fonts, tables,
etc. Data instances are not objects, and a language such as JSON Schema
defines only Types and Fields. Of course Objects can be serialized as
data, but their semantics, relationships and behavior are not relevant
at the data layer, they only become relevant when interpreted by
applications such as an SBOM scanner or the TCP driver in a network stack.
RFC 4775 discusses extensibility:
"An extension is often likely to make use of additional values added
to an existing IANA registry (in many cases, simply by adding a new
"TLV" (type-length-value) field)."
IPv4 has a "Protocol" field, an 8 bit value used to designate the format
of the protocol header contained in the IP header.
So to get back to our discussion, is defining TCP "creating" or
"modifying" IP? Is IP mutable or not? If TCP is a profile of IP; does
it define something new or restrict what already exists?
My answers are:
1) TCP does create something new that isn't defined in IP
2) IP is not "mutable", it is extensible through the use of extension
points such as the protocol enumeration, Adding fields to an
enumeration (including the enumerated values in an array or map
structure) is a special case that should be distinguished from the
general mutability of deleting, modifying or inserting fields in
instances without defining them in the Type.
3) TCP is a profile of IP in the same sense that Bluetooth profiles
extend the base spec, not restrict it to a subset of what is defined in
the base spec.
If the word "profile" is a Venn diagram sticking point, then perhaps
"extension" would be a better word to use when defining new things
that fit into the base. OpenC2 uses "profile" in the Bluetooth sense of
defining new types as well as adding constraints to types defined in the
base. Tightening constraints on base types (going from optional to
required) in a profile is fine, relaxing them (going from required to
optional) is verboten.
Dave
On Thu, Apr 1, 2021 at 11:55 AM Alexios Zavras <[email protected]
<mailto:[email protected]>> wrote:
Hi all,____
__ __
Following the extremely interesting and intellectually stimulating
discussion on the SPDX Tech call on Tuesday, I thought I'd try and
list the interactions between profiles that may exist. These gave us
some head-scratching moments when we tried to model them.____
__ __
We all understand that, if we are going to have a number of
profiles, each one of them will include some new information (for
example, new fields). It may also affect some of the information
defined outside this profile (for example, making a field
mandatory).____
__ __
In an effort to “formalize” things, I'll be using abstract terms
like Object, Field, and Type -- I hope we all understand the general
meaning, even though our specification is not using these terms.____
__ __
So, a profile may do one or more of the following:____
__ __
[CREATE]____
1. define new Fields____
2. define new Types (used in new Fields)____
3. define new Objects, with included Fields of certain Types____
__ __
[MODIFY]____
4. add new Fields (with their Types) to Objects defined elsewhere____
5. change the cardinality of Fields defined elsewhere (and thus
change optional/mandatory status)____
6. extend an Enum in a Type defined elsewhere, adding more
alternatives (typical case: adding more Relationship types)____
__ __
All these were mentioned during the call.____
I assume removing/deleting Fields or Objects is not possible
(right?). What about:____
__ __
7. restrict an Enum in a Type defined elsewhere, removing some
alternatives ?____
As an example, could a profile introduce something like a "Secure
Checksum" idea that says that FileCheksum may NOT be of MD2 type?____
__ __
Hope this helps show what we’re dealing with.____
__ __
-- zvr____
__ __
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon
Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4031): https://lists.spdx.org/g/Spdx-tech/message/4031
Mute This Topic: https://lists.spdx.org/mt/81780695/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
