Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 10 June 2013 07:51 UTC
Return-Path: <prvs=1873a61d1e=magnus.westerlund@ericsson.com>
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 1A2DD21F854D; Mon, 10 Jun 2013 00:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 pcjtc2IIixWP; Mon, 10 Jun 2013 00:51:52 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3BC721F8519; Mon, 10 Jun 2013 00:51:51 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-9c-51b58595c4b0
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8A.1F.15700.59585B15; Mon, 10 Jun 2013 09:51:49 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Jun 2013 09:51:49 +0200
Message-ID: <51B585A7.7060109@ericsson.com>
Date: Mon, 10 Jun 2013 09:52:07 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Elwyn Davies <elwynd@folly.org.uk>
References: <1370477514.4596.9052.camel@mightyatom> <51B1A95B.2030208@ericsson.com> <1370607960.4596.9114.camel@mightyatom> <51B1E8BD.80901@ericsson.com> <1370619602.4596.9175.camel@mightyatom>
In-Reply-To: <1370619602.4596.9175.camel@mightyatom>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvre7U1q2BBstarCwufjnCbnH8wA52 i6uvPrNYPNs4n8Vi6vLHLA6sHl9PtrN4LFnyk8njy+XPbAHMUdw2SYklZcGZ6Xn6dgncGbN3 9jEWXJCrmPbfu4HxiUQXIyeHhICJxJ1Jn9khbDGJC/fWs3UxcnEICZxilFh+ZgsrhLOcUWL2 61csIFW8AtoSZ+csB7NZBFQlvu/5xApiswlYSNz80cgGYosKBEsc2b4Zql5Q4uTMJ2C2iICa xOavDxhBhjILrGOU+LGsCaxBWCBMYt6WbiaIbYcZJSZt2Ad2EyfQfe/7Glkg7pOU2PKiHSzO LKAnMeVqCyOELS/RvHU2M4gtBHRdQ1MH6wRGoVlIls9C0jILScsCRuZVjOy5iZk56eWGmxiB gX1wy2/dHYynzokcYpTmYFES59XjXRwoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MIqq VfHFeD+1rMxKDxN78chSxLnK+Pq289Hik4MWPGyK0NvMWSva9eun0smTgsWZkRsKxPL8UvPm n/BgdL2QsTH/h8jtlpsBO7VjWsW1BcxPXIjlMchftWa9Ws8vlsZXM9WfvvO6uvL7SeZQNgbb QyIeYdci7KbnPYpcNbHsskBBul/lG/X5SizFGYmGWsxFxYkA7ohWYD8CAAA=
Cc: General Area Review Team <gen-art@ietf.org>, IETF discussion <ietf@ietf.org>, "mmusic (E-mail)" <mmusic@ietf.org>, draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org
Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
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: Mon, 10 Jun 2013 07:51:59 -0000
On 2013-06-07 17:40, Elwyn Davies wrote: > On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote: > >>> Appendix F: I missed that the text/parameter format appeared in the >>> examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the >>> definitions of these methods what encodings are acceptable for the >>> message bodies that may go with these methods and their responses. >> >> Exactly, that is intentional. These methods can use anything that has a >> MIME type. Also it has HTTP's mechanisms for determining what formats >> one supports. >> >>> Clearly the new text/parameter MIME format is one. Is it the only one? >> >> It is the only one defined by IETF for this purpose. That is why it is >> in the appendix so that RTSP users shall have something to define the >> parameters they want in. However, they have to accept the limitations of >> a basic text format. >> >>> I guess you could use a application/json or an XML format but I guess >>> these would also either have to be called out explicitly in the method >>> descriptions or put in as feature extensions. This needs to be >>> clarified in the method descriptions (s13). The upshot of all this is >>> that I think Appendix F needs to be pulled back into Section 20 as >>> currently it is the only way to encode the message bodies. >> >> I can agree that the format negotiation for the bodies of >> GET/SET_PARAMETER is not clear. I will look at proposing some >> improvements of the text related to the handling of method bodies and >> their format negotiation. > Good. I don't see where the server tells what formats it accepts for > either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say > anything about SET_PARAMETER. AFAICS the client could tell the server > what formats it accepts as a side-effect of DESCRIBE but that's a bit > arcane - and it is not clear how you would separate the formats for > DESCRIBE from those for GET_PARAM and SET_PARAM. Yes, I think this negotiation should happen on per methods basis. >> >> However, I am not pulling in Appendix F. It is an optional to use format >> for parameter value pairs that can be used in these methods, it is not >> required. Nor, does the specification define any parameters that are >> transferred using this interface. The things that are in the appendix >> are not core protocol, they represent either informational things, like >> the examples and the state machine. The other appendices are normative >> definitions of particular choices for things that can be combined or >> used with RTSP, like RTP as media transport. >> > OK, it is possible to use GET_PARAM for basic requirements without using > message bodies, so you can get away without defining a lowest common > denominator format. However, the use of message bodies for SET_PARAM is > RECOMMENDED so it seems a little odd not to ensure that server and > client will have at least one format in common. (And its not as if we > are dealing with a hugely complicated bit of spec for > text/parameters! :-) ). Then, given the example in GET_PARAMETER it > seems sensible to advise implementing text/parameters as the default for > GET_PARAM also. Sure, I personally don't have any issue with making it at least SHOULD implement text/parameters. But from my horizon a forward pointer with the normative requirements is sufficient to accomplish that. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- [MMUSIC] RTSP 2.0: Body format negotiation Magnus Westerlund