MediaMan, Agenda IETF 122

Date and time: March 15 - 21, 2025 17:00 - 18:30 (UTC+7 Indochina Time)

Room Name: Boromphimarn 5

Duration: 90 minutes

Note taker: Jonathan Lennox

Introduction, Note Well, scribe, agenda bash

Adding item to agenda on more extensive negotiation mechanisms

Status of WG documents

Status of -6838bis

Merged PR 11 (standards-tree)
Merged PR 12 (toplevel)
Commented on PR 14 (suffixes) but it's still a draft; hold for more review

PR 17 (replace macOS file types with macOS/Windows clipboard types)
Pete: I like this but I don't know how we'd backfill in the clipboard types for existing registrations.
Jonathan: Do we want to also fill in other platforms (iOS, Android) if they're different?

Issue 5: closed by #17

Issue 7 to be discussed later, under Rahul's item

Issue 8:

Alexei: This is by design, for standards-track documents you want it to be approved by IESG. Should Historic or Experimental be a lower bar? Shrug.

Pete: The idea here is that for things in the standards tree, it needs standards-level approval, which is the IESG. If it's coming from an external standards body, that's okay.

Harald: But we have registered types in ISO documents that are in pre-approval.

Pete: So do we want to allow early allocation for IETF-registered types from Internet-Drafts?

Alexei: There's an ianabis WG, it may be working on this.

Harald will create a new issue, should we have an early allocation procedure

Brian Campbell: A less-mature registration by W3C was allowed (from a Candidate Registration) when I was told I had to wait for work in an I-D. I don't think what we have is right, and I think we should fix it.

Harald: We should talk about what we expect from other standards organizatons in maturity before they (allocate/register) names. We may also allow early registrations. New issues will be filed.

A. J.: Ok to merge text as is, but we'll still need to iterate on some of them.

Michael Jones: I was in that WG in the W3C, I tried to stop it; procedurally they were in the right, according to the liaison agreement. For ianabis, I think it's critical for other organizations that are accredited standards bodies before the specs are 100% final, so they get review by the DE before they're final.

Pete: I just read over RFC 7120 (early allocation), this was a missed opportunity, an early allocation could have been done for the one in the IETF. This document should call out 7120.

Murray: 7120 is in charter for ianabis to get updated, if we have any changes we want to make for that talk to their chairs (which will shortly be me).

Amanda: For specification required and everything with everything RFC required, they're all subject to early allocation and if so will still go to DE for review. Also, we have asked for that in the past, and we were told to use provisional procedures instead.

Pete: In this particular case, the AD probably would have noticed fishiness between W3C and IETF.

Brian: It would have been nice if an AD had told me this was possible, or given better advice. It's extremely frustrating and makes me not want to participate in this process.

Pete: Completely agreed, this was a screw-up, a failure to understand there was a way to avoid this problem. It wasn't your fault, you shouldn't be expected to know this. 7120 is recent enough that leadership should know about it. Let's talk offline for possibilities for fixing this.

Brian: Thank you, I appreciate that; until now I've had the feeling that the only response I've gotten buck passing and being told to go take a hike.

Harald: The hard part about having an organization that has rules is that we can't just change the rules when we have a problem, changing the rules is a slow process.

Pete: The problem wasn't that the rules needed to be changed, the problem is that the rules weren't followed, certain people didn't know the rules and gave bad advice. This document should point to the early allocation procedure as part of the instructions.

Alexei: I apologize, as DE I didn't know that early allocation would apply. Though no one asked us. I'm sorry that happened to you.

Brian: I'm used to following bespoke, esoteric rules and I couldn't navigate this process, that's something that needs fixing.

Pete: That's what we're trying to fix here.

Harald: This WG can't fix your problem, but we can make sure it doesn't happen again.

Mike: While the unfortunate circumstance with the verifiable credentials happened with the media type, it could happen for any registration, so it needs to be fixed in ianabis not here.

Rahul: As long as we keep adding more rules we're going to have this problem.

Harald: That's why we're obsoleting 6838, not patching it.

Rahul: The person doing the registration needs to have all the information in one place.

