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

Richard Barnes <rlb@ipv.sx> Mon, 22 September 2014 00:41 UTC

Return-Path: <rlb@ipv.sx>
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 D3A0B1A039B for <mmusic@ietfa.amsl.com>; Sun, 21 Sep 2014 17:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.923
X-Spam-Level: *
X-Spam-Status: No, score=1.923 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 LFJ_rR-_dAVV for <mmusic@ietfa.amsl.com>; Sun, 21 Sep 2014 17:41:29 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D09C1A0396 for <mmusic@ietf.org>; Sun, 21 Sep 2014 17:41:29 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id p9so5246163lbv.3 for <mmusic@ietf.org>; Sun, 21 Sep 2014 17:41:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hKOSoJ+qVLqzfWWi5/XBStDIaMWh/51nLkcFuzcI0FE=; b=OmAJbuRXNFX9Accq7HPgA6TTXK6xmXUfu0s1lWDxpDerHjbMg74BhqHSLWnhl5HAzZ 7MJrnJuo6KxOKMVJ/6eKYwwUCYBozk0yY2rcKlH7NkfqXw5tZGYnJTViriCvk1p6M+9p jd2WVLhgH0+LphYZ6y6wWJPnwZvS6cKZ5TMR8f+Vni15eCODW10TzHvjUVgbkm/k78/6 k9/wMZ3gcgBYh38TraHOzTRo/eGU8aWYvhk5iG4sx3BpwYKOgE7gkBmCCWLJJCpp2IyG oZ5oFcv3ihCfpDMdgGZPbVDo1kTCkIp5lwmFZ6cRLfQjTAgldWGOPwLne89Y3/1022Qk q16w==
X-Gm-Message-State: ALoCoQn86withTjGN7TW8jZD1SeU/3CnfvbxCiuFqowyyHeYiCJZF1FCRKQoV1IRj4j52rG+eAmO
MIME-Version: 1.0
X-Received: by 10.152.170.227 with SMTP id ap3mr21990960lac.15.1411346487593; Sun, 21 Sep 2014 17:41:27 -0700 (PDT)
Received: by 10.25.159.84 with HTTP; Sun, 21 Sep 2014 17:41:27 -0700 (PDT)
In-Reply-To: <D041D4DF.333A0%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>
Date: Sun, 21 Sep 2014 20:41:27 -0400
Message-ID: <CAL02cgQ4+0r_2DC+R4-xyogjhdG7LJGhPShaL6FrDnOOf8eyFg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Content-Type: multipart/alternative; boundary=089e013c65580c605505039cb6b0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PePp_UJmKdFY2NZbIRa9hKI-Nxw
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:41:32 -0000

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>
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>
> 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>> 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>>
> >>
> >>     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>
> >>     https://www.ietf.org/mailman/listinfo/mmusic
> >>
> >>
> >>
> >>
> >> --
> >> # Cisco                         | http://www.cisco.com/telepresence/
> >> ## tomkrist@cisco.com <mailto:tomkrist@cisco.com>  |
> >> http://www.tandberg.com
> >> ###                               | http://folk.uio.no/tomkri/
> >
> >_______________________________________________
> >mmusic mailing list
> >mmusic@ietf.org
> >https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>