Re: [Sip] Additional uses of INFO

Paul Kyzivat <pkyzivat@cisco.com> Sun, 25 June 2006 00:37 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuId1-0004jc-BM; Sat, 24 Jun 2006 20:37:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuIcz-0004jX-Ov for sip@ietf.org; Sat, 24 Jun 2006 20:37:29 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuIcy-0004rG-HR for sip@ietf.org; Sat, 24 Jun 2006 20:37:29 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Jun 2006 17:37:28 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.06,172,1149490800"; d="scan'208"; a="30415977:sNHT30257844"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5P0bSYL027048; Sat, 24 Jun 2006 20:37:28 -0400 (EDT)
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.211); Sat, 24 Jun 2006 20:37:27 -0400
Received: from [10.82.224.187] ([10.82.224.187]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Jun 2006 20:37:27 -0400
Message-ID: <449DDAC6.7030408@cisco.com>
Date: Sat, 24 Jun 2006 20:37:26 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] Additional uses of INFO
References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <200606220213.k5M2DP3q011828@dragon.ariadne.com> <74E6B44E-684D-4814-8278-C71069C976D0@softarmor.com> <200606242207.k5OM7SoU011019@dragon.ariadne.com>
In-Reply-To: <200606242207.k5OM7SoU011019@dragon.ariadne.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jun 2006 00:37:27.0403 (UTC) FILETIME=[88C1FBB0:01C697EF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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:

>    Content-type tells about what the content is. Content-disposition  
>    tells about what one is supposed to do with the content, and might be  
>    a better candidate for this sort of usage. Or perhaps a combination  
>    of the two.
> 
>    If I send you an image/jpeg during a call, what do you do with it?  
>    Display it? Add it to your phone book next to my name? Run a  
>    steganographic search on it to look for a hidden message?
> 
> Ah, yes.  But I note that you can define x-* Content-Dispositions as
> well.  (RFC 2045 via RFC 2183 via RFC 3261!)
> 
> For that matter, we should start getting people used to defining
> Content-Dispositions to describe the roles of message bodies.  Might I
> suggest draft-ietf-sip-hop-limit-diagnostics-03, "Diagnostic Responses
> for Session Initiation Protocol Hop Limit Errors", as a good place to
> start?  It proposes a message/sipfrag body to the 483 response that
> gives the contents of the failed request.  There ought to be a
> Content-Disposition to explain the significance of that body.

I agree there is a lot of potential in Content-Disposition. But it 
suffers from a lack  of clear specification about how it is to be used.

I have a strong suspicion that most UAs totally ignore Content-Disposition.

Question: If you send an INVITE containing an SDP body with 
Content-Disposition:render, how many will think it is an offer?

It would be a good thing to start using this for more in order to 
motivate support. But it will take awhile before it starts working 
widely. Starting by using it in something like INFO (rathere than 
INVITE) is probably a good baby step in that direction.

	Paul

_______________________________________________
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