Re: [Sip] MESSAGE for rendering

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: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
>> Sent: Friday, December 14, 2007 6:28 PM
>> To: sip@ietf.org
>> Subject: Re: [Sip] MESSAGE for rendering
>>
>>    From: Paul Kyzivat <pkyzivat@cisco.com>
>>
>>    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 sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip