Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

[Christian Groves <[e-mail]>]

Hello Paul,

On 10/12/2015 3:47 PM, Paul Kyzivat wrote:
> On 12/9/15 11:04 PM, Christian Groves wrote:
>> Hello Juergen and Paul,
>>
>> The proposed text by Juergen is OK.
>>
>> Paul: Is an IANA registry the right place to capture the nuances of what
>> you're describing below? I agree that when people are defining new
>> attributes that they should consider their use with data channels, but
>> shouldn't that be documented in an RFC rather than the IANA registry?
>> People need to read the RFC rather than simply relying on the registry.
>
> It shouldn't *only* be in the IANA registry. The registry serves as an 
> index getting you to the right place, and helping you figure out what 
> you need to read.
[CNG] This is what I was getting at. It not just a registry update we're 
talking about there's a much more significant document explaining the 
use of the attributes with dcsa.
>
> Won't it be confusing if the registry covers usage of attributes a 
> session, media, and source level but doesn't cover their use in dcsa?
[CNG] The registry is a short cut. Even if the registry mentions that 
its a source attribute, a person still needs to read the RFC to see how 
it works. I see that people want to use an attribute for its 
functionality not because of what the IANA reg says.
>
> If this isn't needed for dcsa, then by the same logic we ought to 
> strip out that other information, and reduce the table to contain only 
> references to documents.
>
>> Also isn't the consequence of what you're suggesting is that another
>> draft similar to draft-ietf-mmusic-sdp-mux-attributes would have to be
>> completed in order to populate the IANA registry field that you're
>> proposing?
>
> Perhaps. We'd have to discuss the best way. It may be that most of the 
> existing attributes can be covered with a couple of default rules, and 
> maybe a few exceptions.
[CNG] Still the analysis of each attribute would need to be done and 
documented to get to the few rules. I not completely against doing this, 
I'm just keen to get this work finished and this will just delay things.

Regards, Christian

