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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, December 14, 2007 6:28 PM
To: [email protected]
Subject: Re: [Sip] MESSAGE for rendering
From: Paul Kyzivat <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
