[Bug 24910] GSM IMSI accessor

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24910

Senko Rasic <senko at senko.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Senko Rasic <senko at senko.net> 2010-04-30 07:54:23 PDT ---
(In reply to comment #2)
> Putting at least the SMSC on this interface too seems sensible?

Indeed, added MessageServiceCentre (renamed) from the original ring spec.

> The message validity period could conceivably apply to other protocols too, I suppose, but...
> 
> (Are those overrideable on individual SMSes?)

IMHO the message validity period could be useful enough for other protocols too
(IIRC there's supposed to be a XEP for this, too, but I can't find it ATM).
Also, the message validity period is actually per-message, so IMHO it makes
sense to put it in Channel.I.Messages.

OTOH, I wouldn't go so far as to create Connection.I.Messages just to put the
connection-default validity period there. So I propose that C.I.Cellular keeps
MessageValidityPeriod property.

Renamed SMS* to Message* since all of the properties could be applicable to
other cellular services as well, and not neccessarily be called SMS there
(though CDMA apparently calls SMS' SMS too).

Also tried to be more precise for MessageValidityPeriod - define units used (so
we're talking seconds, not eg. days), and outline possible limitations
(rounding, maximum timeout). I wouldn't go so far as to explicitly define
rounding and timeout, since we would be generalising on the basis of just one
data point (GSM SMS).

Updated branch is at:
http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/cellular

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.