Re: [MMUSIC] 4566bis outstanding issues

Paul Kyzivat <> Sat, 07 June 2014 00:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AC9FF1A0268 for <>; Fri, 6 Jun 2014 17:59:22 -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 0Z4MZwD49pep for <>; Fri, 6 Jun 2014 17:59:21 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:80]) by (Postfix) with ESMTP id B458C1A0264 for <>; Fri, 6 Jun 2014 17:59:21 -0700 (PDT)
Received: from ([]) by with comcast id BCyA1o0031ei1Bg58CzEkt; Sat, 07 Jun 2014 00:59:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id BCzE1o0083ZTu2S3kCzEdZ; Sat, 07 Jun 2014 00:59:14 +0000
Message-ID: <>
Date: Fri, 06 Jun 2014 20:59:14 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.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=1402102754; bh=qCufaHJemPhMM2Iyd/QtZctqPPNJnRItC7qU3to8sA4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vA9Ox2j8M9B8kdmW/KuKhG3k64md8C0hqU338Yy2312L6vBMZboAHK0mi5aXCMTdB 5ANj7aMqKCUsPxszPH6ifT+RJI+nBo+dgXJLmrlA7rJ2ttYVlHd8hwEWDuRxY/4Rd9 wAVl5L5KS82pepqvrJjC3p1q2FJLm+3J7hz4tdenIOQWzJZi5kxiFr2OFR8oBHVwft 0Bow6uM0MylblTFkAlLh9aEpVPmc/c3kRlGimbq0iccJDNYF0lDtOVAxSrpIhmsi2Y Hj+NBbOw0XIS3bCd3bH1aU9noizuvmP7VJiFyIJT+3EpXWCKbSE1mDdS4LwHCF3d7g qp+Cg7xvO/3Og==
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: Sat, 07 Jun 2014 00:59:22 -0000

Hi Ali,

It is great that you are working on this!!!

On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:
> Hi everyone
> I went thru the mail archives since 01/2012 and tried to list the issues that seem to be unresolved at this point. I can put them in the tracker but I wanna provide a summary first.
> For some of the issues below, no solution has been proposed. For the rest, there was no agreement on what to do. Here it goes:
> 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?

> 2) 4566bis should update the format of the IANA registries to reflect the dependency between addrtype and net type.
> Comments: There does not seem an agreement on this but it looks to be an easy fix.
> 3) Section 8.2.4 defines the IANA registry and populates it with the attributes defined in 4566, however, Section 8.2.4 does not specify the name or format of the table.
> Comments: No text has been proposed or agreed but seems to be an easy fix if we wanna do this.
> 4) 4566bis does not make the registration of new network or address types mandatory. Section 8.2.6 and 8.2.7.
> Comments: If we agree that this should be mandatory, we can change the text.

IMO we should make this change

> 5) Source-level attributes defined in 5576. Should these attributes be included in the same table structure in the IANA registry?
> Comments: This seems to be an organizational issue rather than a technical issue. If we agree we need this, we can take on this as well.

Yes, but IMO an important one. The current registries are hard to read, 
and easy to get wrong when adding new attributes.

Also, we ought to have templates for what goes into the IANA 
consideration section when defining new attributes, and that template 
would be best in this document.

> 6) Should we add a new column called "registered network type" in the addrtype table in the IANA registry as not all address types are applicable for all network types?
> Comments: This is also an IANA fix that we can do in this bis document or in a separate document (with all the other IANA registry changes).

Similar comment to the one just above.

> These are the issues I was able to identify. There is one more thing related to ICE and I sent an email about this to Marc Petit-Huguenin. As soon as he responds and depending on his answer, I might add one more issue.
> If there are things I missed, please let me know. The chairs and editors would like to close these issues and finalize 4566bis soon.

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.)