[media-types] Re: [IANA #1418198] application/vnd.an gel.evidence-package registration request

The last I heard was that the requester was seeking publication via the
ISE, and then this would be referred to the IESG by IANA for possible
one-shot approval on the standards tree.

The template is fine, so the registration is approved simultaneous with the
publication of the draft by the ISE, as long as my feedback on May 19th was
addressed (it was minor).

-MSK


On Tue, Jul 22, 2025 at 4:03 PM Amanda Baber via RT <
[email protected]> wrote:

> Hi Murray,
>
> It looks like this requester's been waiting for a response since 5/22. I'm
> not sure what to tell them.
>
> thanks,
> Amanda
>
> On Tue Jun 17 02:21:17 2025, amanda.baber wrote:
> > Hi Murray,
> >
> > I'm not sure what the advice for the requester is at this point. I
> > think this is what we've got so far:
> >
> > - They make the case to DISPATCH that this is work that should be
> > supported by the IETF and see what they recommend (noting here that
> > they don't appear to be familiar with IETF processes)
> >
> > - The path of least resistance is a registration on the vendor tree,
> > once we have an actual specification to look at.  An independent
> > stream publication would meet this requirement.
> >
> > Would an I-D that's never published as an RFC be acceptable for a
> > vendor-tree registration?
> >
> > If not, and publication is required, given Ned's earlier instructions
> > that we send standards-tree requests in independent-stream I-Ds to the
> > IESG around the time of the conflict review, it's not clear whether
> > there's any benefit in requesting vendor-tree registration in an I-D.
> > (I do see that one vendor-tree type was registered that way back in
> > 2017, though, for RFC 8216. That type would've been approved by the
> > experts rather than the IESG.)
> >
> > Would these be their possible routes?
> >
> > - approach DISPATCH (standards tree)
> > - if not DISPATCH, approach the ISE (standards tree)
> > - if neither, or if they want to register more quickly and deprecate
> > the initial registration later, produce a non-IETF spec (vendor tree)
> >
> > More information about IESG approval for media types: since RFC 6838
> > was published, we've only requested this (per the experts) in two
> > situations: either an independent-stream I-D requested it, and the
> > expert didn't see any issues, or the expert believed that a certain
> > degree of documented use meant that the grandfathering approach
> > described in RFC 6838, Appendix A was appropriate. (This was used
> > recently for application/toml, stratum, and texinfo.)
> >
> > (Of course, the IESG could technically approve any kind of
> > registration request, given that RFC 8126, Section 3.3 says that the
> > IESG "is granted authority to override registration procedures and
> > approve assignments on a case-by-case basis," but we haven't been
> > asked to request this.)
> >
> > thanks,
> > Amanda
> >
> > On Tue Jun 10 16:05:48 2025, [email protected] wrote:
> > > Apparently I've been thinking about this a lot today.
> > >
> > > On Tue, Jun 10, 2025 at 2:57 PM Murray S. Kucherawy
> > > <[email protected]>
> > > wrote:
> > >
> > > >
> > > > (1) Invoke the previous process to get it onto the standards tree
> > > > by just
> > > > having the IESG approve it either as a direct submission to the
> > > > reviewers
> > > > or an ISE publication;
> > > >
> > > >
> > > Of course, if I were on the IESG, I might not know how to decide
> > > whether to
> > > approve this.  Why would we not approve onto the standards tree
> > > anyone that
> > > bothers to ask?
> > >
> > > -MSK
>

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]