My point is that if you leave no other way out, that is what will happen.

On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng <> wrote:

> That's the case today already, and I haven't seen this happening.
> Daniel
> On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch <> wrote:
>> I'm sure you're aware that you can encode any binary blob as UTF-8
>> text/plain. If you don't support application/octet-stream, then that just
>> becomes the "dumping ground".
>> On Thu, Jun 25, 2015 at 7:39 PM, Daniel Cheng <> wrote:
>>> No UA supports it today. No UA is likely to support it anytime soon.
>>> Daniel
>>> On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch <> wrote:
>>>> Yet you restrict mime-types AND you support application/octet-stream?
>>>> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng <>
>>>> wrote:
>>>>> For reasons I've already mentioned, this isn't going to happen because
>>>>> there is no so-called "dumping ground".
>>>>> No one is going to risk their paste turning into thousands of lines of
>>>>> gibberish because they tried to stuff binary data in text/plain.
>>>>> Daniel
>>>>> On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch <>
>>>>> wrote:
>>>>>> No, what I'm saying is that if you restrict mime types (or don't
>>>>>> explicitly prohibit such restriction), but require
>>>>>> application/octet-stream, that application/octet-stream becomes the
>>>>>> "undesirable mime-type" dumping ground. And that would be bad because 
>>>>>> that
>>>>>> makes it much harder for applications to deal with content. But if that's
>>>>>> the only way UAs are going to act, then applications will work around 
>>>>>> that
>>>>>> by using elaborate guessing code based on magic bytes, and perhaps some
>>>>>> application developers will use their own mime-type annotation pretended 
>>>>>> to
>>>>>> the octet-stream.
>>>>>> If you inconvenience people, but don't make it impossible to work
>>>>>> around the inconvenience, then people will work around the inconvenience.
>>>>>> It can't be the intention to encourage them work around it. So you've got
>>>>>> to either not inconvenience them, or make working around impossible.
>>>>>> On Thu, Jun 25, 2015 at 5:07 PM, Wez <> wrote:
>>>>>>> Florian, you keep referring to using application/octet-stream -
>>>>>>> that's not a format that all user agents support (although the spec says
>>>>>>> they should ;), nor is there any mention in the spec of what it means to
>>>>>>> place content on the clipboard in that format (given that platform 
>>>>>>> native
>>>>>>> clipboards each have their own content-type annotations).
>>>>>>> So it sounds like you're saying we should also remove
>>>>>>> application/octet-stream as a mandatory format?
>>>>>>> On Thu, 25 Jun 2015 at 15:55 Florian Bösch <> wrote:
>>>>>>>> It's very simple. Applications need to know what's in the clipboard
>>>>>>>> to know what to do with it. There is also a vast variety of things that
>>>>>>>> could find itself in the clipboard in terms of formats, both formal and
>>>>>>>> informal. Mime types are one of these things that applications would 
>>>>>>>> use to
>>>>>>>> do that.
>>>>>>>> If a UA where to restict what mime type you can put into the
>>>>>>>> clipboard, that forces the clipboard user to use 
>>>>>>>> application/octet-stream.
>>>>>>>> And in consequence, that forces any such-willing application to forgoe 
>>>>>>>> the
>>>>>>>> mime-type information from the OS'es clipboard API and figure out 
>>>>>>>> what's in
>>>>>>>> it from the content. In turn this would give rise to another way to 
>>>>>>>> markup
>>>>>>>> mime-types in-line with the content. And once you've forced such ad-hoc
>>>>>>>> solutions to emerge for meddling with what people can put in the 
>>>>>>>> clipboard,
>>>>>>>> you'll have no standing to put that geenie back in the bottle, again,
>>>>>>>> relevant XKCD quote omitted.
>>>>>>>> On Thu, Jun 25, 2015 at 4:48 PM, Wez <> wrote:
>>>>>>>>> You've mentioned "resorting to application/octet-stream" several
>>>>>>>>> times in the context of this discussion, where AFAICT the spec 
>>>>>>>>> actually
>>>>>>>>> only describes using it as a fall-back for cases of file references 
>>>>>>>>> on the
>>>>>>>>> clipboard for which the user agent is unable to determine the file 
>>>>>>>>> type.
>>>>>>>>> So IIUC you're suggesting that user agents should implement
>>>>>>>>> "application/octet-stream" (as is also mandated by the spec, albeit 
>>>>>>>>> without
>>>>>>>>> a clear indication of what it means in this context) by putting the 
>>>>>>>>> content
>>>>>>>>> on the clipboard as an un-typed file?
>>>>>>>>> Again, I'm unclear as to what the alternative is that you're
>>>>>>>>> proposing?
>>>>>>>>> On Thu, 25 Jun 2015 at 15:27 Florian Bösch <>
>>>>>>>>> wrote:
>>>>>>>>>> Surely you realize that if the specification where to state to
>>>>>>>>>> only "safely" expose data to the clipboard, this can only be 
>>>>>>>>>> interpreted to
>>>>>>>>>> deny any formats but those a UA can interprete and deem well-formed. 
>>>>>>>>>> If
>>>>>>>>>> such a thing where to be done, that would leave any user of the 
>>>>>>>>>> clipboard
>>>>>>>>>> no recourse but to resort to "application/octett-stream" and ignore 
>>>>>>>>>> any
>>>>>>>>>> other metadata as the merry magic header guessing game gets 
>>>>>>>>>> underway. For
>>>>>>>>>> all you'd have achieved was to muddle any meaning of the mime-type 
>>>>>>>>>> and
>>>>>>>>>> forced applications to work around an unenforceable restriction.
>>>>>>>>>> On Thu, Jun 25, 2015 at 3:21 PM, Wez <> wrote:
>>>>>>>>>>> And, again, I don't see what that has to do with whether the
>>>>>>>>>>> spec mandates that user agents let apps place JPEG, PNG or GIF 
>>>>>>>>>>> directly on
>>>>>>>>>>> the local system clipboard. The spec doesn't currently mandate 
>>>>>>>>>>> OpenEXR be
>>>>>>>>>>> supported, so it's currently up to individual user agents to decide 
>>>>>>>>>>> whether
>>>>>>>>>>> they can support that format safely.
>>>>>>>>>>> On Thu, 25 Jun 2015 at 14:16 Florian Bösch <>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On Thu, Jun 25, 2015 at 3:13 PM, Wez <> wrote:
>>>>>>>>>>>>> I think there's obvious value in support for arbitrary
>>>>>>>>>>>>> content-specific formats, but IMO the spec should at least give 
>>>>>>>>>>>>> guidance on
>>>>>>>>>>>>> how to present the capability in a safe way.
>>>>>>>>>>>> Which is exactly the core of my question. If you intend to make
>>>>>>>>>>>> it say, safe to put OpenEXR into the clipboard (as opposed to 
>>>>>>>>>>>> letting an
>>>>>>>>>>>> app just put any bytes there), the UA has to understand OpenEXR. 
>>>>>>>>>>>> Since I
>>>>>>>>>>>> don't see how the UA can understand every conceivable format in 
>>>>>>>>>>>> existence
>>>>>>>>>>>> both future and past, I don't see how that should work.

Reply via email to