Markdown Version | Session Recording

Session Date/Time: 05 Nov 2025 17:00

MEDIAMAN

Summary

The MEDIAMAN working group met to address outstanding issues from the RFC 6838bis Working Group Last Call (WG Last Call), which did not achieve consensus due to identified concerns. The primary goal of this meeting was to resolve these technical issues to enable the document's progression to the IESG. Discussions focused on IANA registry procedures, the semantics of provisional registrations, change control mechanisms for community formats, and the responsibilities of designated experts. Several decisions were made regarding IANA references and change control, while the complex issue of provisional registrations was deferred to the mailing list for further discussion. A plan for the "Reviewer's Checklist" charter item was also outlined.

Key Discussion Points

• Working Group Status (RFC 6838bis): The WG Last Call concluded without consensus for readiness, but successfully surfaced several issues. The goal is to resolve these issues for the editor(s) to make necessary changes and send the document to the IESG before the next IETF meeting.
• IANA-Related Terms ("Readily Available" and "Contact Information"):
  • For "readily available," the group agreed to reference RFC 8126.
  • For "guidance on contact information," the group agreed to point to existing IANA text, noting some disappointment that IANA documentation pushes specific details to individual registry specifications. There was a discussion about the dependency this creates on RFC 8126 and its normative nature.
• Issue 81: Registration rules for namespaces (e.g., vendor tags):
  • The current IANA practice for vendor spaces lacks a specific, explicit process for this registry.
  • Decision: The working group will check with IANA for their preference on how to manage vendor-like namespaces, specifically whether to leverage existing registries or create a new one, considering the overhead for IANA.
• Acknowledgements: This is an editorial issue. Contributions will be captured from meeting sheets, mailing list traffic, and GitHub.
• Community Format Change Controller:
  • For media types registered under the "community format" mechanism (which do not originate from an SDO), the question was who serves as the change controller. Previous discussions considered the community itself or the IETF. IANA prefers the IETF as a whole, rather than the IESG specifically.
  • Decision: A sense of the room indicated that the IETF should be the default change controller for community format registrations. This introduces a slight disincentive to use the community process, which was viewed as a positive friction.
• Issue 2119 (Restore text): This issue will be handled offline by the editor.
• Issue 59 (Define "readily available"): This was addressed by pointing to RFC 8126 earlier in the meeting.
• Issue 64: Syntax in 2.3 (multiple plus signs):
  • The document's rules on structured syntax suffixes (using +) seem to disallow multiple + signs in registrable names, yet parsing rules need to accommodate unregistered types that might contain them.
  • Decision: Clarify in the text that only the leftmost + sign defines the structured syntax suffix, and while robust parsing is needed for non-registrable names with multiple + signs, such names are not considered legitimate for registration. An ABNF update may be needed to reflect this.
• Issue 60 (Producer's name designation approval): This was identified as the same class of issue as Issue 81 regarding vendor/namespace registration.
• Issue 68: Effect of provisional registration not specified:
  • A lengthy discussion ensued about the semantics and purpose of "provisional registrations." The current system allows a lower-bar registration that does not expire, distinct from IANA's "early allocation" procedure which typically has an expiry. Concerns were raised about the complexity of having similar, yet different, mechanisms and the "rug-pulling" effect if existing provisional registrations were converted to expiring early allocations. Some participants suggested converting all provisional registrations to early allocations to provide expiry, while others preferred keeping provisional as a non-expiring name reservation. The idea of this registry being a "special flower" with unique provisional rules was pushed back against.
  • No Decision: This complex issue requires further discussion. It was decided to take this discussion to the mailing list. Mark volunteered to analyze current provisional registrations to better inform the discussion.
• Issue 7 (Guidance on contact information): Addressed earlier by pointing to IANA text.
• Issue 76: IESG and change controllers (redundant sentence):
  • A sentence stating that IESG makes the final decision on change controller updates, even if the current controller approves, was considered redundant and overly burdensome.
  • Decision: Remove the redundant sentence. The change controller can initiate reassignment, and IANA handles it without IESG involvement if the current controller approves.
• Issue 78 (Provisional media types URL): This issue will remain open, pending the resolution of the provisional registration discussion.
• Issue 80 (Early allocation): This issue will remain open, pending the resolution of the provisional registration discussion.
• Issue 82: Who appoints designated experts:
  • Decision: The IESG appoints designated experts, with the understanding that this responsibility is typically delegated to a specific Area Director.
• Issue 83: Who checks for semantical alignment:
  • The document uses passive voice for checking semantic alignment to avoid placing an overly draconian burden on the designated expert (DE). Discussion centered on clarifying whose responsibility it is.
  • Decision: IANA should provide the DE with relevant context regarding potential semantic clashes (e.g., similar-looking names) without making a judgment. The DE retains the flexibility to use this information without being strictly required to enforce alignment, providing grounds to reject a registration if needed. This must be clearly spelled out in the document.
• Issue 85: Ability for change control to pass responsibility:
  • Previous text allowing a change controller to reassign control to another entity was lost. The current text implies only IESG can reassign. This is considered too heavy-weight for simple reassignments.
  • Decision: Restore the text that allows a change controller to reassign change control responsibility to another entity without IESG involvement.

Decisions and Action Items

• IANA References: Point to RFC 8126 for "readily available" and existing IANA text for "guidance on contact information."
• Namespace/Vendor Tags (Issue 81): Check with IANA regarding their preference for managing these (existing registry vs. new).
• Community Format Change Controller: Use the IETF as the change controller for community format registrations.
• Syntax (Multiple Plus Signs, Issue 64): Clarify document text that only the leftmost + defines structured syntax, and multi-+ names are not registrable, though parsing should be robust. Consider ABNF update.
• IESG and Change Controllers (Issue 76 & 85): Remove redundant text and clarify that a change controller can reassign control to another entity without IESG approval.
• Designated Expert Appointment (Issue 82): Appointed by the IESG.
• Semantic Alignment Check (Issue 83): IANA to provide relevant context on potential clashes to the DE, without judgment. The DE has flexibility in using this information.
• Provisional Registrations (Issue 68, 78, 80): Deferred to mailing list for further discussion. Mark volunteered to analyze current provisional registrations to inform this discussion.
• Editorial Issues: Issues 2119 and Acknowledgements to be processed offline by editors.

Next Steps

• Mark (Editor): Work on resolving open issues identified, particularly those with clear decisions. Analyze current provisional registrations to inform mailing list discussion.
• Pete (Editor): Work on resolving open issues.
• Alexei: Draft a first version of the "Reviewer's Checklist" instructions for Designated Experts, incorporating IANA registration form elements and MUSTs from 6838bis. This will be hosted as a living document (website/GitHub).
• Working Group: Engage in discussion on the mailing list regarding the future of provisional registrations, early allocation, and their interplay.
• Charter Item: Reviewer's Checklist: A plan for this milestone has been outlined:
  • Use IANA registration form instructions.
  • Add a section listing MUSTs from RFC 6838bis.
  • Host as a living document (e.g., GitHub) maintained by DEs.
  • Pending: Clarify who approves changes to this living document (e.g., Area Director or delegate).
• Interim Meeting: An interim meeting in January was suggested, but attendance concerns were noted. Progress on issues is key to closing before the next IETF.