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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 05 August 2014 15:12 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9821B2890 for <mmusic@ietfa.amsl.com>; Tue, 5 Aug 2014 08:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C23b2akRLacj for <mmusic@ietfa.amsl.com>; Tue, 5 Aug 2014 08:12:49 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0891B2873 for <mmusic@ietf.org>; Tue, 5 Aug 2014 08:12:37 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id b0cC1o0041HzFnQ563Cc66; Tue, 05 Aug 2014 15:12:36 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id b3Cc1o00K3ZTu2S3a3CcCL; Tue, 05 Aug 2014 15:12:36 +0000
Message-ID: <53E0F464.3080600@alum.mit.edu>
Date: Tue, 05 Aug 2014 11:12:36 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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
To: mmusic@ietf.org
References: <b0f1449ce327d51a1a6e947df246533f@mail.gmail.com>
In-Reply-To: <b0f1449ce327d51a1a6e947df246533f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407251556; bh=djyZUC8DiDomDKVYACa/eoImpNMlwsiDYugfFvnCAuY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fvluUXP+5Wa3fafgUQshVpoDvv4VHBn2zEJZgLPbFduwxtYYfQ4FCo9zzSgOFgMCM T97QfzQFwAdG/xIs2dFtCGn5gldmIrL8oUpHY57XyuGYfjnc+tOv4ozyiz+BKjsrL3 y8pqzQ6BMYxeMT3ZuHENUsOQfBGkdX4ylEyIcWsAqNi2aCZVtg8+Rt032ZrQ0Pa++x U4987/BY2u+BI0qUSgKEq9BnSNTpxUQhQNk4PfzQHg/82NGym+tvwrpL1fJHOMPOJw fCUtet915uOPgrm/OgxnDc8ufi75fLpHXKb0Qd5Md6jdgpdQJJfqib7qEHGCHEwuCM pLawSjZV+rpYg==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tbCu2CbWGZhuXuh5Sj_YqQJg5mo
Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 05 Aug 2014 15:12:51 -0000

On 8/5/14 10:12 AM, Brett Tate wrote:
> Hi,
>
> Draft-ietf-mmusic-rfc4566bis-10 section 5.13 discusses two formats of
> attribute fields.  However, it doesn't appear to clearly indicate the
> validity/invalidity of colon without a value.
>
> Is an attribute such as "a=rtcp-xr:" valid?  For instance, RFC 3611
> indicates that it is valid; however errata 3795 indicates that it
> potentially shouldn't be valid.
>
> Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify
> the topic?

Yes, it probably should.

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

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.

Another possibility would be to make the colon optional if there is no 
value.

I am inclined to think that the *generic* syntax for attributes ought to 
work that way, in order to be most forgiving. The current syntax is:

    attribute =           (att-field ":" att-value) / att-field

    att-field =           token

    att-value =           byte-string

    byte-string =         1*(%x01-09/%x0B-0C/%x0E-FF)
                          ;any byte except NUL, CR, or LF

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.

Possibly the syntax of individual attributes can continue to be more 
restrictive. That will certainly be the case until/unless they are all 
updated.

In principle we need to confront *that* for each of the attributes 
defined in 4566 if we are going to give ABNF for each of them. But it is 
only of concern for an attribute where the value is optional. I don't 
think that is the case for any attributes defined in 4566.

	Thanks,
	Paul