RE: on Messaging

Hi Zoltan,

On 22 ene 2013 at 17:06:57, EDUARDO FULLEA CARRERA wrote:
> Hi Zoltan,
>
> On 22 ene 2013 at 14:28:29, Kis, Zoltan wrote:
>> Hello,
>>
>> There was no answer on email below (please read).
>> Are we counting on discussing all these issues on a face to face meeting?
>> Nevertheless, I try pinging, since email discussion still makes sense
>> before f2f.
>> I have moved the Intel proposal for Messaging into the Messaging
>> directory, with the intention to align them as much as possible.
>>
>> Could we move forward with the Messaging specs as follows:
>> - agree on the structure of SMS, MMS and USSD messages
>
> I agree this is low hanging fruit at least for SMS and MMS, on whose
> necessity everybody seems to be clear. Let's start with it. I am working
> on a revised version of my proposal, which I will probably publish
> during this week.
>

I have already published a new version of the Messaging API draft, which is available at:
http://sysapps.github.com/sysapps/proposals/Messaging/Messaging.html


>> - agree on the methods for the above (send, receive, etc)
>
> Seems a reasonable next step.
>
>> - discuss adding the notion of messaging services (see below)
>> - discuss IM and group chat
>> - discuss email.
>>
>> The aim is to discuss all messaging types in this round, especially
>> from the converged messaging point of view brought up by Bryan. The
>> specs look complex, but in the end the use cases can be supported by
>> adding the notion of "messaging service" (which is a user account on a
>> given provider service, usually tied to a protocol or a set of
>> protocols), with which applications could support e.g. SMS over IP or
>> various message bridging solutions. The Intel proposal was designed
>> with these use cases in mind, and I would like to hear feedback
>> whether is it good enough, and simple enough.
>>
>> In the simplest case, this would just be an opaque identifier in the
>> methods (as in Telephony), but in Messaging this was not enough IMO,
>> and I needed to define a separate object for handling the use cases.
>> Ultimately, it was mainly because the different messaging services can
>> receive messages in parallel, but all incoming calls from all
>> telephony services compete for getting picked up, therefore need
>> central arbitration.
>>
>> I am open for alternative suggestions.
>>
>> Best regards,
>> Zoltan
>>

Best regards,
Eduardo.


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Thursday, 31 January 2013 09:23:24 UTC