Minutes IETF118: mediaman: Mon 16:30
minutes-118-mediaman-202311061630-00
Meeting Minutes | Media Type Maintenance (mediaman) WG | |
---|---|---|
Date and time | 2023-11-06 16:30 | |
Title | Minutes IETF118: mediaman: Mon 16:30 | |
State | Active | |
Other versions | markdown | |
Last updated | 2023-11-24 |
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
- proposed: move or copy concrete rules to IANA consid
-
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
- issue #8 - IANA considerations being tightened, anticipate quick
-
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
- freeform text in the registry bad; link to specifications
-
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
- ??: could IANA check spec instead of expert? Manu: There
- change suffix regitry from "expert review" to "spec reqd"
-
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
- alexey: failure mode: can experts veto a
-
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
- manu: right now vc+ld+json is registered; the
-
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 tovc-ld-json+jwt
; it's painful but
it cuts bait
- mark: are you saying this is dangerous for those
-
orie: draft registration requests for these
registrations should be shared with the list if they
haven't been already, they've changed since IETF117
- manu: should "+ld+json+jwt" and "+json+jwt" really be
-
next steps: newest draft is only a week old, will continue
on list when all have had a chance to review drafts
- current process requires permutations to be registered as
-
-
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
- alexey: if a case arises that creates a hurry, maybe ship
-
murray:
- SDO list has no criteria, just set by IESG without explicit
process
- SDO list has no criteria, just set by IESG without explicit
-
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
- mark: current spec gives expert reviewers the option to
- recent req to register mermaid diagrams; was registered as
-
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
- mark: split registry? alexey: that's my least-preferred
-
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
- TLD - a few +1s on list after a few cleanup PRs and we ship it
-
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
intotyp
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)