Re: [Sip] MESSAGE for rendering

[Salvatore Loreto <[e-mail]>]

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:
>
>
> Hadriel Kaplan wrote:
>> 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. :(
>
> 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
>
>> -hadriel
>>
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> Sent: Friday, December 14, 2007 6:28 PM
>>> To: [e-mail]
>>> Subject: Re: [Sip] MESSAGE for rendering
>>>
>>>    From: Paul Kyzivat <[e-mail]>
>>>
>>>    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.
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use [e-mail] for questions on current sip
>>> Use [e-mail] 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 [e-mail] for questions on current sip
>> Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip