[Multiformats] Roman Danyliw's Block on charter-ietf-multi-00-01: (with BLOCK and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
charter-ietf-multi-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-multi/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

** After all of the introduction, a single sentence seems to describe the
actual scope: “specifically, the group is currently focused on the
standardization of the two most generally-useful multiformats: multibase and
multihash.”  Can the narrative text please define what multibase and multhash
are; and the scope of what problem is to be solved in specifying them.

** The charter text states that “The outputs from this Working Group are
currently being used by various groups, including the W3C Verifiable
Credentials Working Group, W3C Decentralized Identifiers Working Group …”. 
Trivially, the tense here is doesn’t seem right as there is neither a WG nor
output from it.  More practically, I would like to get clarity on the exact
cross-SDO dependencies are in place here.  At the IETF-W3C liaison meeting last
week, W3C mentioned that there was no dependency on this proposed work. 
Combing from the list archive, linkages were described as follows: 
https://mailarchive.ietf.org/arch/msg/multiformats/fH3BDoFkr5sirxiI_1qP4QavTLg/
(Orie Steele/Fri, 08 September 2023).  Can we get ground truth and capture it
in the text?

https://mailarchive.ietf.org/arch/msg/multiformats/KqdFPgjbUcYhc4dHoWqQrUFGi08/
(Mike Jones/Wed, 06 September 2023), and the resulting thread, highlight
foundational questions about whether such flexible building blocks are needed
and the impact of this flexibility .  Clarifying actual/anticipated
dependencies will help.

** Realizing that draft-multiformats-multihash is only a starting point, it
does suggest a new, generic hash registry is needed, as does the output of “an
RFC defining a multihash registry”.  What is the anticipated relationship with
the existing IANA “Named Information Hash Algorithm Registry”,
(https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg).
(originally mentioned in:
https://mailarchive.ietf.org/arch/msg/multiformats/KqdFPgjbUcYhc4dHoWqQrUFGi08/)

** Per “An RFC defining a registry-group for all the multicodecs, empty at
inception, with registration process and group-wide constraints on registration
values”, what is the thinking behind creating an empty registry that the WG
explicitly declared doing work for as out of scope (i.e., out of scope is
“Creating or standardizing new data formats identified by a multicodec byte
header.”)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Is the intent of this proposed work to:

(a) “bring the projects in https://github.com/multiformats/multiformats into
the IETF” (aka, standardized an inflight body of work); or

(b) to address the generic problem of a “self-describing data formats that
consist of an inline data header and a data value” within some constraints.

If (a), why are these links not more explicit?

If (b), my initial reaction was that CBOR is a “self-describing data formats.”
COSE and JOSE’s work also provides flexible representations for hashes.  There
must be other design requirements/constraints that rule these out.  Can they be
explained?

** Per “[t]he scope of this Working Group is to discuss these formats as they
relate to standardization at the IETF for wider and safer usage”:

-- What does “wider and safer usage” mean”?  What are the design constraints
that language is intended to impose?

-- Does this language imply change control of the formats is not possible?  I
ask because it surprised me that text would seemingly constrain what discussion
would occur.  I also had the same change control question around the
prohibition of “changing current multiformat header assignments in a way that
breaks backward compatibility with production deployments.”  Are the header
assignments the prefixes before the value?  My concern is that if backwards
compatibility is needed with the drafts that are the starting points, what new
work is needed?

** Per the outputs of the group, I recommend specifying the intended status of
these specifications (e.g., s/RFC/Proposed Standard RFC/)

** Per “An RFC specifying multibase usage”, is that the same as specifying
“multibase”?  I don’t follow what “usage” adds, unless the intent is to
describe how implementations use multi-base.

** Per “An RFC defining an independent multibase registry and populating it
with today's already-implemented stable and final values”, what does
“independent” mean?  Are the code points in the registry not coming from the
RFC which specifies multibase?  Why two documents?

** Same questions for the two “multihash” outputs.

** Declaring “[d]etermining whether one data format is better than another data
format” out of scope if likely there for a good reason.  However, it isn’t
obvious to me what this prohibition is intended to cover.  If the WG was
designing a data format solution, compare candidate options seems like an
obvious thing to do.  Could this text please be clarified?