Lassi suggests SMSReducedCharacterSet be looked at as well for this spec.

Properties exposed by these interfaces:

 - SMSServiceCentre
Either Cellular/SMS-specific, or part of ServicePoint (Service_Point_Type_Unknown or add a new type).

 - SMSValidityPeriod
SMS-specific, for both Connections and Channels.  Made part of Cellular.

 - Flash
Required for regulatory reasons.  Boolean, and only necessary for a channel interface.  Not necessarily cell/SMS specific; could be thought of as an Emergency or Urgency-style property, and made part of Text (as a channel property) or ServicePoint as a point type (either adding a new SP type, or as Service_Point_Type_Emergency).

 - TargetMatch
This is not something that should be exposed to the client; it's the CM's job to figure out how to match channels based upon the protocol.  Also, as Rob pointed out, this is not just a problem w/ GSM; it's also an issue w/ SIP as well.  As such, it's beyond the scope of this bug.  Dropped.

(In reply to comment #2)
>  - SMSServiceCentre
> Either Cellular/SMS-specific, or part of ServicePoint
> (Service_Point_Type_Unknown or add a new type).

Decided that there's no need for this to be per-channel. It's already on Cellular, and if we need a way to override this in the future, it should be a message header. Binned.

>  - SMSValidityPeriod
> SMS-specific, for both Connections and Channels.  Made part of Cellular.

Indeed. Binned.

>  - Flash
> Required for regulatory reasons.  Boolean, and only necessary for a channel
> interface.  Not necessarily cell/SMS specific; could be thought of as an
> Emergency or Urgency-style property, and made part of Text (as a channel
> property) or ServicePoint as a point type (either adding a new SP type, or as
> Service_Point_Type_Emergency).

Here's a Channel.Interface.SMS with a single Flash boolean property: <http://people.freedesktop.org/~wjt/telepathy-spec-chan_iface_sms/spec/Channel_Interface_SMS.html>. While this is not necessarily cellular-specific, currently SMS is the only implemented protocol with this regulatory requirement, and having a single boolean makes writing the HandlerChannelFilter very straightforward.

>  - TargetMatch
> This is not something that should be exposed to the client; it's the CM's job
> to figure out how to match channels based upon the protocol.  Also, as Rob
> pointed out, this is not just a problem w/ GSM; it's also an issue w/ SIP as
> well.  As such, it's beyond the scope of this bug.  Dropped.

As it turns out, this property was not actually used in Maemo 5. The length of the string to match is region-specific, and matching is much easier if you have access to the user's full address book. (For instance, if you have a conflict, the UI could consider further characters until the conflict is resolved.)

So, dropped, and left up to the UI.

> +    tp:causes-havoc="literally incredible">

I appreciate the sentiment, but perhaps we should change this before merging it :-)

Other than that, override-smsc is r+ from me, and chan-iface-sms looks good as a draft.

(In reply to comment #1)
> Lassi suggests SMSReducedCharacterSet be looked at as well for this spec.

For the record, this is already on Conn.I.Cellular.

Strengthening smcv's review+ based on IRC:

11:45              wjt | smcv: any chance we could merge Flash as a non-draft?
11:45              wjt | smcv: it's been implemented and proven to work on the 
                         phone in my pocket :)
11:45             smcv | wjt: tbh ship it
11:46         Robot101 | I also shoulder-reviewed on the plane yesterday :)

Merged, will be in telepathy-spec 0.19.12.