Re: [w3c/editing] Add revised OS custom format naming. (#316)

@dway123 commented on this pull request.



> @@ -115,11 +115,33 @@ Sites can read or write pickled versions of sanitized formats, by providing the
 ### OS-Interaction: Format Naming
 Native applications will only be able to interact with these formats if they explicitly add support for these pickled formats. Different platforms / OS’s often have different conventions for a clipboard format’s name, so formats will be named accordingly per OS. Payloads will be unaffected/unmodified between different OS’s.
 
-On MacOS (and iOS), clipboard formats are named using the UTI reverse-DNS naming convention. Therefore, a MIME type `"custom/format"` will be transformed to `"com.web.custom.format"`. Note that the pickling prefix `"com.web"` precedes the transformed format name `"custom.format"`, and the slash is converted to a period.
+On Windows, there is room for around [16,000 registered window messages and clipboard formats](https://devblogs.microsoft.com/oldnewthing/20150319-00/?p=44433). Once those are exhausted, things will start behaving erratically because window classes use the same pool of atoms as clipboard formats, so nobody will be able to register window classes until the user logs off and back on. Linux has a limitation on the atom space as well so we are proposing a new approach for custom format namings and payload serialization/deserialization format which will be safer from a security prespective and also deterministic as to how many custom formats are guranteed to be available in the clipboard inserted via pickling APIs. Generation of clipboard formats dynamically risks exhaustion of the atom pool.

* "nobody" -> "applications"
* "we are proposing" shouldn't be necessary, as the explainer is the proposal. You can just describe the state we'll hope for.
* Split up the sentence starting with "Linux has a limitation"? It's a bit long.
* "Generation of clipboard formats dynamically risks exhaustion of the atom pool" can probably be the first sentence instead of the last one

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/pull/316#pullrequestreview-711168701