Subject: RE: [Simple] 3GPP Messaging requirements

From: [email-masked]
Date: Wed, 22 Jan 2003 13:55:45 +0200

Hi Milt,

Thanks for the comments. Sorry for this late response.

[snip]

> First, I suggest changing the word "wireless" in the title
> to "3GPP" to more clearly reflect the contents of the ID.

OK.
 
> Section 3.2 Message Content Requirements
> Regarding the OPEN ISSUE on content sequencing.  The 
> sequencing of media in
> 3GPP messaging is currently handled by a subset of the Synchronized
> Multimedia Integration Language (SMIL).

That was my understanding as well. As far as I understand, SMIL descriptions are carried as normal MIME payload, so there doesn't seem to be any additional requirements to SIMPLE.
 
> As mentioned in Section 2, terminals are simple devices and 
> there is often a
> problem with terminals trying to exchange multimedia messages when the
> media support in thesender and recipient don't match up. There is a
> requirement that says:
> The recipient's network MUST be able to take into account
> the recipient's terminal capabilities and translate
> message content into a form that can be used on the 
> recipient's terminal.

The media transcoding issues were already directed elsewhere, I believe.
 
> NOTE: Although this isn't a protocol issue, there are a 
> minimum set of media
> formats that MUST be supported in all 3GPP messaging clients, 
> defined in
> 3GPP TS 26.140 and 3GPP TS 26.234.

This doesn't seem to be a SIMPLE requirement, but rather up to the 3GPP.
 
> Section 3.4 Message Delivery and Handling Requirements
> There is an additional 3GPP requirement that says:
> It MUST be possible for the UA be able to store immediate 
> messages in a
> persistent network-based message store and then to 
> subsequently retrieve,
> list, delete and forward immediate messages.
> 
> The statement of requirements for message filtering in section 3.4 is
> incomplete.  Some filtering criteria from the 3GPP 
> requirements were left
> off of the list.
> 
> The original wording of 3.4 says:
>    It MUST be possible to divert or block instant messages as 
> part of a
>    user configurable option.  Such mechanisms MUST support instant
>    message diversion based on sender address, message size, message
>    priority, message subject, message class and message content type.
>    The mechanism MAY support instant message diversion based on other
>    message properties.
> 
> The missing message filter criteria are message type and recipient's
> presence status.

I'll add the message type (meaning session or pager mode), but I'm not sure about the presence status of the recipient. It seems different from the other criteria, could you elaborate a bit? I don't see how the recipient's presence status as a criteria adds any requirements to the first, main requirement of "MUST be possible to divert or block". Is it an absolute criteria in fact, like based on "all messages"?

> There are also a number of required actions resulting from a filter
> match beyond divert and block. These are:
> 1)	Store the message content and notify recipient.
> 2)	Store the message content for a specific time or until 
> the recipient
> requests delivery.
> 3)	Store and push the message content to recipient when available.

Right, seems that I originally completely omitted all of these. I'll include them for the next version.  

> In the Normative References section, in addition to 3GPP TR 
> 22.940 the ID
> should also refer to 3GPP TS 23.340, "IMS Messaging Stage 1".

Will change that. Even though most (if not all) of the stuff is now covered in Jonathan's advanced IM I-D, I will update the 3GPP reqs for the sake of completeness. 

Thanks.

Cheers,
Aki
 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple