Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

Magnus Westerlund <> Mon, 10 June 2013 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A2DD21F854D; Mon, 10 Jun 2013 00:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pcjtc2IIixWP; Mon, 10 Jun 2013 00:51:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F3BC721F8519; Mon, 10 Jun 2013 00:51:51 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-9c-51b58595c4b0
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8A.1F.15700.59585B15; Mon, 10 Jun 2013 09:51:49 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 10 Jun 2013 09:51:49 +0200
Message-ID: <>
Date: Mon, 10 Jun 2013 09:52:07 +0200
From: Magnus Westerlund <>
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 <>
References: <1370477514.4596.9052.camel@mightyatom> <> <1370607960.4596.9114.camel@mightyatom> <> <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 <>, IETF discussion <>, "mmusic \(E-mail\)" <>,
Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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: