>> 1. Each APN has a defined "Name", which would be helpful to display to the user.

>What is the use case?

The name pulled from the provisioning database is usually something that makes sense to a user ( eg. "ATT Phone" or "Vodafone NL" ), whereas the "APN" field contains a server name ( eg. "live.vodafone.com" ).

> I could understand showing the name if we let you select an APN from a list, or import/export APN settings on external storage, or set up an APN separately from choosing which Types it should be used for.  Currently we're doing none of those things, so I'm leaving it out for now. I wouldn't want to mislead people into thinking that all they need to do to make their Orange phone work is to delete "T-Mobile US" and type "Orange" in its place, leaving all the actual settings unchanged.

We're currently in the midst of transitioning our GPRS provisioning from the mobile-broadband-provider-info database to new code that queries apns-conf.xml ( sourced from AOSP ).  This transition will allow multiple Internet APNs to be provisioned.

>> Also, it might be helpful to include the MCC ( mobile country code ) and MNC ( mobile network code ).

> What is the use case? Are those data editable? If so, what would an APN do differently if you changed them? And if not, what do you need to see them for?

They are editable in AOSP, but you raise a good point.  Once we've provisioned the APNs, the MNC/MCC really aren't all that useful other for reference purposes.

>> 2. Currently the only protocol that's supported for Mobile data connections is IPv4.

> Explained: "The 'Protocol' menu should be present when IPv6 has been implemented."

OK

>> 3. The MMS fields are close, but not quite accurate.

> Fixed: each APN now has fields for "APN", "Proxy", and "Proxy port".

The MMS fields that should be exposed are "MMS Proxy", "MMS Port", and "MMSC".  These fields may be present on an Internet APN that also supports MMS as well as a standalone MMS APN ( see below ).

>> 4. We're still trying to determine how we rectify the difference between ofono contexts and Android's APN db.

>What is the use case for an APN that isn't default/internet or mms? For example, what does a supl APN do?

A 'supl' APN is used for A-GPS.  A 'dun' APN is dedicated to support BT tethering.  The latest apns-conf.xml files don't contain any standalone "supl" or "dun" APNS.  We don't really support either of these types right now either.  At this point our plan is to support combined Internet/MMS contexts, and standalone MMS contexts.  There may be multiple of the former provisioned, and for now only one MMS context.

>> 5. Turns out that there are ~100 or so APNs defined with "proxy" and "port" attributes that are used to configure what I'm guessing is a required HTTP proxy.

>Fixed as for #3.

At this point, we're not supporting generic APN proxies.

>> 6. Some APNs also expose an "authentication-type" attribute that can be: "None", "PAP", "CHAP", or "PAP or CHAP".

>Added: "The 'Authentication' menu should contain 'None' (the default), 'PAP or CHAP', 'PAP only', and 'CHAP only'." Since "PAP or CHAP" is an option, I'm assuming that the rationale for the more restrictive options is to prevent MITM attacks? If we can auto-detect authentication methods altogether, then we can get rid of the menu altogether.

At this point, we're not planning on supporting this attribute.

>> 7... we've decided that it'd be best to provision all of the possible APNs for the given SPN/MNC/MCC combination, pick a default ( which is the first that supports Internet in the list ), and then allow the user to select any of the APNs that have been provisioned

>If I understand you correctly, that would make the UI much more complex: first you'd set up one or two APNs, and then you'd say "I want to use that one for Internet", rather than having dedicated "Internet APN" fields. That would be a reason to show the "Name" field (#1 above), but I'd rather avoid it (see #4 above).

Agreed, it does make the UI more complex.  The reason this is necessary is operators that may occasionally decide to create new APNs and only subscribe new customers to them, leaving older customers to use older APNs.  Unfortunately the only way to tell which of an operator's APN is use-able, requires us to provision all of the possible contexts and try them in order, till we find one that works ( note, this is for the Internet APN ).

>> 8. AOSP allows a user to manually create a new APN.

> As for #7 above.

I think this needs more discussion.

>> 9. AOSP also allows a user to reset their APN configuration to it's default ( ie. undo any changes made ).

> How does Ubuntu know what the default is?

The way this would work would be to delete the provisioned and/or manually created APNs, and re-run the provisioning process.  This isn't something we yet support, but I mentioned it as something that might be a useful future feature.