I don't think running an experiment will work well for this case. W3C already assumed that multiple suffixes would be allowed...
If they end up forbidden, W3C will need to make updates... If they end up allowed but are really only relevant to JSON-LD, or other polyglot media types... the problem will remain open every time a polyglot media type requests registration as a structured suffix. Best solution seems to be: 1. Specification required. 2. Experts are directed to relax registration requirements for suffixes that build on other subtypes (like +cose builds on +cbor, and +jwt builds on +json)... So you don't need to register weird and useless stuff like +ld+jwt, or +json+jwt if you don't have a need to use them by themselves... If that changes in the future and someone really needs +ld+jwt... They can claim it, by writing a specification and getting it to RFC. If the draft says this explicitly the problem with suffixes seems solved. On Wed, Jul 19, 2023, 9:38 PM Michael Richardson <[email protected]> wrote: > > Orie Steele <[email protected]> wrote: > >> Agreed, we need to remove that ambiguity. I also think that we > might > >> need an RFC3999 experiment here. > >> > > > I fear whatever you are referring to regarding RFC3999. > > Sorry, that's RFC3933. > > This specification permits and encourages the IESG to adopt and > institute "process experiments" by using the following procedure: > > 1. An I-D is written describing the proposed new or altered > procedure. A statement of the problem expected to be resolved is > desirable but not required (the intent is to keep the firm > requirements for such an experiment as lightweight as possible). > Similarly, specific experimental or evaluative criteria, although > highly desirable, are not required -- for some of the process > changes we anticipate, having the IESG reach a conclusion at the > end of the sunset period that the community generally believes > things to be better (or worse) will be both adequate and > sufficient. The I-D must state an explicit "sunset" timeout > typically, not to exceed one year after adoption. > > To my mind, the process of reviewing multiple suffixes might fit into such > a > thing. We write something down, ackwowledge that it might be perfect, and > then come back at the sunset time to re-evaluate. Would one year be long > enough? Maybe not. > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
