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

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

Hello Harald, others,

On 2022-08-01 21:44, Harald Alvestrand wrote:
> 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").

I have added a paragraph about this topic to the subsection about 
negative criteria. I wrote this to also include ideas such as
https://datatracker.ietf.org/doc/html/draft-eastlake-cturi-07#section-3.1, 
which fortunately does not use a top-level type, but only a subtype 
prefix. As a result, it proposes to map http://example.com/tag42 to 
application/uri.http%3A%2F%2Fexample.com%2Ftag42. The problem with that 
is that I don't think there's any mechanism to reserve the prefix "uri." 
under application.
Something like application/uri-mapping; uri=http://example.com/tag42 
(with escapings according to context) seems quite a bit more appropriate.

While I have added the necessary text, I haven't added any references 
because I don't want to explicitly point to stuff that we consider 
non-appropriate. Please tell me if you want references.

[The alternative would be to define a single top-level type "mapping" 
with subtypes such as mapping/extension, mapping/uri,... each with a 
parameter that contains the mapped data. But I'm not sure we want to go 
there.]

Regards,   Martin.

> 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
> 
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan