I think you're missing the point: there is already no other way out, and that has not happened.
Daniel 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. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
