Re: [Sip] MESSAGE for rendering

Paul Kyzivat <pkyzivat@cisco.com> Sat, 15 December 2007 00:13 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Kem-0001gi-Df; Fri, 14 Dec 2007 19:13:28 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3Kek-0001dq-Pg for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 19:13:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Kek-0001dZ-Fs for sip@ietf.org; Fri, 14 Dec 2007 19:13:26 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Kej-0004pc-W0 for sip@ietf.org; Fri, 14 Dec 2007 19:13:26 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Dec 2007 19:13:24 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBF0DN0s011476; Fri, 14 Dec 2007 19:13:23 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBF0AbZM005880; Sat, 15 Dec 2007 00:13:23 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:08:56 -0500
Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:08:56 -0500
Message-ID: <47631B18.4070705@cisco.com>
Date: Fri, 14 Dec 2007 19:08:56 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] MESSAGE for rendering
References: <E6C2E8958BA59A4FB960963D475F7AC30273B2D97F@mail.acmepacket.com> <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com>
In-Reply-To: <200712142327.lBENRjRq023454@dragon.ariadne.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2007 00:08:56.0736 (UTC) FILETIME=[AF5C6A00:01C83EAE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2387; t=1197677603; x=1198541603; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=AdGWCvq1epr1oGLtlX9HCZMxyIvXuQewLwQ/imBXwM8=; b=OP8cN369ShNGLT8Dyr3RPJhU9lVbYjFR4DQSG7DCFrcDd9NevuCAO+hVaN nInPVAxDnDuxZqHmjyiYZS49djWLKai1QMgFR7iQFM0Pkvbh1RRjBdTasTA6 IX7Eayu1uD;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Dale.Worley@comcast.net wrote:
>    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". 

Does it? Lots of things could mean that. E.g. "inline" and "attachment" 
could mean that too. If the "layer above the sip ua" can get these 
things with different dispositions then we have simply passed the buck 
on what it means.

I *think* each different type of sip message needs to define the content 
dispositions that are valid with it and what they mean for it.

> 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.

I don't understand the above.

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

I'm not certain I understand that either, or to the extent I do I don't 
know how to operationalize it.

>    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]

Balance, and maybe signal strength, could also be usefully rendered to 
the user.

	Paul

> 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