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 > >
- [MMUSIC] [Technical Errata Reported] RFC5888 (231… RFC Errata System
- Re: [MMUSIC] [Technical Errata Reported] RFC5888 … Tom Taylor