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. >>>>>>> >>>>>> >>>>> >>> >