Re: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)

Harald Alvestrand <harald@alvestrand.no> Mon, 19 June 2023 18:24 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05D2C15106F for <mmusic@ietfa.amsl.com>; Mon, 19 Jun 2023 11:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2lvqKZgCCSz for <mmusic@ietfa.amsl.com>; Mon, 19 Jun 2023 11:24:36 -0700 (PDT)
Received: from smtp.alvestrand.no (smtp.alvestrand.no [65.21.189.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7077EC14CE5F for <mmusic@ietf.org>; Mon, 19 Jun 2023 11:24:35 -0700 (PDT)
Received: from [10.67.95.67] (static-212-247-159-251.cust.tele2.se [212.247.159.251]) by smtp.alvestrand.no (Postfix) with ESMTPSA id 1C1C54D388 for <mmusic@ietf.org>; Mon, 19 Jun 2023 20:24:34 +0200 (CEST)
Message-ID: <44d1f8b0-3239-7e06-f7e1-35854037a760@alvestrand.no>
Date: Mon, 19 Jun 2023 20:24:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: mmusic@ietf.org
References: <20230615183640.9EB26E5F76@rfcpa.amsl.com> <HE1PR07MB4441E284AC9058185C6E28A39358A@HE1PR07MB4441.eurprd07.prod.outlook.com>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <HE1PR07MB4441E284AC9058185C6E28A39358A@HE1PR07MB4441.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/5zeX9mR9fH26cNG-RS9yeNY-3Kk>
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
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: <https://mailarchive.ietf.org/arch/browse/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, 19 Jun 2023 18:24:40 -0000

The actual case where it did not go well was a case where the members 
were internally represented as a set, but where the count was taken from 
the field.

The code added two elements, and then removed two elements - when 
removing the second element, there was no such member in the set any more.

(Not the exact code, but illustrates the prinicple)

This violates the Principle of Least Astonishment. We shouldn't violate 
that.

On 6/16/23 03:18, Christer Holmberg wrote:
> Why would someone use something like a=ssrc-group:FID 1234 1234? And, even if
> someone does, what error would it cause?
>
> Also, we don't have similar text for e.g., the SDP group attribute.
>
> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: mmusic <mmusic-bounces@ietf.org> On Behalf Of RFC Errata System
> Sent: Thursday, 15 June 2023 21.37
> To: jonathan@vidyo.com; jo@acm.org; ts@thomas-schierl.de; superuser@gmail.com;
> Francesca Palombini <francesca.palombini@ericsson.com>; Bo Burman
> <bo.burman@ericsson.com>; fandreas@cisco.com
> Cc: phancke@microsoft.com; mmusic@ietf.org; rfc-editor@rfc-editor.org
> Subject: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)
>
> The following errata report has been submitted for RFC5576, "Source-Specific
> Media Attributes in the Session Description Protocol (SDP)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7544
>
> --------------------------------------
> Type: Technical
> Reported by: Philipp Hancke <phancke@microsoft.com>
>
> Section: 4.2
>
> Original Text
> -------------
> Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined by a
> corresponding "ssrc:" line in the same media description
>
> Corrected Text
> --------------
> Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined by a
> corresponding "ssrc:" line in the same media description and MUST appear only
> once in this ssrc-group
>
> Notes
> -----
> The goal is to clarify that something like
>    a=ssrc-group:FID 1234 1234
> is not valid. While this is demuxable (in the BUNDLE sense) it would require
> chaining of ssrc-demuxing and payload type demuxing which is a lot of
> complexity.
> The uniqueness is already implied by the following sentence (emphasis is
> mine):
>     The SDP media attribute "ssrc-group" expresses a relationship among
> *several* sources of an RTP session earlier in the section.
>
> 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 can log in to change the status and
> edit the report, if necessary.
>
> --------------------------------------
> RFC5576 (draft-ietf-mmusic-sdp-source-attributes-02)
> --------------------------------------
> Title               : Source-Specific Media Attributes in the Session
> Description Protocol (SDP)
> Publication Date    : June 2009
> Author(s)           : J. Lennox, J. Ott, T. Schierl
> Category            : PROPOSED STANDARD
> Source              : Multiparty Multimedia Session Control RAI
> 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 mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic