[media-types] Re: [Ext] Standards tree registration and RFC 6838

Hi Amanda,

> On 12 Sep 2025, at 2:56 pm, Amanda Baber <[email protected]> wrote:
> 
> Hi Mark,
> 
> Sorry about the late review here. The community formats section looks pretty clear to me, but some notes/questions about other sections:
> 
> Section 3.1.1:
> 
> This section's last bullet point says that the example top-level type has an "example" subtype, but RFC 4735 told us not to register that (although it did have us register an example subtype for the other then-extant top-level types). I have no idea whether this would be confusing to anyone outside of IANA. More substantially:

I'll respond to Martin's e-mail.

>  Section 4.1.1:
> 
> - "Media types registered by the IETF in the standards tree MUST be published as RFCs. Standards-tree registrations for media types defined by other standards-related organizations MUST be described by a formal specification produced by that organization. Note that in both cases, the early allocation process described in [RFC7120] is available": The last sentence isn't correct. The RFC 7120 process is available for Specification Required registrations, but only when that specification is an I-D in the IETF stream. 
> 
> However, we are planning to specify in 8126bis that a kind of early allocation is possible for SDO specs, although we haven't worked out the details. (We would prefer to avoid an overhead-heavy 7120-style process that involves multiple approvals, monthly expiration reports, escalation to the IESG after a certain number of renewals [or perhaps renewals at all], etc.)
> 
> It might be worth noting RFC 8392 gets around the absence of any current text to that effect by saying, "to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published." 
> 
> Could an SDO use the community format (it wouldn't conflict with SDO work, presumably) and modify the registration later to add itself as a change controller? 
> 
> Note: I couldn't tell you whether the experts have approved media types associated with specs that were available online, but not yet published in their final form. The reason I haven't tracked it is that we haven't made a practice of copying URLs from the registration template into the registry's "Reference" field. Do you want to use the IANA Considerations section to tell IANA to populate registry fields in a specific way, or to add fields? (We have a couple of thousand somewhat-free-form registration templates, so we might not be able to populate these fields immediately upon document approval.)

Captured here:
  https://github.com/ietf-wg-mediaman/6838bis/issues/80

> - "In the case of IETF standards, the change controller is normally the IESG": The IESG prefers that the IETF be named here instead, unless an older RFC requires otherwise. (Right now this is mentioned only at https://www.iana.org/help/protocol-registration, linked from 8126.)

https://github.com/ietf-wg-mediaman/6838bis/issues/79

> - Probably an IANA-only nit (if that): because "Consensus" is capitalized, I initially thought "IETF Consensus documents" might be referring to the registration procedure that's now called "IETF Review."

Fixed.

> Section 5.1:
> 
> For the last few years, after an AD-approved expert request (which I think was actually misunderstood by us), IANA has been copying the media-types mailing list on most requests sent directly to IANA. Exceptions: SDO requests accompanied by expert-only copies of expensive specs; vendor-tree requests, when the submitter prefers privacy (this is rare); and administratively awkward submissions, like a set of 32 forms in a zip file. Should this practice be mentioned here? (I would suggest not, both because we're open to additional future exceptions and in case anyone comes to prefer that we generally not do this, and I don't think our current practice contradicts anything in the text.)

I agree.

> Section 5.2:
> 
> If you want to add the URL: https://www.iana.org/assignments/provisional-standard-media-types 
> 
> Should the provisional registration option be mentioned in Section 4.1.1's discussion of early allocation?

https://github.com/ietf-wg-mediaman/6838bis/issues/78

> Section 5.3:
> 
> If you want the URL for the IESG-approved list: https://www.iana.org/assignments/iesg-recognized-organizations 
> 
> (FWIW, I think we'd like to ask the ADs/experts to revisit the note at the top of that page, but that text doesn't appear in 6838 and probably doesn't need to be addressed within the context of this document.)

https://github.com/ietf-wg-mediaman/6838bis/issues/77

> Section 5.5:
> 
> "The IESG makes the final decision regarding updates to change controllers" suggests that even if the current change controller does approve its own replacement, IANA would have to ask the IESG to approve. Can this be changed to something like "In this case, the IESG [...]"? Also, can you confirm that you want us to escalate to the IESG for vendor- and personal-tree registrations as well as standards-tree?

https://github.com/ietf-wg-mediaman/6838bis/issues/76

> Section 5.6:
> 
> Section 2.8 indicates that "Windows clipboard name" is going to be included in the template's "Additional Information" section, but it doesn't appear here.  

https://github.com/ietf-wg-mediaman/6838bis/issues/75

> Section 8.1: 
> 
> "In the Top-Level Media Types registry, IANA should link the reference field for each top-level type to the specific subsection in question, rather than just the relevant RFC": unfortunately, for what it's worth, right now we can point to the appropriate section, but we can't actually link to it (using our method for linking to RFCs and I-Ds, rather than other URIs; we have various reasons for sticking with the former). I'll bring this up again internally. You should probably continue telling us to do it.

OK.

Thanks!

> thanks,
> Amanda
> 
> On 8/12/25, 4:37 PM, "Mark Nottingham" <[email protected]> wrote:
> 
>    Hi Amanda,
> 
>    We're attempting to address this sort of situation with this:
>      https://urldefense.com/v3/__https://ietf-wg-mediaman.github.io/6838bis/draft-ietf-mediaman-6838bis.html*name-community-formats-in-the-st__;Iw!!PtGJab4!9XVdB2yUpKHFfXRvNJzpJOjCKzHUH3v70_rLh4OOJX5dDbhplFIJkghy5BFEWguD22BbqTr5He8anO3D0y8$ [ietf-wg-mediaman[.]github[.]io]
> 
>    I'd be curious to hear what you think. There have also been adjustments in other parts of the text which may clarify these issues too.
> 
>    Cheers,
> 
> 
>> On 23 Jul 2025, at 8:50 pm, Amanda Baber <[email protected]> wrote:
>> 
>> Hi,
>> I wanted to point out a few recurring standards tree media type processing issues we see in IANA. RFC 6838 is unclear on these points:
>> 
>>    • Requesters often have a hard time figuring out what their options are if they don’t represent an SDO and can’t/don’t want to write an IETF stream RFC. The process you can derive from Section 3.1, as Ned Freed explained when he was the media type expert, was that requesters could submit an independent stream I-D, and if the ISE was willing to take it up, the expert could provide an informal advisory review for the IESG to refer to. The IESG could then approve the media type directly, if they chose (although they of course wouldn’t approve the I-D itself). It was worked out that we would coordinate this with the ISE around the time of the conflict review. The section doesn’t really outline any of this, though. 
>> 
>>    • Does the document need guidance for the IESG/ISE re: when an independent submission is appropriate for standards tree registration? (For what it’s worth, it’s been several years since we received a request of this type.)
>> 
>>    • Grandfathering can also be an option for standards tree requesters, if the experts want to recommend approval to the IESG, but it’s possible that the requirements for this are underspecified. See Appendix A for this.
>> 
>>    • The IESG isn’t really given guidance as to what constitutes a standards organization for this purpose.
>> I also want to check on whether these auxiliary-type registries are OK as they are, as the instructions in 6838 are a little minimal:
>> 
>>    • https://www.iana.org/assignments/iesg-recognized-organizations (The note is IESG-provided text from around the time of publication. I wonder if it needs any rephrasing that would reflect the fact that the IESG does have the ability to approve one-off registrations from organizations without adding them to this list.)
>> 
>>    • https://www.iana.org/assignments/provisional-standard-media-types
>> I won’t be able to make the session, but Murray would be able to speak to much of this, I think.  Thanks,
>> Amanda _______________________________________________
>> media-types mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
> 
> 
>    --
>    Mark Nottingham   https://urldefense.com/v3/__https://www.mnot.net/__;!!PtGJab4!9XVdB2yUpKHFfXRvNJzpJOjCKzHUH3v70_rLh4OOJX5dDbhplFIJkghy5BFEWguD22BbqTr5He8ar-uoa20$ [mnot[.]net]

--
Mark Nottingham   https://www.mnot.net/

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