Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value

Brett Tate <> Tue, 05 August 2014 17:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A99A1B2A9A for <>; Tue, 5 Aug 2014 10:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ffTRHHyBmqEn for <>; Tue, 5 Aug 2014 10:54:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3C101A0AAA for <>; Tue, 5 Aug 2014 10:54:39 -0700 (PDT)
Received: by with SMTP id ik5so2135098vcb.20 for <>; Tue, 05 Aug 2014 10:54:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=V98mO1/iWBNd4ND8sDuKD2nAm3PH6AJbR6xwWvSitHg=; b=Lc50/w/8OH3FDuVlSlGOjRtxWnEUtkat68Ry71Q6C5tJ+KD38Eqfnhrc1QZenyTikn 38kgoctU6FTwS4xkG8atBm4eR0yz5P5WHEjzyJfdR6KEhSTYQljy2Qm94YkGZwt3RxXj 1Xml6i84+zfEvB+1JIzc5oKnPO5ZsX0jDGSP0ZIIkURsp47VyKACY1RGWhXEWmuyJPtw CBdesupC5iBoAbnooM8FHcqqSHKK2QW9HrScs5qq5CVSGRuytQLU/RSbOMt/YP9bdJsI wTBhnteAgDFUFZexL1vAByanCYdVm7rSIlXVupAzn+bxOdKhk4BF5a4aKfajH3oBdUav cozg==
X-Gm-Message-State: ALoCoQnWMkBp8LLAbAvtDgWoRx08RJsg62gXwQ+eeHHKcNNvv2+Z/X6zfxmmsmBqIyMju/ERqdf3
X-Received: by with SMTP id sp8mr3520832vdb.61.1407261278812; Tue, 05 Aug 2014 10:54:38 -0700 (PDT)
From: Brett Tate <>
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGOoE2KbpIxOGP3Is83t9nwJAFlDAGQHQwOnDff9VA=
Date: Tue, 5 Aug 2014 13:54:38 -0400
Message-ID: <>
To: Paul Kyzivat <>,
Content-Type: text/plain; charset=UTF-8
Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Aug 2014 17:54:45 -0000

> Given how established SDP is, I think we need to be careful about
> *how* we clarify it, to minimize compatibility issues.

I agree.  One option is potentially to keep it invalid.  A comment
potentially could be added indicating that RFC 3611 is a reason to
accommodate the unexpected ABNF expansion (i.e. sender not updated to
comply with the errata).

> The referenced erratum says that for one particular attribute the
> colon is required even if there is no value after it. And the proposed
> fix is to only permit the colon if there is a value.

Errata 3795's proposed fix to RFC 3611 would allow the ABNF to comply with
RFC 4566.

> I think we should at least *consider* changing it to:
>     attribute =           att-field [ ":" [att-value] ]
> It would be good to hear from anybody who thinks this change
> would be troublesome.

It would cause the rfc4566bis attribute ABNF to not be backward compatible
with RFC 4566 devices.

This could cause issues with some RFC 4566 devices; however some already
accommodate it for interoperability reasons.