From 92b24f9859f88f9dca40e43cebaf0167571be30c Mon Sep 17 00:00:00 2001 From: olf Date: Thu, 19 Jan 2023 01:52:57 +0100 Subject: [PATCH] Enhance a bit --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5037545..40003fa 100644 --- a/README.md +++ b/README.md @@ -20,8 +20,8 @@ Hence *obexd-contentfilter-off* provides a simple way to disable the filter for #### Background * The purpose of the original *obexd-contentfilter-helper(app)* is to strictly adhere to the OBEX specification in MeeGo and subsequently in SailfishOS. The idea is to never let users receive files per Bluetooth, which cannot be processed on the device.
- But this behaviour is contrary to most other file transfer methods and falls short, as e.g. TUI (textual user interface, "shell") programs usually do not register MIME types of files they can process and apparently the MIME type registrations of Android apps installed in an Android runtime environment (e.g. AlienDalvik, Anbox) are not being passed through to the underlying GNU/Linux distribution.
+ But this behaviour is contrary to most other file transfer methods and falls short, as e.g., TUI (textual user interface, "shell") programs usually do not register MIME types of files they can process and apparently the MIME type registrations of Android apps installed in an Android runtime environment (e.g., Alien Dalvik aka "Android App Support", Anbox → Waydroid) are not being passed through to the underlying GNU/Linux distribution.
The main argument from the manufacturers perspective was, "BT SIG qualification for Obex push requires that unsupported content is rejected, regardless of whether we want to let everything through or not." (2014-09-25). Actually the OBEX aka [IrDA Interoperability (IrOBEX)](https://www.bluetooth.com/specifications/protocol-specifications/) (v2.0, 26 Aug 2010) and [Generic Object Exchange Profile (GOEP)](https://www.bluetooth.com/specifications/profiles-overview/) (v2.1.1, 15 Dec 2015) specifications do not require this, but the [Object Push Profile (OPP)](https://www.bluetooth.com/specifications/profiles-overview/) (v1.2.1, 15 Dec 2015) specification may (the latter does not seem to be publicly available, only [the aspects essential for implementing the OPP](https://www.amd.e-technik.uni-rostock.de/ma/gol/lectures/wirlec/bluetooth_info/k11_opp.html) are). -* The deliberate filtering for supported MIME types has sparked heated dicussions at TJC (e.g. [[1]](https://together.jolla.com/question/1302/bluetooth-file-transfer-for-all-file-types/), [[2]](https://together.jolla.com/question/55104/sending-files-from-pc-to-jolla-by-bluetooth-is-extension-dependent/?answer=56832#post-id-56832)), because users expect arbitrary files to be easily transferred as on their PCs.
+* The deliberate filtering for supported MIME types has sparked heated dicussions at TJC (e.g., [[1]](https://together.jolla.com/question/1302/bluetooth-file-transfer-for-all-file-types/), [[2]](https://together.jolla.com/question/55104/sending-files-from-pc-to-jolla-by-bluetooth-is-extension-dependent/?answer=56832#post-id-56832)), because users expect arbitrary files to be easily transferred as on their PCs.
Obviously the current behaviour does not fit well for this user group. * *obexd-contentfilter-off* evolved from [this](https://together.jolla.com/question/1302/bluetooth-file-transfer-for-all-file-types/?answer=192893#192893-original-answer-2018-11-10) (kudos to [@hmallat](https://together.jolla.com/users/2541/hmallat/) for the original suggestion).