- From: Daniel Cheng <dcheng@google.com>
- Date: Thu, 25 Jun 2015 17:57:03 +0000
- To: Florian Bösch <pyalot@gmail.com>
- Cc: Wez <wez@google.com>, Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>, public-webapps <public-webapps@w3.org>
- Message-ID: <CAF3XrKqNN7BA-0D3twamHBb1WwDzvKMvkcqLeV1BZxKgyGqE+w@mail.gmail.com>
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 <pyalot@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 <dcheng@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 <pyalot@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 <dcheng@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 <pyalot@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 <wez@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 <pyalot@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 <wez@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 <pyalot@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 <wez@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 <pyalot@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Thu, Jun 25, 2015 at 3:13 PM, Wez <wez@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. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
Received on Thursday, 25 June 2015 17:57:40 UTC