# IETF 118 - MEDIAMAN WG {#ietf-118---mediaman-wg} ## Introduction, Note Well, scribe, agenda bash (5 min) {#introduction-note-well-scribe-agenda-bash-5-min} * scribe = @bumblefudge ## Status of WG documents {#status-of-wg-documents} * Top-level has DISCUSS votes on -04 draft * Haptics is approved (but is on reference hold) * Suffixes has been very quiet ## Principles for new Top Level types (15 min) {#principles-for-new-top-level-types-15-min} * DISCUSS positions and presentation of proposed changes: 5 min * issue #8 - IANA considerations being tightened, anticipate quick resolution * issue #9 - some rules sound like considerations to some reviewers * proposed: move or copy concrete rules to IANA consid section, move other stuff to considerations section (2) * murray: clarification: considerations section 2, distinct from iana considerations, section 5 * issue #10: fair, some editorial oversights, everything that isn't purely editorial will be opened as new issues * issue #11: being more explicit should avoid issues like this one, which I feel missed a crucial part of the syntax/structure; no intent/content changes needed * murray: just request re-review after addressing * issue #13 - reference IANA reg policy * solution: add 8126 as norm ref, easy peasy * any more agenda? ok then editors will proceed as described above * Discussion (15 min) * Decision: Adopt proposed changes and return to the IESG for processing ## Multiple suffixes for media types (15 min) {#multiple-suffixes-for-media-types-15-min} * Presentation of draft-ietf-mediaman-suffixes (Manu Sporny): 5 min * version -06 is live (linked from slides) * update suffix reg template * freeform text in the registry bad; link to specifications now required and i did a pass, should be all good * IANA has been * update IANA consid * change suffix regitry from "expert review" to "spec reqd" (it's been governed as though this were already the case for a long time anyways, it seems like a bug) * ??: could IANA check spec instead of expert? Manu: There may be nuances, so expert might prefer to have a chance to intervene if it's a spec issue or any other corner case * ??: i'm thinking through edge cases or abuse modes; manu: i'm not sure how perscriptive we need to be * manu: https://www.rfc-editor.org/rfc/rfc8126.html#page-20 * req change controller consent for base subtypes - alexey: failure mode: can experts veto a community-versus-change-controller issue? manu: if change controller goes rogue, we can always version or re-reg later (: but maybe we shouldn't accept anything where community looks that far out of consensus at time of reg) - darrell miller: change controller will have to work with des experts to avoid semantic slippage or overdetermining * changes since ietf117 * processing multiple structured suffixes * process left to right * skip structured suffixes if unregistered * stop processing on de/encode error * orie: i read newest ver, this part is greatly improved, thanks * allow reg of media types w/o suffixes * current process requires permutations to be registered as new entries; newest version allows structured suffixes to be registered independently * alexey: this sounds tricky; i don't understand the point of registering things that are not known or knowable * manu: should "+ld+json+jwt" and "+json+jwt" really be distinct specs and registrations? a suffix with no processing rules shouldn't need to be registered * \: but if "ld+json" has no spec * mark: earlier you said you process left to right; are any of these unregistered terms... trademarks? what are the semantics of "processing" left to right and skipping unregistered types? * manu: right now vc+ld+json is registered; the question is how to add +jwt to the end, which my theory is that * mark: this feels like we're optimizing for making things easier for registrants and i don't think that's good; 3 options: 1 register exactly as expressed 2 don't process an unregistered suffix 3 yolo and handwaving * manu: I think i'm proposing #2 * jonathan: but what if someone registers it later? can they swoop in and break content in the wild? * orie: some version of what mark said needs to be clarified; +JWT spec includes a recommendation to only combine with registered/spec-defined content types; COSE and JOSE all have rules and assumptions about content types that I recommend this group consider those carefully * mark: are you saying this is dangerous for those other specified behaviors? * orie: not exactly, and i think the newest version addresses a lot of my feedback on this issue and I recommend people review the newest version; but in the case of this specific registration, I think the "vc+" part is determinant (they're a form of attestation credential) * alexey: already in use? manu: not in use yet; alex: obvious fix is just use `-`s not `+`s; manu: but when JSON-LD was first created, this exact group told us that it had to be `+`s; there's all kinds of `+{suffix}` in the recent registrations; * alexey: i don't see an easy path forward here; * orie: easy solution is switch W3C docs and registration to `vc-ld-json+jwt`; it's painful but it cuts bait * orie: draft registration requests for these registrations should be shared with the list if they haven't been already, they've changed since IETF117 * next steps: newest draft is only a week old, will continue on list when all have had a chance to review drafts * NOTE: Link is to the github version, NOT the published draft (deadline trouble) * What has changed since last time? * Discussion (5 min) * Decision: Adopt proposed changes? ## Community registration in the standards tree (15 min) {#community-registration-in-the-standards-tree-15-min} * Mark Nottingham: Document: https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-standards-tree-00 * Introduction (Mark Nottingham) (5 min) * Discussion (10 min) * not much feedback yet, i think people are happy with it * harald: just ship it qua RFC? mark: no rush on my side; i think we need to let it percolate * alexey: stable but not ship to IESG? mark: yes, because main document will obsolete current document anyways; let this hang out as an internet-draft * alexey: if a case arises that creates a hurry, maybe ship then? * mark: if IESG gives us that leeway, roadtesting it a bit with our own registry might help * murray: * SDO list has no criteria, just set by IESG without explicit process * darrel miller * recent req to register mermaid diagrams; was registered as `VND-mermaid` - should open-source, community-run efforts that are single-implementation like mermaid is be community or vendor? * mark: current spec gives expert reviewers the option to make exceptions; i think it's a thorny issue, i would research more how that spec is governed and whether other implementations exist * jonathan: ABT formats are registered in content-type reg; also some registrations llike RDP that have been poorly maintained; * one option is deprecate or remove the RDP but * interested parties should poke into the ABT mailing list * harald: my co-chair found that many important types were never registered or closed * jonathan: tricky process issue * alexey: in email group, we're adding some header-fields registrations that are email-specific; it can be scary to add registries only applicable to a subset of the registry, * mark: split registry? alexey: that's my least-preferred way * harald: 4855 --> change control ultimately lies with the WG; I believe there may be a process bug worth filing here * see /admin#1 to participate * jonathan: some of the video registries have some iffy registrations * Decision: Ready for Last Call (or not). * "stable" # Wrapup, action items, followup (10 min) {#wrapup-action-items-followup-10-min} * next steps * TLD - a few +1s on list after a few cleanup PRs and we ship it again * skipping reg level (take it to the list, hopefully resovled long before 119) * comm reg issue - if IESG lets us go * banter * `typ` = content type of the token itself (originally just `jwt`); but over time people worried about protocol confusion attack so they started putting the type that the JWT encodes into `typ` instead; mark: but that only works once; orie: yes; mark: isn't that incompatible with this framewoke, tho? orie: +xml +cbor +jwt are all popular (only one at a time, tho)