Subject: [Sip] MESSAGE for rendering

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Dec 2007 12:27:52 -0500

Regarding the INFO use-case discussion, one comment from people is MESSAGE is really for things to be rendered to the user, and not for such things as vcards or vcalendars.  Not that I want to contradict myself on it being a valid use-case for INFO, but personally I'm not so sure that vcard/vcalendar is wrong for MESSAGE.  I mean we can argue if sending that type of data is really justification for an "Instant Message" request, but I'm talking more about whether content that isn't directly rendered to the user can be put into MESSAGE.

In some ways a vcard/vcalendar *is* being rendered to the user - it's just that by definition the content type is formatted in a vcard or vcalendar format and needs to be interpreted, if the app understands it.  Just as, for example, a MESSAGE can contain message/cpim when we don't really expect to visibly render the message/cpim headers without interpretation.

It just so happens that some applications know a vcard/vcalendar type content can be integrated into their contact or calendar program, and bypass "rendering" it directly to the user in visible form.  From a SIP protocol perspective it is still user "data" for "rendering".

-hadriel

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Dec 2007 16:54:19 -0500

Hadriel,

I am entirely with you if the *intent* of sending the vcard is to render 
it to the user in some human readable way. Its hardly any different from 
sending HTML.

Its much more questionable if the intent is that the vcard be filed in 
the recipients address book without being rendered.

Even so, I think it is an open question whether content-dispositions 
other than "render" are valid with MESSAGE. And if so, which ones?

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Dec 2007 18:09:22 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, December 14, 2007 4:54 PM
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [Sip] MESSAGE for rendering
>
> Hadriel,
>

I guess the question is if "render" is synonymous with "inline", as 3261 sounds like it is?  If so, then I think you're right "render" is wrong.  How is it done in email?  I think content-disposition "attachment" vs. inline.  So yeah, the question is if MESSAGE can handle non-render ones.  (clearly "session" would NOT be valid :)

-hadriel

---

From: [email-masked]
Date: Fri, 14 Dec 2007 18:27:45 -0500

From: Paul Kyzivat <[email-masked]>

IMHO, filing information is as good as actually rendering it.  The
real question is layering -- "render" means "deliver to the layer
above the SIP UA".  Anything that partakes of media is "rendered" and
is acceptable for MESSAGE, anything that partakes of signaling is not
"rendered" and is acceptable for INFO.

One criterion is "Would it make sense to let the user arbitrarily
re-route where this information goes?"  With a vcard, it makes sense.
With the information INFO was intended to carry, it does not:

   RFC 2976 1.1 Example Uses

      The following are a few of the potential uses of the INFO message:

      - Carrying mid-call PSTN signaling messages between PSTN
        gateways.

      - Carrying DTMF digits generated during a SIP session.

      - Carrying wireless signal strength information in support of
        wireless mobility applications.

      - Carrying account balance information.
	[in a pay-as-you-go network -- DRW]

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Dec 2007 18:34:29 -0500

