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

Brett Tate <brett@broadsoft.com> Tue, 05 August 2014 17:10 UTC

Return-Path: <brett@broadsoft.com>
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 321111A0055 for <mmusic@ietfa.amsl.com>; Tue, 5 Aug 2014 10:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS--ln8i9eOi for <mmusic@ietfa.amsl.com>; Tue, 5 Aug 2014 10:10:13 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542FC1A03E7 for <mmusic@ietf.org>; Tue, 5 Aug 2014 10:10:13 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so2065758vcb.1 for <mmusic@ietf.org>; Tue, 05 Aug 2014 10:10:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=A07N6RoNy253DZbPO8un8+fbJnvrqUtPsTTCs1rLlX4=; b=h5IyAAKxc4OQOYE+tAvCLAvcUx24aafTbDBsCLOZhSoBkbXpPcll8V/q+AxJFeDDnv gWWabq3MuxmkmixMO4FuCo+JZrfyl7wNTXU6Bi8Ggh7zyIdcBUnuNM5pVdsLw3+w/Y61 /De4HsYJ+xTYecR1vXwPlPzYZEiykn70rq27gw7MXyORc9CWca4V+tddi+RCQ9eScSdz dOxoo4Wngxv7tX/AP4zdSCiCgOA7CM9lzeGw00NMVuUXq0NlR8Slp1c0IDbC2H19hOpA S+X+l3S3IvEIKEq5FmwCs5b0lZ0bmJY245prs7l2Z92UyJGWylUMe0h1S1QSv6xhBk9G 9FcQ==
X-Gm-Message-State: ALoCoQnAVVn8kUJ62PReOG26shq1DYTaIUnvZKHSIb/jAtb1mI2k2QBshRvm550FapPyK4UyGzTf
X-Received: by 10.52.138.175 with SMTP id qr15mr2382055vdb.94.1407258268763; Tue, 05 Aug 2014 10:04:28 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
References: <b0f1449ce327d51a1a6e947df246533f@mail.gmail.com> <B2202240-B887-4E76-8D36-C3C15A95846F@cisco.com>
In-Reply-To: <B2202240-B887-4E76-8D36-C3C15A95846F@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGOoE2KbpIxOGP3Is83t9nwJAFlDAKUUI93nC+x/AA=
Date: Tue, 5 Aug 2014 13:04:28 -0400
Message-ID: <bddd6fb33eb722d32311a16981f5c4cf@mail.gmail.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, mmusic@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/T50hHJh4o5F1c-tqpW33JueME4g
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 17:10:15 -0000

Thanks for the response.  I agree with your RFC 4566 interpretation.  RFC
3211 did not conform to RFC 2327 (or RFC 4566) when introducing the
rtcp-xr attribute.  Thus I guess that it is just a matter of deciding how
best to remedy the situation.  Since the rfc4566bis ABNF is explicit, one
option is potentially to recommend that errata 3795 be accepted and leave
rfc4566bis as-is.

RFC 4566:

attribute-fields =    *(%x61 "=" attribute CRLF)
   attribute =           (att-field ":" att-value) / att-field
   att-field =           token
   att-value =           byte-string
   token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                         / %x41-5A / %x5E-7E
   token =               1*(token-char)
   byte-string =         1*(%x01-09/%x0B-0C/%x0E-FF)
                         ;any byte except NUL, CR, or LF

RFC 2327:

attribute-fields =    *("a=" attribute CRLF)
   attribute =           (att-field ":" att-value) | att-field
   att-field =           1*(alpha-numeric)
   att-value =           byte-string
   byte-string =         1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
                         ;any byte except NUL, CR or LF

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ali C. Begen
(abegen)
Sent: Tuesday, August 05, 2014 10:42 AM
To: Brett Tate
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have
a null value


On Aug 5, 2014, at 5:12 PM, Brett Tate <brett@broadsoft.com> 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.

It says there are two forms. since "a=<attribute>:" is not listed as a
form, I guess it simply means it is not valid usage.

>
> Is an attribute such as "a=rtcp-xr:" valid?

Not based on my knowledge.

> For instance, RFC 3611
> indicates that it is valid; however errata 3795 indicates that it
> potentially shouldn't be valid.

I am not sure why that errate is not verified. To me, 3611 has an abnf
syntax error that should be fixed.

>
> Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to
> clarify the topic?

We can add a sentence to ban such a usage but now I wonder whether they
have been attributes defined in that form in the past. Is anyone aware of
any?

-acbegen