I think you're missing the point: there is already no other way out, and
that has not happened.


On Thu, Jun 25, 2015 at 11:08 AM Florian Bösch <pya...@gmail.com> wrote:

> 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 <dch...@google.com> 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 <pya...@gmail.com> 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 <dch...@google.com> 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 <pya...@gmail.com>
>>>> wrote:
>>>>> Yet you restrict mime-types AND you support application/octet-stream?
>>>>> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng <dch...@google.com>
>>>>> 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 <pya...@gmail.com>
>>>>>> 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 <w...@google.com> 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 <pya...@gmail.com>
>>>>>>>> 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 <w...@google.com> 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 <pya...@gmail.com>
>>>>>>>>>> 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 <w...@google.com> 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 <pya...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On Thu, Jun 25, 2015 at 3:13 PM, Wez <w...@google.com> 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