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

Elwyn Davies <elwynd@folly.org.uk> Fri, 07 June 2013 15:40 UTC

Return-Path: <elwynd@folly.org.uk>
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 586AB21F9798; Fri, 7 Jun 2013 08:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599]
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 TBguRDe8Pqk6; Fri, 7 Jun 2013 08:40:14 -0700 (PDT)
Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by ietfa.amsl.com (Postfix) with ESMTP id C662021F9732; Fri, 7 Jun 2013 08:40:07 -0700 (PDT)
Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtp (Exim 4.77) (envelope-from <elwynd@folly.org.uk>) id 1Ukylo-0003mK-T1; Fri, 07 Jun 2013 16:40:05 +0100
From: Elwyn Davies <elwynd@folly.org.uk>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
In-Reply-To: <51B1E8BD.80901@ericsson.com>
References: <1370477514.4596.9052.camel@mightyatom> <51B1A95B.2030208@ericsson.com> <1370607960.4596.9114.camel@mightyatom> <51B1E8BD.80901@ericsson.com>
Content-Type: text/plain
Organization: Folly Consulting
Date: Fri, 07 Jun 2013 16:40:02 +0100
Message-Id: <1370619602.4596.9175.camel@mightyatom>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 07 Jun 2013 12:06:50 -0700
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: Fri, 07 Jun 2013 15:40:19 -0000

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.
> 
> 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.

/Elwyn