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