MESSAGE for rendering

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://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

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


Hadriel Kaplan wrote:
> 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://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

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
> Sent: Friday, December 14, 2007 4:54 PM
> To: Hadriel Kaplan
> Cc: sipietf.org
> Subject: Re: [Sip] MESSAGE for rendering
>
> 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?

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


_______________________________________________
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

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


> -----Original Message-----
> From: Dale.Worleycomcast.net [mailtoale.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