Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 18 October 2013 18:33 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4C11E8302 for <mmusic@ietfa.amsl.com>; Fri, 18 Oct 2013 11:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.272
X-Spam-Level:
X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUfQd9je1oLq for <mmusic@ietfa.amsl.com>; Fri, 18 Oct 2013 11:33:25 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 7938711E80DE for <mmusic@ietf.org>; Fri, 18 Oct 2013 11:33:25 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id eb9f1m0021vXlb85EiZQBo; Fri, 18 Oct 2013 18:33:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id eiZQ1m00i3ZTu2S3diZQCl; Fri, 18 Oct 2013 18:33:24 +0000
Message-ID: <52617EF3.8040705@alum.mit.edu>
Date: Fri, 18 Oct 2013 14:33:23 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C2F3D@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382121204; bh=Wb44MGBHKZCzBsz+j/F3mRhvH2shrIISNVVw7tv+HmY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kkBAMjsiA0XR+HKaAW4+ZP5t02dmsu8n/BIrx/m5TE097SaXAHutFKrKBHV+4l6hK c9+BQGe0eV92xS+71Tnm9yq0v7VS70XWqCMcgnWs7fPgazqRl4r1UR+OB9RZ9PzB+W 445UqQO3bbqmKAqVba7iBlgfXGFS9/2xibzFuB+/lm2IO6wcJavX7vo8CeuePiS9av WayXfwtt4oX6gufghi/gAv2AwP5vPyNgqgVO/ZL6ju1HujwWOtZ9toAiqlxov5YCbh ery9YofdvP7MhqO1bg1pnkRb3TtNZ2fg8WImJu8rNAoueQCNyLHc18MihWWsnxeCZO Qt55hfNiuu6/g==
Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2013 18:33:31 -0000

On 10/18/13 2:11 PM, Christer Holmberg wrote:
> Hi,
>
> The draft says that one will use the "application/sdpfrag" MIME type value for POFs and PANs.
>
> What about using "application/sdp" - ie the same MIME type value as for "normal" SDP Offers and Answers? From a SDP syntax perspective it should not be a problem - any SDP parser will be able to parse a POF/PAN.
>
> An entity that does not support POF/PAN would probably trigger an error. BUT, maybe that is good: It could be a mechanism to verify that all SDP processing/inspecting entities along the signaling path actually support the mechanism. At least for SIP I can't think of any other mechanism to do that (we can't use Proxy-Require).
>
> Comments?

It isn't the same as SDP. The SDP fragments aren't syntactically valid 
SDP - they are missing some mandatory fields.

Conceivably the POF/PAN stuff could require more, so that they are 
syntactically valid SDP. But do we want to?

And required processing is semantically different. If it were the same 
content type then some other means would be required to indicate that it 
is being used for POF/PAN, not offer/answer. Adam isn't talking about 
that part. In sip, that could be done via content-disposition.

	Thanks,
	Paul