More importantly MESSAGE allows out-of-dialog requests.  :)
I was thinking the same as you, but I believe Paul's right in that render=inline and vcard/vcalendar are not inline.  The question is if we want to let "attachment" disposition be allowed.  I dread to do that, because people are already using MESSAGE to transfer 10MB images, but that's a separate ugly problem. :(

-hadriel

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 14, 2007 6:28 PM
> To: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Dec 2007 19:03:10 -0500

Hadriel Kaplan wrote:
> I guess the question is if "render" is synonymous with "inline", as 3261 sounds like it is? 

I'm not very well informed of MIME, but I question whether "render" is 
synononymous with "inline". Rather I suspect "render" was chosen because 
"inline" didn't make sense for SIP.

My impression is that with mail "inline" is used for "extra" body parts 
to indicate that they should be rendered "inline" with the rendering of 
the overall message, which makes sense since for mail the expectation is 
that the overall message *is* being rendered. So the headers of the 
message are rendered (usually not literally, but rather in a pretty 
way), and the body parts marked inline are rendered inline with that.

In the case of sip, the overall message is *not* being rendered, at 
least not in the case of INVITE. (At the time this was being defined 
MESSAGE wasn't in the picture.)

If "render" were used with a body part in an invite, then I think it 
makes sense to expect that the UA goes out of its way to present it to 
the user of the device in some way - unusual because most invites don't 
have this.

If somebody had thought about it at the time, MESSAGE should probably 
have been handled just like mail, using "inline" and "attachment", etc. 
But I guess for purposes of MESSAGE we might be able to treat inline and 
render as synonymous.

> If so, then I think you're right "render" is wrong.  How is it done in email?  I think content-disposition "attachment" vs. inline.  So yeah, the question is if MESSAGE can handle non-render ones.  (clearly "session" would NOT be valid :)

Attachment could be good for a vcard in a MESSAGE. But it might be a bit 
strange without also having an inline or render part as well. (Just as 
it would be strange to get an email that only had "attachment" parts - 
there is nothing to attach them to.)

So you might have a MESSAGE that says: "Here is my vcard." and has the 
vcard as an attachment.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Dec 2007 19:08:56 -0500

[email-masked] wrote:
> above the SIP UA". 

Does it? Lots of things could mean that. E.g. "inline" and "attachment" 
could mean that too. If the "layer above the sip ua" can get these 
things with different dispositions then we have simply passed the buck 
on what it means.

I *think* each different type of sip message needs to define the content 
dispositions that are valid with it and what they mean for it.

> Anything that partakes of media is "rendered" and

I don't understand the above.

> With the information INFO was intended to carry, it does not:

I'm not certain I understand that either, or to the extent I do I don't 
know how to operationalize it.

> 	[in a pay-as-you-go network -- DRW]

Balance, and maybe signal strength, could also be usefully rendered to 
the user.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Dec 2007 19:11:21 -0500

> I was thinking the same as you, but I believe Paul's right in that render=inline and vcard/vcalendar are not inline.  The question is if we want to let "attachment" disposition be allowed.  I dread…

I'm thinking that the body of a MESSAGE ought to allow almost all the 
same things, with the same meanings, as the body of an MSRP message.

BUT it should be strictly limited in the overall size it can be. If what 
you want to send won't fit in a MESSAGE then switch to MSRP.

	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 18 Dec 2007 21:05:34 +0200

Hi Paul,

just to add another example to this discussion (same as the vcard example):
an application/im-iscomposing+xml content-type can be put in the body of 
a SIP MESSAGE and it is not (or it is not supposed to be) rendered
as is to the recipient; an application that understood it would render 
it in whatever way it indicates that a user is in the process of 
composing a message.

/Sal

Paul Kyzivat wrote:
>> I was thinking the same as you, but I believe Paul's right in that 
>> render=inline and vcard/vcalendar are not inline.  The question is if 
>> we want to let "attachment" disposition be allowed.  I dread to do 
>> that, because people are already using MESSAGE to transfer 10MB 
>> images, but that's a separate ugly problem. :(
>
> BUT it should be strictly limited in the overall size it can be. If 
> what you want to send won't fit in a MESSAGE then switch to MSRP.
>
>     Paul
>
>> -hadriel
>>
>>

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Dec 2007 16:31:48 -0600

On Dec 18, 2007, at 1:05 PM, Salvatore Loreto wrote:

> an application/im-iscomposing+xml content-type can be put in the  
> body of a SIP MESSAGE and it is not (or it is not supposed to be)  
> rendered
> as is to the recipient; an application that understood it would  
> render it in whatever way it indicates that a user is in the  
> process of composing a message.
>

Okay, I'm now completely convinced that most uses of MESSAGE are  
really candidates for the new INFO events.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Dec 2007 18:33:43 -0500

I think application/im-iscomposing+xml IS rendered; and its rendering 
causes the UI to show that the user is typing.

As a litmus test for this stuff, a question is whether it can reasonably 
be converted to a text/plain content and sent in a MESSAGE, and if it is 
rendered, is the resulting behavior reasonable. For the iscomposing 
indicators, I think you could. You could instead send a text IM like 
"Joe is typing a reply..." and render that, and this would achieve the 
same objective.

Also, I would not want to send iscomposing over the SIP dialog - I think 
it should be on the media path. There will be a LOT of them, and there 
is a requirement for timeliness. See my other note on the criteria for 
sending something in dialog vs. along the media path.

-Jonathan R.

Dean Willis wrote:
>> an application/im-iscomposing+xml content-type can be put in the body 
>> of a SIP MESSAGE and it is not (or it is not supposed to be) rendered
> Okay, I'm now completely convinced that most uses of MESSAGE are really 
> candidates for the new INFO events.
> 
> -- 
> Dean
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Dec 2007 19:07:19 -0500

I agree with Jonathan re the rendering.

Regarding suitability of using MESSAGE in a sip dialog for this, I think 
its suitability for this is no better or worse than for sending the 
actual text itself. I suppose the is-typing functionality increases the 
number of messages used by roughly a factor of two. If you thought 
MESSAGE was suitable without this, then you might still think it is 
suitable with it.

Its probably not a good example. The point is that rendering doesn't 
necessarily mean literal rendering of communicated text. E.g. you could 
send some MIDI encoding and have it rendered audibly.

	Paul

Jonathan Rosenberg wrote:
>>> render it in whatever way it indicates that a user is in the process 
>>> of composing a message.
>>>
>>

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Dec 2007 23:21:02 -0600

On Dec 18, 2007, at 5:33 PM, Jonathan Rosenberg wrote:

> I think application/im-iscomposing+xml IS rendered; and its  
> rendering causes the UI to show that the user is typing.
>

I think INVITE is rendered, and its rendering causes the uses phone  
to make a ringing nose that causes the user to press a button that  
causes a new message to be sent.

> As a litmus test for this stuff, a question is whether it can  
> reasonably be converted to a text/plain content and sent in a  
> MESSAGE, and if it is rendered, is the resulting behavior  
> reasonable. For the iscomposing indicators, I think you could. You  
> could instead send a text IM like "Joe is typing a reply..." and  
> render that, and this would achieve the same objective.

If you displayed the current iscomposing object on  the screen, I'm  
afraid you'd just confuse my mom. It's not just text.

Before you send it, you really need to know that the other end  
understands what you mean. That's the crux of what is wrong with INFO  
today.

> Also, I would not want to send iscomposing over the SIP dialog - I  
> think it should be on the media path. There will be a LOT of them,  
> and there is a requirement for timeliness. See my other note on the  
> criteria for sending something in dialog vs. along the media path.
>

Well, that's reasonable, but we have what we have, and that's a SIP  
message for iscomposing, and probably some IPR on that too.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Dec 2007 07:59:21 -0500

Dean Willis wrote:
> I think INVITE is rendered, and its rendering causes the uses phone to 
> make a ringing nose that causes the user to press a button that causes a 
> new message to be sent.
> 
>> reasonably be converted to a text/plain content and sent in a MESSAGE, 
>> and if it is rendered, is the resulting behavior reasonable. For the 
>> iscomposing indicators, I think you could. You could instead send a 
>> text IM like "Joe is typing a reply..." and render that, and this 
>> would achieve the same objective.
> 

Do you think its ok for the message to contain html?

If you rendered html text directly it would also confuse your mom.

Whatever is sent is just an *encoding* that must be translated into a 
meaningful rendering for the recipient.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 Dec 2007 07:50:38 -0600

> Do you think its ok for the message to contain html?

That's actually debatable.

HTML at least has relatively standard "rendering"  -- XML, especially  
in the absence of some kind of style sheet, doesn't.

> If you rendered html text directly it would also confuse your mom.

True. It would be nice to make sue her UA supports HTML before  
sending it to her, wouldn't it?

But at least here (this use of MESSAGE) we have an existing way to  
say "I don't support that MIME type in a render-to-user context",  
which may be adequate. That does put is in a better position than we  
were with INFO.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 Dec 2007 23:40:59 -0600

Not that I like responding to my incoherent posts, but this one totally 
failed to make sense. I've got to stop posting after midnight and before 
noon.

Dean Willis mumbled:
> True. It would be nice to make sue her UA supports HTML before  sending 

That's "make sure her UA supports HTML before sending it" . . .

> it to her, wouldn't it?
> 
> But at least here (this use of MESSAGE) we have an existing way to  say 
> "I don't support that MIME type in a render-to-user context",  which may 
> be adequate. That does put is in a better position than we  were with INFO.

That should have read  "does put us in a batter position than we were 
with INFO".

--
Dean

---

From: David R Oran <[email-masked]>
Date: Thu, 20 Dec 2007 10:32:26 -0500

Perhaps the salient difference isn't whether the contents are directly  
rendered (or indirectly rendered), but whether there are additional  
side-effects that alter an application-level state machine.

On Dec 19, 2007, at 12:21 AM, Dean Willis wrote:

> understands what you mean. That's the crux of what is wrong with  
> INFO today.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Dec 2007 11:14:43 -0500

This is an aspect of the ongoing attempt to nail down what the content 
dispositions mean, and whether they mean the same thing for all methods. 
Its especially pertinent for "render" because that is the default 
disposition code for sip body parts, and because its far from clear that 
"render" could mean the same thing for all methods.

	Paul

David R Oran wrote:
>> make a ringing nose that causes the user to press a button that causes 
>> a new message to be sent.
>>
>>> MESSAGE, and if it is rendered, is the resulting behavior reasonable. 
>>> For the iscomposing indicators, I think you could. You could instead 
>>> send a text IM like "Joe is typing a reply..." and render that, and 
>>> this would achieve the same objective.
>>