Re: [media-types] New toplevel type - extension

["Martin J. Dürst" <[e-mail]>]

On 2022-06-11 01:21, Phillip Hallam-Baker wrote:
> I am not going to defend the aesthetics of this proposal. But it definitely
> has utility.
> 
> The proposal is for a new toplevel type extension where the subtype is the
> file extension used to announce the type to the operating system.
> 
> Yes, I know it is ugly.

Graham's proposal for application/extension.foobar looks just a little 
bit less ugly to me.

> But it would be damned useful when writing an
> archiving tool. At the moment, I have to record both the original file
> extension and the inferred media type. And this results in a whole rack of
> ambiguity and mess because having two ways to describe the same thing
> inevitably results in ambiguity.

I understand the problems you get with the ambiguity, but what about 
just leaving the media type blank? With your extension, you don't really 
provide information, you just duplicate it.


> Consider the case that Alice saves her html document out to a DARE archive
> from a html editor. In this case the content is definitely text/html.
> 
> But what happens when Alice zips a set of files on disk and the archive
> tool infers the content types? Well obviously file.html is almost certainly
> html but that is an inference and when the archive tool guesses the type of
> less well known file types it can easily get it wrong.

Yes. In that case, the archive tool should just not guess anything.


> So in the spirit of 'describe exactly what you know', extension/dcat seems
> to be the way forward for when my archive tool detects a file of extension
> .dcat.

Well, when your archiving tool detects a file with extension .dcat, it 
can just note this extension as part of the file name, because it's all 
it knows. The media type can just stay empty.


Regards,   Martin.

> 
> Thoughts?
> 
> [The use case that brought this up is that I threw together a little Web
> browser that can surf a Web site published as a set of static encrypted
> files. So all the content is encrypted end to end.
> 
> If a threshold encryption scheme is used, the administrator of the group
> can add and remove decryption rights from users without changing the
> encrypted content or compromising the end-to-end encryption.
> 
> One consequence of this approach is that the media type to be reported to
> the browser is only known after the browser attempts decryption. If Alice
> attempts to read a file encrypted to a group she has not been read into,
> she will see a HTML warning page telling her she is not allowed access.
> 
> Oh and my very ad hoc usability study strongly suggests that when a user is
> surfing the Web and suddenly hits an Orange Page shouting TOP SECRET they
> do actually take notice. But even if they don't the data is still
> encrypted.]
> 
> 
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types