Re: [MMUSIC] [Technical Errata Reported] RFC5888 (2313)

Tom Taylor <tom111.taylor@bell.net> Thu, 24 June 2010 18:35 UTC

Return-Path: <tom111.taylor@bell.net>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AA03A69C2 for <mmusic@core3.amsl.com>; Thu, 24 Jun 2010 11:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.942
X-Spam-Level:
X-Spam-Status: No, score=0.942 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803]
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 cd5--YlUoJwD for <mmusic@core3.amsl.com>; Thu, 24 Jun 2010 11:35:07 -0700 (PDT)
Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by core3.amsl.com (Postfix) with ESMTP id 3F8A93A68B3 for <mmusic@ietf.org>; Thu, 24 Jun 2010 11:34:53 -0700 (PDT)
Received: from BLU0-SMTP81 ([65.55.116.74]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 11:35:00 -0700
X-Originating-IP: [70.26.17.94]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID: <BLU0-SMTP81E7A5F3D6E0218CC7B9A1D8C60@phx.gbl>
Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP81.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 11:35:00 -0700
Date: Thu, 24 Jun 2010 14:34:55 -0400
From: Tom Taylor <tom111.taylor@bell.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20100624181521.ED6EFE0661@rfc-editor.org>
In-Reply-To: <20100624181521.ED6EFE0661@rfc-editor.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Jun 2010 18:35:00.0510 (UTC) FILETIME=[F41E33E0:01CB13CB]
Cc: ah@TR-Sys.de, mmusic@ietf.org, schulzrinne@cs.columbia.edu, Gonzalo.Camarillo@ericsson.com, jf.mule@cablelabs.com
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5888 (2313)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 24 Jun 2010 18:35:18 -0000

This looks like a good catch. It should be accepted.

RFC Errata System wrote:
> The following errata report has been submitted for RFC5888,
> "The Session Description Protocol (SDP) Grouping Framework".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5888&eid=2313
> 
> --------------------------------------
> Type: Technical
> Reported by: Alfred Hoenes <ah@TR-Sys.de>
> 
> Section: 9.2.1
> 
> Original Text
> -------------
> 9.2.1.  Example
> 
>    The example below shows how the callee refuses a media stream offered
>    by the caller by setting its port number to zero.  The "mid" value
>    corresponding to that media stream is removed from the "group" value
>    in the answer.
> 
>    SDP description in the INVITE from caller to callee:
> 
>           [...]
> 
> |  SDP description in the INVITE from callee to caller:
> 
>           [...]
> 
> 
> Corrected Text
> --------------
> 9.2.1.  Example
> 
>    The example below shows how the callee refuses a media stream offered
>    by the caller by setting its port number to zero.  The "mid" value
>    corresponding to that media stream is removed from the "group" value
>    in the answer.
> 
>    SDP description in the INVITE from caller to callee:
> 
>           [...]
> 
> |  SDP description in the "200 OK" from callee to caller:
> 
>           [...]
> 
> 
> Notes
> -----
> Rationale: In the scenario described by the prose,
>   the SDP answer is carried in the non-provisional 
>   response to the INVITE, in this case a "200 OK",
>   not in another INVITE.  The latter (using a re-INVITE)
>   is a different scenario.  (Note that a re-INVITE would
>   likely contain an SDP offer, where port 0 is not allowed.)
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5888 (draft-ietf-mmusic-rfc3388bis-04)
> --------------------------------------
> Title               : The Session Description Protocol (SDP) Grouping Framework
> Publication Date    : June 2010
> Author(s)           : G. Camarillo, H. Schulzrinne
> Category            : PROPOSED STANDARD
> Source              : Multiparty Multimedia Session Control
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 
>