Re: [MMUSIC] 4566bis outstanding issues

"Ali C. Begen (abegen)" <> Fri, 13 June 2014 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E0341B2936 for <>; Fri, 13 Jun 2014 07:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eXHkiMnA4pbL for <>; Fri, 13 Jun 2014 07:32:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDE821B2935 for <>; Fri, 13 Jun 2014 07:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3934; q=dns/txt; s=iport; t=1402669954; x=1403879554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MgQv5ciSjeAsJjVL6wZ9V0TOrqO7wzCTxHzilL+cle0=; b=Jj194v51taTZKToapLep+YXTuTNWgPRCLkETCOPe/JRUJUJV4IVAlid1 7IPYHnTz0KfYa8tU8c2jNe31scWXuGfqlOMIODWNZ9MVCYC3w+EzJZt/B /ekrHXO54md3u2CiQ+tYJJC0YcUqQOErLno+JGoijCxR+Vc8ykYaCh6PY M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="333000870"
Received: from ([]) by with ESMTP; 13 Jun 2014 14:32:34 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s5DEWWrh030340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 14:32:33 GMT
Received: from ([fe80::747b:83e1:9755:d453]) by ([]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 09:32:32 -0500
From: "Ali C. Begen (abegen)" <>
To: Paul Kyzivat <>
Thread-Topic: [MMUSIC] 4566bis outstanding issues
Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgASkPUAAUom8IA=
Date: Fri, 13 Jun 2014 14:32:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Fri, 13 Jun 2014 14:32:39 -0000

Thanks Paul for the comments. Before I comment on your email, I would like other participants to say their comments, too.

If you have comments on the following issues, please speak up.

On Jun 7, 2014, at 3:59 AM, Paul Kyzivat <> wrote:

> 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.)
> 	Thanks,
> 	Paul
> _______________________________________________
> mmusic mailing list