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

[Harald Alvestrand <[e-mail]>]

extension/string-under-someone-elses-control seems to me as close as we 
can get to something that top level types should NOT be used for, I think.

As such, it should inform the top-level draft as needing to state a 
principle that makes it clear that it's not an appropriate usage.

application/octet-string; filename=foo.dcat conveys all the information 
one has about such an object (application-octet-stream is a long-winded 
say of saying "I have no idea what this is").




On 6/17/22 08:17, Martin J. Dürst wrote:
> 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
> 
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types