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

[Graham Klyne <[e-mail]>]

Hi!

A thought:

Rather than a new top-level media type, how about a new tree under 
"application", such as:

     application/extension.foobar

to be established per https://www.rfc-editor.org/rfc/rfc6838.html#section-3.5 ?

It feels to me that your general goal sits more comfortably with an 
"application" top-level type than as something new.

#g
--


On 10/06/2022 17: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. 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.
> 
> 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.
> 
> 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.
> 
> 
> 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

-- 
Graham Klyne
mailto:[e-mail]
http://www.ninebynine.org
Skype/Twitter: @gklyne