Re: [Sip] [Sip-implementors] Content-Disposition
"Worley, Dale R (Dale)" <dworley@avaya.com> Wed, 09 March 2011 18:29 UTC
Return-Path: <dworley@avaya.com>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148883A693B for <sip@core3.amsl.com>; Wed, 9 Mar 2011 10:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.541
X-Spam-Level:
X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4crRth8MWTj1 for <sip@core3.amsl.com>; Wed, 9 Mar 2011 10:29:35 -0800 (PST)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id F2DEE3A6989 for <sip@ietf.org>; Wed, 9 Mar 2011 10:29:34 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALpVd02HCzI1/2dsb2JhbACmcHSpRQKaH4VlBIUiinqIRw
X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="62653024"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 09 Mar 2011 13:30:51 -0500
X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="614077128"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Mar 2011 13:30:51 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 9 Mar 2011 13:30:50 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Attila Sipos <attila.sipos@vegastream.com>, isshed <isshed.sip@gmail.com>, "discussion-bounces@sipforum.org" <discussion-bounces@sipforum.org>, sip-implementors <sip-implementors@lists.cs.columbia.edu>, "sip@ietf.org" <sip@ietf.org>
Date: Wed, 09 Mar 2011 13:28:14 -0500
Thread-Topic: [Sip-implementors] Content-Disposition
Thread-Index: Acveg68aWRI22h/6TWKKNoOKhxJZAgAASUoAAAC7KIg=
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B220B5C1565@DC-US1MBEX4.global.avaya.com>
References: <AANLkTikBQ+U7g6uU4g4AVT-UQZdtO=nM74StDk7G_gz5@mail.gmail.com>, <680808427CF931459462C3D78CB5EC600BFCEA79@EXVS02.nasstar-t1.net>
In-Reply-To: <680808427CF931459462C3D78CB5EC600BFCEA79@EXVS02.nasstar-t1.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Sip] [Sip-implementors] Content-Disposition
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2011 18:29:36 -0000
________________________________________ From: sip-bounces@ietf.org [sip-bounces@ietf.org] On Behalf Of Attila Sipos [attila.sipos@vegastream.com] Strictly, for an error like that, there should be a "404 Bad Request" response but you might decide it is better to treat it as if it is missing: If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition "session", while other content types imply "render". In this case, I think I would opt for a 404 response and then inform the UA vendors that their UA is misbehaving. _______________________________________________ I agree with Attila, although beware he typed "404" where he should have typed "400". (404 is "Not Found".) Be careful that your parser will accept all possible future extensions of Content-Disposition as specified in RFC 3261 section 25.1 -- you wouldn't want your device rejecting calls that implemented some future extension. Dale
- Re: [Sip] [Sip-implementors] Content-Disposition Attila Sipos
- Re: [Sip] [Sip-implementors] Content-Disposition Worley, Dale R (Dale)