IETF 118 - MEDIAMAN WG

Introduction, Note Well, scribe, agenda bash (5 min)

• scribe = @bumblefudge

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)

• 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)

• 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)

• 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)

• 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)