IETF Logo Mail Archive

Re: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 20 June 2016 09:34 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: avtext@ietfa.amsl.com
Delivered-To: avtext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC50712B019 for <avtext@ietfa.amsl.com>; Mon, 20 Jun 2016 02:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 qsplFc0uL9xm for <avtext@ietfa.amsl.com>; Mon, 20 Jun 2016 02:34:59 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B394B12D0B4 for <avtext@ietf.org>; Mon, 20 Jun 2016 02:34:58 -0700 (PDT)
Received: (qmail 17701 invoked from network); 20 Jun 2016 11:28:13 +0200
Received: from p5dec2e4f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.46.79) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Jun 2016 11:28:13 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <1E7F244A-2045-48E5-B817-7B87D6E5B094@cooperw.in>
Date: Mon, 20 Jun 2016 11:28:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DCA3012C-8F86-4135-993F-6D4441A05EBC@kuehlewind.net>
References: <20160614215932.31629.25074.idtracker@ietfa.amsl.com> <1E7F244A-2045-48E5-B817-7B87D6E5B094@cooperw.in>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avtext/qorrVXnvBE8A4rcjV_gfNwHW3Ak>
Cc: Jonathan Lennox <jonathan@vidyo.com>, avtext@ietf.org, avtext-chairs@ietf.org, IESG <iesg@ietf.org>, draft-ietf-avtext-splicing-notification@ietf.org, Alia Atlas <akatlas@gmail.com>
Subject: Re: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS)
X-BeenThere: avtext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Extensions working group discussion list <avtext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avtext>, <mailto:avtext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avtext/>
List-Post: <mailto:avtext@ietf.org>
List-Help: <mailto:avtext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avtext>, <mailto:avtext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jun 2016 09:35:00 -0000

Hi,

> Am 16.06.2016 um 01:17 schrieb Alissa Cooper <alissa@cooperw.in>:
> 
> - I agree that the MUST NOT forward language is ill-advised, and it’s also unnecessary. But even if this document said MUST forward, there is nothing in the protocol semantics that would require implementations to do that, so I imagine that splicers that do not want to forward this information (whether to prevent detection or to reduce overhead) won’t forward it. Similarly, I would imagine that at least some of the payload-specific mechanisms used for this purpose have the same property, so even if systems rely on those mechanisms rather than RTP because the RTP spec says MUST forward, there is no guarantee that the splicing information will reach the receiver.

I still support Alia’s discuss here, because even if we can’t change what people/splicers do, we should not write should an ill-advise in an RFC!

Mirja

v2.23.0 | Report a Bug | By Email