Issue 9:
Can WGs be contact information for registrations?

Jonathan: WGs don't live forever [Magnus: except for AVT], we expect them to be closed, so we need a process to update the pointer.

Harald: The same applies to people, but on a longer timescale.

Murray: Should we have a fallback pointer?

Harald: What happens if MPEG closes?

Rahul: Related to the MPEG thing, IESG registered it, but it is with ISO. If MPEG "falls away" and ISO no longer maintains, does it "come back" to IESG?

Harald: That's also a good question.

Magnus: In the case of the change controller, the AVT payload formats have been the IESG delegated to AVT as long as it exists, that's what we've been doing there.

Needs more discussion in the issue, then a PR.

Issue 10:
What's the appeal process for a DE
Jonathan: I think this is an ianabis problem not this WG's, it applies to all DEs.

Punt to ianabis.

RTP related information in the registry

Magnus: Can we get RTP in the registration template,

Alexei: There is an encoding field, is that the same thing?
Magnus: I ask for something more explicit. I don't know if we're the only ones that used frames.
Alexei: As we're revising the document I'm sure we could add that field. Relatedly it'd be nice to have an RTP expert on the team of designated experts.
Murray: Having a column for RTP makes me a little nervous, what if others want this? What about a top-level types?
Magnus: We have 25 years of history, in almost all the top-level types.
Alexei: On the IANA page can we get a reference to RFC 4855?
Harald: If currently framed means RTP, we can change this.
Pete: If RTP goes in the template, is there a need for the column?
Magnus: Some other bodies have been referencing this.
Harald: You need to be able to look at the registation and see whether it defines an RTP format, or doesn't.
Pete: It needs more thinking.
Murray: What about a second table that says these are the RTP ones?
Harald: That's what we were doing, but the tables were inconsistent
Magnus: There are types that are both file formats and RTP formats

Magnus to think about it and make a suggestion

Follow-up on incomplete and nonexistent registration templates (15 min)

Rahul: The registration database is a mess, what are we going to do to clean it up?
Alexei: We (for some definition of we) should write a draft with what the values should be, and then we can argue about it.
Rahul: Some of them are very confusing, like multipart.
Alexei: Once upon a time I had an illusion that I'd revise 2045, after I was done with emailcore. But I think we can update just the templates.
Harald: So are you volunteering?
Alexei: Yes, but I won't do it alone, I want at least two volunteers to help me.
Harald: We'll put out a call on the mailing list and see what happens.
Rahul: Do we want to add something to 6838bis about how media types are updated when a new RFC is published?
Pete: I think that turns mostly into an ianabis issue, this is about more than just media types. IANA needs good IANA considerations sections in documents that do that, that's on the IETF, it's not IANA's responsibility.
Alexei: Any update to a media type should update the registration.
Murray: Let's make sure all our ianabis issues end up over there.
Rahul: For non-IETF stuff, what happens when authors are writing and someone else updates it, and fails to register it? How is IANA supposed to discover that.
Pete: We should probably have specific guidance in 6838bis for what should happen when other SDOs' media types are updated, that they should keep their registration up to date; if they don't, there's not much we can do about it, but we should make it clear that they should.
Murray: This is what being a change controller is, if you change something you have to let us know.

More extensive negotiation mechanisms

Rahul: Suffixes are used for two things, extensions, and enveloping; using a single content for both may not be the best route. Maybe we should consider arithmetic on the order of RFC 2912. Should we try something else since structured suffixes failed
Harald: I think suffixes failed because both those modes were a bad idea. In neither case, in practice, could you take action based on part of a type. So the type should be the description of the format. More detail on the format should be parameters, not the media type.
Rahul: This requires that the original registrant allow these parameters.
Mike Jones: I disagree that suffixes failed, we use them for jwts. What the suffix gives you is the notion that this is of that kind.
Rahul: I didn't mean suffixes failed, I meant the structured suffixes draft.
Murray: If structured suffixes failed, why is this better?
Rahul: This is more explicit.
Harald: The discussion of suffixes was that we all had different opinions about how it worked.
Rahul: I started a discussion on the mailing list, please comment there.

Wrap up, action items, and followup