>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>
>> On 10/12/2015 2:43 AM, Paul Kyzivat wrote:
>>> Juergen and others,
>>>
>>> What you have below is a good start.
>>>
>>> I still think we need to at least specify how dcsa impacts IANA
>>> registration of attributes.
>>>
>>> The attribute registration is (going to be) updated so that there is
>>> one table containing all attributes, with fields indicating for each
>>> attribute whether it can be used at session level, media level, or
>>> source level.
>>>
>>> Now consider an attribute usable at media and/or source level:
>>>
>>> It *might* *also* be usable with dcsa, or it might not. That will at
>>> least in part be determined by whether the protocol that it applies to
>>> can run over a data channel.
>>>
>>> There was a suggestion (Keith?) that media level attributes be
>>> implicitly allowed with dcsa if the protocol they apply to is defined
>>> over a data channel. I find that plausible. But then the instructions
>>> for registration ought to say that. Also, if there can be exceptions
>>> (attributes that *can't* be used with dcsa even when the protocol is
>>> defined over data channel) then there should be a way to register that.
>>>
>>> Source level attributes add another complication. They only apply over
>>> RTP. For now, RTP isn't defined over a data channel. (Though in
>>> principle it *could* be.) If it were, then I suppose the ussage would
>>> have to be 'a=dcsa nn source ...'. I don't think we need to deal with
>>> that right now.
>>>
>>> And then there is the possibility of new attributes being defined that
>>> can be used *only* with dcsa, not directly at media level:
>>>
>>> If this is because the protocol is only defined to run over a data
>>> channel, then it could possibly be registered as a media level
>>> attribute (which is then allowed by default with dcsa). If the
>>> protocol were ever defined over another transport the sdp would be
>>> ready for it.
>>>
>>> But if, for some reason, the protocol can run over a data channel and
>>> also over some other transport, but for some reason a particular
>>> attribute only applies with data channels, or only applies without
>>> data channels, then there ought to be a way to record that in the
>>> registry.
>>>
>>> The worst case is for every spec that defines an attribute to pick its
>>> own way to specify all this, and for there to be no hint in the iana
>>> registry.
>>>
>>> IMO it is still better for the iana registry to be given another field
>>> to indicate applicability with data channels.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> On 12/9/15 8:24 AM, Juergen Stoetzer-Bradler wrote:
>>>> Paul, Christian, Keith,
>>>>
>>>> Would propose to add following two new paragraphs to the end of 
>>>> current
>>>> section 5.1.2.1 (dcsa Attribute) in order to more clearly describe the
>>>> relationship of a subprotocol's attribute and the subprotocol's
>>>> transport protocol, especially data channel.
>>>>
>>>>
>>>>     It is assumed that in general the usages of subprotocol related
>>>> media
>>>>     level attributes are independent from the subprotocol's transport
>>>>     protocol.  Such transport protocol independent subprotocol related
>>>>     attributes are used in the same way as defined in the original
>>>>     subprotocol specification, also if the subprotocol is transported
>>>>     over a data channel and if the attribute is correspondingly 
>>>> embedded
>>>>     in a "a=dcsa" attribute.
>>>>
>>>>     There may be cases, where the usage of a subprotocol related media
>>>>     level attribute depends on the subprotocol's transport 
>>>> protocol.  In
>>>>     such cases the subprotocol related usage of the attribute is
>>>> expected
>>>>     to be described for the data channel transport, e.g. in an 
>>>> extension
>>>>     of the original subprotocol specification.
>>>>
>>>>
>>>> Section 5.1.2 already explicitly mentions that (subprotocol related)
>>>> media level attributes may follow a data channel declaration (the
>>>> a=dcmap line). Thus the restriction to subprotocol related media level
>>>> attributes only  seems to be covered already.
>>>>
>>>> Thanks,
>>>> Juergen
>>>>
>>>>
>>>> On 01.12.2015 02:12, DRAGE, Keith (Keith) wrote:
>>>>> I think we need to be a little bit careful here.
>>>>>
>>>>> In a large number of cases, the use of the attribute will be 
>>>>> unaltered
>>>>> by the transport that is being used, and I do not think we should 
>>>>> have
>>>>> a need of saying anything if this is the case - it should be the
>>>>> default.
>>>>>
>>>>> So for example for MSRP, there are a number of attributes associated
>>>>> with MSRP - for file transfer and so on, and as far as I can tell,
>>>>> they are used when MSRP is sent over a data channel in exactly the
>>>>> same way as when MSRP is sent over TCP or SCTP. We don't write 
>>>>> special
>>>>> rules for TCP, so why write special rules for datachannel.
>>>>>
>>>>> We do need to identify how we document any special cases, and yes 
>>>>> when
>>>>> we find them, drafts like the msrp draft are the way to do that.
>>>>>
>>>>> Additionally, if we find when defining a new attribute, that it is
>>>>> inappropriate for datachannel usage in some way, then we can write
>>>>> that in the defining specification for the new attribute (although I
>>>>> suspect in this case it will be inappropriate to other transports 
>>>>> than
>>>>> just datachannel).
>>>>>
>>>>> I do assume this entire discussion is limited to attributes that can
>>>>> be applied to media lines. We might find it useful to say that in the
>>>>> general draft, if we have not done so already.
>>>>>
>>>>> Regards
>>>>>
>>>>> Keith
>>>>>
>>>>> -----Original Message-----
>>>>> From: mmusic [mailto:[e-mail]] On Behalf Of Christian
>>>>> Groves
>>>>> Sent: 01 December 2015 00:53
>>>>> To: [e-mail]
>>>>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
>>>>>
>>>>> Hello Paul,
>>>>>
>>>>> I actually meant to post the reply to the list, sorry for the
>>>>> confusion.
>>>>>
>>>>> I do understand your concerns. For multiplexing it makes sense to
>>>>> check all the existing attributes to see whether they're applicable
>>>>> due to the fact that quite alot may be used when multiplexing occurs.
>>>>> I think the data channel usage is quite a bit more narrow in scope.
>>>>>
>>>>> Whilst this draft does introduce a general purpose mechanism the
>>>>> actual use of the dcsa is being defined by other drafts. E.g.
>>>>> draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what
>>>>> happens when both a=setup and a=dcsa:setup are present. msrp-cema is
>>>>> another one discussed, etc.
>>>>>
>>>>> I think you need to understand the application protocol being carried
>>>>> in a data channel before you can say whether particular attributes
>>>>> should be carried in dcsa and what that actually means. Going through
>>>>> the IANA registry wouldn't be trivial and unless the attributes are
>>>>> put in context of an application protocol I don't think it will be
>>>>> terribly helpful.
>>>>>
>>>>> draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate 
>>>>> that
>>>>> the dsca parameters follow the procedures defined in the subprotocol
>>>>> specific documents. Maybe we could strengthen this to indicate that
>>>>> the use of dsca by an application protocol should be documented in a
>>>>> specification?
>>>>>
>>>>>
>>>>> Regards, Christian
>>>>>
>>>>> On 1/12/2015 11:30 AM, Paul Kyzivat wrote:
>>>>>> Christian,
>>>>>>
>>>>>> On 11/30/15 6:45 PM, Christian Groves wrote:
>>>>>>> Is this level of detail really needed? There are several drafts for
>>>>>>> CLUE, MSRP and BFCP related to the use of this sdpneg mechanism. 
>>>>>>> E.g.
>>>>>>> CLUE doesn't use dcsa and MSRP provides guidelines on the use of
>>>>>>> dcsa.
>>>>>>>
>>>>>>> Can't we just follow the principle that the use of the dcsa 
>>>>>>> attribute
>>>>>>> should be detailed in a specification and leave it at that? I'm not
>>>>>>> sure what we gain by analysing every existing attribute and forcing
>>>>>>> every new attribute to do this analyses when the set of possible
>>>>>>> parameters in likely to be very small.
>>>>>> I guess it is arguable both ways. Originally there was only session
>>>>>> level and media level. That was always supposed to be identified, 
>>>>>> but
>>>>>> it wasn't always followed.
>>>>>>
>>>>>> Then we got source level. That has complicated the registry and the
>>>>>> usage. I am not convinced that two SDP experts would come up with 
>>>>>> the
>>>>>> same list of which attributes can be used at source level.
>>>>>>
>>>>>> The dcsa attribute becomes the 4th "level" for attributes. It at 
>>>>>> least
>>>>>> makes sense to me that it ought to be managed analogously to the
>>>>>> source attribute. But I agree it doesn't provide the same degree of
>>>>>> confusion as the others. It only makes sense if the usage the
>>>>>> attribute applies to works over a data channel. And that should be
>>>>>> known to whatever is processing the SDP.
>>>>>>
>>>>>> I see this was a private message. Why don't you repost it on the 
>>>>>> list
>>>>>> and lets see what other people think? (Feel free to repost this 
>>>>>> reply
>>>>>> if you wish.)
>>>>>>
>>>>>>      Thanks,
>>>>>>      Paul
>>>>>>
>>>>>>> Regards, Christian
>>>>>>>
>>>>>>> On 1/12/2015 2:36 AM, Paul Kyzivat wrote:
>>>>>>>> One thing occurred to me that we may have forgotten about:
>>>>>>>>
>>>>>>>> This draft introduces the dcsa attribute, which allows other
>>>>>>>> attributes to be used in this new scope. It notes that not all
>>>>>>>> attributes are suitable for use this way.
>>>>>>>>
>>>>>>>> ISTM that in the future other attribute definitions should include
>>>>>>>> an indication of whether they can be used with dcsa, and the IANA
>>>>>>>> registration of the attribute ought to include this. And then 
>>>>>>>> there
>>>>>>>> is a need to update the iana registry for all the existing
>>>>>>>> attributes.
>>>>>>>>
>>>>>>>>      Thanks,
>>>>>>>>      Paul
>>>>>>>>
>>>>>>>> On 11/25/15 4:52 AM, Bo Burman wrote:
>>>>>>>>> This is to announce a 4 week Working Group Last Call for
>>>>>>>>>
>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg-06
>>>>>>>>>
>>>>>>>>> as proposed standard.
>>>>>>>>>
>>>>>>>>> Please review and provide any comments you may have on the 
>>>>>>>>> document
>>>>>>>>> by Wednesday, December 23, 2015. Comments should be sent to the
>>>>>>>>> document authors and the MMUSIC WG list. If you review the 
>>>>>>>>> document
>>>>>>>>> but do not have any comments, please send a note to that 
>>>>>>>>> effect as
>>>>>>>>> well.
>>>>>>>>>
>>>>>>>>> Please also forward this WGLC call to any other interested 
>>>>>>>>> parties
>>>>>>>>> who may be able to review the draft, asking them to also direct
>>>>>>>>> their comments to the authors and the list as above.
>>>>>>>>>
>>>>>>>>> Thank you!
>>>>>>>>>
>>>>>>>>>           Bo Burman (MMUSIC co-chair)
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>