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

From: [email-masked]
Date: Mon, 2 Sep 2002 19:42:40 +0300

Keith,

> 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".

draft-ietf-sip-message-06 states that the body can be of ANY MIME type:
"The body of the request will contain the message to be delivered.
   This body can be of any MIME type, including message/cpim."

Regards,
Krisztian

> 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: [email-masked]
Date: Mon, 2 Sep 2002 20:23:31 +0300

Hi Keith,

> With hindsight, I drafted the last paragraph of my original 
> message badly.
> 
> Rather than try to paraphrase again, I will select a direct 
> quote from the message draft abstract:
> 
> The MESSAGE method is an extension to the Session Initiation Protocol
>    (SIP) that allows the transfer of Instant Messages.  
> MESSAGE requests
>    carry the content in the form of MIME body parts.  
> 
> My concern is not over how such a body should be coded. The 
> questions is does such a usage to carry "Please top up your 
> units or your call may be terminated prematurely" qualify as 
> an Instant Message, i.e. is it within the semantics of 
> MESSAGE to perform this function.

The introduction part of the draft contains some "hint" about this:
"Instant messaging is defined as the exchange of content between a set
   of participants in near real time.  Generally, the content is short
   text messages, although that need not be the case."

Based on this, my guess is that carrying "Please top up your units or your call may be terminated prematurely" fits to the semantics of the MESSAGE request.

Regards,
Krisztian

> Keith
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 02 September 2002 17:43
> > To: [email-masked]; [email-masked]
> > Subject: RE: [Sip] use of MESSAGE method for passing display 
> > information
> > to the user
> > 
> > 
> > 
> > Keith,
> >

---

From: [email-masked]
Date: Tue, 3 Sep 2002 10:26:09 +0300

I guess it could be done that way, but you might find that others would prefer some sort of Notification package for this type of thing.

/Hisham

> From: ext Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, September 02, 2002 8:02 PM
> To: Kiss Krisztian (NRC/Tampere); Drage, Keith (Keith); [email-masked]

---

From: [email-masked]
Date: Tue, 3 Sep 2002 10:46:52 +0300

This application seems rather different from the presence type notifications because it seems these notifications are unsolicited. So to me MESSAGE seems like a perfect fit. I don't have to "subscribe" in order to receive instant messages either.

So by saying "Notification package" perhaps you mean a new MIME type specifically for these unsolicited notifications?

Cheers,
Aki

> From: ext [email-masked] 
> [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2002 10:26 AM
> To: [email-masked]; Kiss Krisztian (NRC/Tampere); [email-masked]
> I guess it could be done that way, but you might find that 
> others would prefer some sort of Notification package for 
> this type of thing.
> 
> /Hisham
>

---

From: [email-masked]
Date: Tue, 3 Sep 2002 11:48:33 +0300

You're not subscribing to get an instant message, you're subscribing to get information about your prepaid units.

Why is it unsolicited? 

/Hisham

> From: Niemi Aki (NET/Espoo) 
> Sent: Tuesday, September 03, 2002 10:47 AM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked]; Kiss Krisztian
> (NRC/Tampere); [email-masked]
> This application seems rather different from the presence 
> type notifications because it seems these notifications are 
> unsolicited. So to me MESSAGE seems like a perfect fit. I 
> don't have to "subscribe" in order to receive instant messages either.
> 
> So by saying "Notification package" perhaps you mean a new 
> MIME type specifically for these unsolicited notifications?
> 
> Cheers,
> Aki
>

---

From: [email-masked]
Date: Tue, 3 Sep 2002 11:56:44 +0300

Is it feasible to have that subscription state hanging around just in case you may some day run out of credit?

Cheers,
Aki

> From: Khartabil Hisham (NMP/Helsinki) 
> Sent: Tuesday, September 03, 2002 11:49 AM
> To: Niemi Aki (NET/Espoo); [email-masked]; Kiss Krisztian
> You're not subscribing to get an instant message, you're 
> subscribing to get information about your prepaid units.
> 
> Why is it unsolicited? 
> 
> /Hisham
>

---

From: [email-masked]
Date: Wed, 4 Sep 2002 13:18:23 +0300

> How useful can this be when I'm talking on the phone and I 
> get an Instant Message with text telling me that I'm running 
> out of credit? How often do you stop talking on the phone 
> just to read your SMS? 

At least my phone gives me an audible indication that a message has arrived. Especially while I'm using a hands-free set, I often read SMSs *while* I'm talking.

> The most likely scenario is that your 
> phone call will be cut short, then you go and read your IM 
> and only then you find out what the contents of the IM were.

Same as a user ignoring an in-band notification of low credit.
 
> I think this type of information should be conveyed by a 
> special tone that the phone plays or by a light going red of 
> the phone. Perhaps implementation specific. The point is that 
> we can't standardise that "your running out of credit" type 
> of IM MUST be rendered to the user.

Again, the phone can give you an audible tone when a message arrives. If its urgent, maybe the tone is a little louder...

> Having said that, I agree that MESSAGE is the choice if 
> contents of a request are to be rendered to a user. But if I, 
> as a phone manufacturer want my phone to flash a red light 
> when suck IM is received, then I can't.

Are you saying that a phone should have a red light for indicating low credit? If that same red light is used for anything else, you will anyway need to stop talking to determine exactly why it's blinking this time.

Perhaps this sort of functionality could be implemented using the Explode-Your-Phone header? ;-D

Cheers,
Aki