# Multiformats/IETF Hearts and Minds

## Resources

- list for outreach is [here](https://docs.google.com/spreadsheets/d/13TX4qDLorTUPze_J_RZeosz31mo0XyV7-TAbRK0DxRQ/edit#gid=0)
- IETF multiformat mailing list is [here](https://mailarchive.ietf.org/arch/browse/multiformats/)
- first-attempt:
- charter - [i-d 00-01](https://datatracker.ietf.org/doc/charter-ietf-multi/), [un-registered working draft preview](), and [github thereof](http://www.caballerojuan.com/ccg-multibase-spec/)
- multibase - [i-d 08](https://datatracker.ietf.org/doc/draft-multiformats-multibase/), [xml preview](), and [github]()
- multihash - [i-d 00](https://datatracker.ietf.org/doc/draft-multiformats-multihash/), [xml preview](), and [github]()
- see also: historical attempts here
- multibase - [i-d 00](https://datatracker.ietf.org/doc/html/draft-snell-multihash) and [github](https://github.com/multiformats/specs)
- multihash - [i-d 00](https://datatracker.ietf.org/doc/html/draft-snell-multihash), and [github](https://github.com/multiformats/specs)

## To-do list for overhaul
- add chronological listing of deliverables/RFCs to charter:
- unsigned varint profile
- multiformatsregistry (fka multicodecs)
- governance of registries specified in an RFC & then aligned with github.com/multiformats (i.e, require IANA before "final" in the community repo)
- multibase specification + multibase registry (delivered at same time)
- multihash specification + multihash registry (delivered at same time)
- possible recharter?
- update registry governance section of charter

## Feedback Tracker

- AD ballots
- Robert Wilton [9/21](https://mailarchive.ietf.org/arch/msg/multiformats/sILnXnJgZv4ccwQlIG0xo969InU/)
- support Murray's "no breaking changes" issue and "benefit of bringing to IETF"
- need greater clarity on "whole picture", which seems "a set of point solutions"
- sponsoring AD should [hold a BOF](https://www.ietf.org/how/bofs/) and get agreement on scope
- Murray Kucherawy [9/21](https://mailarchive.ietf.org/arch/msg/multiformats/Dcb0pclYZqNCcr4gJcXJJF_NXjA/)
- "no breaking changes" sounds like rubberstamping
- "who has change control"? this isn't standards track if WG can't accept breakage
- Mike Jones thread feels unresolved
- John Scudder [9/21](https://mailarchive.ietf.org/arch/msg/multiformats/Dcb0pclYZqNCcr4gJcXJJF_NXjA/)
- no objection but "initial milestones" would be good
- Roman Danyliw [9/21](https://mailarchive.ietf.org/arch/msg/multiformats/ORMoikGdkVDjno5SE9UnxmZPdjw/)
- charter doesnt say what the point is
- IETF/W3C corss-dependency needs "ground truth" captured in text
- mike jones thread unresolved- "Clarifying actual/anticipated dependencies will help."
- relationship between multihash registry and IANA “Named Information Hash Algorithm Registry”
- empty registry + no new entries scope = fail
- Zaheduzzaman Sarker [9/10](https://mailarchive.ietf.org/arch/msg/multiformats/xpqjOGlcf4yBbBhVsoTZypall2c/)
- charter gives no examples of usage
- themes in email feedback
- badly-explained "optionality" in use-case for multibase - Mike Jones [9/6 point #1](https://mailarchive.ietf.org/arch/msg/multiformats/KqdFPgjbUcYhc4dHoWqQrUFGi08/) - "protocols chose their encodings" / "institutionalized failure"
- martin dürst [9/11](https://mailarchive.ietf.org/arch/msg/multiformats/-FGj7J_J7Y_S5l4wXauafb9__DE/) - sometimes they do, sometimes they don't. maybe consensus isn't going well, encodings don't seem to justify optionality.
- aaron goldman [9/18, point #1] - actually I think the intent here is decoupling the protocol schemes at other layers (//Protocol Numbers IANA registry) from the higher-level protocols relying on them (//IPv4 "Protocol" prop, IPv6 "Next Header" prop). the optionality model (and the order-of-operations) are being followed here
- additional information/feedback for new charter: the use-case for multibase is data being recorded in its native encoding (for instance, logging events in a wire protocol, adding things to file systems, content-addressing raw data, and other encoding-restrained contexts) to allow arbitrary composability of protocols and contexts, including ones unknown at time of recording data in self-describing form
- Melvin Carvalho [7/14](https://mailarchive.ietf.org/arch/msg/multiformats/AjdDheiiaCY_pZc8w7jg-9Muw3U/) - Are CID's in scope for multihash?
- [Robin Berjon 8/21](https://mailarchive.ietf.org/arch/msg/multiformats/O0RlWgcoIhFUZXiQO1lJTI3aJJo/): No, only a very narrow subset of CIDs contain only a multihash of a raw file; see ["CIDs are not file hashes"](https://docs.ipfs.tech/concepts/content-addressing/#cids-are-not-file-hashes); [Manu 8/21 +1](https://mailarchive.ietf.org/arch/msg/multiformats/zJdUkiLmzdOBNXtg4JqpIi9_d3U/)
- Melvin Carvalho [4/10](https://mailarchive.ietf.org/arch/msg/multiformats/W7UstaPkyo5phCwb793yEQ6A8S4/) interested in implementing multihash, but [9/5](https://mailarchive.ietf.org/arch/msg/multiformats/W3iaZpYiK7aGJySqS71Qy6dIoZA/) IFF a multihash URN scheme is registered by or in coordination with this group
- Additional Info: Bumblefudge will meet with Melvin in Prague at IETF 118 to discuss further
- Orie Steele [9/7]() - community-governed registries can be inconsistent and insufficiently prescriptive (with examples about key types)
- Additional Info: since the draft Orie was commenting on, some registrations have been marked as "Draft" that were previously marked as "Final" and should a working group be established at IETF, the governance of these registries would be discussed before any deliverables were presented for wider review
- W3C dependencies/normative references mentioned first by Orie Steele []() and clarified in [9/8](https://mailarchive.ietf.org/arch/msg/multiformats/fH3BDoFkr5sirxiI_1qP4QavTLg/)