Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03

[Jon Ingi <jii_ietf at skeyti.com>]

> At 9:36 AM +0100 8/9/06, Ben Last wrote:
>
> >   You can fit 140 bytes into an SMS, so
> >  there's not much room for more than a notification that events have
> >  occurred.  You can fit far more into an MMS (with all the cost
> >  implications)
SMS supports concatenation which allows the notification to be larger 
then 140 bytes.  This is required for MMS notifications which are sent 
over SMS and are usually are larger then 1 SMS, especially due to legacy 
issues with clients who did not support specific WSP tokens and 
therefore require string encoding of those tokens.  A MMS notification 
can contain the following (MMS version 1.3):

* transaction-id
* mms-version
* from address
* subject
* delivery-report flag
* storage flag
* message class
* priority
* message-size
* expiry value
* reply charging
* reply charging deadline
* reply charging size
* reply charging id
* distribution indicator
* element descriptor
* recommended retrieval mode
* recommended retrieval mode text
* application id
* reply application id
* aux application info
* content class
* drm content
* replace-id
* content-location

so as you can see a surprising amount of information is being squeezed 
in there over SMS  :-)  Most of this is optional and not used in any 
real deployment that I've seen.

Randall Gellens wrote:
> With MMS, generally a notification is sent to the client, with advice 
> from the server as to if the client should immediately retrieve the 
> message or defer it.  So to send notification of new mail over MMS 
> would be convoluted, since:
>     (1) new mail arrives at message store
>     (2) notification sent as MMS to client
>     (3) MMS arrives at server
>     (4) MMS server sends notification to client
>     (5) client brings up traffic channel and fetches MMS
and sends notification response to the MMS server which due to a design 
flaw in MMS forces the message store to be tightly coupled to MMS server 
configuration in the device.
>     (6) MMS client hands MMS to mail client
>     (7) mail client brings up traffic channel and fetches mail
>
> Whew!

I agree with others on this list that MMS is a poor choice for a 
notification protocol.  In that case it would be more logical to use MMS 
as the access protocol and skip IMAP  :-)

wr,
Jon Ingi


_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade