Re: [MMUSIC] 4566bis outstanding issues

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 <pkyzivat@alum.mit.edu> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic