8:01 p.m.
---
TODO | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 3e8c91b..c27cec9 100644
--- a/TODO
+++ b/TODO
@@ -53,6 +53,17 @@ SMS
Priority: Low
Complexity: C2
+- Add support for setting the SMS Validity Period (3GPP 23.040). Currently the
+ value is hard coded as 24 hours.
+
+ Validity period can be given in three different formats
+ (Relative/Enhanced/Absolute), but support for Relative format (as currently
+ used in hard coded value as well) is comprehensive enough. Therefore Enhanced
+ and Absolute formats will not be supported unless later on so required.
+
+ Priority: Medium
+ Complexity: C1
+
SIM / SIM File system
=====================
--
1.7.0.4
8:47 p.m.
Hi Miia,
TODO | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 3e8c91b..c27cec9 100644
--- a/TODO
+++ b/TODO
@@ -53,6 +53,17 @@ SMS
Priority: Low
Complexity: C2
+- Add support for setting the SMS Validity Period (3GPP 23.040). Currently the
+ value is hard coded as 24 hours.
didn't we actually change this to be the maximum value?
Regards
Marcel
9:06 p.m.
Hi Marcel,
> +- Add support for setting the SMS Validity Period (3GPP
23.040). Currently the
> + value is hard coded as 24 hours.
didn't we actually change this to be the maximum value?
Only place I could find this to be edited was following line in
smsutil.c (3421)
template.submit.vp.relative = 0xA7; /* 24 Hours */
Have I missed something then?
In any case, I'd rather see the value something that API allows to set
instead of hard coded value, as user can have different needs for the
SMS validity period and sometimes it is not the best thing either that
period is set to maximum.
BR,
Miia
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
9:31 p.m.
Hi Miia,
> > +- Add support for setting the SMS Validity Period (3GPP
23.040). Currently the
> > + value is hard coded as 24 hours.
>
> didn't we actually change this to be the maximum value?
Only place I could find this to be edited was following line in
smsutil.c (3421)
template.submit.vp.relative = 0xA7; /* 24 Hours */
Have I missed something then?
In any case, I'd rather see the value something that API allows to set
instead of hard coded value, as user can have different needs for the
SMS validity period and sometimes it is not the best thing either that
period is set to maximum.
why does the user have different needs here? Where are these needs
coming from?
How does a normal user actually know what this means for him and the
network he is using? Is the network actually honoring these values at
all these days?
Regards
Marcel
10:23 p.m.
Hi Marcel,
2011/1/31 Marcel Holtmann <marcel(a)holtmann.org>:
How does a normal user actually know what this means for him and the
network he is using? Is the network actually honoring these values at
all these days?
These are not clear to me either, so I don't see the point in exposing
this setting over the D-Bus interface. I would, however, err on the
side of flexibility here, and make this a configuration option in
main.conf (once that support is available in oFono).
Cheers,
Aki
11:42 p.m.
Hi Aki,
> How does a normal user actually know what this means for him and
the
> network he is using? Is the network actually honoring these values at
> all these days?
These are not clear to me either, so I don't see the point in exposing
this setting over the D-Bus interface. I would, however, err on the
side of flexibility here, and make this a configuration option in
main.conf (once that support is available in oFono).
we did talk a bit about expected operator defaults especially in the
context of default character set etc. I think Portugal is such an
exception where you have to start out with a proper character set if
your SIM card is originated from there.
Maybe this is another one case where just picking a proper operator
default is better than actually providing any option to change it.
Regards
Marcel
7:19 a.m.
Hi Marcel,
On Mon, 2011-01-31 at 13:42 +0100, ext Marcel Holtmann wrote:
> > How does a normal user actually know what this means for
him and the
> > network he is using? Is the network actually honoring these values at
> > all these days?
>
> These are not clear to me either, so I don't see the point in exposing
> this setting over the D-Bus interface. I would, however, err on the
> side of flexibility here, and make this a configuration option in
> main.conf (once that support is available in oFono).
we did talk a bit about expected operator defaults especially in the
context of default character set etc. I think Portugal is such an
exception where you have to start out with a proper character set if
your SIM card is originated from there.
Maybe this is another one case where just picking a proper operator
default is better than actually providing any option to change it.
Yes, some of these language variants are mandated by certain regulators,
some by operators. So certainly the default SMS alphabet should be a
main.conf item.
Whether or not to provide a corresponding D-Bus property is then a
separate question. Neither the validity period nor the alphabet strike
me as ones desperately needing a property, but especially the alphabet
might actually need one since it has such nasty backwards compatibility
issues.
Cheers,
Aki
5:52 p.m.
Hi Aki,
> > > How does a normal user actually know what this means
for him and the
> > > network he is using? Is the network actually honoring these values at
> > > all these days?
> >
> > These are not clear to me either, so I don't see the point in exposing
> > this setting over the D-Bus interface. I would, however, err on the
> > side of flexibility here, and make this a configuration option in
> > main.conf (once that support is available in oFono).
>
> we did talk a bit about expected operator defaults especially in the
> context of default character set etc. I think Portugal is such an
> exception where you have to start out with a proper character set if
> your SIM card is originated from there.
>
> Maybe this is another one case where just picking a proper operator
> default is better than actually providing any option to change it.
Yes, some of these language variants are mandated by certain regulators,
some by operators. So certainly the default SMS alphabet should be a
main.conf item.
I don't think that main.conf is really what you want here. If I
understand this requirement correctly, then the defaults have to be
picked based on the SIM card you put into the device. You don't really
wanna build country or operator specific main.conf and ship different
software core software to every single operator.
So I think we need to approach this a little bit different to make it
easy to handle and also easy to update if needed while still having the
same distribution running on every device no matter what country it
actually got manufactured for. And with GSM we are in the lucky position
that every single SIM card has its MCC and MNC. My idea is that we go
with sensible operator defaults here.
My idea is to have /usr/lib/ofono/defaults/ directory where we can store
a set of proper default values with operator variants. So any builtin
default could be easily overwritten this way. An example would be to
have a sms.conf file here.
[bearer]
default=cs-preferred
262=ps-preferred
26202=ps-only
[charset]
...
This way the atom could come in and read this file for a new SIM card
and automatically set sensible defaults. And if not present we just use
the hardcoded builtin defaults.
And we can keep this minimal since there will be only so many exceptions
to the default here. The other advantage is that this can actually be
maintained outside of oFono by the device manufacturer. In the end these
might be all so trivial that we can just ship them with oFono directly.
Regards
Marcel
11:27 p.m.
Hi Marcel,
why does the user have different needs here? Where are these needs
coming from?
You want real life user cases? :)
OK, I give you some. Personally nr 1 is my favourite one as that is such a
common thing to happen.
1) Have you ever been drunk and written stupid messages you really don't
want to reach their destination the next day anymore if they have not
already (maybe you wish they never would have reached the destination
but all the mistakes can't be prevented..)
2) You have a situation that you want to buy something important and
there are two options of which you prefer other one. You can not reach
the guy with preferred option via call so you send a message, but you
want to be sure that you know the situation before the other offer
closes. Of course the preferred option's seller expects you to make the
commitment right away for purchase so text message can not be sent in
vain.
3) Example from the wonderful world of Internet:
http://www.developershome.com/sms/sms_tutorial.asp?page=basicConcepts
How does a normal user actually know what this means for him and the
network he is using?
The normal user knows this by reading the manual if he does
not
understand it directly when seeing the setting in the device. And if
there is a chance that network does not support all features that device
can offer, a disclaimer about that can be added to manual or help files.
Is the network actually honoring these values at
all these days
Whether the network is honoring this case or not is not the issue
here.
If such would be the reason for dropping features then many things would
never get completed when people would just discuss who should do what
first. I have not met a situation at least in Finland where network does not
support it, but I have not made comprehensive study about this. If the
network does not follow the request then that is a network issue and should
be handled through other channels. The truth is that if oFono does not allow
this setting through the API, then devices using oFono have no means to
offer this choice to its users even if the network would support it.
One more thing, Meego also has a requirement about this in Featurezilla:
Feature 4564 - [FEA] Cellular - SMS Validity period
BR,
Miia
______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
11:52 p.m.
Hi Miia,
> why does the user have different needs here? Where are these
needs
> coming from?
You want real life user cases? :)
OK, I give you some. Personally nr 1 is my favourite one as that is such a
common thing to happen.
1) Have you ever been drunk and written stupid messages you really don't
want to reach their destination the next day anymore if they have not
already (maybe you wish they never would have reached the destination
but all the mistakes can't be prevented..)
2) You have a situation that you want to buy something important and
there are two options of which you prefer other one. You can not reach
the guy with preferred option via call so you send a message, but you
want to be sure that you know the situation before the other offer
closes. Of course the preferred option's seller expects you to make the
commitment right away for purchase so text message can not be sent in
vain.
3) Example from the wonderful world of Internet:
http://www.developershome.com/sms/sms_tutorial.asp?page=basicConcepts
and what does this all buy you? There are so many funny ideas in GSM
that having nothing to do with reality anymore since the world has moved
on since 1995.
> How does a normal user actually know what this means for him and
the
> network he is using?
The normal user knows this by reading the manual if he does not
understand it directly when seeing the setting in the device. And if
there is a chance that network does not support all features that device
can offer, a disclaimer about that can be added to manual or help files.
This is the worst explanation ever. You might wanna talk to some user
interaction experts. They will tell you that they do exactly not want
this in a mobile device. It needs to self explanatory and your are not
suppose to read 600 pages of manual first.
I feel like being back in 1995 with my good old Nokia phone where I had
no clue what half of the options where doing for me ;)
> Is the network actually honoring these values at
> all these days
Whether the network is honoring this case or not is not the issue here.
If such would be the reason for dropping features then many things would
never get completed when people would just discuss who should do what
first. I have not met a situation at least in Finland where network does not
support it, but I have not made comprehensive study about this. If the
network does not follow the request then that is a network issue and should
be handled through other channels. The truth is that if oFono does not allow
this setting through the API, then devices using oFono have no means to
offer this choice to its users even if the network would support it.
And what would be the impact here with defaulting to the networks value?
It would just work fine and normally it all depends on the network
anyway. You can tell it to have 24 hours, but if it only wants to hold
it for 6 hours, then there is nothing you can do about. SMS is not a
reliable form of communication. I am pretty sure that all the terms of
service regarding SMS are phrased properly by the network operators.
Regards
Marcel
1:54 a.m.
Hi Marcel,
and what does this all buy you? There are so many funny ideas in GSM
that having nothing to do with reality anymore since the world has moved
on since 1995.
First of all, I don't think people stopped drinking and sending
stupid
messages after 1995. Or that no one does any personal commerce with
questionable means any more. Are simple needs of a normal individual
funny? I guess many of them are but still it always feels nice when you
are able to get your needs met even if for someone else your need might
not make sense. Not everyone wants same things.
Of course if the aim here is to do an API that already decides in the
lower level the options for the device manufacturers so they don't need
to bother themselves with business decisions, then this is the way to
go. Good luck with serving people-of-today who value options and freedom
of choice. In the end, oFono is not providing the UI, if the device
manufacturer does not want its users to have the option to change the
validity period then they can omit the feature. But if this kind of
features are not supported even in the oFono level, then what purpose
does that serve?
This is the worst explanation ever. You might wanna talk to some
user
interaction experts. They will tell you that they do exactly not want
this in a mobile device. It needs to self explanatory and your are not
suppose to read 600 pages of manual first.
A user interaction expert would be
clever enough hide the menu for the
setting when it is not supported by the network. There are so many
decisions that UI guys can do to make the feature self explainable. So I
don't think it is required to drop the features only for the reason that
maybe some networks don't support it.
I feel like being back in 1995 with my good old Nokia phone where I
had
no clue what half of the options where doing for me ;)
Come on! :D Here we can go
back to the fact that not everything must be
used that is available if you feel content as you are.
And what would be the impact here with defaulting to the networks
value?
It would just work fine and normally it all depends on the network
anyway. You can tell it to have 24 hours, but if it only wants to hold
it for 6 hours, then there is nothing you can do about. SMS is not a
reliable form of communication. I am pretty sure that all the terms of
service regarding SMS are phrased properly by the network operators.
What comes to
SMS not being reliable, can you honestly say that you are
working to make a better phone but the features you support are not to
trust? Anyway, even if the user can not do anything to the value when
network does not support the setting, then is that enough reason to deny
the option from everyone?
I know these are small issues in some level, but I still go for the
right to choose.
BR,
Miia
______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
2:44 a.m.
Hi Miia,
> and what does this all buy you? There are so many funny ideas in
GSM
> that having nothing to do with reality anymore since the world has moved
> on since 1995.
First of all, I don't think people stopped drinking and sending stupid
messages after 1995. Or that no one does any personal commerce with
questionable means any more. Are simple needs of a normal individual
funny? I guess many of them are but still it always feels nice when you
are able to get your needs met even if for someone else your need might
not make sense. Not everyone wants same things.
Of course if the aim here is to do an API that already decides in the
lower level the options for the device manufacturers so they don't need
to bother themselves with business decisions, then this is the way to
go. Good luck with serving people-of-today who value options and freedom
of choice. In the end, oFono is not providing the UI, if the device
manufacturer does not want its users to have the option to change the
validity period then they can omit the feature. But if this kind of
features are not supported even in the oFono level, then what purpose
does that serve?
there is no point in supporting some dreamed up use case that you are
making up right now. You have no control over your SMS once it leaves
your mobile phone and got accepted by the network for submission. No
weird option is going to make this any better.
There is no control if the receiver has their mobile phone on or off.
And there is certainly no control over when the network will deliver the
SMS.
Same as you can not recall an email once it got delivered to the
receivers inbox. This is all just a wet dream ;)
> This is the worst explanation ever. You might wanna talk to some
user
> interaction experts. They will tell you that they do exactly not want
> this in a mobile device. It needs to self explanatory and your are not
> suppose to read 600 pages of manual first.
A user interaction expert would be clever enough hide the menu for the
setting when it is not supported by the network. There are so many
decisions that UI guys can do to make the feature self explainable. So I
don't think it is required to drop the features only for the reason that
maybe some networks don't support it.
oFono's API is clearly about what makes sense to be exposed to the
actual user. It was never and will never be about adding any kind of
feature that you can dream of in the GSM world.
Until you really make a good case why the user should be exposed to such
an option, I don't see it.
So I am clearly in favor of sensible defaults here. But that is a
different story.
> I feel like being back in 1995 with my good old Nokia phone
where I had
> no clue what half of the options where doing for me ;)
Come on! :D Here we can go back to the fact that not everything must be
used that is available if you feel content as you are.
Actually exposing things that can not be used or the end user can not
make sense of is a pretty bad idea.
> And what would be the impact here with defaulting to the
networks value?
> It would just work fine and normally it all depends on the network
> anyway. You can tell it to have 24 hours, but if it only wants to hold
> it for 6 hours, then there is nothing you can do about. SMS is not a
> reliable form of communication. I am pretty sure that all the terms of
> service regarding SMS are phrased properly by the network operators.
What comes to SMS not being reliable, can you honestly say that you are
working to make a better phone but the features you support are not to
trust? Anyway, even if the user can not do anything to the value when
network does not support the setting, then is that enough reason to deny
the option from everyone?
I am not following here. What is an option good for if it does not give
anything to the user. In fact it could potentially be actually lying to
the user since we have no control whatsoever.
But hey, let me ask you this part. When did you ever changed that option
on your smartphone the last time. Maybe my last phone that had such an
option was the Nokia 6210 with the Bluetooth battery pack and even back
then it did not make sense to me.
Regards
Marcel
12:01 a.m.
Hi Marcel,
Seems that you are not going to go with me on this. I do understand your
point that this is very marginal feature, me myself I only use it couple
times a year (which also answers to your question) and I might be in a
rare group. But I do appreciate the feature when I need it.
I am not following here. What is an option good for if it does not
give
anything to the user. In fact it could potentially be actually lying to
the user since we have no control whatsoever.
What I meant was that if the network
does not support the setting, then
it could be hidden from the UI. Then there would not be scenario that
user has option that does nothing. I understand from the specification
(23.040) that this should be possible to know:
"The SC shall reject any Unsupported/ Reserved values received by
returning the ‘TP-VP not supported’ TP-FCS value in the Submit SM Report
for RP-Error."
But when it comes to this SMS Validity Period being supported in oFono,
I guess we are done. I asked for it and gave my arguments but you said
no. I don't find I am able to do more to this for now at least.
BR,
Miia
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
4246
days inactive
4248
days old
12 comments
5 participants
participants (5)
-
Aki Niemi -
Aki Niemi -
Marcel Holtmann -
Miia Leinonen -
Miia.Leinonen＠tieto.com