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

Paul Kyzivat <> Tue, 05 August 2014 18:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0B7621B2AAF for <>; Tue, 5 Aug 2014 11:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XmG1cWVK9X13 for <>; Tue, 5 Aug 2014 11:06:22 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:24]) by (Postfix) with ESMTP id C40161A00D2 for <>; Tue, 5 Aug 2014 11:06:10 -0700 (PDT)
Received: from ([]) by with comcast id b4dv1o0091ap0As5166ASU; Tue, 05 Aug 2014 18:06:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id b66A1o0083ZTu2S3i66AH7; Tue, 05 Aug 2014 18:06:10 +0000
Message-ID: <>
Date: Tue, 05 Aug 2014 14:06:10 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1407261970; bh=ZLbhy2l/fMOgBexhOnldTfoEcuz+Ird2Ks1BSFJKJd4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mmul6og8po09PiLuDPTotnfG3c0HLpOlENZ+3pPGHhwW5Dyx4HEVZG6u5NYuB/5co PpBPMIm/YuYddMjyTs/JbyOvZvd4S3zGl/WQf3jAghaXw5wTKIHY5PKxkyrfaRAf5/ /BCG1i0+B00EbrkwB+CPCNbGJXwYi/zdsLHyCK+NMuZ3Dpy7VoirjM2OEYSMBbPZ19 7RgRA7t3K0hjmx/E9SBDh17UvGcisQB3MzaLA8GOheWUbd1bntbUqbq4ljAyYeYUgX sjHqCo/PlmrKkSjVCmPocNaQAlSMqkA/gMEXjWlWlP0sPGwGc9yh0S1qcc1I5BIO09 +mXgKUjyTZUoA==
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 18:06:23 -0000

On 8/5/14 1:54 PM, Brett Tate wrote:
>> 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.

In practice this is only an issue for attributes that are specified to 
be meaningful both with and without a value. We could investigate the 
current population to see how many fit into that category. I suspect it 
is very few.

My thought in proposing the change was to encourage those ignoring 
attributes they don't understand to also ignore those with a colon and 
no value. But we don't want to encourage people to do that. If we only 
have one case that called for this usage, then maybe we just deal with 
it there.