Re: service-provider extension patch

[Dan Williams <dcbw redhat com>]

On Tue, 2010-05-25 at 10:37 +0100, Neil Williams wrote:
> On Mon, 24 May 2010 16:46:34 -0700
> Dan Williams <dcbw redhat com> 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 <gsm> node to incorporate
> > > <voicemail> and <balance-check> methods for a network provider. 
> 
> > - When two <dtmf> 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 <ussd> be used, and when would
> > <ussd-response> be used?
> 
> <ussd> is fire and forget.
> <ussd-response> 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 <sms> 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 <name> and <desc> subelements to give
users some help here too.

That would mean changing the format a bit though to something more like:

<voicemail dtmf="901">
    <name xml:lang="de">asdfadfadf</name>
    <desc xml:lang="de">Blah Blah</desc>
</voicemail>

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 <sms></sms> 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