Subject: RE: [Simple] 3GPP Messaging requirements

From: [email-masked]
Date: Sun, 17 Nov 2002 20:47:06 +0200

Hi Jonathan,

Thanks for your comments. I've got some inline.

[...]
> This is a good collection of requirements. As you know, I 
> think most of 
> them are addressed already. A few comments on some of them:

I agree. I think from the 3GPP point of view, they just like to keep a comprehensive list of their requirements in this I-D. But we definitely should focus on the ones which do not seem to be covered already. 

> > It MUST be possible to use a single address to identify the 
> recipient
> >    or sender of an instant message or a member in a message session,
> >    irrespective of the messaging system.
> 
> I wasn't sure what to make of this requirement. Is this asking for 
> something new from SIP? You can put whatever kind of address you want 
> into the From field of a MESSAGE request or an INVITE to set 
> up a session...

The original requirements were pretty vague, so my interpretation was that this was actually requiring CPIM compliance. The other requirement is for using E.164 numbers. So nothing new there I think. Both are already enabled.
 
> >  Additionally, it MUST be possible to send the entire 
> message body, or
> >    parts of the body in a way that allows the recipient to choose
> >    between receiv�ng the body and ignoring it.
> 
> parts of the body? What does that mean? Do you mean I can ask 
> to receive 
> the top half of a jpeg only? I hope not.

No, simply if there is a MIME multipart body. This is poor wording from my part. It probably should say parts of the payload instead of body.

> If you are just talking about receiving parts on a 
> body-by-body basis, 
> clearly indirection is the right solution for this.

Definitely, CI was what we were also thinking of.

> > 3.3 Data Manipulation and Management Requirements
> 
> I suspect all of these will be met by the conference control protocol 
> work going on in sipping.

Yes, that seems to be the best home for these requirements.

> > 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.
> 
> what is message class?

The 3GPP documents define message class as being e.g., advertisement, announcement, personal, and so on. Frankly I had trouble with this as well, since message class is obviously not available currently in SIP, so I was doubtful as to whether this is actually a protocol issue at all. There may actually be a hidden requirement here, something like:

	There MUST be a mechanism available by which the sender of 
	an instant message can set a specific class for the message.
	Possible classes could be 'advertisement', for commercial 
	messages, and 'personal' for messages intended for personal
	consumption.

Either this, or the message diversion could also depend on an implementation specific mechanism for grouping messages to classes.

(I'm well aware of the futility of the message class type mechanisms, and I'm not expecting spammers to actually mark their messages as spam...)

> > It is proposed that the SIMPLE Working Group evaluates the
> >    requirements presented in this document and incorporates 
> the relevant
> >    ones in its current work items.  Those requirements 
> possibly falling
> >    out of the scope of the SIMPLE WG should find a more 
> suitable home,
> >    possibly also in other standardization bodies.
> 
> As I commented at the last IETF, I would propose that those 
> requirements 
> which do belong to SIMPLE get folded into our general work item on 
> advanced IM requirements.

I agree. But just to have the complete list available, I'll keep updating this document. And keep track of the requirements and where they end up.

Cheers,
Aki
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 01:02:21 -0500

inline.

[email-masked] wrote:

 >
 >>> 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.
 >>
 >> what is message class?
 >
 >
 > The 3GPP documents define message class as being e.g., advertisement,
 > announcement, personal, and so on. Frankly I had trouble with this as
 > well, since message class is obviously not available currently in
 > SIP, so I was doubtful as to whether this is actually a protocol
 > issue at all. There may actually be a hidden requirement here,
 > something like:
 >
 > There MUST be a mechanism available by which the sender of an instant
 > message can set a specific class for the message. Possible classes
 > could be 'advertisement', for commercial messages, and 'personal' for
 > messages intended for personal consumption.
 >
 > Either this, or the message diversion could also depend on an
 > implementation specific mechanism for grouping messages to classes.
 >
 > (I'm well aware of the futility of the message class type mechanisms,
 > and I'm not expecting spammers to actually mark their messages as
 > spam...)

Thats the problem exactly. The Priority header does exist, and plays a 
similar role. But, like class, you can't do much with it beyond 
rendering to the user.

Another problem with class is determining the enumerated set of what 
classes there can be...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com