Re: service-provider extension patch
On Wed, 2010-06-16 at 17:20 +0100, Neil Williams wrote: > On Wed, 02 Jun 2010 01:08:57 -0700 > Dan Williams wrote: > > > On Tue, 2010-05-25 at 10:37 +0100, Neil Williams wrote: > > > On Mon, 24 May 2010 16:46:34 -0700 > > > Dan Williams wrote: > > > > - When two are listed, what's the difference between the two? Do > > > > both do the same thing? Or are they different? > > > > > > The same "networkID" can have differing implementations from which the > > > user needs to select according to local requirements like tariff or > > > locality or handset. Our UI offers a default and then allows the user to > > > choose from the alternatives. > > > > Is it useful to tag those different implementations with a name? We > > could add a name to each of the items that need it, though it can't be a > > property, it'd have to be a sub-element so that it could be localized. > > Each definition is more of a fallback than a discrete alternative. We > don't have a reliable way of mapping one alternative to one particular > description. Current theory is that service providers themselves > "adopt" new details when taking over smaller networks etc. and then fold > those into the main network such that whichever method works gets > through to the same network space. So some items will be legacy and > some will be ongoing alternatives which providers maintain for their > own reasons (and could drop or switch at any time). We really cannot > tell from this end. Where both alternatives work in our tests, there > appears to be no way to distinguish one alternative from another, > except by changes which would be inherent in the type of interface. > > There may have been a name tag for some alternatives but there is also > no guarantee that providers will continue using the same name on the > handset, leading to confusion. > > All we have been able to establish is that certain alternatives do > appear to be a sane default and those are listed first. > > > > > - For the SMS balance check, when two items are listed, what's the > > > > different between the two? > > > > > > Handset / regional / tariff based differentiation. The user configures > > > which of the available methods to use, the choice is then stored in > > > the application. > > > > Again, might make sense to have and subelements to give > > users some help here too. > > If we could know that the name or desc would be persistent then that > would be useful. That just doesn't appear to be a reliable assumption > and is outside user control, sadly. > > > That would mean changing the format a bit though to something more like: > > > > > > asdfadfadf > > Blah Blah > > > > > > and the same for the rest of the items. Or replace the "dtmf" attribute > > with an element inside voicemail perhaps. Either way. Maybe we don't > > actually need name/description for some of these? The issue is that if > > we go with the format you're suggesting, it's really hard to add > > localized name or description later without breaking the DTD. > > From this end, it looks more like adding names or descriptions (and > then translating them) is more likely to be misleading and error-prone, > causing more work for everyone. > > > I'd also like to see comments in the DTD if we can stuff them in about > > what each of the new fields is, like you've described them here. That > > makes the DTD more of a "specification". Or if that's not the right way > > to do it, at least comment about them at the top of the XML file. > > Comments added to the DTD. > > > > No problem. Further updates may follow as more devices get out to real > > > users. Network methods can be impossible to test without real access to > > > the network itself. > > > > Completely understood. Think you'd be able to respin the patch with the > > suggested changes? > > I'm attaching a revised patch with the DTD comments to replace the > first one we sent. Pushed, thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: service-provider extension patch
On Wed, 02 Jun 2010 01:08:57 -0700 Dan Williams wrote: > On Tue, 2010-05-25 at 10:37 +0100, Neil Williams wrote: > > On Mon, 24 May 2010 16:46:34 -0700 > > Dan Williams wrote: > > > - When two are listed, what's the difference between the two? Do > > > both do the same thing? Or are they different? > > > > The same "networkID" can have differing implementations from which the > > user needs to select according to local requirements like tariff or > > locality or handset. Our UI offers a default and then allows the user to > > choose from the alternatives. > > Is it useful to tag those different implementations with a name? We > could add a name to each of the items that need it, though it can't be a > property, it'd have to be a sub-element so that it could be localized. Each definition is more of a fallback than a discrete alternative. We don't have a reliable way of mapping one alternative to one particular description. Current theory is that service providers themselves "adopt" new details when taking over smaller networks etc. and then fold those into the main network such that whichever method works gets through to the same network space. So some items will be legacy and some will be ongoing alternatives which providers maintain for their own reasons (and could drop or switch at any time). We really cannot tell from this end. Where both alternatives work in our tests, there appears to be no way to distinguish one alternative from another, except by changes which would be inherent in the type of interface. There may have been a name tag for some alternatives but there is also no guarantee that providers will continue using the same name on the handset, leading to confusion. All we have been able to establish is that certain alternatives do appear to be a sane default and those are listed first. > > > - For the SMS balance check, when two items are listed, what's the > > > different between the two? > > > > Handset / regional / tariff based differentiation. The user configures > > which of the available methods to use, the choice is then stored in > > the application. > > Again, might make sense to have and subelements to give > users some help here too. If we could know that the name or desc would be persistent then that would be useful. That just doesn't appear to be a reliable assumption and is outside user control, sadly. > That would mean changing the format a bit though to something more like: > > > asdfadfadf > Blah Blah > > > and the same for the rest of the items. Or replace the "dtmf" attribute > with an element inside voicemail perhaps. Either way. Maybe we don't > actually need name/description for some of these? The issue is that if > we go with the format you're suggesting, it's really hard to add > localized name or description later without breaking the DTD. >From this end, it looks more like adding names or descriptions (and then translating them) is more likely to be misleading and error-prone, causing more work for everyone. > I'd also like to see comments in the DTD if we can stuff them in about > what each of the new fields is, like you've described them here. That > makes the DTD more of a "specification". Or if that's not the right way > to do it, at least comment about them at the top of the XML file. Comments added to the DTD. > > No problem. Further updates may follow as more devices get out to real > > users. Network methods can be impossible to test without real access to > > the network itself. > > Completely understood. Think you'd be able to respin the patch with the > suggested changes? I'm attaching a revised patch with the DTD comments to replace the first one we sent. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ Index: serviceproviders.2.dtd === --- serviceproviders.2.dtd (revision 10747) +++ serviceproviders.2.dtd (working copy) @@ -6,7 +6,7 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + Index: serviceproviders.xml === --- serviceproviders.xml (revision 10747) +++ serviceproviders.xml (working copy) @@ -287,6 +287,11 @@ Telstra + +125111 +125 +*100# + 139.130.4.4 203.50.2.71 @@ -2017,6 +2022,16 @@ + Test Network + + + +dummy +dummy + + + + airtel vodaphone @@ -2038,7 +2053,11 @@ - + 901 + +*#10# + + Contract o2web @@ -2079,6 +2098,12 @@ T-Mobile + 222 + +150 +150 +150 + User mms @@ -2102,6 +2127,11 @@ Vodafone + 121 + +*#1345# +2345 + Contract web @@ -2138,7 +2168,10 @@ - + 123 + +
Re: service-provider extension patch
On Tue, 2010-05-25 at 10:37 +0100, Neil Williams wrote: > On Mon, 24 May 2010 16:46:34 -0700 > Dan Williams wrote: > > > On Mon, 2010-05-24 at 16:54 +0100, Neil Williams wrote: > > > Toby Churchill have been running an internal project to compile a list > > > of gsm network operators and the relevant information such as MCC/MNC > > > codes, voicemail, balance check methods etc for use in a mobile-phone > > > enabled communication aid. > > > > > > We created an XML document for our use internally but have since come > > > across the the serviceprovider package which has a fair amount of > > > overlap. So it has been suggested that it may be worthwhile adding our > > > information with the serviceprovider list... > > > > > > Please find attached a patch (serviceprovider.2.tdt & > > > serviceprovider.xml) to extend the node to incorporate > > > and methods for a network provider. > > > - When two are listed, what's the difference between the two? Do > > both do the same thing? Or are they different? > > The same "networkID" can have differing implementations from which the > user needs to select according to local requirements like tariff or > locality or handset. Our UI offers a default and then allows the user to > choose from the alternatives. Is it useful to tag those different implementations with a name? We could add a name to each of the items that need it, though it can't be a property, it'd have to be a sub-element so that it could be localized. > We also fallback to SMS when our own communication aid is set to silent > mode (to silence normal dialling noises / notifications etc.) > > > - For the USSD stuff, when would be used, and when would > > be used? > > is fire and forget. > needs to have the modem hang on for a response > from the user before the balance will be sent. The UI passes the > network prompt back to the user. (Choose 1 for X, 2 for Y etc.) > > Which to use is down to handset/tariff variability. Ok. > > - For the SMS balance check, when two items are listed, what's the > > different between the two? > > Handset / regional / tariff based differentiation. The user configures > which of the available methods to use, the choice is then stored in > the application. Again, might make sense to have and subelements to give users some help here too. That would mean changing the format a bit though to something more like: asdfadfadf Blah Blah and the same for the rest of the items. Or replace the "dtmf" attribute with an element inside voicemail perhaps. Either way. Maybe we don't actually need name/description for some of these? The issue is that if we go with the format you're suggesting, it's really hard to add localized name or description later without breaking the DTD. I'd also like to see comments in the DTD if we can stuff them in about what each of the new fields is, like you've described them here. That makes the DTD more of a "specification". Or if that's not the right way to do it, at least comment about them at the top of the XML file. > > - Also for SMS, what is the meaning of the "text" attribute, and what's > > the meaning of the data inside the item? > > For balance check enquiries by SMS, the text is the keyword passed as > the body of the SMS and then recognised by the network. The content of > the SMS tag is then used as the number to which the SMS is sent. > > > - If you could also add voicemail to the CDMA stanza that would be great > > since all of these have voicemail #s too. > > Not testable in TCL, so that's harder. We only support GSM currently. > > > Thanks for sending the patches! > > No problem. Further updates may follow as more devices get out to real > users. Network methods can be impossible to test without real access to > the network itself. Completely understood. Think you'd be able to respin the patch with the suggested changes? Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: service-provider extension patch
On Mon, 24 May 2010 16:46:34 -0700 Dan Williams wrote: > On Mon, 2010-05-24 at 16:54 +0100, Neil Williams wrote: > > Toby Churchill have been running an internal project to compile a list > > of gsm network operators and the relevant information such as MCC/MNC > > codes, voicemail, balance check methods etc for use in a mobile-phone > > enabled communication aid. > > > > We created an XML document for our use internally but have since come > > across the the serviceprovider package which has a fair amount of > > overlap. So it has been suggested that it may be worthwhile adding our > > information with the serviceprovider list... > > > > Please find attached a patch (serviceprovider.2.tdt & > > serviceprovider.xml) to extend the node to incorporate > > and methods for a network provider. > - When two are listed, what's the difference between the two? Do > both do the same thing? Or are they different? The same "networkID" can have differing implementations from which the user needs to select according to local requirements like tariff or locality or handset. Our UI offers a default and then allows the user to choose from the alternatives. We also fallback to SMS when our own communication aid is set to silent mode (to silence normal dialling noises / notifications etc.) > - For the USSD stuff, when would be used, and when would > be used? is fire and forget. needs to have the modem hang on for a response from the user before the balance will be sent. The UI passes the network prompt back to the user. (Choose 1 for X, 2 for Y etc.) Which to use is down to handset/tariff variability. > - For the SMS balance check, when two items are listed, what's the > different between the two? Handset / regional / tariff based differentiation. The user configures which of the available methods to use, the choice is then stored in the application. > - Also for SMS, what is the meaning of the "text" attribute, and what's > the meaning of the data inside the item? For balance check enquiries by SMS, the text is the keyword passed as the body of the SMS and then recognised by the network. The content of the SMS tag is then used as the number to which the SMS is sent. > - If you could also add voicemail to the CDMA stanza that would be great > since all of these have voicemail #s too. Not testable in TCL, so that's harder. We only support GSM currently. > Thanks for sending the patches! No problem. Further updates may follow as more devices get out to real users. Network methods can be impossible to test without real access to the network itself. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpnXF3uaQ6ct.pgp Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: service-provider extension patch
On Mon, 2010-05-24 at 16:54 +0100, Neil Williams wrote: > Toby Churchill have been running an internal project to compile a list > of gsm network operators and the relevant information such as MCC/MNC > codes, voicemail, balance check methods etc for use in a mobile-phone > enabled communication aid. > > We created an XML document for our use internally but have since come > across the the serviceprovider package which has a fair amount of > overlap. So it has been suggested that it may be worthwhile adding our > information with the serviceprovider list... > > Please find attached a patch (serviceprovider.2.tdt & > serviceprovider.xml) to extend the node to incorporate > and methods for a network provider. - When two are listed, what's the difference between the two? Do both do the same thing? Or are they different? - For the USSD stuff, when would be used, and when would be used? - For the SMS balance check, when two items are listed, what's the different between the two? - Also for SMS, what is the meaning of the "text" attribute, and what's the meaning of the data inside the item? - If you could also add voicemail to the CDMA stanza that would be great since all of these have voicemail #s too. Thanks for sending the patches! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: service-provider extension patch
On Mon, 2010-05-24 at 20:32 +0100, Neil Williams wrote: > On Mon, 24 May 2010 20:35:57 +0200 > Marcel Holtmann wrote: > > > Hi Neil, > > > > > We created an XML document for our use internally but have since > > > come across the the serviceprovider package which has a fair amount > > > of overlap. So it has been suggested that it may be worthwhile > > > adding our information with the serviceprovider list... > > > > > > Please find attached a patch (serviceprovider.2.tdt & > > > serviceprovider.xml) to extend the node to incorporate > > > and methods for a network provider. > > > > nice addition. Another missing piece is the MMS information. > > Indeed, hopefully we can work together on that data from here on. We > don't use MMS information yet. Yeah, eventually I"d like to add MMSC, WAP proxy, etc to the information as well. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: service-provider extension patch
On Mon, 24 May 2010 20:35:57 +0200 Marcel Holtmann wrote: > Hi Neil, > > > We created an XML document for our use internally but have since > > come across the the serviceprovider package which has a fair amount > > of overlap. So it has been suggested that it may be worthwhile > > adding our information with the serviceprovider list... > > > > Please find attached a patch (serviceprovider.2.tdt & > > serviceprovider.xml) to extend the node to incorporate > > and methods for a network provider. > > nice addition. Another missing piece is the MMS information. Indeed, hopefully we can work together on that data from here on. We don't use MMS information yet. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpwCeEfNZRK3.pgp Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: service-provider extension patch
Hi Neil, > Toby Churchill have been running an internal project to compile a list > of gsm network operators and the relevant information such as MCC/MNC > codes, voicemail, balance check methods etc for use in a mobile-phone > enabled communication aid. > > We created an XML document for our use internally but have since come > across the the serviceprovider package which has a fair amount of > overlap. So it has been suggested that it may be worthwhile adding our > information with the serviceprovider list... > > Please find attached a patch (serviceprovider.2.tdt & > serviceprovider.xml) to extend the node to incorporate > and methods for a network provider. nice addition. Another missing piece is the MMS information. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: service-provider extension patch
Am Montag, den 24.05.2010, 16:54 +0100 schrieb Neil Williams: > Toby Churchill have been running an internal project to compile a list > of gsm network operators and the relevant information such as MCC/MNC > codes, voicemail, balance check methods etc for use in a mobile-phone > enabled communication aid. Wow, I think that's pretty cool stuff. Cheers, -- :M: ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
service-provider extension patch
Toby Churchill have been running an internal project to compile a list of gsm network operators and the relevant information such as MCC/MNC codes, voicemail, balance check methods etc for use in a mobile-phone enabled communication aid. We created an XML document for our use internally but have since come across the the serviceprovider package which has a fair amount of overlap. So it has been suggested that it may be worthwhile adding our information with the serviceprovider list... Please find attached a patch (serviceprovider.2.tdt & serviceprovider.xml) to extend the node to incorporate and methods for a network provider. Let me know if you think this information might be of use and worth adding to the serviceprovider package. http://www.toby-churchill.com/ -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ Index: serviceproviders.2.dtd === --- serviceproviders.2.dtd (revision 10747) +++ serviceproviders.2.dtd (revision 10870) @@ -6,13 +6,23 @@ - + + + + + + + + Index: serviceproviders.xml === --- serviceproviders.xml (revision 10747) +++ serviceproviders.xml (revision 10870) @@ -287,6 +287,11 @@ Telstra + +125111 +125 +*100# + 139.130.4.4 203.50.2.71 @@ -2017,6 +2022,16 @@ + Test Network + + + +dummy +dummy + + + + airtel vodaphone @@ -2039,6 +2054,11 @@ + 901 + +*#10# + + Contract o2web @@ -2079,6 +2099,12 @@ T-Mobile + 222 + +150 +150 +150 + User mms @@ -2102,6 +2128,11 @@ Vodafone + 121 + +*#1345# +2345 + Contract web @@ -2138,7 +2169,11 @@ - + 123 + +453 +150 + Contract orange @@ -2565,6 +2600,9 @@ O2 + +*#100# + Contract gprs @@ -4163,6 +4201,10 @@ Telenor + +220 +222 + 212.17.131.3 148.122.161.2 @@ -5100,6 +5142,10 @@ + +*111# +211 + Mobilt Internet @@ -5156,7 +5202,10 @@ - + +*120# +*121# + pgpLJYBvSo1qW.pgp Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
