Re: [MMUSIC] Missing IANA registrations

Hi Flemming

-----Original Message-----
From: Flemming Andreasen
Date: Friday, January 23, 2015 at 6:13 PM
To: Christian Groves, "Ali C. Begen", "<mmusic-chairs@tools.ietf.org>"
Cc: mmusic
Subject: Re: [MMUSIC] Missing IANA registrations

>
>On 1/12/15 12:26 AM, Christian Groves wrote:
>> Hello Ali,
>>
>> With regards to "X-...", RFC2848 Annex B on IANA considerations notes:
>>
>> "It should be noted that private Address Types (in section 3.4.1) have
>>    been explicitly excluded from this process, as they must be in the
>>    form of an X-Token."
>>
>> So I'm not sure whether we need to register just the "X-" part.
>>
>> Regards, Christian
>>
>> On 10/01/2015 5:53 PM, Ali C. Begen (abegen) wrote:
>>> Hi Flemming, Ari,
>>>
>>> This is an action item I had from the last meeting. Here is the 
>>> information on the missing IANA registrations. I am copying Christian 
>>> who may pitch in.
>>>
>>> On October 15th, Christian wrote:
>>> IANA registry is still missing network "TN" and address type 
>>> "RFC2543" from RFC2848.
>>>
>>> Checking the registry at 
>>> 
>>>http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-
>>>parameters-4 
>>> I see TN registered in the nettype registry. However, "RFC2543" is 
>>> missing from the addrtype registry and it should be added. RFC2848 is 
>>> also defining an address type of "X-...", for private addresses. 
>>> Should it be added to the IANA table, too?
>>>
>I think we need a note under the "TN" nettype saying the prefix "X-" is 
>reserved (per RFC 2848). Looking at 
>https://tools.ietf.org/html/draft-begen-mmusic-rfc4566bis-iana-updates-01,
> 
>I see you changed the order of the nettype and addrtype columns, which I 
>agree with (works better for this case and follows the order of the "c=" 
>line).
>
>Is the proposal simply to handle this part of the RFC 2848 registration 
>via the above draft (whether it gets included in 4566bis or proceeds 
>seperately) ? If so, I think that makes sense.

I think I can do that. Upon publication, IANA has to change the table 
formats anyway so this omission should be “fixed” automatically. 

>
>>> Later, Christian added:
>>> Some attributes that weren't registered (all these are from RFC 2848)
>>> a=phone-context
>>> a=clir
>>> a=Q763-nature
>>> a=Q763-plan
>>> a=Q763-INN
>>> a=require
>>>
>Right. Looking at RFC 2848 it seems these are all defined as both 
>session and media-level attributes. Do people agree ?

That is my take. I have not checked whether the mux draft actually 
examined them. 

>
>>> RFC 2848 also registers the PROTO values of "voice", "fax" and 
>>> "pager" to be used with the TN nettype and these are not in the IANA 
>>> proto registry.
>>>
>Yup - they should be added.
>
>Are you planning no handling all of these as part of the iana-updates 
>document, 4566bis, or do you want to have one or more of them handled by 
>the chairs (the ones that depend on SDP registry format changes are a 
>bit more challenging for the chairs to handle I think).

I think the missing attributes and PROTO values are things the chairs 
should handle directly with IANA. They have been already defined and 
specified, they are simply missing from the IANA registry.

Thanks.
-acbegen

>
>Thanks
>
>-- Flemming
>
>
>>> Thanks,
>>> -acbegen
>>>
>>>
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>
>