[media-types] Re: Hash based media typing

On Fri, May 23, 2025 at 10:20 PM Martin J. Dürst <[email protected]>
wrote:

> Hello Phillip,
>
> I have difficulties understanding the relevance of your
> draft-hallambaker-earl-00 on media types. But that may be just me.
>
> Your draft uses media types, but that usage seems just fine.
>
> [While we are at it, many of the references in your draft say
> "[Reference Not Found!]", which looks like some document production error.]
>

The repository must have been down when I did the document build, it will
fix itself next time round, I am sure.


On 2025-05-24 02:14, Phillip Hallam-Baker wrote:
> > The concept:
> >
> > earl/<hash-of-description-document>
>
> The syntax seems to suggest 'earl' as a top-level media type. Is that
> what you are proposing? This WG just spent quite some effort to define
> criteria for new top-level types, see RFC 9694. An 'earl' top-level type
> would cut across the traditional text/image/audio/video/application
> distinction of top-level types, so I doubt that's where this belongs.
>

I am using it as a toplevel type to separate out the names assigned
algorithmically from those assigned through registration.

Historically, we have separated the identifiers by type but I think that
was really to try and simplify searching the registry rather than to
provide information to applications using them. What does text/html really
tell an app if it don't understand html? The next biggest text format is
application/pdf.

I do understand people like to sort information into taxonomies but it is
almost never useful unless there is a tree like structure to the
information as with species.

DNS would have worked so much better without the com, net, org stuff.
Register mit, digital, etc. No risk of ietf.com squatting on ietf. Just as
pretty much everything ended up in dotcom, pretty much everything ends up
in application/*


> As for JSON or XML documents with different schemas, I think the
> traditional approach would be to use a parameter on the media type for
> the schema (where of course your earl scheme might be used).
>

But then you have to pick a unique tag for that and registration seems like
the wrong approach for permissionless innovation.

If we followed that approach you end up with my earls spread right across
the whole registry. I really don't think you would want that result. Much
cleaner to sort these identifiers by the type of the identifier rather than
what they might point to.

Another place to consider in case you want to use something like earls
> in media types would be to define an earl tree, similar to
> vendor/personal/unregistered trees. These media types would then e.g.
> look like
> application/earl.<actual earl data>.
>

But the referenced content could be any of your six classifications. So we
would have application/earl and image/earl and so on if we were taking the
taxonomy seriously.



> Hope this helps,   Martin.
>
>
> > Draft describing the hash approach, this is a refined version of the
> > RFC6920 approach.
> >
> > https://www.ietf.org/archive/id/draft-hallambaker-earl-00.html
> >
> >
> > Rationale
> >
> > * No registry of media types can ever be complete and there are many
> cases
> > in which the developer of the media type wants to register it.
> >
> > * Naming the media type by a unique, universal identifier provides the
> core
> > function of a media type registration, 'interpret this content according
> to
> > this unique identifier'.
> >
> > * A digest of a JSON or XML schema is one possible identifier.
> >
> > * The EARL mechanism allows content to link to a specific version of a
> > schema that can be upgraded in the future.
> >
> > * The resulting identifiers are human readable and can fit in the same
> > slots used for IANA media types.
> >
> > * The IANA registry would not go away, it will simply be a registry of
> > additional important information.
> >
> >
> > Discussion
> >
> > I came across the need for this while passing data between some Web
> > Servicey type systems. In brief, there is an envelope with a header and
> > content body and the header has a slot for media type. And that media
> type
> > is used to tell the JSON parser what type of object to return after
> parsing.
> >
> > So up until now, I have been developing using content types like
> >
> > application/mesh-deviceprofile.
> >
> > OK, so lots of problems there, I know what I am doing and I am not likely
> > to do something bad. But my code generation tools are designed to make it
> > easy for anyone to do this sort of thing. What if 'anyone' did? We are
> > going to end up with collisions.
> >
> > But the ContentType slot is a place where I would normally specify that
> the
> > thing inside the envelope is a JPG or whatever. I can easily mint an
> extra
> > slot but then I have two places to look for the same data and that leads
> to
> > errors.
> >
> > So what if I could specify the content type as:
> >
> > earl/eluv-woab-g7ih-onix-ybns-qdxk-rzqs;DeviceProfile
> >
> > The Media Type is functionally a URN here. The only way that the
> > application can understand the content type is if either it is programmed
> > into the app from the start or if there is a mechanism that allows it to
> > resolve the content type. That mechanism is deliberately left
> unspecified,
> > noting the W3C experience of using HTTP to identify schemas.
> >
> >
> > What this allows me to provide is a seamless path from identifiers used
> in
> > development to those used in production.
> >
> > The EARL construction is a direct descendant of the TAXI assertion
> > structure used in SAML which is in turn a descendant of PKIX. There is a
> > metadata slot and a content slot wrapped by an unauthenticated header and
> > trailer allowing a digital signature to be specified.
> >
> > So let's say I change the schema, the new schema will of course have a
> > completely different digest which means that we can specify a specific
> > version if we like. But inside that envelope there is a signature
> > authenticating the new assertion under an update key specified in the
> > original.
> >
> > And if I pass change control to IETF or W3C or whoever, I can sign an
> > assertion passing the update key to them.
> >
> > The security angle might seem a bit over the top, but it is a pretty
> > effective way of ensuring everyone is clear about their responsibilities,
> > who currently has change control over what, etc. and of ensuring third
> > party services don't get confused and act under divergent interpretations
> > of the circumstances.
> >
> >
> > The main risk here is that someone mints a content type that later
> becomes
> > important and is unable to sign an assertion transferring change control.
> > But that is OK, it is indistinguishable from refusing to.
> >
> >
> > _______________________________________________
> > media-types mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
>

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]