Re: [MMUSIC] [Editorial Errata Reported] RFC4583 (4111)

Christian Groves <Christian.Groves@nteczone.com> Mon, 22 September 2014 00:58 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B4D1A039C for <mmusic@ietfa.amsl.com>; Sun, 21 Sep 2014 17:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GZP_-ZEMhyT for <mmusic@ietfa.amsl.com>; Sun, 21 Sep 2014 17:58:34 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E503B1A0396 for <mmusic@ietf.org>; Sun, 21 Sep 2014 17:58:33 -0700 (PDT)
Received: from ppp118-209-206-23.lns20.mel8.internode.on.net ([118.209.206.23]:53686 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1XVrue-00055E-1j; Mon, 22 Sep 2014 10:55:32 +1000
Message-ID: <541F7434.6070506@nteczone.com>
Date: Mon, 22 Sep 2014 10:58:28 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Richard Barnes <rlb@ipv.sx>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
References: <20140915023001.7CB6A180015@rfc-editor.org> <CAFHv=r_7HcRSSt5Rao0dR44TQirbtwji1Occ-ijTRpiun6tybg@mail.gmail.com> <54183F55.40203@nteczone.com> <D041D4DF.333A0%eckelcu@cisco.com> <CAL02cgQ4+0r_2DC+R4-xyogjhdG7LJGhPShaL6FrDnOOf8eyFg@mail.gmail.com>
In-Reply-To: <CAL02cgQ4+0r_2DC+R4-xyogjhdG7LJGhPShaL6FrDnOOf8eyFg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/zOjv9klaVc_RDnx8FoqQkkOLSJ4
Cc: "ari.keranen@ericsson.com" <ari.keranen@ericsson.com>, "<mmusic@ietf.org>" <mmusic@ietf.org>, "Tom Kristensen \(tomkrist\)" <tomkrist@cisco.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, "Flemming Andreasen \(fandreas\)" <fandreas@cisco.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [MMUSIC] [Editorial Errata Reported] RFC4583 (4111)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 22 Sep 2014 00:58:37 -0000

Hello Richard and Charles,

No problem. I've submitted the errata on RFC5239.

Regards, Christian

On 22/09/2014 10:41 AM, Richard Barnes wrote:
> Since the -bis document is going to obsolete RFC 4583, I'm just going 
> to mark this one "Rejected", since it will be addressed in the -bis.
>
> Christian: Please do go ahead and submit an erratum on RFC 5239, and 
> I'll mark it Verified.
>
>
>
> On Fri, Sep 19, 2014 at 3:43 PM, Charles Eckel (eckelcu) 
> <eckelcu@cisco.com <mailto:eckelcu@cisco.com>> wrote:
>
>     Yes, please do. The BFCPBIS WG does not have plans to update RFC
>     5239, so
>     an errata would be helpful.
>
>     Cheers,
>     Charles
>
>     On 9/16/14, 6:47 AM, "Christian Groves"
>     <Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com>>
>     wrote:
>
>     >Hello Tom,
>     >
>     >Ah, I missed the bis document. Good to see it's addressed.
>     RFC5239 also
>     >has the same issue in clause 8.4 where it uses m-stream. Its probably
>     >worth an errata also.
>     >
>     >Regards, Christian
>     >
>     >On 16/09/2014 5:11 PM, Tom Kristensen wrote:
>     >> Well spotted!
>     >>
>     >> This is addressed and fixed in rfc4583bis.
>     >> https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis (a new
>     >> version of this draft will be submitted very soon).
>     >>
>     >> Cf. Section 6, where this paragraph is added:
>     >>
>     >>     "Note: In [15
>     >>
>     <https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-09#ref-15>]
>     >> 'm-stream' was erroneously used in Section 10
>     >>
>     >><https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-09#section-10>
>     >>.
>     >>     Although the example was non-normative, it is implemented
>     by some
>     >>     vendors and occurs in cases where the endpoint is willing
>     to act as
>     >>     an server.  Therefore, it is RECOMMENDED to support parsing and
>     >>     interpreting 'm-stream' the same way as 'mstrm' when
>     receiving."
>     >> In the example pointed to in the errate, we are now using the
>     correct
>     >>string for the floorid attribute:
>     >>    "a=floorid:1 mstrm:10
>     >>     a=floorid:2 mstrm:11"
>     >> -- Tom
>     >>
>     >> On 15 September 2014 04:30, RFC Errata System
>     >> <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>
>     <mailto:rfc-editor@rfc-editor.org
>     <mailto:rfc-editor@rfc-editor.org>>> wrote:
>     >>
>     >>     The following errata report has been submitted for RFC4583,
>     >>     "Session Description Protocol (SDP) Format for Binary Floor
>     >>     Control Protocol (BFCP) Streams".
>     >>
>     >>     --------------------------------------
>     >>     You may review the report below and at:
>     >> http://www.rfc-editor.org/errata_search.php?rfc=4583&eid=4111
>     >>
>     >>     --------------------------------------
>     >>     Type: Editorial
>     >>     Reported by: Christian Groves
>     <Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com>
>     >>     <mailto:Christian.Groves@nteczone.com
>     <mailto:Christian.Groves@nteczone.com>>>
>     >>
>     >>     Section: 9
>     >>
>     >>     Original Text
>     >>     -------------
>     >>     For the purpose of brevity, the main portion of the session
>     >>        description is omitted in the examples, which only show 'm'
>     >>     lines and
>     >>        their attributes.
>     >>
>     >>        The following is an example of an offer sent by a conference
>     >>server
>     >>        to a client.
>     >>
>     >>        m=application 50000 TCP/TLS/BFCP *
>     >>        a=setup:passive
>     >>        a=connection:new
>     >>        a=fingerprint:SHA-1 \
>     >>  4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
>     >>        a=floorctrl:s-only
>     >>        a=confid:4321
>     >>        a=userid:1234
>     >>        a=floorid:1 m-stream:10
>     >>        a=floorid:2 m-stream:11
>     >>        m=audio 50002 RTP/AVP 0
>     >>        a=label:10
>     >>        m=video 50004 RTP/AVP 31
>     >>        a=label:11
>     >>
>     >>     ...
>     >>
>     >>     Corrected Text
>     >>     --------------
>     >>     For the purpose of brevity, the main portion of the session
>     >>        description is omitted in the examples, which only show 'm'
>     >>     lines and
>     >>        their attributes.
>     >>
>     >>        The following is an example of an offer sent by a conference
>     >>server
>     >>        to a client.
>     >>
>     >>        m=application 50000 TCP/TLS/BFCP *
>     >>        a=setup:passive
>     >>        a=connection:new
>     >>        a=fingerprint:SHA-1 \
>     >>  4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
>     >>        a=floorctrl:s-only
>     >>        a=confid:4321
>     >>        a=userid:1234
>     >>        a=floorid:1 mstrm:10
>     >>        a=floorid:2 mstrm:11
>     >>        m=audio 50002 RTP/AVP 0
>     >>        a=label:10
>     >>        m=video 50004 RTP/AVP 31
>     >>        a=label:11
>     >>
>     >>     ...
>     >>
>     >>     Notes
>     >>     -----
>     >>     In section 6 of the RFC the ABNF for the "floorid"
>     attribute is:
>     >>       floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP
>     >>     token)]
>     >>
>     >>     The text string " mstrm:" is used to reference the media stream
>     >>     rather than "m-stream" that appears in the examples.
>     >>
>     >>     Instructions:
>     >>     -------------
>     >>     This erratum 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.
>     >>
>     >>     --------------------------------------
>     >>     RFC4583 (draft-ietf-mmusic-sdp-bfcp-03)
>     >>     --------------------------------------
>     >>     Title               : Session Description Protocol (SDP) Format
>     >>     for Binary Floor Control Protocol (BFCP) Streams
>     >>     Publication Date    : November 2006
>     >>     Author(s)           : G. Camarillo
>     >>     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 <mailto:mmusic@ietf.org>
>     <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>     >> https://www.ietf.org/mailman/listinfo/mmusic
>     >>
>     >>
>     >>
>     >>
>     >> --
>     >> # Cisco                         |
>     http://www.cisco.com/telepresence/
>     >> ## tomkrist@cisco.com <mailto:tomkrist@cisco.com>
>     <mailto:tomkrist@cisco.com <mailto:tomkrist@cisco.com>> |
>     >> http://www.tandberg.com
>     >> ###                               | http://folk.uio.no/tomkri/
>     >
>     >_______________________________________________
>     >mmusic mailing list
>     >mmusic@ietf.org <mailto:mmusic@ietf.org>
>     >https://www.ietf.org/mailman/listinfo/mmusic
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>