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: Dale.Worley comcast.net [mailto ale.Worl
eycomcast.net]
>>> Sent: Friday, December 14, 2007 6:28 PM
>>> To: sipietf.org
>>> Subject: Re: [Sip] MESSAGE for rendering
>>>
>>> From: Paul Kyzivat <pkyzivatcisco.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://ww
w1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core
SIP Protocol
>>> Use sip-implementorscs.columbia.edu for
questions on current sip
>>> Use sippingietf.org for new
developments on the application of sip
>>
>>
>> _______________________________________________
>> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
>>
>
>
> _______________________________________________
> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
