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
- [Sip] MESSAGE for rendering Hadriel Kaplan
- Re: [Sip] MESSAGE for rendering Paul Kyzivat
- RE: [Sip] MESSAGE for rendering Hadriel Kaplan
- Re: [Sip] MESSAGE for rendering Dale.Worley
- RE: [Sip] MESSAGE for rendering Hadriel Kaplan
- Re: [Sip] MESSAGE for rendering Paul Kyzivat
- Re: [Sip] MESSAGE for rendering Paul Kyzivat
- Re: [Sip] MESSAGE for rendering Paul Kyzivat
- Re: [Sip] MESSAGE for rendering Salvatore Loreto
- Re: [Sip] MESSAGE for rendering Dean Willis
- Re: [Sip] MESSAGE for rendering Jonathan Rosenberg
- Re: [Sip] MESSAGE for rendering Paul Kyzivat
- Re: [Sip] MESSAGE for rendering Dean Willis
- Re: [Sip] MESSAGE for rendering Paul Kyzivat
- Re: [Sip] MESSAGE for rendering Dean Willis
- Re: [Sip] MESSAGE for rendering Dean Willis
- Re: [Sip] MESSAGE for rendering David R Oran
- Re: [Sip] MESSAGE for rendering Paul Kyzivat