Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32

Ben Campbell <> Wed, 20 March 2019 03:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91D4E12787D for <>; Tue, 19 Mar 2019 20:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5SWMSfP4uNvE for <>; Tue, 19 Mar 2019 20:07:47 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66CD1126CFF for <>; Tue, 19 Mar 2019 20:07:47 -0700 (PDT)
Received: from bens-macbook.lan ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x2K37Wm5024238 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Mar 2019 22:07:34 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1553051255; bh=QXA15lT2qlV0iO5WpIMsmdslZjZpBpYMkEoHW3nenuQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=M0mefuznXzOYVv2uuuH9sBI21DDLhykeX0s5FtX4LChUuNUmd7Z8GbHHsPyCihRgR Eo//6atMc4L2qYMxPbhpXLbq/6Osn6V6f5aL1F8Rnvz9q8eV5v4ZaPOKxpBOY7ptV+ zJCLWKp4j2xUk7nfAf31HwWH+p/4kl84Hn/zAMH0=
X-Authentication-Warning: Host [] claimed to be bens-macbook.lan
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_F72473F0-9A5C-4385-9495-7E3D7006BB43"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 19 Mar 2019 22:07:26 -0500
In-Reply-To: <>
Cc: Colin Perkins <>,
To: Paul Kyzivat <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Mar 2019 03:07:48 -0000

> On Mar 14, 2019, at 12:32 PM, Paul Kyzivat <> wrote:
> On 3/11/19 7:22 PM, Ben Campbell wrote:
>> Sent from my iPhone
>>> On Mar 11, 2019, at 5:26 PM, Paul Kyzivat <> wrote:
>>> On 3/11/19 1:43 PM, Colin Perkins wrote:
>>>>>> §5 has several changes to normative language. Most are okay, but I think the change from “all MUST appear in exactly the order given here” to “all must appear” weakens it too much, and I’d prefer that to remain a MUST.
>>>>> The reason for changing that is because the *normative* specification of the ordering is from the ABNF. The text here is explanatory and non-normative. (Note that a couple of paragraphs prior to this is a new statement emphasizing that the ABNF is normative.)
>>>> Sorry, but I think this change is problematic. The text needs to use normative language that is consistent with the ABNF.
>>> My thinking is that we don't like to have redundant normative specification, just in case they aren't consistent. The ABNF is normative. This section is of necessity an approximation.
>>> But I defer to Ben or whoever.
>> I agree with both of you. :-)
>> That is, we should avoid duplication normative requirements when possible, because it increases the chance of  spec errors. But we should still try to make sure the sections agree.
> That is what I have tried to do. AFAIK they are consistent within the limits of the expressiveness of the informal syntax in the Section 5 figure.
> The only divergence I am aware of is in the time description. The figure can't express that z= may only be used if it is preceded by an r=. It used to be that the abnf was consistent with the figure as written - permitting a z= without an r=. But that was nonsense because we have clarified that the z= only affects the immediately preceding r=.
> IMO trying to indicate that subtlety in this figure would be counter-productive, by making the figure harder to follow.

I am convinced.

How far are we from having a revision ready for IETF LC? (I’ll be glad to approve an embargo override if needed.)