Subject: [CDNi] RFC-8007bis - Generic Trigger Object Selector - Starting a Discussion

From: Nir Sopher <[email-masked]>
Date: Sun, 14 Nov 2021 21:45:01 +0200

Hi All,

Following the adoption of the RFC-8007bis draft, and the milestone set
during the last IETF meeting, I would like to move forward and define the
"Generic Trigger Object Selector" object.

A quick recap:
As defined in RFC8007, the trigger object holds a closed set of
content/metadata selection properties:

   - meta+data.urls
   - metadata.patterns
   - content.urls
   - content.ccid
   - content.patterns
   - content.regexs
   - content.playlists

Being built of a closed set, whenever one would like to define a new way to
select content, and therefore need to add a new such property, a new
version of the trigger object has to be re-defined.
In order to avoid such redefinition, we suggested defining the
"GenericTriggerObjectSelector" object. The Trigger.v2 object would contain
a list (?) of such objects and we will be able to continuously define new
types of selectors without changing the Trigger.V2 object structure.

Few questions comes to mind while trying to define the new Generic object:

*1)* Would the Trigger.V2 object be holding a list of
"GenericTriggerObjectsSelector"s or only a single one?
Currently the Trigger object may hold a "metadata.urls" property as well a
"content.urls" property etc..
Citing RFC8007: At least one of "metadata.*" or "content.*" MUST be present
and non-empty.
However, what is the usecase requiring more than a single selection
property to be used?
And what is the semantics when using both "content.patterns" and
"content.ccid" properties together? Is it an additive or a narrowing
semantic?

I would like to suggest that the Trigger.V2 object would hold a single
"GenericTriggerObjectsSelector" object. It would be simple and clear.
In the future, if one finds the need in creating an objects list, s/he can
define a special GenericTriggerObjectsSelector type that is built of a list
of other GenericTriggerObjectsSelector objects, and define its semantic as
needed.

*2)* Does the "GenericTriggerObjectsSelector" hold a "mandatory-to-enforce"
(MtE) boolean property (similar to the GenericMetadata object)?
As the newly defined object is used for target selection, and as I see it,
without it the trigger is practically useless, I think the MtE property is
not really needed. It's value should be "true" by convention.
On the other hand, having this property anyway may be considered as a good
practice.

*3)* Does the "GenericTriggerObjectsSelector" hold a "safe-to-redistribute"
(StR) boolean property (similar to the GenericMetadata object)?
I believe it should.

*4)* RFC8007bis already defines the GenericTriggerExtension object, which
allows to define further instructions on the trigger execution (e.g. time
of execution).
Should the new GenericTirggerSelection object be merged with the
GenericTriggerExtension?
I believe that the 2 types of generic objects here have different nature of
usage. One indicates "what to work on" and the other indicates "how to do
the work".
I would therefore suggest keeping them separated.

*5)* What would be the real name of the new object?
So far I called it "GenericTriggerObjectsSelector" but any suggestion would
be highly appreciated.

*6)* What would be the structure of the GenericTiggerObjectSelection object?
Below is a suggestion of properties to start with.
Note the separation to "selected-object-type" (content vs. metadata) and
"selector-type" (url / patterns...)

   - selected-object-type: metadata / content
   - selector-type: url / pattern / regex / playlist / ccid
   - selector-values: <a list of values in the proper type>
   - safe-to-redistribute: True/False

I would highly appreciate any input regarding the above discussion, so
please share your thoughts,

Nir