Re: [MMUSIC] 4566bis outstanding issues

"Ali C. Begen (abegen)" <> Mon, 07 July 2014 08:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DDFE51B279F for <>; Mon, 7 Jul 2014 01:07:10 -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 EM8PBqMCUCtY for <>; Mon, 7 Jul 2014 01:07:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8FDF91B279D for <>; Mon, 7 Jul 2014 01:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5154; q=dns/txt; s=iport; t=1404720429; x=1405930029; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=StfnKrIVw4fGqxi/aIo131cNiary2GuKTVVWQTHw8vo=; b=gINRYCgzaIri7xR9iHxZ8QUhrbkcbFyiO4KtUPjj5JoeFicXJJ/olEX8 DGVRe946giYirwvPcZ8ymmw34PW12NLzchw1FBh4vAMSGVAn6LvZoLFZp GCapuwwdoj6R1ufJ2cdt1yr5dngV+jTr/x2bRf9qFXV4q3A8xXUEqvoeb 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,616,1400025600"; d="scan'208";a="58750644"
Received: from ([]) by with ESMTP; 07 Jul 2014 08:07:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s67876Es007709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 08:07:06 GMT
Received: from ([fe80::747b:83e1:9755:d453]) by ([]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 03:07:06 -0500
From: "Ali C. Begen (abegen)" <>
To: Paul Kyzivat <>
Thread-Topic: [MMUSIC] 4566bis outstanding issues
Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgASkPUAAUom8IAEqYhwgA==
Date: Mon, 7 Jul 2014 08:07:05 +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: Mon, 07 Jul 2014 08:07:11 -0000

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:

>> 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?

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.

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

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

You did not comment on this but this is an easy fix so I will do this.


Is this (and all other IANA related issues) supposed to be part of the 4566bis document or a separate document? A separate document may keep 4566bis clean and nice IMO.

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

I will also take care of this along with issue #2.

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

I will 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.

OK, this will be taken care of along with issues #2 and #3.

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

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?


>> 	Thanks,
>> 	Paul
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list