Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

["Roni Even (A)" <[e-mail]>]

Hi Keith,
Thanks, so I understand from the document that dcsa has different set of attributes which will require to create a registry in section 9.3? 

Roni

-----Original Message-----
From: mmusic [mailto:[e-mail]] On Behalf Of Keith Drage
Sent: Friday, October 19, 2018 12:24 AM
To: [e-mail]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

I vaguely remember that there was thinking that the set of attributes that can be used with dcsa is not the same as the set of attributes that are defined for the a= level. In general, that applied that all generally defined attributes cannot be be used with dcsa, but I think there was also a thought that it could be the other way round.

I think there was a thought that attributes used in dcsa should have that usage explicitly described, but not sure how that got carried through.

Keith

On 08-Oct-18 6:43 PM, Paul Kyzivat wrote:
> On 10/8/18 7:57 AM, Roni Even (A) wrote:
>> Hi,
>>
>> I updated the document in -21 that will be available based on the AD 
>> review.
>>
>> I have an open issue from the AD review is
>>
>> "§9.3, first paragraph: " SDP attributes that are defined for use at 
>> the dcsa
>>
>>     usage level only SHALL use the dcsa usage level when registering 
>> the
>>
>>     attribute."
>>
>> I don't understand this sentence. Consider a MUST NOT/SHALL NOT 
>> construction."
>
> I agree this is a little odd. In particular it seems to assume that 
> when new attributes are defined for use with dcsa that they will
> *only* be used with dcsa, while existing attributes may have their 
> definitions extended for use with dcsa.
>
> Also, I've lost track of the path to getting att field stuff in iana 
> cleaned up. I'm sure there was intent to do so, but it currently still 
> isn't. Specifically:
>
> Right now there are separate registries for: session level only, media 
> level only, both session and media level, source level, and unknown.
> Adding dcsa level to that structure would presumably be analogous but 
> parallel to source level. The "both" structure is weird in this 
> context. It seems that in this structure it would simply make sense to 
> list an attribute in every category it applies to, which means in both 
> session and media if both apply.
>
> But this is all messy to manage and to look things up in. It would be 
> better to simply have a single registry with an entry for each 
> attribute, and a field in that to enumerate the contexts in which it 
> is valid - session, media, source, and dcsa.
>
> As I said, I have some memory that there was a plan to make this 
> change. But I don't recall what that plan was attached to. Maybe it 
> was with the changes for bundle and mux-attributes. (The 
> mux-attributes draft seems to assume this change has been made, but I 
> don't see actions to cause this change in either it or bundle.)
>
>> When trying to understand  I am now wondering what is the IANA action 
>> in section 9.3 
>> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-20#section-9.3.
>> is it really needed? I am not sure that the proposal to update the 
>> IANA sdp att-field is the right way and there is no usage level in 
>> the mentioned registries
>>
>> Will it be better if in section 5.2.1 we will say that new attributes 
>> that are for dcsa usage should mention it in the document relevant 
>> document ( at least this is what section 5.2.1 say now)
>
> Given what is in the registry now, this would be very misleading.
>
> I guess another way to go would be to remove all mention of level from 
> the registry, just enumerate the attributes and the documents that 
> define them, and count on the documents to fill in the detail. But 
> then we would have to verify that every single one of them has enough 
> definition in the corresponding document. And I think people expect 
> more in the registry.
>
>     Thanks,
>     Paul
>
>> Roni Even
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic