[media-types] Re: Hash based media typing

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.]

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.

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

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>.

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]