Re: [MEDIACTRL] some corrections to mrb-04

Lorenzo Miniero <lorenzo@meetecho.com> Fri, 14 May 2010 08:32 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B10028C119 for <mediactrl@core3.amsl.com>; Fri, 14 May 2010 01:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.881
X-Spam-Level: *
X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 DBsuj-VCshIP for <mediactrl@core3.amsl.com>; Fri, 14 May 2010 01:32:20 -0700 (PDT)
Received: from smtplq02.aruba.it (smtpweb23.aruba.it [62.149.158.23]) by core3.amsl.com (Postfix) with SMTP id CF50928C112 for <mediactrl@ietf.org>; Fri, 14 May 2010 01:30:34 -0700 (PDT)
Received: (qmail 23554 invoked by uid 89); 14 May 2010 08:30:23 -0000
Received: from unknown (HELO smtp5.aruba.it) (62.149.128.201) by smtplq02.aruba.it with SMTP; 14 May 2010 08:30:23 -0000
Received: (qmail 21064 invoked by uid 89); 14 May 2010 08:30:22 -0000
Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.166) by smtp5.ad.aruba.it with SMTP; 14 May 2010 08:30:22 -0000
Date: Fri, 14 May 2010 10:28:33 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: "MUNSON, GARY A, ATTLABS" <gm3472@att.com>
Message-Id: <20100514102833.4d7d1bfa.lorenzo@meetecho.com>
In-Reply-To: <2F41EF28ED42A5489E41742244C9117C02574A31@gaalpa1msgusr7b.ugd.att.com>
References: <2F41EF28ED42A5489E41742244C9117C02574A31@gaalpa1msgusr7b.ugd.att.com>
Organization: Meetecho
X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N
Cc: "EPLEY, BOB (ATTLABS)" <be1891@att.com>, mediactrl@ietf.org
Subject: Re: [MEDIACTRL] some corrections to mrb-04
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2010 08:32:21 -0000

Hi Gary,

thanks to both you and Bob for your review!
I've corrected all the issues and I'm about to upload the revised
document. I've added a few comments inline as well [LM].



On Thu, 13 May 2010 17:26:12 -0400
"MUNSON, GARY A, ATTLABS" <gm3472@att.com> wrote:

> Hi Lorenzo, Chris,
> 
> My colleague Bob Epley was reviewing -mrb-04, and we believe the
> following are corrections needed:
> 
> 1)	Section 5.2.3, at the beginning talks about a <session-info> in
> the response from MRB, whereas it should be <response-session-info>.
> Additionally, there, the <media-server-address> as a child element is
> not included, whereas it is included in 5.2.5.1.1. and in the XML schema
> as a child element of <response-session-info>. 


[LM] Fixed, thanks.


> 2)	Section 5.2.5.1.1 talks about including <response-session-info>
> in a response from MRB to an update request, whereas that element should
> also be present in a (successful) response to the initial request.
> Additionally, 5.2.3 says the <session-response> element MUST be present
> in a successful response, whereas in 5.2.5.1.1 it is stated that the
> element MAY be present. Can't tell whether those statements conflict, or
> at the least the latter needs clarification.


[LM] You're right, this was ambiguous. The element is optional in
the sense that it would be useless in an error response, since no
session would be created and no related information would be reported.
I've added text to clarify that the element must be present in
successful responses, not needed otherwise.


> 3)	Section 5.2.4.1.1.1 (on <session-info>) and 5.2.5.1.1 (on
> <response-session-info>) both talk about a <max-prepared-duration>
> element. That doesn't belong and should be replaced with <session-info>
> and <response-session-info> statements as appropriate.


[LM] A copy/paste leftover, thanks for finding it.


> 4)	The Query example in Section 6.2.1 has the client query
> containing a <session-info> element, but this would not be present in an
> initial query. In which case it would be useful to clarify in the text
> around the example or alternatively that element should be removed from
> the message content. And, at any rate, the <session-info> there only
> shows one child element, not three.


[LM] This was wrong, you're right. I've also fixed it in the IAMM
example, which presents the same request carried in SIP.


> 5)	The <response-session-info> element in the MRB response message
> content in the example in 6.2.1 should include an <expires>.


[LM] Actually it's there in both examples (Query and IAMM) in the doc
I have. Or are you talking of another section/example?


> 
> Cheers,
> 	
> Gary
> 


Thanks again!
Lorenzo

-- 
Lorenzo Miniero
Meetecho s.r.l.
http://www.meetecho.com/