Re: [MMUSIC] 4566bis outstanding issues

Paul Kyzivat <> Mon, 07 July 2014 14:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B69D1A00FE for <>; Mon, 7 Jul 2014 07:02:29 -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 7OhWyJuvOAu5 for <>; Mon, 7 Jul 2014 07:02:28 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:40]) by (Postfix) with ESMTP id 47BD71A011C for <>; Mon, 7 Jul 2014 07:02:28 -0700 (PDT)
Received: from ([]) by with comcast id PRpS1o0020bG4ec54S2T3l; Mon, 07 Jul 2014 14:02:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id PS2T1o00S3ZTu2S3PS2Tp3; Mon, 07 Jul 2014 14:02:27 +0000
Message-ID: <>
Date: Mon, 07 Jul 2014 10:02:27 -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
To: "Ali C. Begen (abegen)" <>
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=1404741747; bh=O5auDimovej4fH8QMv+yro+kARZieRYA0vkjNoxvOXE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gwaJUX2HJAp+2jK4XZLrWhBbthgvkUaeqk9ZBaUdhJuVY1Y3RVi8gRjxHI+Ss9hE/ TgXaTJmTF0bz/ZYCaFUf9MsmF4H0TsevcX+6/xVrqxUa4shCLBlPkME/vzJLqpRBC0 ZB9BpVthg8LuNeON19LTjFU1y+bbsq1J70GCXkjEBDrT6PosZ70dUxPuAg14+N262P IEHDcHsQ8p0oU4gwNNMs7Uh1UHQ4ZMaCj97GcJlL2NRPNM9OMkpMUXS3vhJM8u3fQc IjHFlSvDN2dCcGuFti2SMpcgmRlMF5AMnRC+x1lbtVwy6ElgKo33X4Au8tw1k/UBmV lCq85bgB3uF3A==
Cc: "" <>
Subject: Re: [MMUSIC] 4566bis outstanding issues
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: Mon, 07 Jul 2014 14:02:29 -0000

On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
> Hi Paul,
> OK, no one else seems to be paying attention to this. I have some comments inline and lets see whether we can reach an agreement:


I've trimmed to a few points to comment on...

>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:

>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined.
>>>> Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this.
>>> IIRC the argument against doing this is that we might get it wrong.
>>> But IMO we should do it because if we can't get it right how can we expect readers to get it right?
> I personally don't wanna take on this task. It is a tedious task and I am not such an ABNF lover to get these definitions right. If you wanna volunteer, by all means, please do so.

I'm willing to contribute to this, but won't have time until after the 
Toronto meeting. Also, I'm not intimately familiar with all of the 

I think I could probably produce a credible proposal for an ABNF 
description all of the attributes currently defined within 4566. This 
would then need to be carefully reviewed.

> Also, dozens of attributes have been defined since 4566 w/o issues so I am not seeing this as a high priority issue (or an issue at all).

Like many things, the ones defined more recently tend to be more 
rigorous than those defined longer ago. But it is uneven, and tends to 
depend upon who does it and (lately) who from the SDP directorate 
reviewed it.

>>> There is an ongoing problem when SDP extensions are defined - lack of a consistent format for defining new attributes. Many people look to 4566 for examples of how to do this, but it provides bad examples.
>>> IMO 4566bis should show the definition of all attributes in a style that complies with a recommended format for defining attributes.
>>> (Of course that implies that we could agree on such a format.)
> OK, this goes back to the issue #1. Personally, I suggest we do not define the abnfs for every sdp attribute in 4566, but then you have a good point. We can seek a format and provide a few good examples to show prospective authors.
> To do this, obviously as you said, we need to agree on that format. Has there been a proposal in the past or does anyone have a good proposal to start with?

Not a formal one. There has been some discussion about this during 
review of individual attribute definitions. My take has been that there 
is not agreement.

One question is whether the definition of a new attribute should:
1) define the full syntax of the line (starting with "a="),
2) should provide additional definitions of <attribute> (via "/=")
3) should provide additional definitions of <att-field> and <att-value>
    (via "/=")
4) provide definitions of the name and value that are consistent with
    <att-field> and <att-value> without formally extending the
    definitions of those.

Note that 4566 loosely follows (4) but gives the definitions informally 
rather than via ABNF. So it gives no guidance on how to use ABNF for 
this. A number of drafts have chosen to follow (2). Some have started to 
do (1) but I don't know of any that ended up that way.

A question I have raised is: if (2) or (3) is followed, does that mean 
that the draft doing so must be considered as "updating" 4566?

One thing that people sometimes forget when defining new attributes is 
that the syntax of the new attribute MUST also be valid when parsed by 
the "generic" attribute syntax. AFAIK there is no way in ABNF to specify 
that. I think that (4) comes closest.