A question was raised during the dmm session regarding whether a developer
would use the Socket options specified in the draft or even be aware of
them.  Mobile developers (Android and other OSes) are quite aware of not
only the network type but also the 'features' that can be requested.

Using Android as an example -
The basic networking tutorial exposes the developer to ways to check
connections and their types (
http://developer.android.com/training/basics/network-ops/managing.html).
The developer is also made aware of permissions requests and features of
the connection type during this and many other 'Getting Started' tutorials
one may find on the Internet.

The Android API permits a developer to request a feature using the
requestNetwork( request, operation) method.  The method is described
as "Request
a network to satisfy a set of NetworkCapabilities " which can be found here
-
http://developer.android.com/reference/android/net/NetworkCapabilities.html

Although many of these capabilities are merely network types you'll note a
few are sub-features or 'qualities' such as NOT_RESTRICTED (general use) or
NOT_METERED.

It is reasonable to assume that for Android the options specified in the
draft would be enumerated here if the developer wishes to manipulate it at
the application level or pass as socket options in the Android Socket API
which likely, in turn, calls the ConnectivityManager first and, upon
success, attempts to open the Socket.   Other operating systems in the
mobile space have similar features.

If security is an issue the OS provider can use their respective
application permissions frameworks to restrict the application's request.

I think the OSes have very good methods to accommodate the options as
described in the draft and developers have a good idea of how to or
discover how to use them.

Lyle
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to