In the most recent community meeting there was a sidebar discussion on the complexity of implementing TUF and how several TAPs (specifically TAP 4 and TAP 8) increase complexity for optional features.
As part of the discussion I proposed that we add an additional TAP status, or update the accepted status, to include a notion of a TAP which is reviewed and approved but, due to its optional nature, is considered supplementary to the specification and is not destined to become a part of the core specification document.
During the discussion the following pros and cons were discussed:
Pros
- implementation simplicity and safety for those only interested in the core TUF functionality of today
Cons
- confusion in how implementations/adoptions communicate which combination of TUF + TAPs are implemented
- this potentially makes it harder to find a TUF implementation which suits all of an adopters needs
- testing combinations of features is harder
- unclear what this means for the reference implementation(s)
FWIW some of these cons (i.e., compatibility across implementations, lack of clarity around what exactly a TUF implementation implements) already exist today.
Filing this issue as a place to continue this discussion.
In the most recent community meeting there was a sidebar discussion on the complexity of implementing TUF and how several TAPs (specifically TAP 4 and TAP 8) increase complexity for optional features.
As part of the discussion I proposed that we add an additional TAP status, or update the accepted status, to include a notion of a TAP which is reviewed and approved but, due to its optional nature, is considered supplementary to the specification and is not destined to become a part of the core specification document.
During the discussion the following pros and cons were discussed:
Pros
Cons
FWIW some of these cons (i.e., compatibility across implementations, lack of clarity around what exactly a TUF implementation implements) already exist today.
Filing this issue as a place to continue this discussion.