Subject: RE: [Sip] use of MESSAGE method for passing display information t o the user

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 5 Sep 2002 11:44:06 +0100

To summarize what I understand so far from the responses.

1)	Where the information is not semantically understood by the UA, but is simply rendered to the user, then MESSAGE method is appropriate. (This is the old ISDN definition of stimulus.) Where it is sent in the context of an existing dialog by an intermediate entity between the two endpoints, that intermediate entity would have to be a B2BUA. The current 3GPP requirements we are trying to address is this one.

2)	Where the information is to be semantically understood by the UA, before it is rendered to the user (e.g. to light an appropriate lamp, or flash an appropriate ikon on a display) then an Event package with the information carried in NOTIFY would be appropriate. (This is the old ISDN definition of functional.) This would require prior UA subscription to the package, which in my opinion is not unreasonable, as the terminal subscribes to packages that match its display or other characteristics.

3)	Nobody is proposing that these methods do not support this capability, or suggesting we need to go away and work on new methods (via SIPPING then SIP).

Thanks for your assistance.

Keith

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: 03 September 2002 17:09
> To: Drage, Keith (Keith)
> Cc: [email-masked]'
> Subject: Re: [Sip] use of MESSAGE method for passing display 
> information
> to the user
> 
> 
> This seems to me to be an entirely appropriate use of page 
> mode MESSAGE. 
> Specifically, I would interpret a message, sent by an 
> automaton, that is 
> intended to be rendered for and interpreted by a human being 
> in a timely 
> manner, to fall into the category of "instant message."
> 
> 
> 
> Drage, Keith (Keith) wrote:
> > Within 3GPP, there is a requirement for intermediate 
> servers to pass textual information for display to the user. 
> This may be related to a dialog or not.
> > 
> > A typical example may be (in the case of a prepay user):
> > 
> > "Please top up your units or your call may be terminated 
> prematurely".
> > 
> > There are a number of methods that are defined which 
> essentially convey body information between User Agents 
> (INFO, NOTIFY, MESSAGE, PUBLISH?).
> > 
> > Some of these would appear more suitable that others for 
> passing this information. 
> > 
> > Of the existing methods, MESSAGE would appear to be the 
> most suitable (and indeed is the one selected by some of the 
> experts involved). However the internet draft specifically 
> talks about the body being an "Instant Message".
> > 
> > Rather than get into a situation similar to that which 
> affects INFO (i.e. people seem to have implemented various 
> applications on INFO and IETF experts say INFO is not 
> appropriate for that application), could I request an 
> exchange of views on the applicability or not of MESSAGE for 
> this type of information, and if not, what solution would 
> otherwise be suggested.
> > 
> > Note that the information would normally be expected to 
> come from some network based entity (acting as a UA). When 
> related to a dialog, the source may well be some B2BUA 
> between the two end UAs involved in the dialog.
> > 
> > Keith Drage
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> > 
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 16:40:38 -0400

I concur on all points below. I just want to add a few sentences of 
motivation, inline:

Drage, Keith (Keith) wrote:
 > 1)	Where the information is not semantically understood by the UA,
 > but is simply rendered to the user, then MESSAGE method is
 > appropriate. (This is the old ISDN definition of stimulus.)

Correct.

 > Where it
 > is sent in the context of an existing dialog by an intermediate
 > entity between the two endpoints, that intermediate entity would have
 > to be a B2BUA. The current 3GPP requirements we are trying to address
 > is this one.

Right.

 >
 > 2)	Where the information is to be semantically understood by the UA,
 > before it is rendered to the user (e.g. to light an appropriate lamp,
 > or flash an appropriate ikon on a display) then an Event package with
 > the information carried in NOTIFY would be appropriate. (This is the
 > old ISDN definition of functional.) This would require prior UA
 > subscription to the package, which in my opinion is not unreasonable,
 > as the terminal subscribes to packages that match its display or
 > other characteristics.

Exactly. It makes no sense to send information to an automata unless you 
know it can process it, and is ready and interested in receiving it. A 
package provides all of that, and allows you to negotiate the types, for 
example.

For a message meant for a human, you can be more flexible. Even if they 
device can't render the type, the human is smart enough to do something 
about it - download a new renderer, or forward it to their email 
account, or ask someone for help, or whatever. Humans are also better at 
understanding whether a message that is receivd late (because it was 
stored in a message store as the user was offline when it was sent) is 
still useful or not. An automata cannot easily make this judgement, and 
so storage of things like notifications to an automata (for message 
waiting, for example), make less sense to me.

-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